Subject: BCPs, Applicability Statements, and draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1)

From: John C Klensin <[email-masked]>
Date: Wed, 09 Dec 2020 00:23:06 -0500

(Changing the subject line and copying the IETF list for reasons
that will become obvious.  I hope that any follow-up will occur
on the IETF list only.)

--On Tuesday, December 8, 2020 19:38 -0500 Keith Moore
<[email-masked]> wrote:

>> I think it's clear from the fact that this document updates a
>> pile of  other documents and that we in fact have been
>> looking at revisions to  documents in the pipeline makes
>> clear that it is intended to constrain  implementations.
>> We've done quite a number of other deprecation  documents as
>> BCP and to the best of my knowledge they have generally  been
>> read this way.
> 
> Maybe that practice needs to change, because it is starting to
> look like an end run around the standards process.
> 
> I was just to the point of concluding that this document was
> Mostly Harmless because it was only being LC'ed for BCP, and I
> think it's somewhat reasonable as a statement of best
> operational practice, but ONLY if it's confined to that scope.
> 
> Now that you're claiming it is intended to constrain
> implementations, I must strongly object to its publication in
> its current form.

Keith,

First, thanks to Ben for what is, IMO, an excellent and fair
summary.  Period.  Not "but..." or "let's continue litigating
this already too-long thread".

I believe that there has been a increasing tendency in recent
years to use the BCP category for documents that, if 2026 were
taken seriously, would be required to be ordinary Technical
Specification or Applicability Statement documents.  My reading
of 2026 (including the paragraphs quoted by ekr) as well as the
distinction I think you are making is that a BCP should never be
used to alter the technical content of a standards track
document.  If we have a document, RFC NNNN that says "you MUST
do this in so-and-so way", then a BCP that says "regardless of
what RFC NNNN says, the best practice is to do it is this other
way".  That would (and, IMO, has) put us in the rather odd
position of defining something as a Standard (even if only a
"Proposed" one) and then turning around and saying "don't take
our standards seriously".  IMO, not good.

Saying in a BCP "the MUST in that other spec may have been a
little too strong" or "here a some circumstances in which a
SHOULD does not apply" are in more of a gray area.  

So, yes, I think a specification like this should have been
written somewhat differently and then published as a an updating
Technical Specification or as an Applicability Statement.   The
latter would, IMO, have been especially appropriate because
classifying those problem methods as "Limited Use" and then
explaining why people should be phasing them out  and why they
might not want to hurry to do that is precisely in line with
what A/S documents are supposed to be all about.  That was part
of what I was getting at when I asked for the clarification that
Ben mentioned.   However, because we have been using BCPs in
this way for quite a while, I don't think it is fair or
reasonable to jump on a WG that has gotten a document into Last
Call and say "despite all of the precedent for this, it is your
bad luck week and you need to go back to the drawing board".

So, IMO, if this situation is going to be straightened out, we
should let this document go with Ben's suggested changes but
should go back to the IETF list and push for some changes,
ideally binding on the IESG, which prevents our getting into
this kind of situation again.  In other words, while I think
this document  is a mistake as written, I think the authors and
WG are victims and we should not punish them for it.  Instead,
we should learn from this example and work to avoid its
happening again.  Or we should find out that the community does
not care and then proceed to revise 2026 accordingly.

    john

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Dec 2020 22:21:18 -0800

> our standards seriously".  IMO, not good.

We could look at process, or we could look at technology. Take for 
example one of the updated RFC, 3856, "A Presence Event Package for the 
Session Initiation Protocol (SIP)". The text says that it basically uses 
TLS to secure the connection. Changing the version of TLS has no 
functional impact on the specification, which relies only on 
version-independent properties of TLS such as confidentiality and 
authentication. The text only mentions a "version" of TLS through its 
references to RFC 2246, TLS 1.0, which was the version of TLS current at 
the time. Yes, the authors of that RFC did not write "TLS 1.0 or a later 
version". Had they done that, there would be no process issue. And I 
think that if we want a narrow process decision, we should start there: 
applications should anticipate that security requirements will change 
over time, and say something like "current version of TLS [RFC XXXX] or 
later."

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Dec 2020 05:46:15 -0500

> not care and then proceed to revise 2026 accordingly.

Of course the intent is not to punish the authors and/or the WG. Instead 
it's to avoid either (a) causing a significant fraction of the user 
community to have to compromise its security even more by having to use 
old hardware, operating systems, application software, and/or firmware 
to continue to interoperate with systems that cannot be upgraded; and 
(b) avoid the damage to IETF's reputation from making security 
recommendations that are unworkable in practice.

But as I wrote elsewhere I suspect it's too late to fix this document, 
and that arguing about the status of this document isn't likely to fix 
that situation at any rate.   So I just hope that the authors and/or 
IESG will try to Do The Right Thing and clarify scope before this is 
published.

I do agree that we (the community) need to stop using BCPs to make 
changes to standards-track protocol specifications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 9 Dec 2020 06:54:54 -0500

[recipient list trimmed to just ietf@]

On 12/9/20 1:21 AM, Christian Huitema wrote:
> example one of the updated RFC, 3856, "A Presence Event Package for 
> the Session Initiation Protocol (SIP)". The text says that it 
> basically uses TLS to secure the connection. Changing the version of 
> TLS has no functional impact on the specification, which relies only 
> on version-independent properties of TLS such as confidentiality and 
> references to RFC 2246, TLS 1.0, which was the version of TLS current 
> at the time. Yes, the authors of that RFC did not write "TLS 1.0 or a 
> later version". Had they done that, there would be no process issue. 
> And I think that if we want a narrow process decision, we should start 
> there: applications should anticipate that security requirements will 
> change over time, and say something like "current version of TLS [RFC 
> XXXX] or later."

I certainly agree that the majority of specifications that reference TLS 
version X SHOULD NOT be updated when TLS version X falls from favor and 
TLS version X+n is now considered the minimum version that's appropriate 
for use.   Revising any RFC can be like opening Pandora's box, because 
the new RFC is then expected to meet current document standards for 
boilerplate, references and dependencies, language, and who knows what 
else.  It also introduces the potential to find new issues and rehash 
old ones. None of those things is inherently bad by itself, but together 
they can require an immense effort for usually marginal benefit. The 
revision may even increase the potential for confusion in the community 
of RFC users as they try to reconcile minor differences between versions.

And yet, one of the problems with SSL 1.0 and all subsequent versions 
seems to be the notion that you can wave a magic wand and create 
"security" as a black box that applications or users don't have to worry 
about.  I would argue that in some cases, applications DO need to worry 
about that layer, and dealing with version transitions is arguably one 
of those cases.  Because the Right Thing to happen when the encryption 
layer needs to improve based on new threats is almost never for existing 
services that people depend on to fail suddenly and/or for no apparent 
reason, and not every use of TLS is an interactive application with a 
user in the loop who can understand the problem and initiate corrective 
action.

I'm reminded again that successful transitions often need more than one 
step before they reach the desired final state, just as it's easier to 
cross a stream by stepping on a stone or two along the way than to try 
to leap across the whole thing.   (And in the absence of such stepping 
stones or a bridge or ferry or whatever, some people may find themselves 
unable to cross.)   Maybe it's worth trying to find a better way to 
upgrade TLS before we discover that TLS 1.2 needs to be deprecated.

Keith

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 9 Dec 2020 07:27:11 -0500

+1 (as a & discussant on RFC 1818 and as the editor of 2026 )

Scott

> On Dec 9, 2020, at 12:23 AM, John C Klensin <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Wed, 09 Dec 2020 05:02:29 -0800 (PST)

+1 as well. The problem of BCPs modifying standards needs to be addressed,
but this is not the right context for that to happen. The operational
considerations text that has been proposed is sufficiently curative that
it is OK for this document to move forward with that addition.

				Ned

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call