Re: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review)

So glad this thread came up!

On Thu, Oct 13, 2005 at 04:52:29PM +0300, Pasi.Eronen@nokia.com wrote:
> 
> Yes, I think the intention was not to prohibit variable-length
> keys with e.g. Blowfish. Here's proposed text for the clarifications
> document:
> 
>    Section 3.3.5 says that "The only algorithms defined in this
>    document that accept attributes are the AES based encryption,
>    integrity, and pseudo-random functions, which require a single
>    attribute specifying key width."
> 
>    This is incorrect. The AES-based integrity and pseudo-random
>    functions defined in this document always use a 128-bit key.  In
>    fact, there are currently no integrity or PRF algorithms that use
>    the key length attribute (and we recommend that they should not
>    be defined in the future either).
> 
>    For encryption algorithms, the situation is slightly more complex
>    since there are three different types of algorithms:
> 
>    o  The key length attribute is never used with algorithms that 
>       use a fixed length key, such as DES, 3DES and IDEA.
>  
>    o  The key length attribute is always included for the currently
>       defined AES-based algorithms (CBC, CTR, CCM and GCM).  Omitting
>       the key length attribute is not allowed; if the proposal does
>       not contain it, it has to be rejected.
> 
>    o  For other algorithms, the key length attribute can be included
>       but is not mandatory. These algorithms include, e.g., RC5, CAST
>       and BLOWFISH.  If the key length attribute is not included, the 
>       default value specified in [RFC2451] is used.
> 
> Does this look right to you?

Except for one thing, yes it does.

That one thing:

	- IKE is supposed to be algorithm-agile.  Let's say some grinning
          weirdo comes up with a better-than-AES algorithm, or worse, some
          other grinning weirdo breaks AES and we NEED a new cipher.

	  How will we handle ciphers in the future?

There are two ways to solve this:

	1.) All algorithms must have a default key length that is used when
	    no key-length attribute is present.  This means picking a default
	    size for AES.

	2.) All new algorithms with variable-sized keys are treated like AES,
	    and MUST include a key-length attribute.

I don't care which one of those two is picked, but one of them must be used
to maintain algorithm-agility.

Dan

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec