Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 10 October 2020 03:25 UTC

Return-Path: <kaduk@mit.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 CFC593A1771; Fri, 9 Oct 2020 20:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 nAUA2YMrFbSY; Fri, 9 Oct 2020 20:25:27 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3B2953A176E; Fri, 9 Oct 2020 20:25:26 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09A3PHlA029067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Oct 2020 23:25:19 -0400
Date: Fri, 09 Oct 2020 20:25:17 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, "<dnsop@ietf.org>" <dnsop@ietf.org>, The IESG <iesg@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>, Roman Danyliw <rdd@cert.org>
Message-ID: <20201010032517.GM89563@kduck.mit.edu>
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <CAF4+nEEkt=QXZ6OErEBdvZgw4X6bhvB9yBjRjLAgY436i_o=FQ@mail.gmail.com> <MN2PR11MB436644FCED99A35EB7A7CD64B5080@MN2PR11MB4366.namprd11.prod.outlook.com> <CAF4+nEHX=GemUiV6uq7ttyqHQqwev4swg-oAc+Ytp9jyjLV0bA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAF4+nEHX=GemUiV6uq7ttyqHQqwev4swg-oAc+Ytp9jyjLV0bA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VqT01QbK--WqpyMdDAONZaK65rc>
Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
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: Sat, 10 Oct 2020 03:25:29 -0000

Hi Rob,

One can do a bit of semi-generic analysis here to help motivate 12 bytes as
being a tolerable choice (one could make some argument for 32 being the
right length to actually use, but the protocol-mandated floor does not
necessarilly need to be the "full protection" value as there can be
trade-offs in play.

There's two general classes of attack to consider: when an external
attacker takes an existing ZONEMD and tries to modify the associated zone,
or when the zone provider is the malicious entity that wants to provide
different content to different people but give them the same digest value
so that the cursory examination indicates the two different zones are
identical.  (The second one is going to be fairly contrived most of the
time, and may not be in the practical threat model for most people.)  In
the former case the cryptographic property in play is second-preimage
resistance which, in the absence of a quantum computer, scales as the
bitlength of the output, so 12 bytes of digest means that for a good hash
function the attacker has to put in a work factor of roughly 2**96, which
is a substantial burden.  The cryptographic property in play for the second
case is regular collision resistance, which scales as the square root of
the preimage problem due to the birthday paradox.

A work factor of 2**48 is feasible but nontrivial, so 12 bytes poses some
burden for both classes of attack and a substantial burden for the riskier
attack.  To me, that seems like a reasonable tradeoff for the bare minimum
allowed by the protocol, though of course opinions can differ.

-Ben

On Fri, Oct 09, 2020 at 11:10:14PM -0400, Donald Eastlake wrote:
> Hi Rob,
> 
> I'm not aware of any precise analysis supporting the 12 byte minimum
> size but I believe it is reasonable and in line with the lower end of
> the range of hash sizes typically standardized by the IETF these days.
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
> 
> On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> >
> > Hi Donald,
> >
> > > -----Original Message-----
> > > From: Donald Eastlake <d3e3e3@gmail.com>
> > > Sent: 09 October 2020 00:47
> > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > Cc: The IESG <iesg@ietf.org>; draft-ietf-dnsop-dns-zone-digest@ietf.org;
> > > Tim Wicinski <tjw.ietf@gmail.com>; <dnsop@ietf.org> <dnsop@ietf.org>;
> > > dnsop-chairs@ietf.org
> > > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-
> > > zone-digest-12: (with COMMENT)
> > >
> > > On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker
> > > <noreply@ietf.org> wrote:
> > > > Robert Wilton has entered the following ballot position for
> > > > draft-ietf-dnsop-dns-zone-digest-12: No Objection
> > > >
> > > > ...
> > > >
> > > > ----------------------------------------------------------------------
> > > > COMMENT:
> > > > ----------------------------------------------------------------------
> > > >
> > > > ...
> > > >
> > > >     2.2.4.  The Digest Field
> > > >
> > > >        The Digest field MUST NOT be shorter than 12 octets.  Digests for
> > > the
> > > >        SHA384 and SHA512 hash algorithms specified herein are never
> > > >        truncated.  Digests for future hash algorithms MAY be truncated,
> > > but
> > > >        MUST NOT be truncated to a length that results in less than 96-
> > > bits
> > > >        (12 octets) of equivalent strength.
> > > >
> > > > When I read this, I wonder why the limit of 12 bytes was chosen.
> > > Possibly a
> > > > sentence that justifies why this value was chosen might be useful,
> > > noting that
> > > > the two suggested algorithms have significantly longer digests.
> > >
> > > To me, the purpose of the limit is to establish a minimum strength
> > > against brute force attacks. Of course, the hash algorithm also has to
> > > be strong but the length of the Digest field puts a sharp limit on the
> > > strength of a ZONEMD.
> > [RW]
> >
> > I absolutely agree on specifying a minimum value.  My question is how was the minimum length of "12 bytes" chosen?  Is there some analysis performed that indicates that this is the right minimal value, or is this just a "12 bytes sounds like enough"?
> >
> > Regards,
> > Rob
> >
> >
> > >
> > > Note that for the same reason there is a similar provision from 2006
> > > in RFC 4635, Section 3.1, point 4, which sets a minimum size of 10
> > > bytes for the hashes that appear in TSIG RRs.
> > >
> > > Thanks,
> > > Donald
> > > ===============================
> > >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > >  2386 Panoramic Circle, Apopka, FL 32703 USA
> > >  d3e3e3@gmail.com
> > >
> > > >     ...
> > > >
> > > > Regards,
> > > > Rob
>