<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日周一 下午3:20写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 8, 2018, at 1:05 AM, Lanlan Pan <<a href="mailto:abbypan@gmail.com" target="_blank">abbypan@gmail.com</a>> wrote:<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>
><br>
> "empty salt, 0 iteration"  will be close to NSEC , just a simple hash map.<br>
<br>
Actually, no, because the input to the hash is the FQDN, so the same<br>
label hashes differently in each domain.  The salt adds little value<br>
unless rotated frequently, and rotation is both difficult and rare<br>
in practice.  See<br>
<br>
   <a href="https://tools.ietf.org/html/rfc5155#section-5" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc5155#section-5</a><br>
<br>
   Then the calculated hash of an owner name is<br>
<br>
      IH(salt, owner name, iterations),<br>
<br>
   where the owner name is in the canonical form, defined as:<br>
<br>
   The wire format of the owner name where:<br>
<br>
   1.  The owner name is fully expanded (no DNS name compression) and<br>
       fully qualified;<br>
<br>
With or without the salt, any rainbow tables are per-domain.  If the<br>
attacker skips pre-computation, and just computes fresh target-specific<br>
hashes from a suitable dictionary, the salt offers no protection.<br></blockquote><div><br></div><div>The salt adds little value unless rotated frequently, and rotation is both difficult and rare in practice.  ＋1</div><div></div><div>Salt is public, not secret, hence, little protection.</div><div></div><div><br></div><div></div><div>When we update ZSK/KSK, salt and rotation can be updated together to reshuffle the subdomain arrangement.<br></div><div>One hash operation is a static subdomain arrangement.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And yes, I am basically suggesting simplifying NSEC3 to "slightly obfuscated<br>
NSEC with opt-out" (perhaps just one hash operation).  This is sufficient to<br>
deter "casual" zone-walking.  A determined adversary will learn most names in<br>
most domains.  They'll be found in certificates, in PTR records, dictionary<br>
attacks, ...<br></blockquote><div><br></div><div></div><div>Agree.</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>
        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-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-operations 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>