Re: [Last-Call] Last Call: Moving single-DES and IDEA TLS ciphersuites to Historic
Benjamin Kaduk <kaduk@mit.edu> Tue, 10 November 2020 22:44 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981533A11A2 for <last-call@ietfa.amsl.com>; Tue, 10 Nov 2020 14:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSZRl6c72Yhp for <last-call@ietfa.amsl.com>; Tue, 10 Nov 2020 14:44:13 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DFB3A11A6 for <last-call@ietf.org>; Tue, 10 Nov 2020 14:44:13 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AAMi6TG006167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2020 17:44:11 -0500
Date: Tue, 10 Nov 2020 14:44:06 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: John C Klensin <john-ietf@jck.com>
Cc: last-call@ietf.org
Message-ID: <20201110224406.GL39170@kduck.mit.edu>
References: <160496123639.8029.4334131339975211167@ietfa.amsl.com> <546D4F43-F227-4E78-8596-313776617B50@vigilsec.com> <2A3E251A56633647FD39A05D@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2A3E251A56633647FD39A05D@PSB>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/yJn2u6RjNHp4_yvJqg6O0H1kzDk>
Subject: Re: [Last-Call] Last Call: Moving single-DES and IDEA TLS ciphersuites to Historic
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2020 22:44:16 -0000
Hi John, On Tue, Nov 10, 2020 at 01:02:24PM -0500, John C Klensin wrote: > For all of the obvious reasons, I think reclassifying these > documents to historic is a good idea. _However_ if we are Glad to hear it. > 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. 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? > 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. 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 > 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 <iesg-secretary@ietf.org> > 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-c > > iphers-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 last-call@ietf.org mailing lists > > by 2020-12-07. Exceptionally, comments may be sent to > > iesg@ietf.org 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-c > > iphers-to-historic/ballot/ > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
- Re: [Last-Call] Last Call: Moving single-DES and … Russ Housley
- Re: [Last-Call] Last Call: Moving single-DES and … Paul Wouters
- Re: [Last-Call] Last Call: Moving single-DES and … John C Klensin
- Re: [Last-Call] Last Call: Moving single-DES and … Benjamin Kaduk
- Re: [Last-Call] Last Call: Moving single-DES and … Keith Moore
- Re: [Last-Call] Last Call: Moving single-DES and … Ted Lemon
- Re: [Last-Call] Last Call: Moving single-DES and … Benjamin Kaduk
- Re: [Last-Call] Last Call: Moving single-DES and … Keith Moore
- Re: [Last-Call] Last Call: Moving single-DES and … Benjamin Kaduk
- Re: [Last-Call] Last Call: Moving single-DES and … Sean Turner
- Re: [Last-Call] Last Call: Moving single-DES and … Salz, Rich