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