[Deliberately responding to the OP rather than to anyone in particular] Hi folks,
I'm seeing a lot of back and forth about general philosophy and the wisdom of 0-RTT but I think it would be useful if we focused on what changes, if any, we need to make to the draft. I made some proposals yesterday (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). Specifically: 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both session-cache and strike register styles and the merits of each. 2. Document 0-RTT greasing in draft-ietf-tls-grease 3. Adopt PR#448 (or some variant) so that session-id style implementations provide PFS. 4. I would add to this that we recommend that proxy/CDN implementations signal which data is 0-RTT and which is 1-RTT to the back-end (this was in Colm's original message). Based on Colm's response, I think these largely hits the points he made in his original message. There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. What would be most helpful to me as Editor would be if people could review these PRs and/or suggest other specific changes that we should make to the document. Thanks, -Ekr On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <c...@allcosts.net> wrote: > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. > Thanks to feedback in the room I've now tightened up the findings from the > review and posted them as an issue on the draft GitHub repo: > > https://github.com/tlswg/tls13-spec/issues/1001 > > I'll summarize the summary: Naturally the focus was on forward secrecy and > replay. On forward secrecy the main finding was that it's not necessary to > trade off Forward Secrecy and 0-RTT. A single-use session cache can provide > it, and with the modification that ekr has created in > https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for > both pre-auth and post-auth tickets, and it allows clients to build up > pools of meaningfully distinct tickets. > > There's also an observation there that it should really be that clients > "MUST" use tickets only once. Any re-use likely discloses the obfuscated > ticket age, which is intended to be secret. Right now it's a "SHOULD". > > On replay, the main finding is that what's in the draft is not workably > secure, and the review includes 5 different attacks against 0-RTT data to > illustrate that. Attacks 1 and 2 show that the kind of replay permitted by > the draft is very different from the kind of replay permitted by dkg's > existing downgrade-and-retry attack. I also go over why it very very > difficult to many applications to achieve that idempotency, and why one > idempotency pattern actually relies on non-replayable messages. > > Attack 3 shows that idempotency is not sufficient, applications must also > be free of measurable side-effects, which is not practical. Attack 4 shows > that 0-RTT breaks a common security mechanism: spoofing-resistant > throttles. Attack 5 shows that 0-RTT replay-ability enables an additional > form of traffic analysis. > > The recommendation in the review is that implementations "MUST" prevent > replays of 0-RTT section, with some additional discussion about why the > existing advice is unlikely to be followed, and why consistent > interoperability matters here. > > Unfortunately, I wasn't aware until Friday that this review would be > coming so late in the TLD1.3 draft process, and my apologies for that. I am > now planning to attend the future WG in-person meetings and look forward to > seeing many of you there. > > -- > Colm > > _______________________________________________ > 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
