Re: [DNSOP] [Ext] TKEY and MD5

Paul Hoffman <paul.hoffman@icann.org> Tue, 21 December 2021 03:42 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA13A10CC for <dnsop@ietfa.amsl.com>; Mon, 20 Dec 2021 19:42:11 -0800 (PST)
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 unoqR1NYv9_z for <dnsop@ietfa.amsl.com>; Mon, 20 Dec 2021 19:42:07 -0800 (PST)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 1C71E3A10CB for <dnsop@ietf.org>; Mon, 20 Dec 2021 19:42:07 -0800 (PST)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa4.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 1BL3g4eP027325 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Dec 2021 03:42:05 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Mon, 20 Dec 2021 19:42:03 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0922.019; Mon, 20 Dec 2021 19:42:03 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Mark Andrews <marka@isc.org>
CC: dnsop WG <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] TKEY and MD5
Thread-Index: AQHX9haWGoOK61vUQ02NHU9nYc33U6w8016A
Date: Tue, 21 Dec 2021 03:42:03 +0000
Message-ID: <130C84BD-3123-4041-95FC-3DEA1E2F8DB2@icann.org>
References: <449C4B8E-982F-44A5-BB11-BC404EB2BD80@isc.org>
In-Reply-To: <449C4B8E-982F-44A5-BB11-BC404EB2BD80@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_CE8B73BB-9A18-4C55-8B1C-67419299309F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-21_01:2021-12-20, 2021-12-21 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZTbHCLIw7Eb7Kk_gWJPKA9398QQ>
Subject: Re: [DNSOP] [Ext] TKEY and MD5
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Dec 2021 03:42:12 -0000

On Dec 20, 2021, at 6:57 PM, Mark Andrews <marka@isc.org> wrote:
> 
> Isn’t it about time we updated DH support in DNS to not use MD5?  Currently there is
> no FIPS compatible DH key exchange in DNS.  I suspect it would be relatively straight
> forward by defining a new TKEY mode which does DH w/o using MD5.

If I read RFC 2930 correctly, there is no way to create new modes for TKEY. MD5 is baked into the TKEY RRtype, it seems. You would have to create a new RRtype which is similar to TKEY but has a different key exchange mechanism.

...and, at that point, you could just re-use any of the dozen or so key exchange mechanisms already standardized in the IETF. Said another way, if you try to put TKEYbis on standards track, it might get pecked to death because key exchange has come a long way in 30 years.

Your note about that there is no FIPS-compliant way to do TSIG is correct. Having said that, its use of hashes in the key material relies on the preimage resistance of the hash, not the collision resistance. It still works fine, and is likely secure, it just just feels unclean.

--Paul Hoffman