RE: Last ditch proposal for crypto suites

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

I don't think we should spec the RSA keystrengths since this is not
typically a negotiated parameter, the parties tend to have one key and the
trustworthiness of that key is the issue.

i.e. the endpoint may reject a key because it does not accept the
certificate (or other validation). If an end point rejects 1024 bit keys as
a matter of policy that will be incorporated into the certification policy.

What we should do however is to require that the implementations accept key
sizes up to at least 2048 bits and possibly 4096. As a practical matter
requiring keys to be multiples of 32 bits is also a good idea (there is a
1000 bit key in use).


		Phill

> -----Original Message-----
> From: Alex Alten [mailto:Alten@attbi.com]
> Sent: Friday, August 30, 2002 10:22 AM
> To: Hallam-Baker, Phillip; Charlie_Kaufman@notesdev.ibm.com;
> ipsec@lists.tislabs.com
> Subject: RE: Last ditch proposal for crypto suites
> 
> 
> This sounds reasonable.  Shouldn't we also spec the RSA key lengths?
> And is 3DES-CBC doing EDE or EEE?  (I assume EDE is preferable?)
> 
> - Alex
> 
> 
> At 06:45 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote:
> >Actually following on from Radia's point I think we would 
> have three suites:
> >
> >1: RSA/3DES-CBC/SHA-1 
> >2: RSA/AES-CTR-128/SHA-2
> >3: RSA/AES-CTR-256/SHA-2
> >
> >The argument for suite 3 being that if something 
> catastrophic does happen in
> >the processing world there is a last ditch fallback.
> >
> >I would limit the SHOULD suites to the DSA variants of the above but
> >excluding 3DES since the demand for DSA is likely to be 
> restricted to people
> >who want NIST acredited crypto and 3DES ain't acredited.
> >
> >4: DSA/AES-CTR-128/SHA-2
> >5: DSA/AES-CTR-256/SHA-2
> >
> >I don't want any other suites. I don't want EC variants, I 
> don't want a
> >different chaining mode for each day of the week.
> >
> >One thing that would be very useful for integration with 
> specs in the Web
> >Services space is if a unique URN was specified for each suite. EG
> >urn:ietf:rfcxxx:cryptosuite-1
> >
> >This would then allow the suite specification to be 
> specified in negotiation
> >at the Web services level. So that a UDDI directory or WSDL 
> could contain a
> >policy statement that says 'this service requires the use of IPSEC
> >cryptosuite 2 or 4'.
> >
> >Note that we have fewer suites in total than we had 
> symmetric algs for IKE1.
> >
> >
> >	Phill
> >
> >> -----Original Message-----
> >> From: Alex Alten [mailto:Alten@attbi.com]
> >> Sent: Friday, August 30, 2002 2:33 AM
> >> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com
> >> Subject: Re: Last ditch proposal for crypto suites
> >> 
> >> 
> >> At 05:58 PM 8/29/2002 -0400, 
> Charlie_Kaufman@notesdev.ibm.com wrote:
> >> >
> >> >I propose that we remove the text for a la carte negotiation 
> >> from the IKEv2
> >> >spec, 
> >> ...
> >> 
> >> I'm amazed that after so many years the WG is still arguing 
> >> over this issue
> >> (or maybe I'm not).  As Steve B. pointed out interoperability 
> >> and buggy code
> >> are very important considerations.
> >> 
> >> We only need to spec two MUST have suites.  RSA/3DES-CBC/SHA-1 and 
> >> RSA/AES-CTR-128/SHA-2.  Forget the rest, they are going into 
> >> the dustbin
> >> of history.  Details like PFS, HMAC should be the same across 
> >> the suites. 
> >> 
> >> What I'll add, along with my vote to do suites, is that the 
> >> receiver MUST
> >> accept whatever suite the sender chooses to use.  This will 
> >> make life a lot
> >> easier and will not be a "security" problem. The difference 
> >> between 3DES and 
> >> AES-128 is minor.  What we are really after is to provide an 
> >> upgrade path from
> >> 3DES to AES, to gain the huge performance improvement and yet 
> >> not screw our
> >> existing customers.
> >> 
> >> Choose the mandatory suites wisely and sparingly.  Once the 
> >> IKEv2 dust has 
> >> settled there will be much more difficult fish to fry.
> >> 
> >> Good luck Charlie & Co.,
> >> 
> >> - Alex
> >> 
> >> --
> >> 
> >> Alex Alten
> >> Alten@ATTBI.com
> >> 
> >
> --
> 
> Alex Alten
> Alten@ATTBI.com
>