Subject: Re: Source Address Selection and CGAs

From: <[email-masked]>
Date: Wed, 12 Nov 2003 18:04:30 +0200

> The table can describe preferences for prefixes and nothing more.

Ouch.

> Thus unless you pit CGA addresses in different prefixes, which would be
> a really BAD idea, you can't use that mechanism AFAIK.

In that case I agree. This means that we do need an API,
if someone wants to tweak the default preference.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 12 Nov 2003 21:40:41 +0100

Current security is based on RSA almost exclusively:

  Each CGA address is associated with a public key and auxiliary
  parameters. The public key is formatted as a DER-encoded
  [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo
  defined in the Internet X.509 certificate profile [RFC3280]. The
  public key SHOULD be an RSA encryption key with the object identifier
  rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public
  key field SHOULD be formatted as an ASN.1 data structure of the type
  RSAEncryptionKey defined in [PKCS.1.2002]. The RSA key length SHOULD
  be at least 384 bits. Using any other public key type or format is
  strongly discouraged as it will result in incompatible CGA
  implementations.

I understand why whatever is chosen (RSA currently) will end up being
*it* as anything else will be incompatible. My question is why not
standardize on ECC instead? This would certainly aid small systems
both because of the lower CPU requirements and because of smaller
packets (true with current levels of 160ECC/1024RSA, improving going
forward to 224ECC/2048RSA, etc).

So was this ever considered? If so, why was it rejected? I couldn't find
any discussion on the mailing list...

tnx,

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Nov 2003 15:15:43 -0800

Gab,

> any discussion on the mailing list...

The original SEND draft that I wrote up very early on suggested using ECC
for exactly the reasons you describe. This was rejected by the original
design team, due to the problem that most ECC methods are heavily RAND IPR
encumbered. RSA is IPR free. With a protocol such as SEND that is deeply
embedded into the base platform, including RAND IPR encumbered technology is
more likely to act as an inhibitor for people who want to implement it.
Unlike CGA, I don't think it would be possible to get a nonRAND IPR
statement on ECC because it is a much broader technology than CGA and, even
if it were, the amount of time and effort required for such a statement
would delay SEND at a time when IPv6 deployment is proceeding apace, thereby
making it less attractive from a market perspective.

At a more general level, one could also ask, why not make the crypto method
negotiable? For a basic system function like SEND, this seems a little
heavyweight, as long as the protocol accommodates Moore's Law, and it also
would complicate the protocol considerably through requiring negotiation.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 13 Nov 2003 00:37:30 +0100

>making it less attractive from a market perspective.
Was this done in the light of the fact that Openssl.org already includes 
(under that license) an
optimized ECC implementation? If open source  can use it, why not SeND?
Further info here:

  http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html

Caveat: That contribution and text is from my employer, but I'm asking 
this question as
an individual who believes ECC may be a better choice. I think the terms 
are fine
(they're part of openssl, so presumably the terms are identical to 
those). But this is
my personal opinion.

-gabriel