Re: [TLS] Security review of TLS1.3 0-RTT

[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 <colm@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
>
>