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
