5 ms·

Exported Authenticators: The long road to RFC

34 points by weinzierl 4y ago

jeroenhd 4y ago
Just like with QUIC, I'm not a big fan of introducing features and protocols that only serve a few huge companies. The attack surface of such a system would be raised enormously and only CDNs profit from this new authentication system, really. For everyone else the web just becomes even more complex. 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.
- tialaramex 4y ago
  > raised enormously 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.
  - withinboredom 4y ago
    > they have performed mathematical verification 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.
- conradev 4y ago
  We all share the internet. Introducing features that make the internet work faster in an open standards body seems like a pretty reasonable thing to do, to me. 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! https://blog.cloudflare.com/the-road-to-quic/ https://blog.cloudflare.com/the-road-to-quic/
bauruine 4y ago
What is the advantage of EA over the existing client authentication with client certs?
- tialaramex 4y ago
  Although OPAQUE-EA is mentioned at the very end of this article, the vast bulk of the article is about the actual Exported Authenticators feature, which has little to do with Client Authentication.
deleted 4y ago
[deleted]
amluto 4y ago
I wonder if this will get integrated with WebAuthn. Originally, WebAuthn was supposed to provide a nifty security property: if a client authenticates via WebAuthn to a server, that server cannot replay the authentication to another server. This property got lost in the standardization process (I think it was meant to come along with token binding, but token binding mostly flopped). 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.

34 points by weinzierl 4y ago

Just like with QUIC, I'm not a big fan of introducing features and protocols that only serve a few huge companies. The attack surface of such a system would be raised enormously and only CDNs profit from this new authentication system, really. For everyone else the web just becomes even more complex. 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.

tialaramex 4y ago
> raised enormously 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.
- withinboredom 4y ago
  > they have performed mathematical verification 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.
conradev 4y ago
We all share the internet. Introducing features that make the internet work faster in an open standards body seems like a pretty reasonable thing to do, to me. 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! https://blog.cloudflare.com/the-road-to-quic/ https://blog.cloudflare.com/the-road-to-quic/

bauruine 4y ago

What is the advantage of EA over the existing client authentication with client certs?

tialaramex 4y ago
Although OPAQUE-EA is mentioned at the very end of this article, the vast bulk of the article is about the actual Exported Authenticators feature, which has little to do with Client Authentication.

deleted 4y ago

[deleted]

amluto 4y ago

I wonder if this will get integrated with WebAuthn. Originally, WebAuthn was supposed to provide a nifty security property: if a client authenticates via WebAuthn to a server, that server cannot replay the authentication to another server. This property got lost in the standardization process (I think it was meant to come along with token binding, but token binding mostly flopped). 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.