Subject: Re: [Last-Call] Last Call: Moving single-DES and IDEA TLS ciphersuites to Historic

From: Russ Housley <[email-masked]>
Date: Tue, 10 Nov 2020 09:27:06 -0500

Removing these is a good move.  Please proceed promptly.

Russ

On Nov 9, 2020, at 5:33 PM, The IESG <[email-masked]> wrote:
> 
> The IESG has received a request from an individual participant to make the
> following status changes:
> 
> - RFC5469 from Informational to Historic
>    (DES and IDEA Cipher Suites for Transport Layer Security (TLS))
> 
> The supporting document for this request can be found here:
> 
> https://datatracker.ietf.org/doc/status-change-tls-des-idea-ciphers-to-historic/
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-12-07. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> The affected document can be obtained via
> https://datatracker.ietf.org/doc/rfc5469/
> 
> IESG discussion of this request can be tracked via
> https://datatracker.ietf.org/doc/status-change-tls-des-idea-ciphers-to-historic/ballot/

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Nov 2020 09:33:15 -0500

> Removing these is a good move.  Please proceed promptly.

Yes. This is a no-brainer. Kill them :)

Paul

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Nov 2020 13:02:24 -0500

For all of the obvious reasons, I think reclassifying these
documents to historic is a good idea.  _However_ if we are
really trying to say "don't use these, they are obsolete and
unsafe" rather than just "no current specification refers to
them but do what you like", I believe that it would be better to
publish a short RFC explaining the issues with them rather than
simply making a datatracker note that points to a "supporting
document", particularly one that doesn't actually say much of
anything.

That should be especially easy because
draft-ietf-tls-oldversions-deprecate-09 already obsoletes 5469,
so why not simply add a sentence there, update the Last Call to
identify the move as "to Historic" as well as "Obsoleted", and
move on.  

Being clear about this seems especially important because RFC
5246, published a five months before 5469, says 

	"Removed IDEA and DES cipher suites.  They are now
	deprecated and will be documented in a separate
	document."

but gives no explanation.   RFC 5469 is presumably the document
being promised, but there is no information in the RFC index
(or, AFAICT, other obvious RFC metadate) binding them together.
Under normal circumstances (which these obviously were not) it
would have been appropriate to publish 5469 as Historic since
the relevant protocols were already deprecated but, presumably
does not indicate that it updates 5246 (to provide the promised
information) because it was published as Informational rather
than Standards Track or BCP.

So, a further suggestion is that
draft-ietf-tls-oldversions-deprecate-09 be further modified to
update 5246 (assuming we are not ready to obsolete it), stating
simply that 5469 is the document describing the IDEA and DES and
the reasons for removing them called for by 5246.

The most common complaint I hear from outside the IETF community
about how we make and document standards is that it is nearly
impossible to ascertain what is and is not relevant to a given
specification and/or current.  Why document an action that might
help clarify such situations by moving a document to Historic in
a way that might make the situation worse and leave loose ends
dangling?

    john

On Nov 9, 2020, at 5:33 PM, The IESG <[email-masked]>
wrote:
> 
> The IESG has received a request from an individual
> participant to make the following status changes:
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists
> by 2020-12-07. Exceptionally, comments may be sent to
> [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Nov 2020 14:44:06 -0800

Hi John,

> documents to historic is a good idea.  _However_ if we are

Glad to hear it.

> identify the move as "to Historic" as well as "Obsoleted", and

I confess that I'm rather confused, given that my understanding of what
your propose above matches exactly with what I believe we are doing.
I note that current IESG procedures require the existence of a
status-change document to effectuate a status change, even if there is also
an associated RFC-to-be that describes the situation in more detail.
References to the status-change document in the datatracker can then be
replaced by references to the (then-)RFC when the RFC in question actually
gets published.  So, in the text at
https://datatracker.ietf.org/doc/status-change-tls-des-idea-ciphers-to-historic/,
when we see:

% Upon approval and its publication as an RFC,
% draft-ietf-tls-oldversions-deprecate should replace this status change
% document as the reference for the status change event.

that is intended to indicate that references to the status change document
here will eventually be replaced by references to
RFC-ietf-tls-oldversions-deprecate.  Likewise, in
https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-09#section-1.1
we see:

   The DES and IDEA cipher suites specified in [RFC5469] were
   specifically removed from TLSv1.2 by [RFC5246]; since the only
   versions of TLS for which their usage is defined are now Historic,
   RFC 5469 (will be|has been) moved to Historic as well.

What am I missing?

> the reasons for removing them called for by 5246.

That's an interesting idea, though it's not entirely clear to me how well
it fits into the intended content of draft-ietf-tls-oldversions-deprecate,
which is otherwise not modifying TLS 1.2 at all.
It would be good to hear additional considered  opinions on this matter.

Thanks,

Ben

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Nov 2020 14:47:49 -0500

> document", particularly one that doesn't actually say much of

I agree that some sort of RFC is appropriate.   One of my growing 
concerns is that deprecating old TLS ciphersuites is breaking old 
systems that are still in use, and actually preventing them from having 
any of their software upgraded, because there are no web browsers that 
run on those systems that support the ciphersuites used by current servers.

So IMO, simply saying "don't use these" is NOT good advice, and instead 
the advice should be something like "treat these ciphersuites as if they 
were unencrypted connections".   I realize that this will make the 
purists uncomfortable, but I think the discussion needs to be had.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Nov 2020 14:56:33 -0500

This seems like a thin argument. These systems have had decades to be upgraded. If they weren’t upgraded before, why would they be now?

Also, anything that’s that deeply old is being operated by someone who can transfer the file to their modern mac and then ftp it over to the ancient iron.

And finally, we are deprecating the cipher suites. People in this situation can simple use old vulnerable software with the ancient ciphersuites on the update server. But this is a bad outcome because the update is now an attack vector. Better to use a secure browser and ftp for the last mile. 

> On Nov 16, 2020, at 14:48, Keith Moore <[email-masked]> wrote:
> 
> I agree that some sort of RFC is appropriate.   One of my growing concerns is that deprecating old TLS ciphersuites is breaking old systems that are still in use, and actually preventing them from having any of their software upgraded, because there are no web browsers that run on those systems that support the ciphersuites used by current servers.
> 
> So IMO, simply saying "don't use these" is NOT good advice, and instead the advice should be something like "treat these ciphersuites as if they were unencrypted connections".   I realize that this will make the purists uncomfortable, but I think the discussion needs to be had.
> 
> Keith
> 
> 
> -- 
> last-call mailing list
> [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Nov 2020 16:03:20 -0800

Hi Keith,

A few things I'll try to unpack here and get more input from you on...

> concerns is that deprecating old TLS ciphersuites is breaking old 

When you say "deprecating old TLS ciphersuites" are you thinking
specifically the single-DES and IDEA ciphersuites of this action, or
extrapolating to a broader class of things?

> systems that are still in use, and actually preventing them from having 

Us publishing an RFC doesn't break things; implementations changing breaks
things.  And there are, of course, two endpoints to any TLS communication;
issues occur when only one is upgraded to a software that removes support
for the deprecated stuff (upgrading both would seem to allow a clean
transition)...

> run on those systems that support the ciphersuites used by current servers.

...and you seem to be concerned about the case where a server is upgraded
to remove support for old stuff (see above question about these specific
ciphers vs "stuff" generically), but a client is stuck with old software.
What about the reverse case, where the client can upgrade/has upgraded but
the server is stuck on old software?

> purists uncomfortable, but I think the discussion needs to be had.

I'm not sure that we have a great way to reflect such sentiment in terms of
our formal document statuses.  I note that openssl, for example, is
exercising a fairly considered approach to this sort of thing, moving
weaker ciphers/algorithms out of the default "security level" but leaving
them implemented for a while, so you can opt in to using the weak stuff but
the out-of-the-box default is still secure.  Only after an additional
deprecation period are the weak ciphers actually removed.

So, I am okay with the IETF saying that this stuff is historic, and letting
implementations choose whether or not they want to keep historic stuff
around for an extended transition period.

If you are specifically concerned about the major browsers and their
deprecation+removal schedules, that seems to be a recurring conversation
that comes up periodically; I will summarize my stance on that question as
being that the browsers have a given target market that they are providing
a free product to, and if you are outside of that target market, it's
unfortunate, but the browsers don't have an economic incentive to provide
free support to everyone and I don't see the IETF changing that.

Thanks,

Ben

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Nov 2020 19:16:08 -0500

> extrapolating to a broader class of things?

oh, dear.  I think I replied to the wrong Last Call message.   I have no 
objections whatsoever to deprecating 1DES and IDEA.

Let me go back and look and figure out which LC I was really concerned 
about, and reply to _that_ message.    Hopefully that reply will make 
more sense.

But you can safely disregard my message about this action.

Keith

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Nov 2020 16:31:43 -0800

> But you can safely disregard my message about this action.

Ah, thanks for the clarification.  I'll look for your response to the
intended thread!

-Ben

---

From: Sean Turner <[email-masked]>
Date: Thu, 19 Nov 2020 23:45:51 -0500

Please do this!

spt

> On Nov 9, 2020, at 17:33, The IESG <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Nov 2020 04:50:23 +0000

Yes, please make DES and IDEA for TLS history.  Er, historic.

On 11/19/20, 11:46 PM, "Sean Turner" <[email-masked]> wrote:

    Please do this!

    spt