Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt

Paul Hoffman <paul.hoffman@icann.org> Thu, 01 November 2018 15:48 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 445081252B7 for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 08:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 wPMHgM9UOvdR for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 08:48:54 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C42124BAA for <dnsop@ietf.org>; Thu, 1 Nov 2018 08:48:54 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 1 Nov 2018 08:48:52 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 1 Nov 2018 08:48:52 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Joe Abley <jabley@hopcount.ca>
CC: dnsop WG <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt
Thread-Index: AQHUcfk4q2WLXNHvMkuk6zrahX4ZJKU7hiuA
Date: Thu, 1 Nov 2018 15:48:51 +0000
Message-ID: <969042CA-920A-4D8D-9331-956127AC0551@icann.org>
References: <154020795105.15126.7681204022160033203@ietfa.amsl.com> <DD4AADA8-A23A-4C2C-9F0D-401CA5A51745@hopcount.ca> <509F5E08-5EDF-4A54-BB34-A76BA390F01D@verisign.com> <263f71ee-05ab-84e1-bb61-4139941b4346@andreasschulze.de> <B87E646F-0FFD-4CFD-9A38-F7126160AD61@icann.org> <7966734C-7229-4173-8CD8-BD57BEC33D1C@hopcount.ca>
In-Reply-To: <7966734C-7229-4173-8CD8-BD57BEC33D1C@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_063609B1-FAC8-408A-86EC-670C53D75402"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4FAnzq6INqFiWr0ucSy3E06JFTI>
Subject: Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt
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: Thu, 01 Nov 2018 15:48:56 -0000

On Nov 1, 2018, at 8:40 AM, Joe Abley <jabley@hopcount.ca>; wrote:
> 
> On Nov 1, 2018, at 16:27, Paul Hoffman <paul.hoffman@icann.org>; wrote:
> 
>> The current ZONEMD draft fully supports algorithm agility. What it doesn't support is multiple hashes *within a single message*. Having seen how easy it is to screw up OpenPGP and S/MIME message processing to handle multiple hashes, I think having one hash per zone is much more likely to work.
> 
> Suppose everybody supports digest algorithm A (e.g. it's the digest type that was mandatory to implement in the original specification). We use that in our ZONEMD RR because we have high confidence that clients will support it.
> 
> At some later time digest algorithm B emerges which has some advantages over algorithm A. B is newer and not all software supports it. We would like to use B because its advantages are attractive to us, but we also want all of our clients to be able to use the ZONEMD RRs we publish.
> 
> Since B is new we have lower confidence that it is supported by our current clients.
> 
> We cannot use both A and B simultaneously on the publication side, since the specification requires us to choose just one.
> 
> There is no signalling mechanism that will give us insight into our client population's support of algorithm B, even if we have non-empirical expectations that support will increase over time.
> 
> Since we don't want to break things, we cannot use B.

Exactly right. This is precisely the problem that OpenPGP and S/MIME looked at when they created their multisig formats. And the results are incredibly complicated code for validation. It also leads to unanswerable questions like "what if the hash for A is right but the hash for B is wrong".

It's fine to go down the multisig route in this document, and it's fine to punt for a decade or three until a problem is found with SHA256 and SHA384. There are costs for both decisions.

--Paul Hoffman