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. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
