Re: [TLS] draft-ietf-tls-tls13-15

[Eric Rescorla <[e-mail]>]

I've reviewed David's PR and I think it's basically sound. Unless I hear
some objection to this over the weekend, I intend to merge it or some
revised version on Monday.

-Ekr


On Thu, Aug 18, 2016 at 8:00 AM, David Benjamin <[e-mail]>
wrote:

> On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara <[e-mail]>
> wrote:
>
>> > > David Bejamin already posted a PR about that. Doesn't clearly say
>> > > that unknown reason handling.
>> > >
>> >
>> > Yeah, I read the list before the PRs. I'll take a look but if you want
>> to
>> > comment that would be great.
>>
>> The only comment is that I would prefer to allow extensions the without
>> client including them in ClientHello[1] (obviously fatal if unknown one is
>> seen[2]), instead of special-casing Cookie.
>>
>
> FWIW, I'm not a fan of special-casing Cookie either. I just left it alone
> for that PR and only bothered about moving to an extension since I wasn't
> sure how it should work.
>
> Just removing the requirement altogether seems reasonable? Although it
> doesn't give much guidance on which are and aren't MTI. Is a TLS client
> over TCP obligated to implement Cookie to avoid interop issues? Seems kind
> of pointless to require it there, just more things to remember. Whereas a
> DTLS client over UDP which doesn't implement cookie is unlikely to work
> well. But probably that kind of guidance ought to live elsewhere anyway. Or
> maybe we should just declare cookie MTI everywhere and leave it at that.
>
> (Though, I'm sure, in practice, no one will ever send cookie over TLS and
> thus some clients won't honor it.)
>
> David
>
>
>>
>> [1] Of course, if the error is related to values in extension, then the
>> client had to include it in its ClientHello.
>>
>>
>> [2] Basically, if client is told that its ClientHello is wrong in some
>> way it does not understand, obviously it can't fix it.
>>
>