> 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
