Re: [TLS] Closing on 0-RTT

It looks like we're ready to merge this PR please do so.

Please note that we will redo WGLC to make ensure that the changes incorporated since the 1st WGLC are the consensus of the WG.

spt

Sent from my iPhone

> On Jun 30, 2017, at 13:23, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
>> On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <nygren@akamai.com> wrote:
>>> On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>> 
>>>> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bkaduk@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