3 ms·

The "oh but middleboxes" argument is a universal one for bodging protocol development. For every new bit sent on the wire there will be some boxes somewhere mes

The "oh but middleboxes" argument is a universal one for bodging protocol development. For every new bit sent on the wire there will be some boxes somewhere messing it up. But there is also the opposite effect, maldesigned devices will never be replaced until users can't reach their services, in which case replacement is swift and decisive. When the big content providers require it, infrastructure improves. Just look at TLS 1.3 for a recent example. When Chrome suddenly couldn't hand shake with a major load balancing vendor, blame was placed with the latter and the problem was fixed.

tialaramex 8y ago
You invoke TLS 1.3 as your example, but the TLS WG spent over a _year_ on essentially nothing except finding a way to bodge the protocol so that it could get past middleboxes. Note that draft 22 in particular is focused on disguising TLS 1.3 connections as something middleboxes are least likely to meddle with. The middlebox firmwares from this year including from prominent vendors like Symantec and often misdescribed as "implementing TLS 1.3" actually mostly do what they _should_ have been doing from the outset if they were correctly implemented, which is to say they refuse to negotiate TLS 1.3 and end up proxying TLS 1.2 instead. "Oh but middleboxes" is exactly why we have TLS 1.3 and QUIC. You are correct that every bit is a new opportunity for middlebox vendors to mess it up, and that's why every possible bit is encrypted. Consider certificate compression. A certificate is about a kilobyte sent on every new connection that has large boring repetitive structures inside it (as well as many bits of random key data that won't compress), so we should clearly compress it. But there was no point even trying in TLS 1.2 and below because the cert was cleartext, and so middleboxes would try to parse it, if you compressed it they'd get confused and close the connection, or worse. Only in TLS 1.3 where certificates are encrypted, and so middleboxes can't inspect them, are we finally able to offer compression.
- xorcist 8y ago
  TLS 1.3 could have chosen to do without certificate encryption and it would have been easier to implement. I did not mean to trivialize the enormous work to make it work with deployed hardware, but in the struggle ibetween new features and compatibilty with broken implementations, TLS ended up overwhelmingly on moving forward and breaking things and the Internet didn't collapse because of it.
  - tialaramex 8y ago
    No, encrypting certificates falls naturally out of the TLS 1.3 design so not doing this wouldn't have made it easier to implement. I can't help you here, you believe something that's flatly contradicted by the observable facts. Just in case anybody else is still reading this thread, here's why encrypting certificates falls out naturally: TLS 1.3 does key exchange (today some variant of Diffie-Hellman) up front. The first message from the client comes with proposed key shares with the client's half of DH done. This means when the server receives that message it can do its half of DH and immediately derive the resulting session keys. It will still need to transmit the public parts of its DH calculations back to the client in plaintext, but alongside and immediately after those it can use encryption, even though neither client nor server are authenticated yet. So everything further is encrypted, including certificates. The original SSL design uses RSA key exchange, which means nobody can encrypt anything until after the server's certificate has been sent, because the public key is baked into the certificate. This is clever because it inherently authenticates the remote server during key exchange, but it has numerous undesirable properties AND it's slower, so removing RSA key exchange was an early goal of TLS 1.3

tialaramex 8y ago

You invoke TLS 1.3 as your example, but the TLS WG spent over a _year_ on essentially nothing except finding a way to bodge the protocol so that it could get past middleboxes. Note that draft 22 in particular is focused on disguising TLS 1.3 connections as something middleboxes are least likely to meddle with. The middlebox firmwares from this year including from prominent vendors like Symantec and often misdescribed as "implementing TLS 1.3" actually mostly do what they _should_ have been doing from the outset if they were correctly implemented, which is to say they refuse to negotiate TLS 1.3 and end up proxying TLS 1.2 instead. "Oh but middleboxes" is exactly why we have TLS 1.3 and QUIC. You are correct that every bit is a new opportunity for middlebox vendors to mess it up, and that's why every possible bit is encrypted. Consider certificate compression. A certificate is about a kilobyte sent on every new connection that has large boring repetitive structures inside it (as well as many bits of random key data that won't compress), so we should clearly compress it. But there was no point even trying in TLS 1.2 and below because the cert was cleartext, and so middleboxes would try to parse it, if you compressed it they'd get confused and close the connection, or worse. Only in TLS 1.3 where certificates are encrypted, and so middleboxes can't inspect them, are we finally able to offer compression.

xorcist 8y ago
TLS 1.3 could have chosen to do without certificate encryption and it would have been easier to implement. I did not mean to trivialize the enormous work to make it work with deployed hardware, but in the struggle ibetween new features and compatibilty with broken implementations, TLS ended up overwhelmingly on moving forward and breaking things and the Internet didn't collapse because of it.
- tialaramex 8y ago
  No, encrypting certificates falls naturally out of the TLS 1.3 design so not doing this wouldn't have made it easier to implement. I can't help you here, you believe something that's flatly contradicted by the observable facts. Just in case anybody else is still reading this thread, here's why encrypting certificates falls out naturally: TLS 1.3 does key exchange (today some variant of Diffie-Hellman) up front. The first message from the client comes with proposed key shares with the client's half of DH done. This means when the server receives that message it can do its half of DH and immediately derive the resulting session keys. It will still need to transmit the public parts of its DH calculations back to the client in plaintext, but alongside and immediately after those it can use encryption, even though neither client nor server are authenticated yet. So everything further is encrypted, including certificates. The original SSL design uses RSA key exchange, which means nobody can encrypt anything until after the server's certificate has been sent, because the public key is baked into the certificate. This is clever because it inherently authenticates the remote server during key exchange, but it has numerous undesirable properties AND it's slower, so removing RSA key exchange was an early goal of TLS 1.3