Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-algs-03.txt

From: [email-masked]
Date: Fri, 8 Oct 2010 01:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure
	Author(s)       : G. Huston
	Filename        : draft-ietf-sidr-rpki-algs-03.txt
	Pages           : 6
	Date            : 2010-10-08

This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size and signature format for
the Resource Public Key Infrastructure subscribers that generate
digital signatures on certificates, Certificate Revocation Lists, and
signed objects as well as for the Relying Parties (RPs) that verify
these digital signatures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-algs-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Sean Turner <[email-masked]>
Date: Tue, 12 Oct 2010 14:06:04 -0400

I think this version looks great with one exception.  I believe the 
last paragraph in Section 5 (repeated below for convenience) should be 
deleted:

  In anticipation of a potential need to transition to stronger
  cryptographic algorithms in the future, CAs and RPs SHOULD be able to
  generate and verify RSASSA-PKCS1-v1_5 signatures using the SHA-512
  hash algorithm and RSA key sizes of 3072 and 4096 bits.

I think we should require that implementations support algorithm 
agility, but I'd like to not presuppose the algorithms and key sizes 
for something that's going to happen 5-8 years down the road.  Who 
knows maybe SHA3 will be so whiz bang maybe we'll want to move to it. 
  If we added the following as a security consideration I believe the 
intent would be satisfied:

   Implementations MUST support algorithm agility.

spt

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Wed, 13 Oct 2010 08:29:26 +1100

Hi Sean,

That last paragraph was inserted in response to this posting from David Cooper

   http://www.ietf.org/mail-archive/web/sidr/current/msg01067.html

At the time David's proposed text attracted no further comment, and I folded it into the subsequent rev of the draft.

I understand that you are proposing that we now drop this text from the next rev of the draft.

I'm happy to do so, unless of course others pipe up to your proposal with a contrary opinion.

  Geoff

On 13/10/2010, at 5:06 AM, Sean Turner wrote:

> I think this version looks great with one exception.  I believe the last paragraph in Section 5 (repeated below for convenience) should be deleted:
> 
> I think we should require that implementations support algorithm agility, but I'd like to not presuppose the algorithms and key sizes for something that's going to happen 5-8 years down the road.  Who knows maybe SHA3 will be so whiz bang maybe we'll want to move to it.  If we added the following as a security consideration I believe the intent would be satisfied:
> 

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 12 Oct 2010 18:15:21 -0400

Sean,

While a generic statement that implementations must support algorithm 
agility is a good one, the RPKI can't transition to a new algorithm 
until everyone has implemented support for the specific new algorithm 
and experience has shown that getting everyone to implement that support 
may take many years.  In the Federal PKI, we began to discuss the need 
to move from SHA-1 to SHA-256 about seven years ago, yet some agencies 
are still saying that they cannot make the transition since they have 
applications that don't support SHA-256.  So, I think it is reasonable 
to begin preparing for a transition at least 5-8 years before the 
transition needs to happen.

In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 will 
be acceptable for so long that by the time there is a need to transition 
to something different the consensus will be that the transition should 
be to something entirely different (e.g., ECDSA with SHA-3).  However, 
the current text is intended to suggest that CAs and RPs be prepared to 
use stronger cryptography in a way that minimizes the extra effort for 
those implementations.  It is much easier for an application that can 
sign/verify 2048-bit RSA to also support 3072-bit RSA than to also 
support ECDSA.

This draft doesn't presuppose that the RPKI will move to 3072-bit RSA, 
it simply helps to ease the transition path to a likely choice for a 
transition to stronger cryptography by mainly encouraging CAs and RPs 
not to hard code their applications to only support one specific RSA key 
length.  If in the future the decision is made to transition to 
something different (ECDSA, SHA-3, RSASSA-PSS) then this text hasn't 
really caused any harm, but it will have to be accepted that such a 
transition will require significantly more time that would be required 
for a transition to algorithms/key lengths more closely related to those 
that are currently required.

Dave

---

From: Sean Turner <[email-masked]>
Date: Wed, 13 Oct 2010 13:05:30 -0400

> transition needs to happen.

I 100% feel you pain and I completely agree that we should prepare for 
a transition *now* by requiring algorithm agility.

> sign/verify 2048-bit RSA to also support 3072-bit RSA than to also 

Definitely not arguing that moving to a large key size for RSA is 
harder than moving to another signature algorithm.

> that are currently required.

I used the word "presuppose" because it's a SHOULD requirement to 
support 3072-bit and 4096-bit RSA and SHA-512.  That means 
implementations need to support these key sizes and algorithms unless 
they've got a good reason not too.

I think we have the same goal: require algorithm agility.  I think we 
can do that with a simple one line sentence in the security 
considerations:

or

   Implementations MUST NOT be hard wired to support one hash
   algorithm or modulus size.

If we want to say something encouraging about algorithm agility then 
maybe something like:

   For example, if an implementations supports SHA-512 (code
   available in [draft-eastlake-sha2b]), then that implementation
   actually supports both SHA-384 and SHA-512 because SHA-384 and
   SHA-512 perform identical processing on message blocks and differ
   only in how initial hash value is initialized and how they
   produce their final output.  Likewise, not hard wiring RSA to a
   2048-bit key size allows an implementation to support 3072-bit and
   4096-bit RSA because the algorithm and key format are identical to
   2048-bit RSA modulo the size of the fields.

(or something like that)

spt

>>>     Title           : A Profile for Algorithms and Key Sizes for use 
>>> in the Resource Public Key Infrastructure
>>>     Author(s)       : G. Huston

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Oct 2010 13:20:51 -0400

At 6:15 PM -0400 10/12/10, David A. Cooper wrote:
>Sean,
>
>While a generic statement that implementations must support 
>algorithm agility is a good one, the RPKI can't transition to a new 
>algorithm until everyone has implemented support for the specific 
>new algorithm and experience has shown that getting everyone to 
>implement that support may take many years.  In the Federal PKI, we 
>began to discuss the need to move from SHA-1 to SHA-256 about seven 
>years ago, yet some agencies are still saying that they cannot make 
>the transition since they have applications that don't support 
>SHA-256.  So, I think it is reasonable to begin preparing for a 
>transition at least 5-8 years before the transition needs to happen.

If we have a clear idea of what that transition will be, I agree. 
But, we're not there yet.

>In the case of the RPKI, it may be that 2048-bit RSA with SHA-256 
>will be acceptable for so long that by the time there is a need to 
>transition to something different the consensus will be that the 
>transition should be to something entirely different (e.g., ECDSA 
>with SHA-3).  However, the current text is intended to suggest that 
>CAs and RPs be prepared to use stronger cryptography in a way that 
>minimizes the extra effort for those implementations.  It is much 
>easier for an application that can sign/verify 2048-bit RSA to also 
>support 3072-bit RSA than to also support ECDSA.

It may or may not be easy. If one uses hardware and the hardware tops 
out at 2048-bit RSA, then it's a big problem. If the same hardware 
already supports ECDSA, then a transition to that suite would be 
easier than a transition to 3/4K RSA. If we suggest, at this very 
early date, that the likely next alg suite is 3K or 4K RSA, we may 
cause folks to make poor choices for crypto implementations. That's 
why I think it is preferable to say nothing about specific algs at 
this time.

>This draft doesn't presuppose that the RPKI will move to 3072-bit 
>RSA, it simply helps to ease the transition path to a likely choice 
>for a transition to stronger cryptography by mainly encouraging CAs 
>and RPs not to hard code their applications to only support one 
>specific RSA key length.  If in the future the decision is made to 
>transition to something different (ECDSA, SHA-3, RSASSA-PSS) then 
>this text hasn't really caused any harm, but it will have to be 
>accepted that such a transition will require significantly more time 
>that would be required for a transition to algorithms/key lengths 
>more closely related to those that are currently required.

You use the phrase "likely choice" above, but I don't think we have 
enough info to judge 3/4K RSA as likely. And, because your text used 
"SHOULD" it goes a long way toward "presupposing" :-).

I believe that this text has the potential to cause harm. You have 
argued that we should include this text because we want people to 
plan ahead; if the guidance is wrong, there is a potential to cause 
people to make wrong choices, and that could, in turn, cause folks to 
resist a switch to a different alg suite that might be selected 
later. That is causing harm.

I also do not accept your assertion that switching to a larger RSA 
key size is easier than switching to different alg. It depends on the 
HW/SW products being used, and what these products offer as APIs, etc.

Steve

p.s.  I also note that the CSI WG has agreed to use RPKI certs.  Some 
of them  have already expressed an interest in a transition to ECDSA 
for the SeND protocol (draft-cheneau-csi-ecc-sig-agility-02). This 
shows that there may be good reasons to consider a transition to 
ECDSA vs. 3/4K RSA.