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

Ben Schwartz <bemasc@google.com> Fri, 09 October 2020 19:09 UTC

Return-Path: <bemasc@google.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 D94643A142F for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 12:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fv9FWfmNAPzS for <dnsop@ietfa.amsl.com>; Fri, 9 Oct 2020 12:09:22 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 3CFCC3A1433 for <dnsop@ietf.org>; Fri, 9 Oct 2020 12:09:22 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k6so11210563ior.2 for <dnsop@ietf.org>; Fri, 09 Oct 2020 12:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKd3+VPHpVDs6lZbUvMziq1HYtcNUYDH8Wz4hhEzWkQ=; b=qYi/JlndIN8AKwIW9++tA0etYuri7iNLGZHZcrmpd5XCycBH4O1q/xvLXSWJe/dpRn 1nKCp/f1sgFAbtPUikDVPerguOkwtD8txxllyfe6SPACWc2Wtew9Sz6vfzq3PDNLLE6b p3rWun5LOCCkt5CcrWHNsMlzlwqukx3KJ+EGEWI3CC6uhhut5u88TZc8e9jfPYnrGatm Ixxn1reqkDhrUq2E4ddUn8dvepfxtFIe1Gb0fDtWH9MRH63oocQKh9Y4HlPl/VySLk2T 8iZUseiEDdfw/ERU0Z6LBXvb0STDIZQkxc4SUeH/peAvJX9eqwRtBqUOjs4N2cdXm2hM RtBg==
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=LKd3+VPHpVDs6lZbUvMziq1HYtcNUYDH8Wz4hhEzWkQ=; b=j6uG4Q7m4LovTTA6d3aUlS3buMGBlZEq4G1DdVIB2HagUX10mB0M68CDMkqIqsIMwH 8fBESDd3RQ4QEQ96c63nl1CbaVSNuA0CrItzrkb8I5CYDmrvx8paIJbjbRgBvdBs4BEE 6dnCtYSUShXlPuBfoHJmE2K82zHmXODO1dc4UyiCMtEDhFq3F8HNWq2vei1M6LZjusUY tuIwkcrqi8uCYcVITvzHCc6M6I74GMvWB0xjCXJH72NEufbBCKKZMxCWlhh8VAwqeQBM OB4gOum+vhrUiVkaWT5nidm0pnJetjkXDCpx4pTv4qYeR+DvMtK1hD1udG2WGOJdd6yX Amog==
X-Gm-Message-State: AOAM532dARoZLq+s/cBT1S2rVfMwnqO5N3xugowWL7JkopmG2duJLkbJ zJ7zb+BaQoxA+QJKz2nnADsd2QIVAv0Jk8ArUrZJUA==
X-Google-Smtp-Source: ABdhPJwzM0xtQrTiMOU43xADeuwYzmGqTeAJkqh8vBc6FKqeEI/GrQ6m/JtpD//f9tpzv4DV133NCqawp+v3aV6dhr8=
X-Received: by 2002:a6b:9156:: with SMTP id t83mr10020996iod.91.1602270561148; Fri, 09 Oct 2020 12:09:21 -0700 (PDT)
MIME-Version: 1.0
References: <160215590178.19643.8185294724542473578@ietfa.amsl.com> <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
In-Reply-To: <514C5EA8-2814-42AA-9787-455445BA828D@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 9 Oct 2020 15:08:35 -0400
Message-ID: <CAHbrMsCxwM_bbu6tO97KkH5rk5DKag5_4FsY3faAbgg=M1-CoQ@mail.gmail.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Cc: Robert Wilton <rwilton@cisco.com>, "draft-ietf-dnsop-dns-zone-digest@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" <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a7dd1c05b141afbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fJI-5O9hyOAgqmebmjy0vpYsd0U>
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: Fri, 09 Oct 2020 19:09:27 -0000

On Fri, Oct 9, 2020, 2:36 PM Wessels, Duane <dwessels=
40verisign.com@dmarc.ietf.org> wrote:

>
>
> > On Oct 8, 2020, at 4: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:
> > ----------------------------------------------------------------------
> >
> > Thank for you this document.  I found it interesting and it looks useful.
> >
> > I have a few comments that may improve this document for you to please
> consider:
> >
> >   Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
> >   Algorithm defined for ZONEMD records that MUST be implemented.  When
> >   SHA384 is used, the size of the Digest field is 48 octets.  The
> >   result of the SHA384 digest algorithm MUST NOT be truncated, and the
> >   entire 48 octet digest is published in the ZONEMD record.
> >
> >   SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
> >   ZONEMD records, and SHOULD be implemented.  When SHA512 is used, the
> >   size of the Digest field is 64 octets.  The result of the SHA512
> >   digest algorithm MUST NOT be truncated, and the entire 64 octet
> >   digest is published in the ZONEMD record.
> >
> > For consistency, perhaps change "with value 1" to "with Hash Algorithm
> value 1"?
>
> Done.
>
>
> >
> >    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.
>
>
> I know there has been some followup on this with Donald.  In our earlier
> conversations with him he wrote "96 bits seems to be a common minimum
> length for disgests in the IETF although perhaps I have that impression
> due to the common case of SHA-1 truncated to 96 bits."
>
>
> >
> >    2.  The ZONEMD Resource Record
> >
> >       It is
> >       RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
> >       publisher is in the process of transitioning to a new Scheme or
> Hash
> >       Algorithm.
> >
> > I'm not quite sure how well this fits with sections 2.2.3 restriction
> that
> > SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a
> recipient
> > of the zone info I understand that I would need to implement both, but
> as a
> > sender am I allowed to only send SHA512, or both, or must I always send
> SHA384?
>
> As sender (publisher) you are allowed to publish whatever you want.
>
> The purpose of the recommendation above is to hopefully avoid the situation
> where multiple records are published (with both types) on an ongoing basis.
> That is something we observe with DS records quite often.  For example,
> 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in
> the root zone.  This new paragraph has been added to the security
> considerations:
>
> 6.2.  Use of Multiple ZONEMD Hash Algorithms
>
>    When a zone publishes multiple ZONEMD RRs, the overall security is
>    only as good as the weakest hash algorithm in use.


Why not require recipients to verify all digests with recognized algorithms?

  For this reason,
>    Section 2 recommends only publishing multiple ZONEMD RRs when
>    transitioning to a new scheme or hash algorithm.  Once the transition
>    is complete, the old scheme or hash algorithm should be removed from
>    the ZONEMD RRSet.
>
>
> >
> >    3.1.  Add ZONEMD Placeholder
> >
> >       In preparation for calculating the zone digest, any existing ZONEMD
> >       records (and covering RRSIGs) at the zone apex are first deleted.
> >
> > I think that this places a requirement that all zone digests must be
> > constructed at the same time.  I suggest at least changing "zone digest"
> to
> > "zone digest(s)", but it might also be worth adding a sentence to
> highlight
> > that.
>
> I've changed it to "zone digest(s)" as you suggest.
>
> Strictly speaking, there is not a requirement that all digests must be
> created
> at the same time (in parallel).
>
> The reason for the placeholder is explained in the next paragraph, which
> is to
> ensure correct NSEC/NSEC3 records when the zone is signed with DNSSEC.
>
>
> >
> > I was also left wondering whether it is strictly required that the zone
> digests
> > must be deleted, or just that placeholder zone digests must be used in
> their
> > place during the calculation.  E.g. what happens if a request is
> received to
> > fetch the ZONEMD record at the same time that it is being reconstructed?
>
> It is not strictly required to delete any existing digest first.  The
> ZONEMD records
> are not included in the digest calculation.
>
> To address your questions around this, I suggest adding this text to
> section 3,
> before section 3.1:
>
> 3.  Calculating the Digest
>
>    The algorithm described in this section is designed for the common
>    case of offline DNSSEC signing.  Slight deviations may be permitted
>    or necessary in other situations, such as with unsigned zones or
>    online DNSSEC signing.  Implementations that deviate from the
>    described algorithm are advised to ensure that identical ZONEMD RRs,
>    signatures, and dential-of-existence records are produced.
>
>
>
> > 4.  Verifying Zone Digest
> >
> >   5.  Loop over all apex ZONEMD RRs and perform the following steps:
> >
> >   ...
> >
> > My, perhaps mistaken, interpretation of these error reporting
> instructions in
> > this loop is that they really assume only a single ZONEMD RR.  I.e., I
> wouldn't
> > expect the recipient to generate/return these errors if there were two
> ZONEMD
> > RR's and only one scheme/algorithm was was supported.  Yes, there is
> some text
> > at the beginning of the entire algorithm that suggests what to do here,
> but
> > further guidance here may also be helpful.  E.g. what does the server
> return if
> > there are two ZONEMD records and neither of them are acceptable for
> different
> > reasons?  I'm presuming, perhaps incorrectly, that only a single error
> > can/should be returned.
>
> Ben raised a similar point about this section, namely that it could result
> in a lot of diagnostic output.
>
> Do you think it would be better remove those "SHOULD report" from each
> individual
> step and instead have a paragraph at the end that says the verifier SHOULD
> report
> the result of its verification and leave it at that?
>
>
> >
> > Regards,
> > Rob
> >
>
> Thanks for the review and comments!
>
> DW
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>