[DNSOP] Re: New draft on collision free key tags in DNSSEC

[Petr Špaček <[e-mail]>]

On 30. 07. 24 9:41, libor.peltan wrote:
> 2) I would still vote for allowing one keytag collision per zone (not 
> per whole chain-of-trust, like Bind does) instead of none. This would be 
> more comfortable for many older/simpler signers and not too much 
> additional work for validating resolvers, IMHO.

Per-zone limit does not defend against resource exhaustion because an 
attacker can construct chain of delegations a.b.c.d.e...... and max out 
limit on each level. Then you instantly get about 126*(per-zone limit on 
validations) just for this particular attack vector.


> 3) The idea of imposing the limit at first on new algorithms seems 
> reasonable -- new algos mean new software which can easily adhere to new 
> rules. However, we are in the situation that in fact, the existing 
> resolvers already impose such (or very similar) limits on existing 
> algorithms. So the document stating the requirement for auths/signer 
> actually comes retrospectively, and I see no point in using this 
> conservative enforcement strategy. Anyway, it can realistically take 
> decades before any new algorithms seize some good portion of DNSSEC. In 
> other words, that flag day has already silently passed.

I agree with the angle that silent flag day has happened already. It's 
just undocumented (in form of RFC).


> 4) It would look prettier if the document mentions also rules/preactices 
> for validating resolvers. Stating what the validator should do (and what 
> it must not do) when observing a tiny or a huge keytag collision.
> 
> 5) I agree with Vladimir that keytag collision is just a small piece of 
> the whole problematic of DNSSEC validator resource consumption. I'm not 
> sure if it's wise to start with this single piece in one document, or 
> working on a more covering document, exploring it all. But it's always 
> useful if we somehow document the limits for signers and validators, so 
> that they can interoperate smoothly. The goal is to prevent surprises 
> when the signer signs somehow, and various validators do and don't 
> validate due to imposing unexpected limits. This is what we should do!

I agree with both of you. This is very small piece of the puzzle and 
IMHO not worth a standalone document - the overhead is too large.

I could see value in a document "here's list of ideas to think about if 
you are trying to defend against resource exhaustion" - in DNSSEC and 
DNS in general.
- RRSIG validation vs. state explosion
- adversarial DNSKEY values (e.g. RSA gives plenty of leeway)
- DS matching & validation
- NSEC3 iterations, NSEC3 with many labels, wildcards, chains ...
- trivial random subdomain attack into a signed domain
- SIG(0) flood
- CNAME/HTTPS/additional processing limits
- five different ways to misuse delegation and CNAMEs
- lots of out of bailiwick NS names
- RD=0 non-compliance
- query coalescing misuse ...
- ...

My two cents.

Petr Špaček
Internet Systems Consortium


> Dne 26. 07. 24 v 2:34 Shumon Huque napsal(a):
>> Folks,
>>
>> For discussion ...
>>
>> Mark Andrews, Elias Heftrig, and I have a new draft on collision free 
>> key tags in DNSSEC. This topic has been in the air since the Keytrap 
>> vulnerability disclosure -- and IETF120 hallway track conversations 
>> this week prompted us to write up a rough initial proposal for this. 
>> Will need much more fleshing out of details etc, but we hope this can 
>> serve as a starting point ...
>>
>> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-keytags-00
>>
>> Shumon, Mark, Elias