On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > 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. > Are there scenarios where the duplication might be accidental rather than a malicious attack? For example, one might see cases where combining 0RTT with TFO and network packet duplication could result in two initial 0RTT flights. One could also see "TCP accelerator" middleboxes doing similar things where the first flight gets replayed. In both of these cases, only one will actually successfully establish a TLS connection and move forwards, but if the successful one is the one that is aborted then the connection will fail. If 0RTT is rejected and both are allowed to proceed, then the bogus accidental replay will be dropped and the legit connection will succeed. Erik
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
