On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario <hka...@redhat.com> wrote:
> > > Speaking of version number, does the text say that a server _MUST_ > > > accept any version higher than the one that is specified in the RFC, > > > but reply with 0x03,0x04 in case it doesn't support any future > > > version of the protocol? It would be nice to have some kind of > > > stick for the broken implementations... > > > > I'm not sure I follow. The specification certainly spells out how > > version negotiation is supposed to work. That hasn't stopped servers > > from getting it wrong. Fundamentally this is the sort of thing where > > bugs don't get noticed until we make a new TLS version, and we don't > > do that often enough to keep rust from gathering. > > yes, but I don't see it spelling out anywhere that a server MUST accept > higher numbers, it just describes how the mechanism works up to this > point, not how it will continue to work > > I added an entry here a bit ago: https://tlswg.github.io/tls13-spec/#rfc.appendix.B.4 "When processing a ClientHello containing a version of { 3, 5 } or higher, do you respond with the highest common version of TLS rather than requiring an exact match?" The ServerHello section says: https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.2 "This field [server_version] will contain the lower of that suggested by the client in the ClientHello and the highest supported by the server. For this version of the specification, the version is { 3, 4 }. (See Appendix C for details about backward compatibility.)" Although the ClientHello section says: https://tlswg.github.io/tls13-spec/#rfc.section.6.3.1.1 "The version of the TLS protocol by which the client wishes to communicate during this session. This SHOULD be the latest (highest valued) version supported by the client. For this version of the specification, the version will be { 3, 4 }. (See Appendix C for details about backward compatibility.)" I'll go put together a PR to change that to say the highest version supported or something. "which the client wishes to communicate" is somewhat ambiguous... David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
