Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

Michael StJohns <msj@nthpermutation.com> Mon, 09 March 2020 21:24 UTC

Return-Path: <msj@nthpermutation.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 AEBAD3A17C7 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2020 14:24:10 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 g9Sn1PnO_hlj for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2020 14:24:09 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 0C04F3A17DD for <dnsop@ietf.org>; Mon, 9 Mar 2020 14:24:08 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id h14so4831501qke.5 for <dnsop@ietf.org>; Mon, 09 Mar 2020 14:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=xegHD7YQF5cLHW/JZCyzgk7G4P9Th2RzAaCMKGigBNo=; b=1JddjruGPe5zZOf3rIL4DUjQyg4WxRMLmDQSQUN9Gcr1L9Fy2qUJnYpReYooawfyJD wPG17j0EjC/3WB7uUHYkWrAT3K21Rnvod1tmv9rprzoPQG8WRK/Sz+HI1Dc38ddJ9p8C hW4ReafKlC4Rz5GdjhU/iyBgNVLfNL+ZM2OwTr8rWEnzXogxyrBRpF/vebTW1YY6bXPo P5qEOLcD8dgcTUMJsWvQear89h0S2oSrlIgCPLxRB7wK7w8mbeaXEYkm7D6HeC5rZOd7 AY97OWKSjPp0XZoYd7dt4D1XBd8uOMOt+f3vvJH/3k9pJ1P+VPbkt0q/r4ADjqv3j2TL MPvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=xegHD7YQF5cLHW/JZCyzgk7G4P9Th2RzAaCMKGigBNo=; b=o6I7vkGsb7zj01nxrIrWkVgJHrEEmNW8K5HHZKyNmN2ldVULCxNufY7Eo+NdxeovXY alGLdb944QWGm17fEEFB8cq9uXSN3YvTERf17S5C4BAikh69CGix5v3NAbOa95qGxU6P 4oGwdUHxy5BURlDKN/GxRSWlvn0Ibp4IWcarmAGf7VTnRseF6lLCcZbESG0ZSTAWA9DX xxtEV9RhEIhq4Z+uzNrLqzLa98ThUCA8VPeLeEkVCv/CmVVGrkovi8FxypKKMWVFji4v nRPwg+6hB5O3v21/B03GoBwRm4jgbSETComuWaOREzSTSJqF9uYEcP7kE8cLcVphxeXV ZVtg==
X-Gm-Message-State: ANhLgQ3s/SeGEIQ0d1Dw0huIjHDmDZttnDWE3WYdbL/i0OmGd7Yxp1cv A2qKiIrQPbH9rKcSMJKHoVYGGAf7VNI=
X-Google-Smtp-Source: ADFU+vsNZBMS0xbusSh0ZR6Mk4rivNU/iCFRK28xelmBdP+zHwPcy5PbKOTZ+zdx31LAm4E3QcTAsA==
X-Received: by 2002:a37:985:: with SMTP id 127mr16370947qkj.302.1583789047565; Mon, 09 Mar 2020 14:24:07 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id p16sm1649885qkj.5.2020.03.09.14.24.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2020 14:24:07 -0700 (PDT)
To: "Wessels, Duane" <dwessels@verisign.com>, Dick Franks <rwfranks@gmail.com>
Cc: Mark Andrews <marka@isc.org>, Tim Wicinski <tjw.ietf@gmail.com>, IETF DNSOP WG <dnsop@ietf.org>
References: <CADyWQ+GDfbaAKz9iAWVH=TP=2A3hr9iGhTarayAEjgF5TrnvXQ@mail.gmail.com> <CAKW6Ri6YbMKquv7sMqK5D4OH7Z=h-zuvmUXqfUG2NpJdu91ooA@mail.gmail.com> <EA3EFDEF-ED88-4918-A49E-4832CBFA9C5E@isc.org> <CAKW6Ri4nVn78LfL_tL8G956gM23JWBJ7HJ3A5L4nqntmyAQRjw@mail.gmail.com> <93E835F5-5421-4343-9D2B-A88937675E0A@verisign.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <6aeded6f-e0eb-063b-a3f1-f33402b21c3a@nthpermutation.com>
Date: Mon, 09 Mar 2020 17:24:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <93E835F5-5421-4343-9D2B-A88937675E0A@verisign.com>
Content-Type: multipart/alternative; boundary="------------10325CF211B36D29BD015710"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-ZsAOdg4orIcuhwwwaEExqVjw74>
Subject: Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones
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, 09 Mar 2020 21:24:18 -0000

On 3/9/2020 4:46 PM, Wessels, Duane wrote:
>> Michael StJohns pointed out (Feb 25) that a verifier that does not
>> recognise a particular
>> ZONEMD Scheme and/or Hash Algorithm may be unable to create the
>> required placeholders,
>> and therefore unable to perform a verification using any
>> (Scheme,Algorithm) at all.
> I don't believe that to be the case.  For the unknown schemes/algorithms
> the recipient simply replaces how ever many octets the received ZONEMD digest
> had with all zeros.
>
>
>

As of right now, I don't believe the current format is future proofed.

Current encoding:

0x01 - simple
0x01 - SHA384
48 bytes of digest.

0x01 - simple
0x02 - SHA512
64 bytes of digest.

0x02 - Complex
0x00 - Ignored - mainly because I'm forced to have it here because of 
the SIMPLE scheme - it doesn't specify a digest type.
[Opaque values that describe the complex scheme - e.g. btree 
description, partial hashes, selection matrix of RRs I actually care 
about etc]
[More opaque values that are the various digest(s)]

These are OPAQUE from a receiver that only understands SIMPLE.

For the latter scheme, I want to include the first part of the opaque 
values in the various hash calculations.   But the SIMPLE scheme will 
set them to zero for its own calculations?   And I have to do special 
things for scheme 1 to do my calculations.  AND I have to know that 
digest 0x02 requires 64 bytes of zero for the calculation even if I'm 
only able to verify SHA384 digests.  Any error in the formation of the 
digest 0x02 digest field or scheme 0x02 data field means that the 0x01 
digest won't verify.  Ditto for any formation for the scheme 2 complex 
digest relative to the Scheme 1 digests.  This makes all digests 
interdependent which I believe was not desired.

I see no benefit to including the ZONEMD RR in any digest calculation 
with our without placeholdering it.

Just omit any ZONEMD RR from the calculation and be done with it.  Make 
ALL ZONEMD RRs independent from each other.