4 ms·

I see it useful as part a layered strategy: X.509 certificates establish the authenticity of the server for that domain, while the SRP/PAKE would establish the

I see it useful as part a layered strategy: X.509 certificates establish the authenticity of the server for that domain, while the SRP/PAKE would establish the authenticity of the legal entity you're actually trying to reach. In the case of a homoglyph-assisted phisher, this would prevent them from obtaining the real password or any credential that would be useful to attack the real target, and also warn the user not to trust them period. However, the current layering of HTTPS doesn't make it possible to enforce the use of secure password exchange, and so I think passkeys are a better solution, because they allow us to remove the password modality entirely. I'm not entirely sure about how effective passkeys would be against homoglyph-assisted MITM though. Assuming you've visited the legitimate domain before and established your passkey at that time, your passkey wouldn't be selected by the browser for the fake domain. But if you started with the fake domain, and logged in through it using a non-passkey method (including first sign up or lost-credential recovery), then I would think the attacker could just enroll his own passkey on your behalf. Now, if we layered passkeys on top of mTLS, then we could almost entirely eliminate the MITM risk!

tptacek 2y ago
As you note, we already have a system that uses more appropriate cryptography (than a PAKE) to solve this: FIDO. You've lost me at mTLS here. At some point it starts to feel like we're advocating for security protocols just so we can fit them all in somewhere.
- kbolino 2y ago
  That was a bit tongue-in-cheek, sorry. I've worked in mTLS shops and it's definitely not practical for the public Internet. Ultimately, I think the practical solution to homoglyphs is in the presentation layer, whether it be displaying different scripts in different ways, warning when scripts are mixed, or some other kind of UX rather than protocol change. The only protocol change I can think of to address them would be to go back to ASCII only (and even that is more of a presentation issue since IDNs are just Punycode).
  - nickf 2y ago
    mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.
    - kbolino 2y ago
      It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates. [1]: https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies https://googlechrome.github.io/chromerootprogram/#321-applic...
      - nickf 2y ago
        It applies to leaf certs too. (Full disclosure - I work in the industry, so know this well). After June 15th, 2026 - no leaf certs with serverAuth and clientAuth. Mind you, client authentication with public certificates is a bad idea anyway, but I appreciate many people do and it's just been 'the way' for many years. This is why I think it's going to hurt if folks don't realise soon and start to plan.
        kbolino 2y ago
        I cannot find any hard evidence of this claim -- I don't have reason to believe you're making it up, but I also would expect this change to be more widely announced. The best I can find is some discussion by Let's Encrypt staff that the roots want to stop issuing clientAuth-enabled leaf certificates eventually. However, there haven't been any hard timelines established because (at least) some mail servers in particular are using domain-validated public certificates for opportunistic mTLS. I've scoured the CA/Browser Forum BRs and ballots, Chrome Root Store policies, and CCADB policies, and can't find mention of this coming restriction.
        nickf 2y ago
        It's a Chrome policy: https://googlechrome.github.io/chromerootprogram/ https://googlechrome.github.io/chromerootprogram/ 3.2.1 (item 2). In case it helps - am the CTO of a large CA, so (un)fortunately aware of what's happening and when.

tptacek 2y ago

As you note, we already have a system that uses more appropriate cryptography (than a PAKE) to solve this: FIDO. You've lost me at mTLS here. At some point it starts to feel like we're advocating for security protocols just so we can fit them all in somewhere.

kbolino 2y ago
That was a bit tongue-in-cheek, sorry. I've worked in mTLS shops and it's definitely not practical for the public Internet. Ultimately, I think the practical solution to homoglyphs is in the presentation layer, whether it be displaying different scripts in different ways, warning when scripts are mixed, or some other kind of UX rather than protocol change. The only protocol change I can think of to address them would be to go back to ASCII only (and even that is more of a presentation issue since IDNs are just Punycode).
- nickf 2y ago
  mTLS is going to be a problem soon, arguably bigger than this lifetime reduction. Most server certs today have clientAuth EKU and can be used for mTLS. That stops next year.
  - kbolino 2y ago
    It took me awhile to dig up evidence for this, but the closest I can find is that subordinate CA certificates will no longer be allowed to have id-kp-clientAuth EKU [1], however this restriction does not apply to leaf certificates. [1]: https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies https://googlechrome.github.io/chromerootprogram/#321-applic...
    - nickf 2y ago
      It applies to leaf certs too. (Full disclosure - I work in the industry, so know this well). After June 15th, 2026 - no leaf certs with serverAuth and clientAuth. Mind you, client authentication with public certificates is a bad idea anyway, but I appreciate many people do and it's just been 'the way' for many years. This is why I think it's going to hurt if folks don't realise soon and start to plan.
      - kbolino 2y ago
        I cannot find any hard evidence of this claim -- I don't have reason to believe you're making it up, but I also would expect this change to be more widely announced. The best I can find is some discussion by Let's Encrypt staff that the roots want to stop issuing clientAuth-enabled leaf certificates eventually. However, there haven't been any hard timelines established because (at least) some mail servers in particular are using domain-validated public certificates for opportunistic mTLS. I've scoured the CA/Browser Forum BRs and ballots, Chrome Root Store policies, and CCADB policies, and can't find mention of this coming restriction.
      - nickf 2y ago
        It's a Chrome policy: https://googlechrome.github.io/chromerootprogram/ https://googlechrome.github.io/chromerootprogram/ 3.2.1 (item 2). In case it helps - am the CTO of a large CA, so (un)fortunately aware of what's happening and when.