Subject: Re: [DNSOP] RFC4641bis version 02.

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 1 Mar 2010 07:57:35 -0500

On 2/26/10 4:51 PM, "Paul Wouters" <[email-masked]> wrote:

> On Fri, 26 Feb 2010, Thierry Moreau wrote:

> 
>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>> hence you inflate the requirements over NIST's.
> 
> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthly
> rollover is fine, whereas NIST recommends to migrate to 2048 bit for that.
> 

NIST's recommendations are for 2048 bit RSA, rolled every 1-3 years.  These
recommendations are based on PKI and/or SSL certs mostly, not DNSSEC.  For
DNSSEC, we made a compromise to allow 1024 bit RSA keys around for a while
if we also recommended rolling more frequently.

>> Thus, in *my* opinion, you induce a waste of DNSSEC bandwidth / CPU time /
>> DNS operations overhead (i.e. rollover management).
> 
Depending on the zone, operational overhead is an acceptable cost compared
to having smaller response sizes.

Scott

> Have you crunched the numbers and packet sizes of 768 bit RSA vs 1024 bit
> RSA vs 2048 bit RSA RRSIG's in common DNS packet answers? I believe the
> concensus reached was that differences between 1024 and 2048 bit had a
> significant impact, whereas the difference between 1024 and 768 did not.
> It thus made sense to both play as save as possible within the constraints
> of DNS, and 1024 was recommended with a one month rollover. It was a combined
> effort of cryptanalysts and network engineers.
> 
> Paul
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2010 05:07:42 -0800

> if we also recommended rolling more frequently.

OK, but I don't understand the technical basis for this recommendation. It just
seems like it makes running 1024-bit keys inconvenient without adding any
significant increase in security. Did NIST provide a rationale?

-Ekr

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 1 Mar 2010 08:26:57 -0500

The 1024 bit key guideline is for response sizes (biggest stumbling block
we've encountered so far in .gov deployment).

The rollover frequency is largely based on an extended time frame.  The
extended roadmap is to try and migrate to ECC by 2015, and there is some
belief that 1024 bit RSA might become "breakable" in months (with reasonable
cost - for some definition of "reasonable") by 2015.  I remember some paper
being reference, but I don't recall which one.  And no, I don't fully
understand all of it either, but the near goal (response size) was met,
which was the primary concern for now given the deployment deadlines within
Federal IT security.

Overall, US Federal gov't security policy errs on the side of caution.
Frequent rolling of keys is seen as good practice, even if the evidence on
its effectiveness isn't fully proven.

Scott

http://www.dnsops.gov/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2010 06:11:59 -0800

> which was the primary concern for now given the deployment deadlines within

I don't really see how this addresses the question without some definition of
"reasonable". If a key is breakable at cost C in M months, then it's breakable
at cost Cx in M/x months. Since the x values we're talking about here are
on the order of 10, then you're basically claiming that you can estimate
the attacker's capabilities to within a factor of 5-10, which seems fairly
implausible.

Even if you do think this is true, it would be far more effective to simply use
fractionally larger RSA keys. My understanding is that the major obstacle to
using (for instance) 1100-bit RSA keys is that NIST only accepts a small
number of concrete key sizes for FIPS 140. If so, rather than specifying
a short rollover time, perhaps NIST could address that.

> its effectiveness isn't fully proven.

It's not at all clear to me that this errs on the side of caution. After all,
there are potential risks of exposure with rolling keys all the time,
since it comes with higher management overhead.
-Ekr

---

From: Chris Thompson <[email-masked]>
Date: 01 Mar 2010 16:45:49 +0000

On Mar 1 2010, Eric Rescorla wrote:

> [...] If a key is breakable at cost C in M months, then it's breakable
>at cost Cx in M/x months.

This isn't true in general (although it may be sufficiently so in the
cases under discussion). In particular, not all stages of NFS factorisation
attempts are easily distributable to many small processors. The sieving
stage is, but distributing the matrix reduction stage is much harder (and
a hot research topic).

Recommended background reading: http://eprint.iacr.org/2010/006.pdf

>a short rollover time, perhaps NIST could address that.

Absolutely: the NIST only-powers-of-2 guidelines have had a malign influence
in the DNSSEC context, where the size of the signature so greatly exceeds
that of the data signed.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2010 09:07:39 -0800

> Recommended background reading: http://eprint.iacr.org/2010/006.pdf

Yes, this is correct, but I believe it is true for the values of x under
discussion.

-Ekr