41–50 of 78 posts
So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.
(... edit, actually, I recognize this username from previous nonsensical discussions about crypto and backdoors: https://news.ycombinator.com/item?id=13364173 )
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this: E.5. Replay Attacks on 0-RTT Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks…
For the nontechnical, what does 0rtt do?
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this: E.5. Replay Attacks on 0-RTT Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks…
Part of the DuckDuckGo $500,000 Privacy Challenge 2018 ; https://www.crowdrise.com/duckduckgoprivacychallenge
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this: E.5. Replay Attacks on 0-RTT Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks…
The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose. I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this: E.5. Replay Attacks on 0-RTT Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks…
A quick thought is that the protocol could require a sequence number on 0-RTT and only accept newer ones.
This looks trivial when you are running one Apache httpd on a Raspberry Pi on your desk. Why not just build any of these approaches right into the standard? And then you try to figure out how to make it work for Netflix or Google, who have thousands of clusters of servers - and your brain explodes.
So that's why the standard doesn't specify one solution and require everybody to use it but it does say if you need 0-RTT then you need to figure out what you're going to do about this, including specifying some of the nastier surprises that shuffle message orders and change which servers get which messages.
Example: let's say you think you're clever, you have two servers A and B, load balanced so they usually take distinct clients but can fail into a state where either takes all clients. You might figure you can just track the PSKs in each server, offer 0-RTT and if a client tries to 0-RTT with a PSK from the other server (somehow) it'll just fail to 1-RTT, no big deal.
Er, nope. Bad guys arrange for a client to get the "wrong" server, they capture the 0-RTT from that client, the "wrong" server says "Nope, do 1-RTT", the client tries again and in parallel the bad guys play the 0-RTT packets to the "right" server, which does the exact same thing as the "wrong" one - the replay has succeeded.
If I'm not mistaken this means no "authorized" MITM - Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
Other types of MiTM still work, such as an active MiTM through a malicious root certificate.
So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.
The rest of your comment is less sensible than the first. Everyone will implement it, and it's up to the user to decide whether they feel that they need the feature and know that their application is unaffected by replay attacks.
Earlier quoted context omitted.
You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...
That's roughly the line of their job, as we have all learned the hard way a few years back.
None of that made it into this draft, indeed the Monday meeting (this link is about the Wednesday meeting although practically speaking I think this was a done deal by Monday) of the TLS working group at IETF 101 basically killed all those plans, at least in so far as they impact TLS 1.3 itself. The IETF operates on "rough consensus" and there wasn't any way forward on "transparency" (aka snooping) that had consensus, so it was either publish this or stall forever.
Earlier quoted context omitted.
The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose. I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.
If you're concerned about it, couldn't you turn it off clientside?