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 <[email protected]> wrote: > On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara <[email protected]> > 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. >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
