[IPsec] revisiting 3DES and -graveyard

Tero Kivinen <kivinen@iki.fi> Wed, 15 April 2020 12:49 UTC

Return-Path: <kivinen@iki.fi>
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 6BF913A0E1A for <ipsec@ietfa.amsl.com>; Wed, 15 Apr 2020 05:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 50qB9TAxMYQU for <ipsec@ietfa.amsl.com>; Wed, 15 Apr 2020 05:49:09 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021153A0E16 for <ipsec@ietf.org>; Wed, 15 Apr 2020 05:49:07 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 615182017B; Wed, 15 Apr 2020 15:49:03 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1586954943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8amj9rcEzafOg0fL+ScvC8B0YFGlV1fMarPZ3flOjk4=; b=wqdcxtFLpHTOrKF+SrhO3VAMGIza2iToqGdySNo/t0zJZ95Cmdp6QQOM6g/QCLI8aE7qNc ubO8oVK/n3rtOzW4O2I2jovRdhfN8mta/bZ1qNW0NW5bCO3b7U5/u9w94cfrw/hoMmymdC DjeYQ81wG8RMWViD8rZuJqu8/nANCOE=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 6EE2B25C0E24; Wed, 15 Apr 2020 15:49:01 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24215.701.417106.744293@fireball.acr.fi>
Date: Wed, 15 Apr 2020 15:49:01 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: ipsec@ietf.org
In-Reply-To: <20200415021321.GI88064@mit.edu>
References: <20200415021321.GI88064@mit.edu>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 7 min
X-Total-Time: 6 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1586954943; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8amj9rcEzafOg0fL+ScvC8B0YFGlV1fMarPZ3flOjk4=; b=UpZzGTAAUqu4ZHZhbTBX3E0/ylo/5IceOCIjUnwhGcH05q1/25NC2mtlwSpCQKg/4nbA6k 5ov6t3TddvHKZN7+/l+62rVWkmRZ++veuJGZ7UULWwmItOeoFqRDMpKXW1yNjHCBkXV8a2 a9IXOWacGlaLV7Nmi4qAZFRxkS8zjqs=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1586954943; a=rsa-sha256; cv=none; b=Y+AA5AnYoSvhKR77phW2sMba6Xn3Qgd2EXMIS39UjiopuWr7AlU9S04p4F00Yj7GMXfjg5 e/Kan2EViaA7HF3AVmTuu/rCsOqDzwfznWiZK/mSIGQC5QWIm1+oSdAMSrX25MzhxBx3Bb YFwUCc+GnKAMvGg+tv3+i24zWv2yhyo=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/qqPpn7iwmggIffOzQIc-G24JXYY>
Subject: [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 12:49:12 -0000

Benjamin Kaduk writes:
> 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.?

One of the problems is that we as an IETF give instructions to
implementors, not to users. If we change 3DES MUST NOT, then all
implementations out there who do implement 3DES, but where it is
disabled in configuration by default are no longer conformant to the
new RFC, as they do still implement 3DES.

Anybody who puts 3DES in any of the new implementations or new
releases of the current implementations are going against the SHOULD
NOT in the current RFC.

Meaning they most likely have some old legacy stuff they need to
support which only supports 3DES and thats why they want to keep 3DES
in their current releases as they want to be able to talk to those.

I would wait bit more than 2.5 years before saying MUST NOT. 

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

Especially with consumers and general-purpose OS there is no option
for using old OS release anymore. Most of those will automatically
update to latest version, and there usually isn't any easy way to
downgrade back to previous version when issues are found.
-- 
kivinen@iki.fi