IETF Logo Mail Archive

Re: [IPsec] revisiting 3DES and -graveyard

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 April 2020 01:48 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 2021A3A150F for <ipsec@ietfa.amsl.com>; Mon, 20 Apr 2020 18:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 tojS1B6lLb5D for <ipsec@ietfa.amsl.com>; Mon, 20 Apr 2020 18:48:05 -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 96B6F3A150D for <ipsec@ietf.org>; Mon, 20 Apr 2020 18:48:05 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 068D038980; Mon, 20 Apr 2020 21:46:16 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3AB363F; Mon, 20 Apr 2020 21:48:02 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: ipsec@ietf.org
In-Reply-To: <20200421000037.GC27494@kduck.mit.edu>
References: <20200415021321.GI88064@mit.edu> <12805.1586963029@localhost> <20200421000037.GC27494@kduck.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: Mon, 20 Apr 2020 21:48:02 -0400
Message-ID: <3139.1587433682@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/qTgg2v2b9QBDGH8R99jUroul16E>
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: Tue, 21 Apr 2020 01:48:11 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    >> 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.

    > Funnily enough, we see a similar thing in the Kerberos world, with 3DES
    > cross-realm keys set up decades ago that everyone is afraid to touch :)
    > (It turns out that most of the time you don't actually need to get both
    > administrators in the same room to update things, and it can be done
    > asynchronously and asymmetrically, by one administrator at a time.)

That requires clue that the current operators (no longer/don't) have.
If it breaks, they don't how to fix or debug it either.

In short: as Tero has pointed out it's already SHOULD NOT, and making it MUST
NOT makes existing deployed products out of spec.  I guess we don't have to rush.

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

v2.23.0 | Report a Bug | By Email