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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
