Hi Keith,
On Tue, Dec 08, 2020 at 09:21:17PM -0500, Keith Moore wrote:
> On 12/8/20 9:07 PM, Stephen Farrell wrote:
>
> > (replying to ekr, but really a question for you...)
> >
> > On 09/12/2020 01:55, Eric Rescorla wrote:
> >>>
> >> I'm curious, what do you think the point of having this update all the
> >> other documents was if it wasn't to constrain implementations?
> >
> > When answering that, can you clarify what you mean by
> > "constrain" and where there's a downside to your idea
> > of that? It's not clear to me at any rate.
>
> Because the requested status was Best Current Practice, I didn't
> interpret this document as saying that implementations of TLS must
> prevent operators from enabling TLS versions prior to 1.2. ("Best"
> implies that other practices can be chosen.)
I don't think that there is anything surprising about the mechanics of the
"Updates:" relationship here (even if we have recently established that
there is not widespread agreement about when the "Updates:" tag should be
used). To take some concrete numbers as an example, suppose that this
draft becomes RFC 9001 (an arbitrarily selected number). It has an
Updates: relationship to RFC 3261. RFC 3261 existed 18 years ago, exists
now, and will continue to exist when RFC 9001 is published. You can
implement it. Your implementation remains RFC 3261 compliant even as RFC
3261 is updated by RFC 9001. Now when RFC 9001 comes around, there is some
kind of abstract logical entity that is
RFC-3261-with-RFC-9001-updates-applied. An implementation of that combined
entity (that implements TLS at all, as RFC 3261 doesn't seem to require a
TLS implementation) will use TLS 1.2 as the minimum TLS version. An
implementation of RFC 3261 might use TLS 1.0 as the minimum TLS version
and would be perfectly justified in continuing to do so even after RFC 9001
exists. Compliance with either RFC 3261 or RFC-3261-as-updated-by-RFC-9001
remains optional.
This is all bog-standard Updates: relationships and all of these Updates:
headers were in the draft that went to IETF Last Call. We even had some
people explicitly call out their support for doing it this way with the
pile of Updates:.
> The downside is that operators may effectively be forced to break
> interoperability with existing clients and/or servers, that provide
> essential functionality, if some of their software is upgraded to
> reflect the recommendations in
> draft-ietf-tls-oldversions-deprecate-09. They may be forced to do this
Yes. That's why I proposed text to say exactly that. Operators can decide
which risk they want to bear, based on the best information we are able to
provide at the current time. They can also supply input to implementations
as to their operational reality and requirements.
> even when the operators have valid operational reasons for continuing to
> use TLS < 1.2, have explicitly evaluated the risks with doing so, used
> their exception processes to justify doing so, etc. (Because it's
I'm sorry; I don't follow this step. Who is forcing anything? I can
assure you that the IETF is not.
> generally not feasible to postpone upgrades indefinitely or sometimes
> even for a short time; there are often interdependencies that preclude
> doing that.)
If you are constrained to not take certain updates for whatever reason,
there are some other updates you may not safely be able to take. Not all
patches are commutative. How is this new?
Thanks,
Ben
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
