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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 12 October 2020 12:23 UTC

Return-Path: <rwilton@cisco.com>
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 5393B3A145A; Mon, 12 Oct 2020 05:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hW54swyA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B2SNnBE0
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 UKtLPwwD3L7d; Mon, 12 Oct 2020 05:23:29 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106F23A1440; Mon, 12 Oct 2020 05:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6286; q=dns/txt; s=iport; t=1602505409; x=1603715009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6vKtjuJ/wKjxMDuhuoNpJwy7q4VeuleHP2VhO6SYuVE=; b=hW54swyAm4/Y47u8FWvT5XxypFsIgDTG6MVu7yZ7OBQJmTJPh1N6FbGM Jk1Yj30vu1FvKkvyDSNU1RyzzALPMy1JC3wCp6mxfc+4BD309JIlTtK/H /HndOvGCdiZN1IKJ0DlMf17uvR2Z8EdmxPkeqNuPq2OuxW460/f+5YMwu c=;
IronPort-PHdr: =?us-ascii?q?9a23=3A2MEnHxQjB4Kw4+N7axLWbcEI8Npsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN2J7vNYzefarvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX7ZkGUr3GvvnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEBgA6SoRf/4YNJK1dAw4OAQEBAQE?= =?us-ascii?q?BBwEBEgEBBAQBAUCBT4FSUQeBSS8sCod5A41QgQKJD45qglMDVQsBAQENAQE?= =?us-ascii?q?tAgQBAYRKAoIWAiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEigGAQE?= =?us-ascii?q?3AQsEAgEIEQQBAQEeECERHQgCBA4FCBqFUAMuAQOcIwKBOYhhdIE0gwEBAQW?= =?us-ascii?q?FAg0LghAJgTiCcoNfhBqCSxuBQT+BEUOCGDU+ghqBeyofJoMDgi2QKIJlAaQ?= =?us-ascii?q?EUgqCaJVeBIUpgxWPSo5boH+SSAIEAgQFAg4BAQWBayOBV3AVgyRQFwINjh8?= =?us-ascii?q?JAhgUgzqKGD50NAMCBgoBAQMJfIsHgTQBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="560219323"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 12:23:28 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 09CCNSFZ025248 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2020 12:23:28 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 07:23:27 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 07:23:27 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 12 Oct 2020 07:23:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gEEHrpA4xm4a4TLjaRQDGbleLnMPUbLvBB+s9IgqBUh6vL6nKnizgjsy7UfwRFE/HhnxZS0Sw8vm4y6b/AAslTnJbaU2SFTu9ZHfC7f0KkS+XVosXLtHkUbczsMbo2oDY40pRVcrMo+MIRxakNx3a6LI9vZKvfDq4r/4+Ic4g2u3cYEvnj9s+13qezg3MYXjroMfKkpfEZraXXn/ODSuckleLHo0zoQz0N1QA8mHMfmiP5EQ3XOn7dl0LhJYmp4hbpch0hirMnioj8Yjs1omp5gw+YZN/aR0U3836IrXK1oZo5OozTPjQh5p6kMJlSehUAvn0ZbYmkHQBa6yqDG3tQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lfYPI7Ilf9weRMTEm0R5CeRFQ/LCRq0PR3xCxEmbd3c=; b=boOdtcWLFUi6yU/Zzktjrn2/qUqocBRestXhzvTzhsZKo8KJ+2sffod9ve+b0J+r8WhF6r64QEcUkLtHbQfnksGfowMvYIXnSye5KPr2QB9PV+BUyLEmODKaVj3zzuHESfrzU3/pPxRvmBYJiiSYY0qZIDVaJkCKrzxrXXYq7hjSrGij5RkcmLbGdwiTk/xXyZ1je53u/ztTfdxTv2nBVCN4C1t3uKjY/l9kRnvmPpFVxPlDRvqQQuvya6zMm6ErfzHcH2ygzlS9Kt5bGp+Wfw/kfuXqQFejqfcDWfPa315iJ7CZn0H5bbno3Vkvng0vDvCMtP55xZSlbyJPFbnNSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lfYPI7Ilf9weRMTEm0R5CeRFQ/LCRq0PR3xCxEmbd3c=; b=B2SNnBE0xqbt4QeYnqBH58srClm59u4Kdfsd7T9okXBT9s7oNdPM4HTJVSWV44r8jf+cU2B7nm7AjzWz7c4INk/E73Sc5twTC4u7bqYXRo+vxt7qNP6Xz1RUFXc0NhjDYsT/q7NnbkYqWAPu8lv0LYNMNBO9L7Jkpb8t9ZUpKRE=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4239.namprd11.prod.outlook.com (2603:10b6:208:192::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Mon, 12 Oct 2020 12:23:26 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3455.030; Mon, 12 Oct 2020 12:23:26 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thread-Topic: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Thread-Index: AQHWnWTLXBOmQTmNGkG7AmGk8bLrYqmOX/qAgACeAOCAASz6AIAABDWAgAO3EsA=
Date: Mon, 12 Oct 2020 12:23:25 +0000
Message-ID: <MN2PR11MB43660E01136DEE60A66014E6B5070@MN2PR11MB4366.namprd11.prod.outlook.com>
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> <20201010032517.GM89563@kduck.mit.edu>
In-Reply-To: <20201010032517.GM89563@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b55d200b-bf67-4844-af15-08d86ea99e8d
x-ms-traffictypediagnostic: MN2PR11MB4239:
x-microsoft-antispam-prvs: <MN2PR11MB42396AB075719E329518CFF8B5070@MN2PR11MB4239.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Gjj1+OtwpgxhyLzERyaqFQrpPoMg3kagrrz7IqDelZVaIKTLmjI2SEwFW1YZg3nc0WTsmPzAgymyBe0oRjbe6s6WYDq1E7BGQ1qy2sITl511xjQbMkWoAi5P2qL5Uh1CpLeRAZqVDYelL1VIdQV+UhdmJbrq0TlsrF389GTIusU5lNdYbx02D6yWQ8MeTga0iaoelXgMmHcu8a3o9eL8isTaejvz3v1kLFAwves4ESGFw7LrWMCwPmM5AfTH48ymUwIJd6wPOc3dMUxKpyVIUp3fD0qGUKbUwWawWDTn0VIPbt3t2O7myqbBXUAWgI5W7t6geDewJf87zlRtnGxzfg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(136003)(366004)(376002)(71200400001)(33656002)(5660300002)(86362001)(6506007)(186003)(4326008)(64756008)(66446008)(66556008)(76116006)(52536014)(8676002)(8936002)(478600001)(66946007)(66476007)(9686003)(6916009)(2906002)(26005)(55016002)(7696005)(316002)(53546011)(83380400001)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oBecoxMicI6jC0uxMJiJsq6lJa67uasyfpU+eMGzVhux4SdGfp1e+6Jyo5XtaKBOkU0+F0G/IPsv77VOKpWj/u4ZhPcU52bpStIcn0TX7WTaz1K4o4kyW3B2VZP0uEo3rEFNuGNW8/ulxb/BSslcrvzQ1SrbCMhgFnK7kbDxLArqZyO+s6IiqPH/7fRNt7PewE37LaFMjUEay2mNnVU0z7fh8BDKVd8zJSX/rSQ4B3Nfvqtj7MAvp75HfxHNLlJ+B1q04svJlSy2mpf3HROOqkdop0C0RP9i6Sgdkoi1IYAkzDwSxGHEsk9bieBtBNMZGcRyn1ZHz1R1uGcJU9S3bAGmcaw7pm+pHlSC6LWtJu9Yf1Tsqfxend0HlMjDN4IDWLiMYgCdPGnJHNonvSmzIXfAqnwp0MjHBN0F6NLr8gT/UXKsjvXSJlxqIYhY0cZ8EWXa/PgM8Ur9n8eS+oInMCWBjz6cD1MJPwxaUjlNAmXFL4kwliVoVGxLfYNHLiIYTC3LkYoUriq9Exv0vDJ4q11j8qUNR850+f84ZtIFjFeCREH7RNjtmhAhKAPgviuAlXgv5fMcgDiWLmQ8daVUEDiwm4gbtjGeQ4fT/38ziPP5IhRo5TbMPPgePW7AWaAWj8q4a2JfWo6WregxctZ+eg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b55d200b-bf67-4844-af15-08d86ea99e8d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 12:23:25.9330 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TmkdWs5iJTtfawIi3XTP1xEhnG4wxXJCbaix2StevkQ/aBrDAoaKh4BfRSsdGOASjlb1Ow/LPSb6iWrITXiSTg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4239
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2X-XMa4QOFlTH5WwwI0axQM4ZxY>
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: Mon, 12 Oct 2020 12:23:38 -0000

Hi Ben,

Thank you for the explanation and justification.

I personally find this sort of explanation really useful.  I do wonder whether this sort of material might make a useful informational RFC at some point ... although of course everyone is very busy.

But anyway, I think that we can regard my original comment as resolved.

Regards,
Rob


> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: 10 October 2020 04:25
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: draft-ietf-dnsop-dns-zone-digest@ietf.org; Tim Wicinski
> <tjw.ietf@gmail.com>om>; dnsop-chairs@ietf.org; <dnsop@ietf.org>
> <dnsop@ietf.org>rg>; The IESG <iesg@ietf.org>rg>; Donald Eastlake
> <d3e3e3@gmail.com>om>; Roman Danyliw <rdd@cert.org>
> Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-
> zone-digest-12: (with COMMENT)
> 
> 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>rg>; draft-ietf-dnsop-dns-zone-
> digest@ietf.org;
> > > > Tim Wicinski <tjw.ietf@gmail.com>om>; <dnsop@ietf.org>
> <dnsop@ietf.org>rg>;
> > > > 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
> >