[DNSOP] The DNSOP WG has placed draft-arends-private-use-tld in state "Adopted by a WG"
The DNSOP WG has placed draft-arends-private-use-tld in state Adopted by a WG (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zone contents digest and DNSSEC stuff
> On Sep 29, 2020, at 6:42 AM, libor.peltan wrote: > > Hi Joe, > > Dne 29.09.20 v 15:03 Joe Abley napsal(a): >> The other use case I seem to think you're implying is that a consumer of the >> signed zone could verify that it was intact using the signed-zone ZONEMD, >> then strip the DNSSEC RRs and retain the ability to verify that the result >> was an accurate representation of the unsigned zone using the unsigned-zone >> ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm >> just not thinking hard enough? >> >> >> Joe > > yes, something like this. > > My initial thought was that the signer, which converts the un-signed zone by > adding signatures and keys, might not be able to compute/update the ZONEMD > record. > > It might also be useful, when the zone is only re-signed and otherwise > unchanged, if the zone checksum was unchanged. > > I'm not sure. This is just a thing to be thought of. > > I would love if there was a bit flag indicating if the checksum has been > computed including DNSSEC records, or without them. This would let the > freedom of choice on the users, while adding some complexity to software > implementation. > > Thanks for consideration, > > Libor Joe's response was very good, especially with respect to signed and unsigned being two different zones. During the working group discussions, we often heard the opinion that ZONEMD is not reliable without DNSSEC signatures. Without a signature on the ZONEMD record, an adversary can easily change the digest to match changes to zone content. I expect in most cases digest calculation will be done at the same time as zone signing. There is no flags field, but you could probably accomplish your goal with a new or private use scheme code point. That is, you could define a collation scheme that excludes DNSSEC RR types during digest calculation. If there were a proposal to standardize such a scheme, the concern I would have is that it complicates the meaning of zone digest verification. It would essentially be verifying a subset of the zone, which is not as strong as verifying the full zone. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Message Digest for DNS Zones Authors : Duane Wessels Piet Barber Matt Weinberg Warren Kumari Wes Hardaker Filename: draft-ietf-dnsop-dns-zone-digest-12.txt Pages : 37 Date: 2020-09-29 Abstract: This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes a ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-12 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zone contents digest and DNSSEC stuff
Hi Joe, Dne 29.09.20 v 15:03 Joe Abley napsal(a): The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough? Joe yes, something like this. My initial thought was that the signer, which converts the un-signed zone by adding signatures and keys, might not be able to compute/update the ZONEMD record. It might also be useful, when the zone is only re-signed and otherwise unchanged, if the zone checksum was unchanged. I'm not sure. This is just a thing to be thought of. I would love if there was a bit flag indicating if the checksum has been computed including DNSSEC records, or without them. This would let the freedom of choice on the users, while adding some complexity to software implementation. Thanks for consideration, Libor ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zone contents digest and DNSSEC stuff
Hi Libor, On Sep 29, 2020, at 05:51, libor.peltan wrote: > Often the zone operators work with both un-signed and signed "versions" of > their zone. The un-signed version usually comes from a registry system or a > database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, > RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip > DNSSEC-related records from signed zone, if needed. > > I feel like it would be equally useful to maintain a digest of the un-signed > and signed version of the zone, respectively. Others may have different ideas about this, but to me it makes the most sense for a particular zone that contains a ZONEMD RRSet to use it to carry a checksum of itself, not some other zone. The unsigned zone, as you have described it, is a different zone from the signed zone; it contains different resource records. It could contain its own ZONEMD RRSet, but that would reflect its own checksum. Since it's unsigned, its ZONEMD would also have no authenticity protection, but there could be internal, trusted environments where that was not a concern and the unsigned ZONEMD could still be useful. For example, you could still compute a ZONEMD for an unsigned zone in order to use it to check that the zone was intact within the internal registry/signer machinery. You would replace it with a newly-computed ZONEMD once the zone had changed through the process of signing (the new ZONEMD reflects those changes). The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] zone contents digest and DNSSEC stuff
Hi, I don't fully know the background of this topic, so my question might be dumb. Often the zone operators work with both un-signed and signed "versions" of their zone. The un-signed version usually comes from a registry system or a database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip DNSSEC-related records from signed zone, if needed. I feel like it would be equally useful to maintain a digest of the un-signed and signed version of the zone, respectively. Does the calculation of ZONEMD include the DNSSEC-related records? Have you maybe thought about including two such records, for both cases? Thanks for comments, Libor Dne 25.09.20 v 22:09 internet-dra...@ietf.org napsal(a): A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Message Digest for DNS Zones Authors : Duane Wessels Piet Barber Matt Weinberg Warren Kumari Wes Hardaker Filename: draft-ietf-dnsop-dns-zone-digest-11.txt Pages : 36 Date: 2020-09-25 Abstract: This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes a ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
