News for hackers. Stuff that matters.
Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by throw0101a on Thursday May 23, 2019 @09:20PM (#19997643)
> 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.

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by dagenix on Friday May 24, 2019 @01:25AM (#19998723)
> 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?

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by throw0101a on Sunday May 26, 2019 @03:01PM (#20016738)
> 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

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.

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by tveita on Friday May 24, 2019 @10:05AM (#20001602)
> 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.

Re:RFC 8548: Cryptographic Protection of TCP Streams (Tcpcrypt) by dagenix on Sunday May 26, 2019 @02:02AM (#20013375)
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.