Subject: RE: question on ecc for draft-ietf-send-cga

From: "Tuomas Aura" <[email-masked]>
Date: Thu, 13 Nov 2003 02:20:31 -0800

Having multiple alternative algorithms is a bad idea for the
following reasons:

- Loss of interoperability unless there is at least one 
  mandatory algorithm that everyone must always accept.
- Reduced security: The more algorithms a node accepts, the 
  more likely it is that one of them will be broken. Thus, 
  implementing any algorithm on top of the one mandatory 
  one reduces security.
- Algorithm negotiation does not work for the delegation 
  chain. 
- Negotiation requires a multi-message handshake. This
  makes protocols far less efficient and breaks broadcast
  protocols like SEND (as Jari already pointed out). 
- Ad-hoc networks and networks with no SEND-capable router
  cannot rely on the router to select the algorithm. 

Tuomas 

--------------------------------------------------------------------
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: Sun, 16 Nov 2003 11:18:58 +0100

>   mandatory algorithm that everyone must always accept.

Clearly at least one (and hopefully not more than that) must be a
MUST.

>   implementing any algorithm on top of the one mandatory 

I seem to think of this the other way around. If we put all
eggs in one basket and that basket is broken into...

>   protocols like SEND (as Jari already pointed out). 

Maybe negotiation does. But maybe that is not necessary.
"Offer-and-choose" could perhaps work in the multicast or broadcast
model( haven't thought through all the details though).

>   cannot rely on the router to select the algorithm. 

Ad hoc networks? Is that in the charter? Perhaps small system
performance is more of a concern? At any rate, from what I hear
1024 bit RSA is not estimated to be secure beyond 2010 (and
some have moved to 2048 bit RSA already). Perhaps performance
and fragmentation issues may force a revisiting of this decision
within a few years.

I realize that the IPR issues are not completely clear to all
in spite of the existence of open source implementations
(openssl is one, mozilla NSS as of version 3.8 is another).

Heck, at least in my mind, this also applies to the CGA IPR itself.
For example, the Ericsson/MS statements  apply to
draft-ietf-send-ipsec-XX, but there is no mention of
draft-ietf-send-cga-XX.

But perhaps the only way to get some warm and fuzzy that things
are ok for us non-lawyers is to have some experience and see a track
record of things being ok.

-gabriel