On 12/8/20 9:36 PM, Stephen Farrell wrote:
ISTM the "MUST NOT" bits of the draft are pretty clear, and I
don't see how they ever could have been unclear. (One could
disagree as to the wisdom and timeliness of course, but
that's a different issue.) For example, it says "TLSv1.0 MUST
NOT be used. Negotiation of TLSv1.0 from any version of TLS
MUST NOT be permitted." My interpretation of Ben's mail was
that the responsible AD figured there was IETF consensus for
those MUST NOT statements. The IESG will or won't (dis)agree
with that when they get to it.
To me "MUST NOT" only made sense in the context of "Best Current
Practice" as in "if you violate this MUST NOT, you aren't conforming to
this recommendation". Because to absolutely forbid implementations to
use TLS < 1.2 in all circumstances is unacceptably disruptive. The
only thing that made the document at all acceptable was that the
intended status was BCP.
I also think that consensus on one status (if it exists) does not equate
to consensus on another status. The community was asked to evaluate
the document as a Best Current Practice, which clearly means something
different than evaluating it as a protocol specification.
That said, the text does not "prevent" implementers from
doing whatever they want, it just expresses (what may turn
out to be) IETF consensus on the topic.
Right. There are still no Protocol Police as far as I know. But the
practical effect of publishing this document may be that implementations
remove support for TLS 1.0 and 1.1, even though (as Kathleen pointed
out) an organization might explicitly decide to accept the business risk
of continuing to use one or both of those.
Anyone can of course continue to use TLSv1.0 (or SSLv3 if
perverse reality requires that;-) and the net result is only
that they won't conform to our latest BCPs. I think that's
ok myself.
Practically speaking, "anyone" probably cannot do that. You or I and
some others here are technically capable of that if we had the time to
spare, but probably few if any of us does.
From the recent conversation it seems clear that a primary goal of this
document is not merely to make recommendations about operational
practice, but to actually reduce the options available to operators. To
eradicate TLS < 1.2 like we'd like to eradicate COVID.
------
I want to take a step back. I don't think it's appropriate to use BCP
as a way to get implementations to remove support for TLS < 1.2. I
also think if people ask the community to approve a document, then they
should be really clear and consistent about what they're asking for. In
my mind the Right Thing to do from a process standpoint is to make the
document text and intended status clear and consistent with one another
and Last Call it again.
But I also seriously doubt that debates over document status will result
in a transition to TLS >= 1.2 with less disruption to essential
operations (which is in fact my goal), or (sadly) even a clearer
document. All of my IETF experience (that I can remember) says that
late debates only serve to consume time and energy, frustrate people,
delay the result, and muddy the waters even more. So I don't want to
take things in that direction.
I certainly want to see stronger encryption and wider use of encryption,
and am sensitive to the notion that implementations that support older
versions of TLS can often be subjected to downgrading attacks. But I
also want existing uses of TLS < 1.2 that can't easily be upgraded to
NOT have to run old operating systems and/or old clients/servers and/or
old hardware (with the associated additional security vulnerabilities)
just to be able to continue to work until, say, the legacy hardware can
be replaced, the existing assembly lines can be dismantled, etc.
And I guess I just think that this document needs to acknowledge that
problem and allow some wiggle room for operators who have to deal with it.
Keith
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
