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