BCP 195 seems very clear, though: it prefaces the list of "MUST NOT"s with text calling them "recommendations."
Both sides seem to have a logically consistent viewpoint here, but it hinges on what the meaning and scope of a BCP actually is. Interpreting the name, "Best Current Practice" should mean that it's a statement on what the IETF
believes is the best choice at the moment. It does feel strange that a BCP can make normative updates to Standards-track documents, precedent or not. I totally see why Keith feels like this is an end-run around the Standards process; if that's valid, then
BCP isn't quite what it sounds like it should be. I don't see anything in BCP 9 that prohibits doing so, but making changes to protocol requirements doesn't feel like it's in the spirit of what BCP 9 Section 5 describes.
Publishing this (on either track) does not mean all implementations will conform or need to conform. Just as business pressures will cause some deployments to still use old versions, they will exert business pressure on the implementations
they use to keep support for those old versions. Some will, and some won't. That's a consideration outside the IETF's purview.
This document says that the IETF's best guidance is not to use old crypto at all, even with protocols that mandated old TLS versions. I don't think that's a false statement, so publishing is probably fine; I would be more certain
about that if it were Standards track instead of BCP.
Personally, I think this discussion highlights more about the lack of clarity around what BCPs are than about the document itself.
Sent from
Nine
From: Martin Thomson <mt@xxxxxxxxxxxxxx>
Sent: Tuesday, December 8, 2020 8:07 PM
To: last-call@xxxxxxxx
Subject: Re: [Last-Call] Results of Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
Sent: Tuesday, December 8, 2020 8:07 PM
To: last-call@xxxxxxxx
Subject: Re: [Last-Call] Results of Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On Wed, Dec 9, 2020, at 11:50, Keith Moore wrote:
> > Well, speaking as someone with no authority, it appears to me that
> > you are in the minority in that opinion, but I'll leave the AD to
> > handle it.
> This is a newly discovered issue, and there's been no input on this
> besides from you and me.
Hi Keith,
BCP 195 very much constrains implementations already. I don't think your view holds here.
(I know that argument from precedent is a logical fallacy in many cases, but I think that it's the best argument here.)
Either way, the effect is the same: the document represents the consensus view of the IETF.
Cheers,
Martin
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
> > Well, speaking as someone with no authority, it appears to me that
> > you are in the minority in that opinion, but I'll leave the AD to
> > handle it.
> This is a newly discovered issue, and there's been no input on this
> besides from you and me.
Hi Keith,
BCP 195 very much constrains implementations already. I don't think your view holds here.
(I know that argument from precedent is a logical fallacy in many cases, but I think that it's the best argument here.)
Either way, the effect is the same: the document represents the consensus view of the IETF.
Cheers,
Martin
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
