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

Bob Harold <rharolde@umich.edu> Thu, 01 November 2018 16:54 UTC

Return-Path: <rharolde@umich.edu>
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 BD5E6128DFD for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 09:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 Sh-7SSMAIkAZ for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 09:54:49 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFD11277BB for <dnsop@ietf.org>; Thu, 1 Nov 2018 09:54:48 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id a28-v6so15658702ljd.6 for <dnsop@ietf.org>; Thu, 01 Nov 2018 09:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=De2B79rqptvmfLqe4Gh6zL/vMuA13qEKcu2sv2BFL5A=; b=ciDE8i6WCo96WJS6b8y6r8RdYUiW1KYwdwqOz3xtYQLvTBkbe9OTcelItDuhH326im 7u+IqnizZgNzzlP4WYHJ/ZA4ycSAygrr84JsnTAy0EmjuRzhOOj+CNC0bskxh7f0W9Ul aSd80lsrS0gO0tgppNTcu3Wm3sq3d/xo9xDNIKDk+YZ7yJDwxIH6NY7S+obg9WVNZ7Om RIHlGwTF4jbFB4xP+1q76pwHmTDxGOjES533ZQYiSDuO2pO8i+GOdsQzSY7OIc4x5Csn JWXYzti0M/KFdRdAqJ9jM9CXAhDQv6/By/c9+p1KxXCZdy+l1N26ZwAxbFigh8Hg6j3P ZfgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=De2B79rqptvmfLqe4Gh6zL/vMuA13qEKcu2sv2BFL5A=; b=D9Cc0sqWjvi0/tFQBXyXVrMAfUoLf3ONvMiqTbxYGvVrDXdb7jZ9PI6MC/L9f2dMx6 lXMLB6Wi9lI+k37y2ptQy7NZFwo8des9v5AMfsf3GqNzMofGtnHpfp+WTyzpzd1wuN3Y h3E5AkhdtPDhzPZlPNZuQnVTMDEM4GlbXpoJH3T0u10v0BMzQ9kiPBBngphK/2qi80x2 vDy1K9ZGHmi+u4l8JBXiE8IdK8GX/i0BYIyfxeB1K/MmuZW8uP3I/1Aou3XoUQE8O23+ dCNnz1aZK0PeoyGC7I9ob12AgohKBWhnv2m7JhxZ5rrGTwfsTRnSNWZ1ffvnP3bYvaog Bdbg==
X-Gm-Message-State: AGRZ1gI0dt9KIzQp+rJ4c3pO9R/dS9bAA+Uxy9mB1Ty3NTpc1tJ/LYVQ wP26KDMAMxD4YgJpGMijP+DvNz9OH/CbkG4zrAHHr5lv
X-Google-Smtp-Source: AJdET5fLgoUb1yQqtjlxVc+mTOt72xlYvrsxxAfdqwKV7uFpjrXFL5Ryqz6GlwKQ3lXrIxVAy6x6FypGomjISCU1y4g=
X-Received: by 2002:a2e:568b:: with SMTP id k11-v6mr5500764lje.105.1541091286083; Thu, 01 Nov 2018 09:54:46 -0700 (PDT)
MIME-Version: 1.0
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> <969042CA-920A-4D8D-9331-956127AC0551@icann.org>
In-Reply-To: <969042CA-920A-4D8D-9331-956127AC0551@icann.org>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 1 Nov 2018 12:54:34 -0400
Message-ID: <CA+nkc8DFT_WGVQ2VhkYiUPUxqjjCqrRrhmDdsf8HOCayLpFZBw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Joe Abley <jabley@hopcount.ca>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ac7e3405799d46bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1OOtU3XMK5jx8wujsbXjQtgYkLg>
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 16:54:53 -0000

On Thu, Nov 1, 2018 at 11:49 AM Paul Hoffman <paul.hoffman@icann.org>; wrote:

> 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_______________________________________________
>
> I don't use DNSSEC or OpenPGP or S/MIME yet, so I have no experience with
this.  My opinion then, for what it is worth...

Allow multiple ZONEMD records with different algorithms or hashes or
whatever.  Expect the receiver to chose the "best" alg and hash that it
supports, and do the verification with that one only.  (Avoid the extra
work for each receiver to check more than one ZONEMD.)  That allows for
adding a new alg or hash.

But we still need some signaling for when everyone understands the new alg
or hash.  An ENDS option could get a signal (what algs and hashes are
supported) back one layer, but we envision a distribution system that could
have multiple independent layers.  Possibly each layer could report back
over time a summary of what it got, when it next pulls from its upstream,
eventually reaching the source.  I don't have a good answer for that.
Perhaps the kinds of hacks we did for the root zone key reporting are
needed.

-- 
Bob Harold