<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Viktor,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks for bringing this issue to everyone's attention and your ongoing work on DNSSEC.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Google Public DNS is also planning to cap NSEC3 iterations to a safe value. Do you have data you can share on the prevalence of high iteration count NSEC3 zones?</div><div class="gmail_default"></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">-Puneet</div><div class="gmail_default" style="font-size:small"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 1, 2021 at 9:42 AM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size<br>
up to perhaps as high as 2500 iterations for 4096-bit keys. In<br>
retrospect such a generous iteration cap is counter-productive. It is<br>
neither particularly effective at keeping your zone content "secret",<br>
nor sufficiently cheap to avoid negative impact on authoritative and<br>
iterative resolver performance.<br>
<br>
In that light, Wes Hardaker and I have authored an Internet-Draft that<br>
strongly recommends setting the NSEC3 additional iteration count to 0<br>
(at least one initial SHA1 hash is always performed).<br>
<br>
<a href="https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02</a><br>
<br>
Today, the Knot resolver became the first one to cap NSEC3 iterations<br>
for now at 150, but this will likely be reduced further (perhaps<br>
ultimately as low as ~25):<br>
<br>
<a href="https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1" rel="noreferrer" target="_blank">https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1</a><br>
<br>
and is expected to be done by more resolvers.<br>
<br>
Since iteration counts above the resolver cap make denial-of-existence<br>
for the entire zone insecure, it is important that all domains with a<br>
high NSEC3 iteration count proactively lower it ideally to 0, but<br>
otherwise ~10 or less.<br>
<br>
While DNSSEC still precludes forged positive answers, any signed<br>
NXDomain or NODATA NSEC3 response can be replayed for any query,<br>
regardless of the qname.<br>
<br>
This impacts any protocol in which negative responses have security<br>
consequences. Potential exposures include:<br>
<br>
- Forged absence of RFC7672 DANE SMTP TLSA records<br>
- Forged absence of CAA records<br>
- Forged absence of HTTPS records enabling various downgrades<br>
- ...<br>
<br>
A number of TLDs have already lowred their iteration counts, and it is<br>
expected that most of the rest will follow soon.<br>
<br>
TLD before after<br>
--- ------ -----<br>
la 150 1<br>
xn--q7ce6a 150 1<br>
blue 100 10<br>
green 100 10<br>
lat 100 10<br>
mx 100 10<br>
pink 100 10<br>
red 100 10<br>
schaeffler 100 10<br>
by 100 3<br>
creditunion 100 3<br>
ally 100 1<br>
autos 100 1<br>
boats 100 1<br>
homes 100 1<br>
motorcycles 100 1<br>
yachts 100 1<br>
<br>
If your DNS zone is configured to use NSEC3, please:<br>
<br>
- Reduce the iteration count to 10 or less.<br>
<br>
- Disable opt-out, you're very unlikely to need it.<br>
<br>
- Either rotate the salt each time you sign, or skip<br>
it entirely. But a short fixed salt is harmless if<br>
leaving it alone easier than changing it.<br>
<br>
Of course, if your zone is small enough (just the zone apex and a<br>
handful of already public or easy to guess names) or in any case has<br>
nothing to hide, even better is to use just plain NSEC. You get smaller<br>
negative replies (less exposure to DoS) and more effective negative<br>
caching at resolvers. So in many cases, it is even simpler to abandon<br>
NSEC3 entirely. Please also consider the pros/cons of that option.<br>
<br>
-- <br>
Viktor.<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>