3 ms·

Can anyone explain why is it designed this way? Why was it necessary to involve DNS into this? Was it unavoidable or is that all in the name of keeping 0-rtt po

Can anyone explain why is it designed this way? Why was it necessary to involve DNS into this? Was it unavoidable or is that all in the name of keeping 0-rtt possible? Tbh, with the current implementation, ECH setup seems rather complicated to me. It benefits CDNs like CloudFlare since they control both DNS and the handshake process, but those who would like to setup ECH on their own are in trouble.

unilynx 6y ago
You need to know if you're talking to the server you think you're connecting to, otherwise a man-in-the-middle could impersonate the server and intercept the handshake to see the hostname you're trying to connect. So you need another channel to pull a public key (or something comparable), and they picked DNS for that
- ameshkov 6y ago
  As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" with the real cert?
  - shawnz 6y ago
    How do you validate the authenticity of the first certificate without revealing any hostnames?
    - ameshkov 6y ago
      If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)
      - corty 6y ago
        You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).
        parliament32 6y ago
        That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.
        johncolanduoni 6y ago
        One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.
        corty 6y ago
        For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.
        corty 6y ago
        no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual
        namibj 6y ago
        No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.
      - shawnz 6y ago
        That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases. Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information
  - MathiasPius 6y ago
    How do you know that the first certificate was not produced by the MitM?
corty 6y ago
The client initiates the connection and must know a key to encrypt the client hello with before the first packet. Unsigned DH is out because that would allow MitM and involve another roundtrip, cached certificate is only known on the second connection and hardcoded keys would be stupid. That leaves DNS.
toast0 6y ago
In order to encrypt the connection handshake, you and the server need to agree on a key to encrypt it with. If you do the key exchange on the connection, you have two choices: a) anonymous key exchange, which could be MITM, because it's unauthenticated. This would be more secure than just sending the hostname in plain text, because it would require active interception rather than passive surveillance, but active interception is not that much harder than passive surveillance. b) signed key exchange, which is tricky, because the server may have certificates for many hostnames, and it doesn't know which one you used In order to have another option, you need to get a key through some other method. DNS is the more or less the most viable out of band method to get that information; after all, it's what you used to turn a hostname into an IP address to contact the server in the first place.
- namibj 6y ago
  You could do (a) to force active attacks, and then at the end (after SNI) authenticate the server based on the then-matching cert, followed by checking that you both got the same symmetric key from the ECDH key exchange at the beginning. If they don't match, you know there was an active MITM and both sides know.

unilynx 6y ago

You need to know if you're talking to the server you think you're connecting to, otherwise a man-in-the-middle could impersonate the server and intercept the handshake to see the hostname you're trying to connect. So you need another channel to pull a public key (or something comparable), and they picked DNS for that

ameshkov 6y ago
As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" with the real cert?
- shawnz 6y ago
  How do you validate the authenticity of the first certificate without revealing any hostnames?
  - ameshkov 6y ago
    If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)
    - corty 6y ago
      You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).
      - parliament32 6y ago
        That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.
        johncolanduoni 6y ago
        One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.
        corty 6y ago
        For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.
        corty 6y ago
        no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual
        namibj 6y ago
        No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.
    - shawnz 6y ago
      That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases. Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information
- MathiasPius 6y ago
  How do you know that the first certificate was not produced by the MitM?

corty 6y ago

The client initiates the connection and must know a key to encrypt the client hello with before the first packet. Unsigned DH is out because that would allow MitM and involve another roundtrip, cached certificate is only known on the second connection and hardcoded keys would be stupid. That leaves DNS.

toast0 6y ago

In order to encrypt the connection handshake, you and the server need to agree on a key to encrypt it with. If you do the key exchange on the connection, you have two choices: a) anonymous key exchange, which could be MITM, because it's unauthenticated. This would be more secure than just sending the hostname in plain text, because it would require active interception rather than passive surveillance, but active interception is not that much harder than passive surveillance. b) signed key exchange, which is tricky, because the server may have certificates for many hostnames, and it doesn't know which one you used In order to have another option, you need to get a key through some other method. DNS is the more or less the most viable out of band method to get that information; after all, it's what you used to turn a hostname into an IP address to contact the server in the first place.

namibj 6y ago
You could do (a) to force active attacks, and then at the end (after SNI) authenticate the server based on the then-matching cert, followed by checking that you both got the same symmetric key from the ECDH key exchange at the beginning. If they don't match, you know there was an active MITM and both sides know.