I think there are also multiple readings of "or higher" here. You could read it to mean "your protocol MUST require that implementations be configured to support all versions from TLS 1.3 and up". Or you could read it to mean "your protocol MUST pick a minimum TLS version of TLS 1.3, or some higher minimum version". I interpreted the discussion in the room to mean the latter.
I notice the current text also talks about "default", but that seems confusing and/or meaningless. There is no such thing as a "default version" in TLS version negotiation. A protocol that uses TLS may have a default vs non-default application profile, but whether that means anything at all is application-dependent, and such profiles would specify a range of versions, not a single version. "MUST require TLS 1.3 or higher" and "MAY be compatible with TLS 1.2" are also contradictions. I took a stab below at revising based on what I think the current text was trying to capture, but it's pretty ambiguous as-is: > Any new protocol that uses TLS SHOULD specify that TLS 1.2 and below MUST NOT be negotiated. That is, the minimum TLS version should be TLS 1.3 (or a higher TLS version, when one becomes standardized). For example, QUIC [QUICTLS] requires TLS 1.3 and specifies that endpoints MUST terminate the connection if an older version is used. > > If deployment considerations are a concern, the protocol MAY permit TLS 1.2, but only as an additional, non-default application profile. The default application profile MUST forbid TLS 1.2 as above. As a counter example, the Usage Profile for DNS over TLS [DNSTLS] specifies TLS 1.2 as the default, while also allowing TLS 1.3. For newer specifications that choose to support TLS 1.2, those preferences are to be reversed. On Mon, Mar 25, 2024 at 8:29 PM Salz, Rich <rsalz= 40akamai....@dmarc.ietf.org> wrote: > > Speaking as non-chair (and my first post to the list). > > Welcome. > > Yes, distinguishing between the standard (or protocol spec) and the > implementation is a (hopefully slight?) source of confusion within the > draft. > > > New standards MUST require TLS 1.3 or higher. > > The problem with the "or higher" construct, one Jonathan Hoyland strongly > favors, is that it doesn't get you what you want, or at least what he > wants. > > > These implementations SHOULD have a way to configure the minimum > allowable TLS version to use. If this setting is configurable, any default > example MUST use TLS 1.3. If the TLS versions are not set in any > configuration, then the implementation MUST use TLS 1.3 or higher. > > Except for "or higher" (see below) this seems nice. > > OpenSSL used to allow "holes" in the protocols, which you said is what > wpa_supplicant allows. I think it was in 1.1 that OpenSSL moved to a > min/max approach. That is better because the common meaning of omitting the > max version is "the highest one available." > > The problem with the "holes" approach is that it tends to be "explicitly > enable the versions you want" because at first glance that's more > flexible. But when a new version comes along, your configuration is now > outdated until you go edit to add the new version. If you use the > "explicitly disable the versions you want" it turns out that almost all the > time what you are disabling is a sequence of old versions. In which case, > setting the min version is simpler. It is hard to see a scenario, except > for bugs, where "1.1,1.3" are allowed and "1.2" is a reasonable > configuration to have. > > I think in all but special cases specifying just the minimum is fine. The > only reason I can think of for specifying the max version is that you have > regulatory/compliance issues to comply with. > > The problem with "or higher" is that it needs context and timelines to be > useful. Let us suppose that I sell a program, Foobar, that uses the system > TLS provider but it is a DLL/.so because I want my customers to be able to > install updates that their OS vendor provides. Now suppose the IETF > specifies TLS 1.4 at T0. OS Vendor A supports it at T2, vendor B at T3, and > FreeTLS provides it at T1. And of course the events could happen in a > different order (except the RFC always comes first :) > > Who becomes non-compliant with the "or higher" construct and at what > Tn+delta? And if you say "the highest version available" you're making it > even more intractable/worse. > > The current wording seems the least disruptive to me. Yes, in some number > of years we'll have to do an update that says TLS 1.4, but that's a lot > less work. > > Hope this helps. > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
