On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <nyg...@akamai.com> wrote:
> 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. > Sure, and this is a good reason to hard fail because it helps us find stuff like that. 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. > Sure, though of course clients can also retry. -Ekr > 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
