On Thu, Aug 18, 2016 at 05:55:16AM -0700, Eric Rescorla wrote: > On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara <[email protected]> > wrote: > > Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in > ServerHello. That was the intent for this draft.
Okay, good to know (/me goes to change it in his code). > > Then why does that server signature_algorithms exist? I think that > > special PSK authentication modes should be specified in the PSK > > extension, so non-PSK clients don't get confused and do inapporiate > > things with those indications. > > > > Can you elaborate on what you mean here? If it's what I think you mean > (namely put it in the server's pre_share_key message) I used to have that > and davidben convinced me this was better. There's no perfect encoding > here, AFAICT, so if you want to make an alternate suggestion that we could > take a look at, that would be great. The issue I'm thinking about is that if missing signature_algorithms means no certificate, some dumb TLS implementation (and there are plenty of those) will heed that even in non-PSK mode... > > 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. [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. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
