A few follow ups:
On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" <dnsop-boun...@ietf.org
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
