Re: [IPsec] revisiting 3DES and -graveyard

Dan Brown <danibrown@blackberry.com> Tue, 21 April 2020 15:58 UTC

Return-Path: <danibrown@blackberry.com>
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 CB1C33A0D31 for <ipsec@ietfa.amsl.com>; Tue, 21 Apr 2020 08:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 (2048-bit key) header.d=blackberry.com
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 C_ystQv-awa3 for <ipsec@ietfa.amsl.com>; Tue, 21 Apr 2020 08:58:27 -0700 (PDT)
Received: from smtp-pc11.blackberry.com (smtp-pc11.blackberry.com [74.82.81.43]) (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 811F83A0D95 for <ipsec@ietf.org>; Tue, 21 Apr 2020 08:58:22 -0700 (PDT)
Received: from pps.filterd (mhs401cnc.rim.net [127.0.0.1]) by mhs401cnc.rim.net (8.16.0.27/8.16.0.27) with SMTP id 03LFv12i040243; Tue, 21 Apr 2020 11:58:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackberry.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp19; bh=lPMFYieaKwJixKdcN8MmdTivLJP/T3MQ3rd77sU2q2I=; b=cGw3eUs7VDNNLj1JbuVWVAkSiddg51elz9i10ckf9S9GCR8kSosoWhMqJ3ZrAG9n9Xzr IOcxTJdRAHHHdBUdg1vgzAUVWWIrZLb1dyXJod3uJzshGruiqRGdrOssoicF5dW/LE07 rr5gOG3Bqh0OftgaDv6z7ye6tmF2MPIiTlfNPASo8hha/vLIGqCHBotHXehkeBl8w89/ 0Na8ZKIeHPDbzeokezPUyeFJMR6Rb7IANJ1CKhy5VRygpvdSxL4uTgiLWjp9ohrDzK3T w/8y5VV7NsfUbZKQ/QPFzFALN9ln1fliuJd8wr5CQlC+w/xrzxmwRSgn/z4sKTNb1M3t mA==
Received: from xch211cnc.rim.net (xch211cnc.rim.net [10.3.27.116]) by mhs401cnc.rim.net with ESMTP id 30hc49jrbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 21 Apr 2020 11:58:13 -0400
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH211CNC.rim.net (10.3.27.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 21 Apr 2020 11:58:13 -0400
Received: from XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8]) by XCH210YKF.rim.net ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Tue, 21 Apr 2020 11:58:13 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>, Tero Kivinen <kivinen@iki.fi>, Benjamin Kaduk <kaduk@mit.edu>
CC: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] revisiting 3DES and -graveyard
Thread-Index: AQHWEst8EfG72jk5fUKJywPnzV1tI6h6ZfCAgAPRi4CABYULYA==
Date: Tue, 21 Apr 2020 15:58:13 +0000
Message-ID: <e110327cce334e84971d2da6d8b36d5b@blackberry.com>
References: <20200415021321.GI88064@mit.edu> <24215.701.417106.744293@fireball.acr.fi> <ee364387-6866-abdb-dd0a-0d788aae74a3@htt-consult.com>
In-Reply-To: <ee364387-6866-abdb-dd0a-0d788aae74a3@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.2]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0015_01D617D4.1AFB9810"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-21_06:2020-04-20, 2020-04-21 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/AUiOnL_LQP3ZC34648pHf-xjbac>
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 15:58:33 -0000

Minor points about 3DES below (likely redundant).

> -----Original Message-----
> From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Robert Moskowitz
>
> Just as an aside thought about 3DES:
>
> perhaps you saw my questions to the CFRG list where I have exactly 64 bits 
> to
> encrypt and no place for an IV or such.
>
> One of the serious suggestions WAS 3DES with 3 keys.
>

[DB] Yes, but "serious" is not the right word.  Also, just to be super-clear, 
this was not a CFRG suggestion!

>
> But for only 64 bits to encrypt, 3DES is a consideration.
>
> Nah.

[DB] Last week, I looked up what NIST documents say about 3DES.
https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
If I read them correctly, this document implies something like:
- NO: new deployment of 3DES
- OK: old deployment of 3DES encryption, until 2023, then NO more 3DES 
encryption.
- OK: old deployment of 3DES decryption (e.g. to decrypt archived stuff).
Not sure how much IPSec wants to follow NIST.  Presumably they do for 3DES, 
since 3DES is NIST's?
The text below sounds to me like IPSec is already trying to do something along 
the NIST guidelines. (So, info above I wrote above is already well-known to 
IPSec.)

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

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.