Exported Authenticators: The long road to RFC
blog.cloudflare.com
blog.cloudflare.com
So now WebAuthn has a weaker security property: it verifies that the client thinks it’s talking to the right origin. So WebAuthn protects users who visit a typo-squatting domain, but it does not protect against attackers who can pretend to be the target origin. The latter can happen by, for example, compromising a server certificate private key, obtaining a fraudulent certificate, or using a MiTM CA.
A hypothetical WebAuthn using exported identifiers would authenticate the user specifically to the server with which the user is actually communicating. This would work without any guarantees from the CA system, and would even work for local network appliances for which server certificates are currently difficult to impossible to use sensibly.
I like the idea of OPAQUE password exchange, but I'd much rather see a move towards FIDO2/WebAuthn instead of going for another round of passwords. Browsers aren't going to support this new TLS standard any time soon and hopefully by the time they start working on it, they don't need to.
Furthermore, with QUIC becoming the next HTTP standard because Google asked nicely, I don't see the point of adding to TLS 1.3 when the crypto scheme seems to be moving towards another protocol anyway. At best the addition is worthless, at worst we'll end up having to choose between http/2 over TCP for feature x or http/3 over QUIC for feature y.
This article explains that (a) they chose to mimic an existing well used technology, the TLS handshake, in order to reduce opportunities for surprises and (b) they have performed mathematical verification, something which wasn't practical a decade ago but is today
> I like the idea of OPAQUE password exchange, but I'd much rather see a move towards FIDO2/WebAuthn instead of going for another round of passwords.
You absolutely should use WebAuthn, this work doesn't deprecate WebAuthn, but not doing it wouldn't have magically resulted in lots of web sites getting WebAuthn. WebAuthn is intended to authenticate humans, but OPAQUE-EA not so much.
> Furthermore, with QUIC becoming the next HTTP standard because Google asked nicely, I don't see the point of adding to TLS 1.3 when the crypto scheme seems to be moving towards another protocol anyway.
The "crypto scheme" in QUIC is TLS 1.3. Not "It's a lot like TLS 1.3" or "They copy pasted some of TLS 1.3" it's just TLS 1.3. Features, including Exported Authenticators, from TLS 1.3 work just fine in QUIC because QUIC's encryption is TLS 1.3.
Given your reference to Google "asking nicely" I'm going to guess that you didn't really pay much attention and have concluded that QUIC (the IETF's encrypted transport protocol) is just Google's 10 year old QUIC protocol (today often referred to as gQUIC) plus a bunch of bureaucracy. That's not so, the fact QUIC is built on TLS 1.3 while gQUIC used Google's custom "QUIC Crypto" is just one example of the differences.
Verification is only as good as the model used to verify it. The implementation may (probably, actually,) still have at least one bug that negates everything.
Domain isolation is important for security on the web (think about the problems CORS solves) and domain isolation right now requires using multiple connections, which is not great for performance. To me, this is just aligning security and performance, so that you don't have to choose.
> I don't see the point of adding to TLS 1.3 when the crypto scheme seems to be moving towards another protocol anyway
The authors of QUIC followed the same principle as the authors of this draft, and borrowed the handshake from TLS 1.3:
"For those familiar with the TLS protocol, QUIC replaces the TLS record layer with its own framing format, while keeping the same TLS handshake messages."
These changes go straight into browsers (Chrome, Firefox, Safari) and servers (nginx, caddy, etc), so you're going to benefit from the performance gains whether you like it or not!