4 ms·

The killer use case I see for PAKEs is that they verify not only that the client has the password, but also the server. When modern browsers trust 150 Certific

The killer use case I see for PAKEs is that they verify not only that the client has the password, but also the server. When modern browsers trust 150 Certificate Authorities [0] (and the untold subordinate/wildcard certs that were further issued by them), it's reassuring to know that I've verified that the server actually had my password (or a derivative), which makes it even harder to phish or impersonate a server with a stolen/malicious signed TLS key (this is all assuming the browser has a special non-spoofable dialog when authenticating via a PAKE). For example, picture all of the people who have lost their banking passwords to phishing sites. If PAKEs were used, then the attacker gets nothing except a single guess at the password. If the attacker already knew the user's password, then the user already lost. [0]: https://wiki.mozilla.org/CA/Included_Certificates https://wiki.mozilla.org/CA/Included_Certificates

tptacek 8y ago
This is true, but can't you address the same problem without a PAKE by simply remembering the server certificate public key (or at least its issuing CA)? Remember: browsers don't support PAKEs now. So consider: what's the least required mechanism to solve the problem you're posing? I agree the PAKE theoretically does a better job on this problem. But does it do that job so much better as to justify its inclusion in a protocol?
- caf 8y ago
  The difference seems to be that server certificate public keys and CAs will change, so browsers will have to include an "Ignore this change?" prompt, which means a certain number of people will click it. On the other hand, a PAKE failure due to the server not having its half of the authentication data is not possible to ignore, so people will be forced to get it right.
  - tptacek 8y ago
    But certificate authentication precedes user authentication, so the people who don't click it are sufficient to detect misissuance and kill the offending CA. You'd rather not have the problem at all, but if every exploit burns an entire CA, that's not the worst place to be.
    - eridius 8y ago
      What happens if the CA change was an intentional change by the server and not the result of an attack?
      - tptacek 8y ago
        In that very rare case, you freak out over nothing.
    - tialaramex 8y ago
      I think I generally sympathise with this way of thinking about the value of a PAKE here, and you're right that only one person has to see a smoking gun - but just to be quite clear here on how fragile such manual checks would be: The certificate used for the HTTP transaction where your credentials are submitted may be completely different from the one used to present the web form you filled them into. A sneaky bad guy can let you talk to the real Bob for every single HTTP transaction aside from the one they want to capture, and intercede just for that single case, then drop back out silently, leaving you talking to Bob directly as before. The web browser's own checks (including matching the FQDN against the certificate) run every single time - if they spot Eve taking Bob's place they'll freak out, but any human checks like "Look at the certificate in Certainly Something" (the nice certificate view for Firefox) only happen when a human gets to intervene which may not happen at all at key moments. Imagine you go to https://www.example.com/ https://www.example.com/ to log in It presents a form with a submission target of login.example.com, your browser does a POST to https://login.example.com/login.form/ https://login.example.com/login.form/ and it gets back a 30x redirect to https://www.example.com/welcome/ https://www.example.com/welcome/ When did you get to examine that certificate for login.example.com? The answer in every browser I've seen is not at all, because it responded with a 30x so the page never finished and displayed.
tialaramex 8y ago
> When modern browsers trust 150 Certificate Authorities That's not what the link you provided shows. It lists 150 CA roots. 20 of those roots lack a "websites" trust bit, which means the web browser does not trust those roots (Mozilla also has an email client even if it's not much loved) Furthermore, the 130 of those roots that are trusted in a web browser are operated by only 52 distinct Certificate Authorities. CAs operate several roots either because of business consolidation or segmentation, for example DigiCert operates 23 of the web trusted CAs you linked because they purchased Symantec's business in 2017 and are in the process of replacing Symantec's soon-to-be-untrusted hierarchy. It's very strange to merge subordinates and wildcards which aren't the same kind of thing at all. Unconstrained subordinates are, in fact, tallied by Mozilla and they're on the adjacent page: https://wiki.mozilla.org/CA/Intermediate_Certificates https://wiki.mozilla.org/CA/Intermediate_Certificates The vast majority of these intermediates are just for issuance and remain entirely under both physical control and legal authority of the CA, so they make no difference to the trust picture they just reduce the exposure if things go wrong.

tptacek 8y ago

This is true, but can't you address the same problem without a PAKE by simply remembering the server certificate public key (or at least its issuing CA)? Remember: browsers don't support PAKEs now. So consider: what's the least required mechanism to solve the problem you're posing? I agree the PAKE theoretically does a better job on this problem. But does it do that job so much better as to justify its inclusion in a protocol?

caf 8y ago
The difference seems to be that server certificate public keys and CAs will change, so browsers will have to include an "Ignore this change?" prompt, which means a certain number of people will click it. On the other hand, a PAKE failure due to the server not having its half of the authentication data is not possible to ignore, so people will be forced to get it right.
- tptacek 8y ago
  But certificate authentication precedes user authentication, so the people who don't click it are sufficient to detect misissuance and kill the offending CA. You'd rather not have the problem at all, but if every exploit burns an entire CA, that's not the worst place to be.
  - eridius 8y ago
    What happens if the CA change was an intentional change by the server and not the result of an attack?
    - tptacek 8y ago
      In that very rare case, you freak out over nothing.
  - tialaramex 8y ago
    I think I generally sympathise with this way of thinking about the value of a PAKE here, and you're right that only one person has to see a smoking gun - but just to be quite clear here on how fragile such manual checks would be: The certificate used for the HTTP transaction where your credentials are submitted may be completely different from the one used to present the web form you filled them into. A sneaky bad guy can let you talk to the real Bob for every single HTTP transaction aside from the one they want to capture, and intercede just for that single case, then drop back out silently, leaving you talking to Bob directly as before. The web browser's own checks (including matching the FQDN against the certificate) run every single time - if they spot Eve taking Bob's place they'll freak out, but any human checks like "Look at the certificate in Certainly Something" (the nice certificate view for Firefox) only happen when a human gets to intervene which may not happen at all at key moments. Imagine you go to https://www.example.com/ https://www.example.com/ to log in It presents a form with a submission target of login.example.com, your browser does a POST to https://login.example.com/login.form/ https://login.example.com/login.form/ and it gets back a 30x redirect to https://www.example.com/welcome/ https://www.example.com/welcome/ When did you get to examine that certificate for login.example.com? The answer in every browser I've seen is not at all, because it responded with a 30x so the page never finished and displayed.

tialaramex 8y ago

> When modern browsers trust 150 Certificate Authorities That's not what the link you provided shows. It lists 150 CA roots. 20 of those roots lack a "websites" trust bit, which means the web browser does not trust those roots (Mozilla also has an email client even if it's not much loved) Furthermore, the 130 of those roots that are trusted in a web browser are operated by only 52 distinct Certificate Authorities. CAs operate several roots either because of business consolidation or segmentation, for example DigiCert operates 23 of the web trusted CAs you linked because they purchased Symantec's business in 2017 and are in the process of replacing Symantec's soon-to-be-untrusted hierarchy. It's very strange to merge subordinates and wildcards which aren't the same kind of thing at all. Unconstrained subordinates are, in fact, tallied by Mozilla and they're on the adjacent page: https://wiki.mozilla.org/CA/Intermediate_Certificates https://wiki.mozilla.org/CA/Intermediate_Certificates The vast majority of these intermediates are just for issuance and remain entirely under both physical control and legal authority of the CA, so they make no difference to the trust picture they just reduce the exposure if things go wrong.