4 ms·

This seems to primarily only protect against passive listeners [1]. So, while I guess this could be useful to transparently increase security of unencrypted pro

This seems to primarily only protect against passive listeners [1]. So, while I guess this could be useful to transparently increase security of unencrypted protocols, it seems like the use cases would be somewhat narrow and that TLS over TCP and QUIC will continue to be much better solutions. [1]. From Section 8: "... tcpcrypt does not protect against active network attackers unless applications authenticate the session ID. If it can be established that the session IDs computed at each end of the connection match, then tcpcrypt guarantees that no man-in-the-middle attacks occurred ..."

throw0101a 7y ago
> This seems to primarily only protect against passive listeners [1]. Which is still useful in that it prevents organizations from simply 'tapping glass'. I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits. It's why I also think that unauthenticated encryption is useful even if it doesn't protect against active attacks: the extra resources needed for the active component forces the adversary to make choices on who to target.
- dagenix 7y ago
  > I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits. On the one hand: protection against passive monitoring is a clear win. On the other hand, in my opinion, saying something like: "which is a small chance of happening" is kinda problematic: you don't need that security, and if some agency targeted you, like, maybe there is a minor chance of personal embarrassment. However, there are also people in the world that when they are targeted, they could face prison time or worse. And the people with the most to lose, are also the most likely to be targeted. So, IMO, it would be somewhat irresponsible to rely on tcpcrypt - it gives people that don't really need protection protection that they don't need, but leaves everyone that does out to dry. The thing is - I just can't think of a use case where it makes sense. HTTP is often used with TLS - and TLS offers protection against active attackers. Many new protocols are based on HTTP - right or wrong, that generally means they get TLS with whatever library they use. DNS is moving toward DoT and DoH. SMTP has STARTTLS already which does the same thing. FTP has been replaced by SFTP / SCP. Telnet is replaced by SSH. Instant messaging protocols have built in security. What protocol and who would actually benefit from this?
  - tveita 7y ago
    > What protocol and who would actually benefit from this? The main promise IMO is providing transparent encryption to old applications and protocols that use TCP without their own encryption layer. It is not possible to provide transparent authenticated encryption to everyone without some sort of CA system for IPs, but we should still provide the strongest privacy available by default, which is protection against passive eavesdropping.
    - dagenix 7y ago
      That sounds like a reasonable goal, I'm just at a loss for what old applications or protocols will benefit. Many of those old applications get stuck running on old kernels which would prevent this type of change from helping them.
  - throw0101a 7y ago
    > What protocol and who would actually benefit from this? All of them. We could have encrypted HTTP back in 2000 if HTTP Upgrade had been more widely deployed: * https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header How much of the stuff that the NSA (and others) did that Snowden exposed could have been made impossible, or at least more difficult, if there was more encrypted traffic to deal with? Sure, there wouldn't have been little padlock icons, and active attacks could still be done, but it wouldn't have been as much wholesale surveillance. Instead, between 2000 and (say) 2016—when Let's Encrypt/ACME went live—we had selective encryption only for 'important' sites where people thought it worth the cost/hassle of getting a cert and going HTTPS. Even now, there are plenty of legacy HTTP-only sites: why not have an Apache module available that does opportunistic encryption, even if the end-user doesn't get a padlock icon.
nullc 7y ago
In my view one of the most significant advances of TCPCrypt is setting appropriate layering. Past cryptographic network transports have committed the sin of layer violation by conflating stream management with correspondent authentication. Authenticating that you are talking to whom you think you're talking to is a complex, highly application specific process which in many cases even requires its own UI. The code to implement authentication is complex and has (e.g. x509 parsing) frequently been a source of vulnerabilities, making it unattractive for implementation in network stacks. Witness the use of TLS for non-webby applications where there aren't readily user provided domain names and things don't fit nicely into a one-side-authenticated server/client model-- they often turn into key management nightmares. TCPcrypt handles the stream encryption and integrity in the network layer where it can do so seamlessly. It hands up the stack the required hooks so that authentication can be performed in whatever way makes sense for the application. As a bonus, even when authentication isn't used applications are protected against dragnet passive content surveillance.
- tptacek 7y ago
  WireGuard authenticates traffic, using modern constructions, and its kernel implementation is famously fewer than 5000 lines of code, and can be implemented without dynamic allocation. Just because TLS is complicated doesn't mean that cryptographic authentication is fundamentally difficult. Watson Ladd once said, on the CFRG mailing list, that if TLS 1.1 had been turned in as an undergraduate assignment, it would have gotten a D. (I'm paraphrasing from memory).
  - crest 7y ago
    You conveniently ignored the 30k LOC crypto framework.
  - nullc 7y ago
    > WireGuard authenticates traffic, using modern constructions Assuming you know in advance of your connection a correct public key for the corespondent. How you got it, how you know it's correct is ... left up to you. Yet it isn't secure if its not done exactly right. This is like arguing that a one time pad provides for unbreakable encryption. True in one sense, often not true in practice.

throw0101a 7y ago

> This seems to primarily only protect against passive listeners [1]. Which is still useful in that it prevents organizations from simply 'tapping glass'. I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits. It's why I also think that unauthenticated encryption is useful even if it doesn't protect against active attacks: the extra resources needed for the active component forces the adversary to make choices on who to target.

dagenix 7y ago
> I'll take the imperfect security of forcing various agencies to expend resources to go after me personally (which is a small chance of happening) versus the ease of them simply vacuuming up all the bits. On the one hand: protection against passive monitoring is a clear win. On the other hand, in my opinion, saying something like: "which is a small chance of happening" is kinda problematic: you don't need that security, and if some agency targeted you, like, maybe there is a minor chance of personal embarrassment. However, there are also people in the world that when they are targeted, they could face prison time or worse. And the people with the most to lose, are also the most likely to be targeted. So, IMO, it would be somewhat irresponsible to rely on tcpcrypt - it gives people that don't really need protection protection that they don't need, but leaves everyone that does out to dry. The thing is - I just can't think of a use case where it makes sense. HTTP is often used with TLS - and TLS offers protection against active attackers. Many new protocols are based on HTTP - right or wrong, that generally means they get TLS with whatever library they use. DNS is moving toward DoT and DoH. SMTP has STARTTLS already which does the same thing. FTP has been replaced by SFTP / SCP. Telnet is replaced by SSH. Instant messaging protocols have built in security. What protocol and who would actually benefit from this?
- tveita 7y ago
  > What protocol and who would actually benefit from this? The main promise IMO is providing transparent encryption to old applications and protocols that use TCP without their own encryption layer. It is not possible to provide transparent authenticated encryption to everyone without some sort of CA system for IPs, but we should still provide the strongest privacy available by default, which is protection against passive eavesdropping.
  - dagenix 7y ago
    That sounds like a reasonable goal, I'm just at a loss for what old applications or protocols will benefit. Many of those old applications get stuck running on old kernels which would prevent this type of change from helping them.
- throw0101a 7y ago
  > What protocol and who would actually benefit from this? All of them. We could have encrypted HTTP back in 2000 if HTTP Upgrade had been more widely deployed: * https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header How much of the stuff that the NSA (and others) did that Snowden exposed could have been made impossible, or at least more difficult, if there was more encrypted traffic to deal with? Sure, there wouldn't have been little padlock icons, and active attacks could still be done, but it wouldn't have been as much wholesale surveillance. Instead, between 2000 and (say) 2016—when Let's Encrypt/ACME went live—we had selective encryption only for 'important' sites where people thought it worth the cost/hassle of getting a cert and going HTTPS. Even now, there are plenty of legacy HTTP-only sites: why not have an Apache module available that does opportunistic encryption, even if the end-user doesn't get a padlock icon.

nullc 7y ago

In my view one of the most significant advances of TCPCrypt is setting appropriate layering. Past cryptographic network transports have committed the sin of layer violation by conflating stream management with correspondent authentication. Authenticating that you are talking to whom you think you're talking to is a complex, highly application specific process which in many cases even requires its own UI. The code to implement authentication is complex and has (e.g. x509 parsing) frequently been a source of vulnerabilities, making it unattractive for implementation in network stacks. Witness the use of TLS for non-webby applications where there aren't readily user provided domain names and things don't fit nicely into a one-side-authenticated server/client model-- they often turn into key management nightmares. TCPcrypt handles the stream encryption and integrity in the network layer where it can do so seamlessly. It hands up the stack the required hooks so that authentication can be performed in whatever way makes sense for the application. As a bonus, even when authentication isn't used applications are protected against dragnet passive content surveillance.

tptacek 7y ago
WireGuard authenticates traffic, using modern constructions, and its kernel implementation is famously fewer than 5000 lines of code, and can be implemented without dynamic allocation. Just because TLS is complicated doesn't mean that cryptographic authentication is fundamentally difficult. Watson Ladd once said, on the CFRG mailing list, that if TLS 1.1 had been turned in as an undergraduate assignment, it would have gotten a D. (I'm paraphrasing from memory).
- crest 7y ago
  You conveniently ignored the 30k LOC crypto framework.
- nullc 7y ago
  > WireGuard authenticates traffic, using modern constructions Assuming you know in advance of your connection a correct public key for the corespondent. How you got it, how you know it's correct is ... left up to you. Yet it isn't secure if its not done exactly right. This is like arguing that a one time pad provides for unbreakable encryption. True in one sense, often not true in practice.