Eric Rescorla <e...@rtfm.com> wrote: > Brian Smith <br...@briansmith.org> wrote: > >> Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> >>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when >>> there >>> are higher versions supported, but not overlapping). >>> >> >> Could you provide a concrete example, please? >> > > When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and > TLS 1.3 draft-17. >
> I would prefer to stick with the current design where if supported_versions > exists it is the sole mechanism for negotiation. > Note that in my suggestion, supported_versions is the sole mechanism for negotiation as well. With my suggestion, in your example where two different TLS 1.3 drafts are supported, by each end, the server will see that no supported draft of TLS 1.3 is supported and then negotiate TLS 1.2 if it supports TLS 1.2; otherwise it would give up. It can make this decision purely based on the contents of the supported_versions extension. Then if the client supports TLS 1.2 it will continue; otherwise it will abort. So there doesn't seem to be a significant benefit to advertising TLS 1.2 support in the extension. Especially since TLS 1.2 is a superset of TLS 1.1 and TLS 1.0, I don't think there's any need for TLS 1.0 or TLS 1.1 to be mentioned in the extension at all, even if the client supports them, because a server that supports this extension shouldn't ever negotiate TLS 1.0 or TLS 1.1. Imagine that we wanted to support clients that support TLS 1.0 and/or TLS 1.1, not TLS 1.2, but TLS 1.3, for some reason. Then we'd need to allow the legacy_version field to be TLS 1.1 or TLS 1.0. But, I don't think it's useful to support this. Cheers, Brian
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
