4 ms·

While it's interesting that the NSA blocked encryption in TCP, I'm not convinced it would have been a good idea to do it at that level in practice. Encryption h

While it's interesting that the NSA blocked encryption in TCP, I'm not convinced it would have been a good idea to do it at that level in practice. Encryption has moved on quite a lot since then (at the very least due to Moore's law holding for all that time). Changing the TCP stack (typically in the kernel) every time encryption moves forward would probably be worse than the current situation of using SSL/TLS. TCP itself has held up pretty well all these years; SCTP and such seem to have had zero impact on its popularity. (not that I'm an expert on either networking or encryption)

tptacek 16y ago
SSL/TLS has gone through numerous revisions, many of them after painful flaws, and was seen at the time it was created as a relatively cutting-edge design --- particularly vis a vis negotiation and flexibility. There is no chance encryption baked into TCP would have survived. How would you even key it? This story seems a bit apocryphal. I'm sure someone had it on a whiteboard somewhere, but...
- justsee 16y ago
  It seemed an interesting anecdote, but in a more recent post on network neutrality he referenced the TCP encryption proposals again (http://www.reed.com/blog-dpr/?p=85 http://www.reed.com/blog-dpr/?p=85): "In the early days of the Internet design, my officemate at MIT, Steven T. Kent, who is now far more well known as one of the premier experts on secure and trustworthy systems, described how the Internet design could in fact, be designed so that all of the bits delivered from source to destination were encrypted with keys unknown to the intermediate nodes, and we jointly proposed that this be strongly promoted for all users of the Internet. While this proposal was not accepted, because encryption was thought to be too expensive to require for every use, the protocol design of TCP and all other standard protocols have carefully preserved the distinctions needed so that end-to-end encryption can be used. That forces the design to not depend in any way on the content, since encryption means that no one other than the source or destination can possibly understand the meaning of the bits, so the network must be able to do perfectly correct job without knowing same."
- gxti 16y ago
  You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way. Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer. But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.
  - tptacek 16y ago
    Everything about this comment is horrifying. Start with AES-CTR (which wouldn't have been an option in 1979; counter mode hadn't been invented): you can't use TCP sequence numbers as counters; among other things, multiple segments can be sent with the same sequence number, and while the byte described at the stream offset of those sequence number (usually, but not always) agrees with every other packet, no other guarantee exists about the nature of those segments. Reuse of a counter in CTR mode is a devastating flaw. Running DH over an unsecured connection with no previous trust anchor is also a recipe for disaster; attackers don't even need a fully-functioning man-in-the-middle to break it; they just need to be able to inject two segments, one in each direction, to fixate the derived key. Everything else you propose to layer on top of this DH + AES-CTR connection is handwaving; if you have to run "application-layer" TLS, what's the value of hardcoding (broken) crypto into the TCP layer? Sorry for the rabid response to a well-intentioned comment, but wow I couldn't disagree with you more strongly.

tptacek 16y ago

SSL/TLS has gone through numerous revisions, many of them after painful flaws, and was seen at the time it was created as a relatively cutting-edge design --- particularly vis a vis negotiation and flexibility. There is no chance encryption baked into TCP would have survived. How would you even key it? This story seems a bit apocryphal. I'm sure someone had it on a whiteboard somewhere, but...

justsee 16y ago
It seemed an interesting anecdote, but in a more recent post on network neutrality he referenced the TCP encryption proposals again (http://www.reed.com/blog-dpr/?p=85 http://www.reed.com/blog-dpr/?p=85): "In the early days of the Internet design, my officemate at MIT, Steven T. Kent, who is now far more well known as one of the premier experts on secure and trustworthy systems, described how the Internet design could in fact, be designed so that all of the bits delivered from source to destination were encrypted with keys unknown to the intermediate nodes, and we jointly proposed that this be strongly promoted for all users of the Internet. While this proposal was not accepted, because encryption was thought to be too expensive to require for every use, the protocol design of TCP and all other standard protocols have carefully preserved the distinctions needed so that end-to-end encryption can be used. That forces the design to not depend in any way on the content, since encryption means that no one other than the source or destination can possibly understand the meaning of the bits, so the network must be able to do perfectly correct job without knowing same."
gxti 16y ago
You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way. Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer. But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.
- tptacek 16y ago
  Everything about this comment is horrifying. Start with AES-CTR (which wouldn't have been an option in 1979; counter mode hadn't been invented): you can't use TCP sequence numbers as counters; among other things, multiple segments can be sent with the same sequence number, and while the byte described at the stream offset of those sequence number (usually, but not always) agrees with every other packet, no other guarantee exists about the nature of those segments. Reuse of a counter in CTR mode is a devastating flaw. Running DH over an unsecured connection with no previous trust anchor is also a recipe for disaster; attackers don't even need a fully-functioning man-in-the-middle to break it; they just need to be able to inject two segments, one in each direction, to fixate the derived key. Everything else you propose to layer on top of this DH + AES-CTR connection is handwaving; if you have to run "application-layer" TLS, what's the value of hardcoding (broken) crypto into the TCP layer? Sorry for the rabid response to a well-intentioned comment, but wow I couldn't disagree with you more strongly.