Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

[Edward Lewis <[e-mail]>]

A few follow ups:

On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" <[e-mail] on behalf of [e-mail]> 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...)