On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara <[email protected]> wrote:
> On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote: > > Thanks for the quick review. > > > > On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara < > [email protected]> > > wrote: > > > > - I note that accepting PSK and selecting the auth mode seem to be > > > in separate messages, which seems quite annoying implementation- > > > wise.. > > > > > > Can you elaborate on this? The intend is that they both appear in > > ServerHello > > (in pre_shared_key and signature_algorithms respectively). > > Eeh, I thought it was in EncryptedExtensions. Reading the text > again, it is IMO really unclear where it goes. > > Checking the extension table, it says "Client". Which impiles that > servers don't send it, but 4.2.2 says servers must send it in some > cases. > Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in ServerHello. That was the intent for this draft. > - Can the server send arbitrary certificate in response to PSK or is > > > it somehow restricted? The document does not seem to talk about it. > > > > > > > The document right now is supposed to be PSK XOR server signs, so the > > answer is supposed to be "no". If/when we allow both together, then > > we'll have to address this, which is a bit tricky. > > 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 HelloRetryRequest is problematic in pure-PSK case[1]. > > > > > > > > > [1] One way to do it would be to move the group to extension, which > > > would only be sent if new group was needed. Then one could always > > > require at least one extension (the field could also be renamed). > > > Also, one could make it so that HRR extensions don't have to > > > correspond to CH extensions (and unsupported one is a fatal error). > > > > > > > Agreed on both counts. PR wanted. > > https://github.com/tlswg/tls13-spec/issues/560 > > 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. -Ekr > > > -Ilari >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
