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)
The purpose of HelloRetryRequest is to allow for clients to not send full keys
for every single algorithm they support, yet allow the server to still pick
from that entire list if it needs to. PSK has no equivalent system; pre-shared
keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid
PSK identity is selected, the server can use HelloRetryRequest to reject a
group in favor of another supported by the client, but it can't reject the
suite or identity in this manner. The response to no acceptable PSK identity is
either to negotiate another suite or to abort with a fatal alert.
See draft 14 section 4.2.5:
https://tools.ietf.org/html/draft-ietf-tls-tls13-14#section-4.2.5
> > ## 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.
> > ## Implementation Pitfalls
> >
> > - Have you ensured that all support for SSL, RC4, EXPORT ciphers, and
> > MD5 (via the "signature_algorithm" extension) is completely removed from
> > all possible configurations that support TLS 1.3 or later, and that
> > attempts to use these obsolete capabilities fail correctly?
> > (see {{backward-compatibility}})
>
> Better to just nuke the code entierely for all versions.
>
> "Disabled" code has nasty tendency of coming back to life.
Emphatically agreed, however I worded it this way to be slightly more general.
If I said that all that code should be universally gutted, I'd risk more people
ignoring it due to the severe status quo bias that is very common. In lieu of
modernizing fully and dropping it completely, having these old features
disabled via the same compile-time option that enables building of TLS 1.3
would be acceptable, IMO (though, more trouble than it should be worth, and
still not ideal at all). Bikeshedding better wordings in this section would not
be unwelcome, if you think anything here can be made better.
> > - Do you handle TLS extensions in ClientHello correctly, including
> > unknown extensions or omitting the extensions field completely?
>
> The extensions field can't be omitted in TLS 1.3. And I would
> consider TLS 1.2 client implementations that send such messages
> as quite pathological.
Implementations should be expected to handle pathological cases gracefully,
even if only to recognize and reject. ;)
Dave
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
