Hi again,
this thread is NOT related to KeyTrap CVE.
This thread focuses on CVE-2023-50868 "NSEC3 closest encloser proof can
exhaust CPU" and lack of caveat about work limits in RFC 5155 section 8.3.
Please note this attack is not described in the KeyTrap technical paper
linked in the other thread (because it was discovered by a different team).
Observation
===========
BCP in RFC 9276 says that we should use sensible limit for NSEC3
iterations. Most implementations at the time went with 150.
What the RFC does not mention is that NSEC3 closest encloser proof
algorithm multiplies that number of iterations by **number of labels**
it needs to try, so for most attack-purposes the effective value is:
(125 labels) * (NSEC3 RR iterations value - usually capped at 150)
Hardware limits
===============
To put things in perspective, try this command:
$ openssl speed sha1
On hardware I have it shows ~ between 9 - 4 _million_ operations per
second for block size between 16 and 256 bytes. That's a lot! ... or not
so much.
Say we go with the middle value:
6 500 000 / 150 iterations as common limit / 125 labels
= 346 closest encloser proofs per second
**Now** divide by number of NSEC3 RRs in the answer you are trying to
validate as well! Let's start with 3:
346 / 3 = 115 QPS
If we consider also answers which contain CNAME into another zone hosted
on the same server we are at half of this value.
Of course the resulting QPS is _upper bound_ because it does not allow
of RRSIG validation and any other overhead in the resolver.
Impact
======
Depending hardware and NSEC3 iterations limits in place, attacker can
exhaust CPUs with QPS somewhere in order of small hundreds.
The Question
============
What work limits you consider sensible for RFC 5155?
Feel free to propose your own variables to be used, and don't forget to
include back-of-envelope example to support your proposal (using say 6
500 000 SHA1 operations per CPU/second as a base).
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
