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 <[email protected]> wrote: > > A few follow ups: > > On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" <[email protected] > on behalf of [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
