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

Benjamin Kaduk <kaduk@mit.edu> Wed, 18 November 2020 00:03 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 3AA7E3A1016 for <last-call@ietfa.amsl.com>; Tue, 17 Nov 2020 16:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 y9JL3O34sy74 for <last-call@ietfa.amsl.com>; Tue, 17 Nov 2020 16:03:29 -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 2CA513A1093 for <last-call@ietf.org>; Tue, 17 Nov 2020 16:03:27 -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 0AI03K4V009631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 19:03:26 -0500
Date: Tue, 17 Nov 2020 16:03:20 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Keith Moore <moore@network-heretics.com>
Cc: last-call@ietf.org
Message-ID: <20201118000320.GS39170@kduck.mit.edu>
References: <160496123639.8029.4334131339975211167@ietfa.amsl.com> <546D4F43-F227-4E78-8596-313776617B50@vigilsec.com> <2A3E251A56633647FD39A05D@PSB> <91d124ec-8889-24dd-ffae-f03e39513f19@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <91d124ec-8889-24dd-ffae-f03e39513f19@network-heretics.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/pXJazu0CfT5AXkRwRlgLubofPHw>
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: Wed, 18 Nov 2020 00:03:30 -0000

Hi Keith,

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

On Mon, Nov 16, 2020 at 02:47:49PM -0500, Keith Moore wrote:
> On 11/10/20 1:02 PM, 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
> > 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.
> 
> I agree that some sort of RFC is appropriate.   One of my growing 
> 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)...

> any of their software upgraded, because there are no web browsers that 
> 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?

> 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.

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