Subject: [DNSOP] RFC4641bis version 02.

From: Olaf Kolkman <[email-masked]>
Date: Fri, 26 Feb 2010 09:06:31 +0100

Colleagues,

I have just posted RFC4641bis version 2.

The document contains a number of significant changes which address a number of the open-issues (see http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/). In some cases text has been rewritten in such a way that it is not immediately obvious if some of the open issues are still relevant. Since today was the last opportunity for me to submit the document before the cut-off and I believe the text is close enough for review on substance and gathering feedback. 

Although a review on (english) style, nits and spelling would be appreciated I believe that can wait until the review on substance has taken place.

http://www.ietf.org/id/draft-ietf-dnsop-rfc4641bis-02.txt

Once the document is available through the tools interface you should be able to study the diffs.
http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Feb 2010 06:19:22 -0800

S 3.1.1:

   Finally there is a risk of cryptanalysis of the key material.  The
   cost of such analysis are correlated to the length of the key and the
   amount of signed material that is available to the analyst.

This statement is false for RSA and as far as a I know, for
any major signature algorithm: RSA is not weakened by the attacker
having a large number of plaintext/ciphertext pairs. [Historical
note: this used to be a problem with symmetric ciphers but is
now mostly just habit. Modern cryptographic algorithms shouldnt
exhibit analytic weaknesses with any practical amount of known
plaintext.]

   For
   reasons of signing speed and DNS packet length one may want to keep
   keylenght at a minimal responsible length and change the key
   relatively frequently while not interacting with the parent.

This statement is a non-sequiter. Sure, one may want to keep the keylength
short to improve signing speed, but since changing the key frequently doesn't
significantly improve security against analysis (as has been covered on-list
ad nauseum), the last half of the sentence doesn't make any sense.

-Ekr

On Fri, Feb 26, 2010 at 12:06 AM, Olaf Kolkman <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Feb 2010 14:41:57 -0500 (EST)

> ad nauseum), the last half of the sentence doesn't make any sense.

cycling a 1024 bit RSA key every month does improve the security of a zone,
compared to not cycling the key.

Cryptanalyses is a function of time (and money). If you reduce the usable
time for attackers, their spending goes up or they will not have enough time
to break the key before it is retired. The recommended key size and time
in the document reflects current cryptographers extremely conservative
estimate of what is deemed safe by a few orders of magnitudes.

Keep in mind that some recommendations (I believe NIST is one) does not
differentiate between key usage when they recommend key sizes. For encryption,
there is a much larger required forward secrecy requirement. For signing
keys, there is none. One could publish the private TTL time after rollover.

(an interesting artifact was also the usage of an algorithm. Openswan uses
  an md5 hash to calculate its vendorid hash. Not to obfuscate it, but just
  to make it unique. This caused problems for FIPS certification because md5
  was not allowed)

The above quoted paragraph clearly states this, despite your "covered on-list
ad nauseum" claim.

Paul

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 26 Feb 2010 15:48:20 -0500

See below a small feedback from an "applied cryptography" perspective. 
In essence, I agree with Eric.

> keys, there is none. One could publish the private TTL time after rollover.

Either of two things:

(A) Some threat/vulnerability analysis is assumed behind a DNSOP-type 
recommendation, and then *I* claim that 1024 RSA modulus cycling every 
month is really an overkill. (I have unpublished written material 
supporting this view.)

  - or -

(B) Some authority (you referred to NIST which seems to refer to 
academic-community factorization exploits, wherein the academic 
community declare themselves unable to digress about "activities that 
take or may take place behind closed doors, such as at government 
laboratories" [1]) decided that 1024 was sufficient. There is no basis 
other than blind faith in the authority reputation for selecting 1024 
and not e.g. 3600 for a given field of use.

[1]     Joppe W. Bos, Marcelo E. Kaihara, Thorsten Kleinjung, Arjen K. 
Lenstra, and Peter L. Montgomery, "On the Security of 1024-bit RSA and 
160-bit Elliptic Curve Cryptography", version 2, August 7, 2009, 18 
pages (published on pages 43-60 in "Comments on the Transition Paper" 
available at 
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transition_comments_7242009.pdf, 
which was listed at http://csrc.nist.gov/groups/ST/key_mgmt/index.html).

Basically, you adhere to (B) and suggest 
1024-bits/1-month-cryptoperiod, hence you inflate the requirements over 
NIST's.

Thus, in *my* opinion, you induce a waste of DNSSEC bandwidth / CPU time 
/ DNS operations overhead (i.e. rollover management).

>  to make it unique. This caused problems for FIPS certification because md5

(...)

> The above quoted paragraph clearly states this, despite your "covered 

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Feb 2010 16:51:11 -0500 (EST)

On Fri, 26 Feb 2010, Thierry Moreau wrote:

> recommendation, and then *I* claim that 1024 RSA modulus cycling every month 
> is really an overkill. (I have unpublished written material supporting this 
> view.)

Cryptographic overkill is not very harmful as long as the queries still
mostly fit snuggly in most UDP packets.

> academic-community factorization exploits, wherein the academic community 
> declare themselves unable to digress about "activities that take or may take 
> place behind closed doors, such as at government laboratories" [1]) decided 
> that 1024 was sufficient. There is no basis other than blind faith in the 
> authority reputation for selecting 1024 and not e.g. 3600 for a given field 
> of use.

It's far from blind faith. The article *you* quote is pretty clear:

"At this point in time a brute-force attack agaisnt 1024-bit RSA
would require about two years on a few million compute cores with
many tens of gigabytes of memory per processor or mainboard."

"open community" effort of a 1024-bit RSA factorization is currently out of
reach"

"factoring breakthroughs have not occured for several decades, and
polynomial time factoring on an actual quantum computer still seems to
be several decades away"

It concludes with:

"an open community effort that would factor a 1024-bit RSA modules cannot
be expected by the year 2015"

You might be right that the NSA worries about the safety margin for 1024
bit RSA based on information unknown to us, and that's why NIST is
recommending to phase out 1024 bit RSA. But it is a giant leap from
"two years on a few million cores" to "one month".

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

> Thus, in *my* opinion, you induce a waste of DNSSEC bandwidth / CPU time / 
> DNS operations overhead (i.e. rollover management).

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Feb 2010 15:02:44 -0800

On Fri, Feb 26, 2010 at 11:41 AM, Paul Wouters <[email-masked]> wrote:
> to break the key before it is retired.

Yes, it increases their spending by the ratio of the frequency of the
key cycling to the original cycle time. For instance cycling at the rate
of monthly instead of a year adds approximately 3.6 bits of security,
equivalent to about an 1100 bit of RSA key
(calculations here:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html)

As I said, this is a trivial improvement.

> The recommended key size and time

Really? Which cryptographers recommend rolling over keys monthly?

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Feb 2010 19:20:58 -0500 (EST)

> As I said, this is a trivial improvement.

I'll have to read that carefully before I can comment on that...

> Really? Which cryptographers recommend rolling over keys monthly?

None. They all said 1024 RSA would be fine for 1 year or even longer.
That's why I said rolling it monthly is "extremely conservative". I
guess I might be wrong depending on the above listed work, but still
need to read that carefully.

Paul