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

[Eric Rescorla <[e-mail]>]

Yes, I believe that this is what people want.

On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov <[e-mail]>
wrote:

> Not sending cookies/authz headers in 0-RTT would solve a part of the
> problem, but will browser vendors go for that? I could be wrong, but there
> seems to be considerable interest in 0-RTT Token Binding…. so folks must be
> planning on sending tokensJ.
>
>
>
> *From:* Karthikeyan Bhargavan [mailto:[e-mail]]
> *Sent:* Monday, March 28, 2016 2:31 PM
> *To:* Andrei Popov <[e-mail]>
> *Cc:* Colm MacCárthaigh <[e-mail]>; [e-mail]
>
> *Subject:* Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety
>
>
>
> Ø  … 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] <[e-mail]>] *On
> Behalf Of *Karthikeyan Bhargavan
> *Sent:* Monday, March 28, 2016 1:31 PM
> *To:* Colm MacCárthaigh <[e-mail]>
> *Cc:* [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]
> https://www.ietf.org/mailman/listinfo/tls
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c88d384e16d794a23be0c08d35750543d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IU9aYW%2b6Gt0pnbIVXnT2yGNzOCGfmvvg%2fY5yFhiKlYY%3d>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>