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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
