Colm,

Thanks for your review. Interesting stuff.

Scrolling ahead to the recommendations, I see you have:

* Require implementations to robustly prevent Ticket re-use for 0-RTT.

This seems like a good idea. I think it's arguable that we got a bit
nihilistic about this, and as you say, you can do a pretty good job of
reducing replay within a given data center using some local
anti-replay mechanism. I would tend to think that a strong SHOULD is
what you want here, as a MUST is going to be a lot more like a 6919
MUST (BUT WE KNOW YOU WON'T). I'll start preparing a PR on this.  Here
are the points I plan to make:

- There are a series of attacks involving lots of replays
  (cherry-picking your draft)

- Implementations cannot completely prevent replay but can do a lot to
  limit it using the following techniques (focusing on strike register
  and single-use cache).

I understand from your document and our previous conversation that you
believe single-use tokens are easier to implement on the server side,
but I'm not sure I really follow your argument. If you want to provide
some short text on that that we can all agree on, then I think we
could incorporate this as well.

* Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT
  data

This seems like some sort of extra-grease, but I'm kinda skeptical
that anyone is going to do it. Perhaps it would be useful to add it to
draft-ietf-tls-grease?


* Require TLS proxies to operate 0-RTT transitively

I've read this several times but I have to admit I don't understand
it. Do you think you could rephrase?


The following doesn't appear in your recommendations, but I think you
also think we should:


* Adopt something like PR#998 to make each PSK_id correspond to a
  different PSK even when they are issued on the same connection.

This seems straightforward, and I think we would also want to add some
text in security considerations describing the security implications
of the use of session-cache style PSKs to those of ticket-style PSKs,
especially when this technique is used.


* Require that clients only use tickets once.

For the reasons Viktor indicated, I tend to think this is inadvisable.
As you indicate, there are two implications of ticket reuse:

- It leaks some of ticket_age If the server wants to support it, it
- needs to not have a single-use session cache, so that threatens PFS.

As discussed on the list, the ticket_age issue is principally a
linkage issue, and the ticket is inherently linkable [0]. WRT the PFS
issue, the server can always implement a single-use cache if it wants
to, and if the server is doing ordinary tickets (which I understand
you don't like, but I don't think we are going to ban), then the PFS
situation seems unchanged. I have considered whether we should have a
way for the server to say "only use this ticket once" but I'm not sure
how that helps as the server can just unilaterally forget the tickeet.


* Remove ticket_age

This doesn't seem like a good idea: if you are implementing a strike
register, you want to use ticket_age to help distinguish "fresh" from
"unknown state". I.e., the ticket_age + the ticket issue time allows
you to determine approximately when a CH was sent, and any CH that
is significantly older or newer than now is forced back into 1-RTT.

-Ekr

[0] With that said, it wouldn't honestly be that hard to
Derive-Secret() a mask off of the PSK at the same time we derive the
early data key, if we really wanted to.











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
>
>