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

[Eric Rescorla <[e-mail]>]

On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <[e-mail]> wrote:

> As promised:
> https://github.com/tlswg/tls13-spec/pull/1005
>
> Note: I may have to do a little post-landing cleanup, but I wanted to get
> people's senses of the text ASAP.
>

Thanks for everyone's comments. I've updated the text to address many of
them and
made comments in Github where I decided not to do so. Can those who have
read
the previous version please take a look?

I'd also like to merge PR#998. I haven't heard any real complaints about it
and it's
an improvement in any case. I'll await the chairs on that, though.

-Ekr



Comments welcome.
> -Ekr
>
>
> On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla <[e-mail]> wrote:
>>>
>>>> I made some proposals yesterday
>>>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>>>
>>>> Specifically:
>>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>>> both session-cache and strike register styles and the merits of each.
>>>>
>>>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>>>
>>>> 3. Adopt PR#448 (or some variant) so that session-id style
>>>> implementations
>>>> provide PFS.
>>>>
>>>> 4. I would add to this that we recommend that proxy/CDN implementations
>>>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was
>>>> in
>>>> Colm's original message).
>>>>
>>>
>>> This all sounds great to me. I'm not sure that we need (4.) if we have
>>> (1.).  I think with (1.) - recombobulating to a single stream might even be
>>> best overall, to reduce application complexity, and it seems to be what
>>> most implementors are actually doing.
>>>
>>> I know that leaves the DKG attack, but from a client and servers
>>> perspective that attack is basically identical to a server timeout, and
>>> it's something that systems likely have some fault tolerance around. It's
>>> not /new/ broken-ness.
>>>
>>
>> Heh. Always happy to do less writing.
>>
>> Thanks,
>> -Ekr
>>
>>
>>>
>>>
>>>> Based on Colm's response, I think these largely hits the points he made
>>>> in his original message.
>>>>
>>>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>>>> What would be most helpful to me as Editor would be if people could
>>>> review
>>>> these PRs and/or suggest other specific changes that we should make
>>>> to the document.
>>>>
>>>
>>> Will do! Many thanks.
>>>
>>> --
>>> Colm
>>>
>>
>>
>