<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 10:22 AM Paul Hoffman <<a href="mailto:paul.hoffman@icann.org">paul.hoffman@icann.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">On Oct 20, 2021, at 9:29 AM, Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>> wrote:<br>
<br>
> I'd like to encourage implementations to change the default RSA key size<br>
> for ZSKs from 1024 to 1280 (if sticking with RSA, or the user elects RSA).<br>
<br>
This misstates the value of breaking ZSKs. Once a KSK is broken, the attacker can impersonate the zone only as long as the impersonation is not noticed. Once it is noticed, any sane zone owner will immediately change the ZSK again, thus greatly limiting the time that the attacker has.<br></blockquote><div><br></div><div>This presupposes what the ZSKs are signing, and what the attacker does while that ZSK has not been replaced.<br><br>For example, if the zone in question is a TLD or eTLD, then the records signed by the ZSK would include almost exclusively DS records.</div><div>DS records do change occasionally, so noticing a changed DS with valid signature is unlikely for anyone other than the operator of the corresponding delegated zone.</div><div>An attacker using such a substituted DS record can basically spoof anything they want in the delegated zone, assuming they are in a position to do that spoofing.<br>And how long those results are cached is controlled only by the resolver implementation and operator configuration, and the attacker.</div><div><br></div><div>So, the timing is not the duration until the attack is noticed (NOTICE_DELAY), it is the range MIN_TTL to MIN_TTL+NOTICE_DELAY (where MIN_TTL is min(configured_TTL_limit, attacker_supplied_TTL)).</div><div><br></div><div>The ability of the operator of the delegated zone to intervene with the resolver operator is not predictable, as it depends on what relationship, if any, the two parties have, and how successful the delegated zone operator is in convincing the resolver operator that the cached records need to be purged.</div><div><br></div><div>Stronger ZSKs at TLDs is warranted even if the incremental improvement is less than what cryptographers consider interesting, IMNSHO. It's not an all-or-nothing thing (jump by 32 bits or don't change), it's a question of what reasonable granularity should be considered in increments of bits for RSA keys. More of those increments is better, but at least 1 such increment should be strongly encouraged.</div><div><br></div><div>I think Viktor's analysis justifies the suggestion of 256 bits (of RSA) as the granularity, and thus recommending whatever in the series 1280, 1576, 1832, 2048 the TLD operator is comfortable with, with recommendations against going too big (and thus tripping over the UDP-TCP boundary).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In summary, it is fine to propose that software default to issuing larger RSA keys for ZSKs, but not with an analysis that makes a lot of unstated guesses. Instead, it is fine to say "make them as large as possible without causing automatically needing TCP, and ECDSA P256 is a great choice at a much smaller key size".<br></blockquote><div><br></div><div>I'm fine with adding those to the recommendations (i.e. good guidance for the rationale for picking ZSK size and/or algorithm), with the added emphasis on not doing nothing.</div><div><br></div><div>Brian </div></div></div>