> Ø … because secrecy is in the control of the client, who can choose to send > or not send sensitive data… > Generally, how can a browser distinguish sensitive data?
By not sending cookies or authorization headers, for example? > > Cheers, > > Andrei > > From: TLS [mailto:[email protected] <mailto:[email protected]>] On > Behalf Of Karthikeyan Bhargavan > Sent: Monday, March 28, 2016 1:31 PM > To: Colm MacCárthaigh <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety > > Let me try to understand the concerns here. > > > Resumption and Forward Secrecy > > PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? > This is already better than TLS 1.2 where we had no way to do forward-secret > resumption. > In that case, the concern is mainly for 0-RTT, which I agree is harder to get > right. > > > 0RTT and Safety > I see at least three different challenges with 0RTT as defined. The first is > a general and high level one: we seem to willing to accept a "lower" level of > security for 0RTT data (e.g. no FS, even if the rest of the session has it). > Why? What is it we think is special about this data that it is "less" worth > protecting? surely there are very sensitive things in urls, surely there are > potential oracles and other things in there too? It just seems super strange > to me. > > I wonder if the QUIC folks have an answer to this question? It would be good > to gather “typical” intended use cases of 0-RTT data. > In any case, it is good to distinguish this forward secrecy concern from > replay, because secrecy is in the control of the client, who can choose to > send or not send sensitive data, but replay detection is in the hands of the > server. > > > The second challenge is that the replayability of the 0RTT poses a > cryptographic safety challenge. Take Lucky13 - which is a brilliant attack > and is stunningly effective against DTLS because it is so easy to replay over > and over; barely needing to change any parameters - and let the server do the > work. 0RTT looks very similar. It doesn't seem wise to let cipher text > manipulators take as many cracks at the whip as they'd like. > The third challenge is that the 0RTT plaintext data itself may not be safe to > replay; that is that it might trigger some kind of non-idempotent action. > Idempotence is really really hard, it isn't safe to simply plug in a > replayable section to existing protocols. There's also a huge difference > between being tolerant to a small number of replays, and a large unbounded > number. For example: a large unbounded number may be used to generate DOS > attacks against throttles and quotas. > > Yes, detecting and preventing replays by default would be good. > However, I wouldn’t tie this in with the session mechanism. > Wouldn’t we want to prevent replay of DH 0-RTT requests? > > Best, > Karthik > > > > > The third challenge is that the 0RTT plaintext data itself may not be safe to > replay; that is that it might trigger some kind of non-idempotent action. > Idempotence is really really hard, it isn't safe to simply plug in a > replayable section to existing protocols. There's also a huge difference > between being tolerant to a small number of replays, and a large unbounded > number. For example: a large unbounded number may be used to generate DOS > attacks against throttles and quotas. > > Tying things together > Short of some kind of transactional locking protocol during TLS handshakes, I > don't think there is a scheme that can perfectly prevent replay. Bill Cox' > analysis is a really good one here. But I'd like to observe that the sort of > single-use-session-id cache outlined above has a nice property that it makes > for a sort of strike register. Since the server-side implementor is > incentivized to evict entries, or at least mark them as used, so that the > slot is available for re-use; that can be doubled-up as a "we've seen this > already" signal. This reduces the replay window to the time period for that > signal to propagate (e.g. for an eviction to happen from the cache). > > So 0RTT data could be encrypted under the resumption session id. That creates > the challenge that the session might not be there any more, so the server may > not be able to decrypt the 0RTT data. I actually think this is a plus, and > lines up with a separate important change I think is necessary - the 0RTT > data shouldn't be application data. It should be a separate, optional, > stream. I find it helpful to think of it as a hint, so it could be called > "replayable_hint". Instead of breaking apart an existing protocol and putting > some of it in the early data and some in the application data transparently > (a disaster in waiting), the client and server would have to formally agree > on the kind of data that could be in a "replayable_hint". This goes a long > way to mitigating many protocol level idempotency concerns, and has no impact > on the kind of pre-fetching people want to do for HTTP and other protocols. > At a bare minimum, I think we should make this change. > > Lastly, and this is a little crazy but I haven't let that stop me before ... > to guard against the smaller replay window and idempotency problems at the > application levels,clients should occasionally send duplicate and unrelated > hints, just opportunistically. This keeps the server side application "on > notice" that that kind of craziness can occur, and better to have it happen a > little all of the time in a controlled way, than rarely by attackers. > > Summary > A common theme in the above is that it makes things more expensive for > server-side implementors, and that sucks - but I don't see another way to > avoid some of the pitfalls here; and I'm unhappy with the state of tickets > today. If I'm on my own on that, I'd be interested in what kinds of data > people might kind convincing. My own impressions come from being an Apache > httpd developer and assisting people with configurations and running > workshops at conferences. It's not scientific, but the prevalence of > non-rotation is so severe in my sample set that I'm convinced it's the norm. > > -- > Colm > _______________________________________________ > TLS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
