Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

[Karthikeyan Bhargavan <[e-mail]>]

> Ø  … 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:[e-mail] <mailto:[e-mail]>] On Behalf Of Karthikeyan Bhargavan
> Sent: Monday, March 28, 2016 1:31 PM
> To: Colm MacCárthaigh <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>