<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>>于2018年1月8日周一 上午4:00写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 7, 2018, at 1:55 PM, Olafur Gudmundsson <<a href="mailto:ogud@ogud.com" target="_blank">ogud@ogud.com</a>> wrote:<br>
><br>
> Sorry for the late response,<br>
<br>
The issue is longstanding so there's no rush, your follow-up is appreciated.<br>
<br>
>> Of the 453 domains with iteration counts above 150 only 4 have counts<br>
>> in excess of 2500, which are unsupported by many resolvers with the<br>
>> default RFC5155 iteration count limits. The remaining "interesting"<br>
>> domains are the 449 with iterations in the interval [151,2500].<br>
><br>
> RFC5155 advice is in hindsight bad, it was written from the point of<br>
> “more work is better protection”.<br>
> Advances in graphics cards have shown that NSEC3 is nothing but an<br>
> obfuscation mechanism, [...]<br>
<br>
The sparse signing (opt-out bit) feature of NSEC3 was and I think still is<br>
useful, despite the fact that it is sometimes misused by small "leaf"<br>
domains, that don't have a large number of insecure delegations.<br>
<br>
The salt value and iteration counts above 0 (i.e. 1 as you note below)<br>
turned out to be largely counter-productive. It seems that Verisign,<br>
for example, understand this quite clearly. The ".com" zone has an<br>
empty salt, 0 iterations, but uses opt-out:<br>
<br>
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM<br></blockquote><div><br></div><div>"empty salt, 0 iteration" will be close to NSEC , just a simple hash map.<br></div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> The harm from NSEC3 iterations if mainly felt be resolvers, but it is<br>
> easy to generate an attack against authoritative servers that serve<br>
> zones with high iteration counts causing them to fall over.<br>
<br>
Yes, I expect the zone with an iteration count of 65535 would take<br>
a noticeable CPU hit at very modest query rates:<br>
<br>
$ openssl speed sha1<br>
...<br>
Doing sha1 for 3s on 64 size blocks: 10499108 sha1's in 3.01s<br>
...<br>
<br>
So, on e.g. my CPU, 65536 iterations of sha1 would take 18ms, so the<br>
server consumes ~1 CPU for just ~54 queries / sec!<br>
<br>
<br>
> I would like to see someone write an RFC saying Max iteration count of <= 10 for all algorithms.<br>
<br>
If the number is to be variable (and not just "0", really 1, like ".com")<br>
then the upper bound should be a power of 2. So the draft could choose:<br>
<br>
0 - Accept the reality that further hashing is futile.<br>
15 - Support a modest additional work-factor.<br>
127 - This covers the vast majority of deployed systems as counts above<br>
100 are quite infrequent.<br>
<br>
That said, the reduced limit would for quite some time apply only to servers,<br>
resolvers would still need to support the RFC5155 limits for some time, as it<br>
will be a while before the message gets out to all the server operators and<br>
domain owners who'd need to make changes.<br>
<br>
>> Of these:<br>
>><br>
>> * 258 have 512-bit P256 (algorithm 13) keys and 300 iterations. This<br>
>> exceeds the RFC5155 iteration limits and breaks secure DoE for many<br>
>> resolvers. All these domains are hosted at "<a href="http://ns1.desec.io" rel="noreferrer" target="_blank">ns1.desec.io</a>”.<br>
> Nit: P256 keys are 256 bit long but have two 256 bit numbers in the key, but<br>
> equivalent to 3100 bit RSA key.<br>
<br>
Yes, I know. I am not sure how resolvers determine the key length. Is it<br>
from the bit count of the published key, or the algorithm bit strength?<br>
Either way though, the number is < 1024, so the limit of 150 is applied<br>
by many resolvers, in particular "unbound" (and IIRC BIND) in their default<br>
configurations.<br>
<br>
>> [...] So the problem described in the draft exists in the wild,<br>
>> but is, for the moment at least, quite infrequent. The vast majority of<br>
>> domains use sensibly low counts (with 1 being the most popular value, though<br>
>> frankly 0 would have done just as well, but is perhaps not as well understood).<br>
><br>
> I think NSEC3 spec is counterproductive in specifying the iteration count<br>
> as additional iteration so value 1 is actually two iterations.<br>
<br>
Yes, I think this has some operators unsure of the meaning, and so they<br>
use "1". I think more would have chosen "0" (that is actually "1") if<br>
the meaning were more obvious.<br>
<br>
>> With a bit of luck, better documentation and tools that warn users to<br>
>> not exceed 150 (regardless of key size) will keep the problem largely<br>
>> in check.<br>
><br>
> 150 is still to high IMHO,<br>
<br>
As I mentioned above, sadly resolvers still need to support the<br>
RFC5155 limits for some time. You're right of course that if<br>
we're clarifying the limits for authoritative servers we may as<br>
well make the changes that make most sense in hindsight. So<br>
do you think that the server limits be should be "0", "15" or<br>
"127"?<br>
<br>
One might even encourage the maintainers of authoritative server<br>
software to artificially cap the user-specified iteration count<br>
to the recommended value unless an additional "I really mean it"<br>
override is also configured. With that, the next zone resigning<br>
would have an iteration count of max(configured, 5155bis limit).<br>
<br>
>> So an update to RFC5155 that sets a flat iteration limit of 127 and<br>
>> reserves the leading 9 bits of the iteration count would IMHO be a<br>
>> good idea.<br>
><br>
> ^^^ Retiring NSEC3 is a better idea,<br>
<br>
I don't think that's practical, it is too widely deployed, and retiring<br>
it would be too disruptive. I want DNSSEC adoption to grow, and not be<br>
disrupted by another major protocol change.<br>
<br>
NSEC3 can be simplified:<br>
<br>
1. Encourage users to not bother with "salt", an empty salt saves some<br>
bandwidth and CPU and is just as effective. It is too difficult to<br>
change salt values anyway once a zone is signed.<br>
<br>
2. Encourage users to set the iteration count to 0 (really 1), cap it<br>
at one of 0, 15 or 127 (based on WG/IETF consensus).<br>
<br>
> and NSEC5 is not the solution,<br>
<br>
Indeed, in my view that falls into the "disrupted by another major protocol<br>
change" category. Cool crypto research, but not operationally sound.<br>
<br>
>> In any case, protocols with integral fields where only a subset of the<br>
>> values is supported, and the supported set depends on other parameters<br>
>> is a design feature that should be avoided.<br>
><br>
> +1<br>
<br>
Thanks for the moral support.<br>
<br>
--<br>
Viktor.<br>
<br>
<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-operationsdns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-operations</a> mailing list<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><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">致礼 Best Regards<br><br>潘蓝兰 Pan Lanlan<br></div></div>