RE: Last ditch proposal for crypto suites

["Housley, Russ" <rhousley@rsasecurity.com>]

Phill:

I think the SHOULD is the way to handle the key size issue.
Here is how the S/MIME WG addressed this issue in RFC 2633.

    A user agent SHOULD generate RSA key pairs at a minimum key size of
    768 bits. A user agent MUST NOT generate RSA key pairs less than 512
    bits long. Creating keys longer than 1024 bits may cause some older
    S/MIME receiving agents to not be able to verify signatures, but
    gives better security and is therefore valuable. A receiving agent
    SHOULD be able to verify signatures with keys of any size over 512
    bits. Some agents created in the United States have chosen to create
    512 bit keys in order to get more advantageous export licenses.
    However, 512 bit keys are considered by many to be cryptographically
    insecure.  Implementors should be aware that multiple (active) key
    pairs may be associated with a single individual. For example, one
    key pair may be used to support confidentiality, while a different
    key pair may be used for authentication.

Russ


At 08:49 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote:
>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
> >