On Fri, Mar 2, 2018 at 12:21 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote: > > > > I believe you are misinterpreting the text, but agree that it could > > be > > made more clear. > > > > Suppose that the ClientHello includes a supported_versions > > extensions > > that contains two values, TLS 1.4 and TLS 1.0, and the server > > supports > > TLS 1.3 and below. My interpretation of the current draft is that > > the > > server MUST use the supported_versions extension to determine the > > client's preference, but then once deciding to use TLS 1.0 for the > > connection sends a normal TLS 1.0 ServerHello, with version field set > > to > > 0x0300 and no supported_versions extension. Note that Section 4.2.1 > > says > > that > > > > A server which negotiates TLS 1.3 MUST respond by sending a > > "supported_versions" extension containing the selected version > > value (0x0304). > > > > It says nothing about a server that negotiates an earlier version. > > > > If my understanding is correct, then I believe the text in Section > > 4.1.3 > > could be made more clear. Draft -21 said that the version field of > > ServerHello "contains the version of TLS negotiated for this > > connection." (this is similar to what RFC 5246 said). The current > > draft > > says: > > > > In TLS 1.3, the TLS server indicates its version using the > > "supported_versions" extension (Section 4.2.1), and the > > legacy_version field MUST be set to 0x0303, which is the > > version number for TLS 1.2. > > > > To be consistent with RFC 5246 and earlier, it seems like the text > > should say something like: > > > > For a TLS 1.3 ServerHello the TLS server indicates its version > > using the "supported_versions" extension (Section 4.2.1), and > > the legacy_version field MUST be set to 0x0303, which is the > > version number for TLS 1.2. For a TLS 1.2 and earlier > > ServerHello > > the legacy_version field contains the version of TLS > > negotiated > > for this connection. > > I understand that this is an interpretation that makes more sense and > aligns with the -21 behavior, but I do not think that this is what this > text literally says. Both Eric in his previous email and another > engineer I've discussed the issue seem to agree that the intention is > to use the new mechanism for all negotiations. You disagree on that, > and it thus apparent that this text needs clarification. > I don't think that's what I meant. I agree with David that if you send ServerHello.supported_versions it ought not to contain TLS 1.2 or below. I missed this in -25, but I have a PR up for it now, so if this looks OK, I'll merge and spin -26. See: https://github.com/tlswg/tls13-spec/pull/1163 -Ekr > The text was written for -21 version which didn't have the server-side > part of the extension, and the flow was natural for pre-TLS1.3 > versions. When the change was done in -22 to include the server-side of > the extension, this ambiguity (in your view) and complicated side- > effect (in my view) was introduced. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
