Re: [IPsec] revisiting 3DES and -graveyard

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 April 2020 15:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8F3A09F3 for <ipsec@ietfa.amsl.com>; Wed, 15 Apr 2020 08:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gTb7WKu9h5zM for <ipsec@ietfa.amsl.com>; Wed, 15 Apr 2020 08:03:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CF23A09F4 for <ipsec@ietf.org>; Wed, 15 Apr 2020 08:03:50 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 649C33897B; Wed, 15 Apr 2020 11:02:07 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1081D602; Wed, 15 Apr 2020 11:03:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>, ipsec@ietf.org
In-Reply-To: <20200415021321.GI88064@mit.edu>
References: <20200415021321.GI88064@mit.edu>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 15 Apr 2020 11:03:49 -0400
Message-ID: <12805.1586963029@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/DTFunm7GY5gFM2UKew0Z6iigDBY>
Subject: Re: [IPsec] revisiting 3DES and -graveyard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 15:03:54 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    > I see in
    > https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00
    > that we didn't want to get rid of 3DES at that time.  Do we have a sense
    > for how quickly that will change, the scope of existing deployments,
    > etc.?

    > In particular, would a general-purpose OS's implementation cause problems
    > for its consumers if the next release dropped support?  (Noting that
    > consumers could stay on an old OS release to match the old algorithms, at
    > least for a while.)

1) They all have AES128, and have had it for at least a decade.

2) general-purpose OS implementations are (sadly) *not* being used by the majority
   of "VPN" users, whether that's site-to-site or remote-access.
   Except on iOS and Android, where OS-provided IKEv2/IPsec is winning,
   and I'll bet they could drop 3DES tomorrow.

The last time I have seen 3DES configured was for site-to-site VPNs between
different (medical!) enterprises because neither side could be sure what the
other side had, and equipment was old.  They didn't dare change the configuration, or
replace the hardware.  (Cargo culting...) This was maybe 6 years ago.

I believe that we could remove it.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-