Re: [TLS] Closing on 0-RTT

[Eric Rescorla <[e-mail]>]

On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <[e-mail]> wrote:

> On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <[e-mail]> wrote:
>
>>
>> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <[e-mail]>
>> 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
>
>
>
>
>