Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla <[e-mail]>]

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren <[e-mail]> wrote:

> On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>>
>> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <[e-mail]> wrote:
>>
>>> > 1. A SHOULD-level requirement for server-side 0-RTT defense,
>>> explaining both session-cache and strike register styles and the merits of
>>> each.
>>>
>>>
>>>
>>> First, a point of clarification, I think two issues have been conflated
>>> in this long thread:
>>>
>>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>>> cache/strike register/replay cache/some other method)
>>>
>>>
>>>
>>> There are definitely cases (i.e. application profiles) where this should
>>> be done. I think a general case HTTPS server is one. But I don’t think this
>>> is strictly necessary across the board (for every application using 0-RTT
>>> at all). DNS was brought up earlier in this thread as an example of a
>>> protocol that is likely quite workable without extra measures to prevent
>>> replay.
>>>
>>>
>>>
>>> We already state “Protocols MUST NOT use 0-RTT data without a profile
>>> that defines its use.”. We could also describe methods that may be used to
>>> provide further replay protection. But I don’t think it’s appropriate to
>>> make a blanket requirement that *all* application protocols should require
>>> it.
>>>
>>>
>>>
>>> I also consider it quite misleading to say TLS 1.3 is insecure without
>>> such a recommendation. Uses of TLS can be insecure, that does not mean the
>>> protocol itself is. It’s insecure to use TLS without properly
>>> authenticating the server. Some users of TLS do not do this correctly. I’d
>>> actually argue that it is easier to mess this up than it is to mess up a
>>> 0-RTT deployment (and it can result in worse consequences). That doesn’t
>>> mean we should require a particular method of authentication, for all uses
>>> of TLS.
>>>
>>
>> I think this is basically right. In the PR I just posted, I spent most of
>> my time describing the
>> mechanisms and used a SHOULD-level requirement to do one of the
>> mechanisms.
>> I think there's a bunch of room to wordsmith the requirement. Perhaps we
>> say:
>>
>> - You can't do 0-RTT without an application profile
>> - Absent the application profile saying otherwise you SHOULD/MUST do one
>> of these mitigations?
>>
>
> I generally agree with Kyle here (and also added a few minor comments to
> the PR).
> I think we should be clear where the responsibilities generally lie as
> well, for example:
>
> "The onus is on clients not to send messages in 0-RTT data which are not
> safe to have replayed and which they would not be willing to retry across
> multiple 1-RTT connections. The onus is on servers to protect themselves
> against attacks employing 0-RTT data replication."
>
> The server responsibility is a general property TLS can maintain while the
> client responsibility requires an application profile to define.
>

These seem like good changes. I will work to incorporate them.

-Ekr


>
>         Erik
>
>