[dns-operations] [Ext] Obsoleting 1024-bit RSA ZSKs (move to 1280 or algorithm 13)

[Brian Dickson]

On Wed, Oct 20, 2021 at 10:22 AM Paul Hoffman <paul.hoffman at icann.org>
wrote:

> On Oct 20, 2021, at 9:29 AM, Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>
> > I'd like to encourage implementations to change the default RSA key size
> > for ZSKs from 1024 to 1280 (if sticking with RSA, or the user elects
> RSA).
>
> 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.
>

This presupposes what the ZSKs are signing, and what the attacker does
while that ZSK has not been replaced.

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.
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.
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.
And how long those results are cached is controlled only by the resolver
implementation and operator configuration, and the attacker.

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)).

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.

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.

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).


> 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".
>

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.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211021/0ca41e93/attachment.html>