Yes, I believe that this is what people want. On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov <andrei.po...@microsoft.com> 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:karthik.bharga...@gmail.com] > *Sent:* Monday, March 28, 2016 2:31 PM > *To:* Andrei Popov <andrei.po...@microsoft.com> > *Cc:* Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org > > *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:tls-boun...@ietf.org <tls-boun...@ietf.org>] *On > Behalf Of *Karthikeyan Bhargavan > *Sent:* Monday, March 28, 2016 1:31 PM > *To:* Colm MacCárthaigh <c...@allcosts.net> > *Cc:* tls@ietf.org > *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 > TLS@ietf.org > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
