Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update
A few follow ups: On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" wrote: >You don’t publish DS records (or trust anchors) for a algorithm until the >incoherent state is resolved (incremental signing with the new algorithm is >complete). While that makes sense, the protocol can't (not simply doesn't) forbid it. The publisher of the DS resource record set may be a different entity than the publisher of the corresponding DNSKEY resource record set. Because of the possibility of misalignment, the protocol as to be specific in order to be robust. >You can only check if all records are signed with a given algorithm by >performing a transfer of a zone and analysing that. There is no way to do it >with individual queries. The historic error involved a resolver, upon receipt of a response, declaring a data set invalid when the set of RRSIG resource records did not cover all the DNSSEC security algorithms that the rules for zone signing specified, as opposed to validating the data set in question because there were sufficient records to build a secure chain. >As for the original question, if all the DNSKEYs for a algorithm are revoked I >would only be signing the DNSKEY RRset with that algorithm. This makes complete sense, but is not in-line with the letter of the protocol's rules. That's the issue. The consequence of following the protocol's current rules is a lot of deadweight. Namely, unusable RRSIG resource records sent in each reply of authoritative data just to include the DNSSEC security algorithm. The signatures need not make mathematic sense - as no one would need to validate them - with one exception. Where ever there is a division of key responsibilities such as having one organization manage the KSK and a different manage the ZSK, a ZSK may be "forced" to exist by rule and operational configuration. (Removed the remainder of the thread history...) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update
Well I think it is time for more fine tuning. It’s still only PS. -- Mark Andrews > On 15 Apr 2019, at 23:21, Edward Lewis wrote: > > A few follow ups: > > On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" on behalf of ma...@isc.org> wrote: > >> You don’t publish DS records (or trust anchors) for a algorithm until the >> incoherent state is resolved (incremental signing with the new algorithm is >> complete). > > While that makes sense, the protocol can't (not simply doesn't) forbid it. > The publisher of the DS resource record set may be a different entity than > the publisher of the corresponding DNSKEY resource record set. Because of > the possibility of misalignment, the protocol as to be specific in order to > be robust. > >> You can only check if all records are signed with a given algorithm by >> performing a transfer of a zone and analysing that. There is no way to do >> it with individual queries. > > The historic error involved a resolver, upon receipt of a response, declaring > a data set invalid when the set of RRSIG resource records did not cover all > the DNSSEC security algorithms that the rules for zone signing specified, as > opposed to validating the data set in question because there were sufficient > records to build a secure chain. > >> As for the original question, if all the DNSKEYs for a algorithm are revoked >> I would only be signing the DNSKEY RRset with that algorithm. > > This makes complete sense, but is not in-line with the letter of the > protocol's rules. That's the issue. > > The consequence of following the protocol's current rules is a lot of > deadweight. Namely, unusable RRSIG resource records sent in each reply of > authoritative data just to include the DNSSEC security algorithm. The > signatures need not make mathematic sense - as no one would need to validate > them - with one exception. Where ever there is a division of key > responsibilities such as having one organization manage the KSK and a > different manage the ZSK, a ZSK may be "forced" to exist by rule and > operational configuration. > > (Removed the remainder of the thread history...) > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-aname-03.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 : Address-specific DNS aliases (ANAME) Authors : Tony Finch Evan Hunt Peter van Dijk Anthony Eden Matthijs Mekking Filename: draft-ietf-dnsop-aname-03.txt Pages : 15 Date: 2019-04-15 Abstract: This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for type A and queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-aname-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-03 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] I-D Action: draft-ietf-dnsop-aname-03.txt
On Mon, Apr 15, 2019 at 11:25 AM wrote: > > 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 : Address-specific DNS aliases (ANAME) > Authors : Tony Finch > Evan Hunt > Peter van Dijk > Anthony Eden > Matthijs Mekking > Filename: draft-ietf-dnsop-aname-03.txt > Pages : 15 > Date: 2019-04-15 > > Abstract: >This document defines the "ANAME" DNS RR type, to provide similar >functionality to CNAME, but only for type A and queries. Unlike >CNAME, an ANAME can coexist with other record types. The ANAME RR >allows zone owners to make an apex domain name into an alias in a >standards compliant manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-aname-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-03 > > Looks good to me, one minor nit. 5.1. Zone transfers "Secondary servers that rely on zone transfers to obtain sibling address records, just like the rest of the zone, and serve them in the usual way (with Section 3 Additional section processing if they support it)." That's not a complete sentence. Perhaps remove the word "that". -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update
> On 15 Apr 2019, at 11:21 pm, Edward Lewis wrote: > > A few follow ups: > > On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" on behalf of ma...@isc.org> wrote: > >> You don’t publish DS records (or trust anchors) for a algorithm until the >> incoherent state is resolved (incremental signing with the new algorithm is >> complete). > > While that makes sense, the protocol can't (not simply doesn't) forbid it. > The publisher of the DS resource record set may be a different entity than > the publisher of the corresponding DNSKEY resource record set. Because of > the possibility of misalignment, the protocol as to be specific in order to > be robust. They will normally be different entities. The same is true for all delegations. You can be robust and still have more nuanced rules. Parents of a delegation should only be publishing DS records on the direction of the child. We have a number of mechanism to pass that direction (inband: CDS, CDNSKEY, out of band: EPP DS entries). The intent of the rule was to prevent validation failures provided it was followed. i.e. if you follow this rule, validators should not produce a bogus result of validation provided you generate good signatures as they will have the necessary data. Zones were the there isn’t a supported algorithm in the DS set are deemed to be insecure. To prevent downgrade attacks you need to look at the DS set, not the DNSKEY set, as that should only be published before (removal of algorithm) / after (addition of algorithm) the natural incoherence resulting from updating zone content (DNSKEY RRset) has stabilised. That said downgrade attacks should be a non issue. If a algorithm is too weak to validate a response it should be ignored, not conditionally used which is the only time one would care about downgrade attacks succeeding. >> You can only check if all records are signed with a given algorithm by >> performing a transfer of a zone and analysing that. There is no way to do >> it with individual queries. > > The historic error involved a resolver, upon receipt of a response, declaring > a data set invalid when the set of RRSIG resource records did not cover all > the DNSSEC security algorithms that the rules for zone signing specified, as > opposed to validating the data set in question because there were sufficient > records to build a secure chain. Yep. >> As for the original question, if all the DNSKEYs for a algorithm are revoked >> I would only be signing the DNSKEY RRset with that algorithm. > > This makes complete sense, but is not in-line with the letter of the > protocol's rules. That's the issue. Basically the protocol rules in this area are and always have been too simple. I should have pushed for more nuanced rules initially but I wasn't sure the working group was up to it. They weren’t up to more nuanced rules to “always send CD=1” which should be struck from the RFC. > The consequence of following the protocol's current rules is a lot of > deadweight. Namely, unusable RRSIG resource records sent in each reply of > authoritative data just to include the DNSSEC security algorithm. The > signatures need not make mathematic sense - as no one would need to validate > them - with one exception. Where ever there is a division of key > responsibilities such as having one organization manage the KSK and a > different manage the ZSK, a ZSK may be "forced" to exist by rule and > operational configuration. > > (Removed the remainder of the thread history…) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
