On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 06/29/2017 03:53 PM, Eric Rescorla wrote: > > I have updated the PR to match people's comments. I would like to merge > this soon, so please get any final comments in. > > > I made a couple comments on the PR that are more appropriate for the list, > so I'll repeat them here and hopefully get replies from the broader > audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't quite > seem realistic to require "MUST use either [single-use tickets] or > [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST limit > replays to at most the number of endpoints capable of accepting connections > for a given identity, and SHOULD provide even stronger replay protections, > such as [single-use tickets] or [ClientHello recording]." I think we have > general agreement that strong anti-replay as described in the document is > feasible for a single-server deployment, and this last formulation is > achievable in multi-server environments by just giving each server its own > local per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here for > everyone's consideration. > > > The pull request also has some text: > > +If the expected arrival time is in the window, then the server > +checks to see if it has recorded a matching ClientHello. It > +either aborts the handshake with an "illegal_parameter" alert > +or accepts the PSK but reject 0-RTT. If no matching ClientHello > +is found, then it accepts 0-RTT and then stores the ClientHello for > +as long as the expected_arrival_time is inside the window. > +Servers MAY also implement data stores with false positives, such as > +Bloom filters, in which case they MUST respond to apparent replay by > +rejecting 0-RTT but MUST NOT abort the handshake. > > I am not sure why we are giving servers a choice between aborting and > accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), > especially not without giving guidance as to why they might choose one or > the other. My natural inclination would be to have the expected behavior > be to abort and only fall back to the other behavior if using a scheme with > false positives, but Ekr thinks Erik Nygren was in support of just > continuing on with 1-RTT. It looks like this was > https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , > where I ... took the opposite position from what I just said my "natural > inclination" was, amusingly enough. But still, why does this need to be a > choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be > reasonable in all the cases mentioned so far. > Well, my reason for not wanting to do that is that it's a clear replay and so should be a hard failure. So, I'd be happy to mandate abort the handshake, but if we can't agree on that, I'd rather have a choice. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
