On Tue, Jul 12, 2016 at 01:52:57AM -0400, Dave Garrett wrote:
> Just replying to a few points.
>
> On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote:
> > ### Hello Retry Request
> >
> > > selected_group
> > > : The mutually supported group the server intends to negotiate and
> > > is requesting a retried ClientHello/KeyShare for.
> > > {:br }
> >
> > What is written into this field if server selects pure-PSK ciphersuite
> > and then decides to reject the ClientHello? Or connections that use
> > pure-PSK just plain can't be rejected for any reason (including IP
> > address verification in DTLS?)
>
> The HelloRetryRequest message is not applicable to pure-PSK, which
> does not use the KeyShare extension at all. PSK has its own separate
> extension. ((EC)DHE-PSK uses both together)
Yes, rejection because of group mismatch can't occur. However, I don't
see any requirement not to reject pure-PSK for cookie check (might be
feasible, if the computational and network load is determined "small
enough").
> > > ## Cipher Suites
> > >
> > > Note: The values listed for ECDHE and ChaCha/Poly are preliminary but
> > > are being or will be used for interop testing and therefore are likely to
> > > be
> > > assigned.
> >
> > Isn't the RFC already published, so the codepoints are stable?
>
> xiaoyinl fixed the second one of those notes, but that was merged
> after the checkpoint for draft 14. I'll fix this one to just note
> for ECDHE PSK AES.
IIRC, there was merged patch that changed the reference, but not the
text. Just checked, seems to still be there in Editor's Copy.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
