On 20/07/18 13:42, David Benjamin wrote:
> I think that's the point of deciding this immediate question now, so we
> can get some text in the specification. If we decide to fix this, we'd
> instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs
> are configured and then, once the fixup document is published, implement
> it and remove the version logic. This is interoperable at all
> combinations as version negotiation runs first.
So, to be clear about this interim proposal:
1) If a client is configured with a 1.2 PSK but not a 1.3 PSK, it should
not provide supported versions, and only negotiate TLSv1.2 or lower. If
it has both then it should supply supported versions and advertise
support for TLSv1.3.
2) If a server is configured with a 1.2 PSK and not a 1.3 PSK it should
only select TLSv1.2 or lower.
3) If a server has separate 1.2 PSKs and 1.3 PSKs should it allow 1.3 to
be negotiated? Presumably "yes" to allow a phased roll out of TLSv1.3 to
clients.
Consider the case after Universal PSKs have been introduced. A client
that has not been explicitly configured for 1.3 PSKs can suddenly start
offering them and will issue a ClientHello containing supported versions
with TLSv1.3 in it. But if it then attempts to connect to a server which
does not support universal PSKs and has been explicitly configured with
separate 1.2 and 1.3 PSKs the server will select TLSv1.3, but then the
connection will fail because the explicit 1.3 PSK configured on the
server is not compatible with the Universal PSK offered by the client.
Or did I misunderstand something somewhere?
Matt
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
