On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekr...@fb.com> 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.
Erik
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
