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

[Mark Andrews <[e-mail]>]

> On 15 Apr 2019, at 11:21 pm, Edward Lewis <[e-mail]> wrote:
> 
> 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.

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: [phone]              INTERNET: [e-mail]