[Top] [All Lists]

Re: I have a technical idea/change for the ECC draft

2008-04-14 11:43:36

You are saying there there is no way to remove 3DES from the set of
algorithm preferences, since it is implicitly there per RFC 4880.

If a key has {AES-128, AES-256} as a preference list, right now it is
effectively {AES-128, AES-256, 3DES}.

And I think it follows that the only logical intended action that your proposal seeks is to break the transmission if one of recipients is an ECC key that disallows 3DES, *if* 3DES is the only shared algorithm for the given set of recipients per RFC 4880.

It is possible to keep this feature limited to the mode of operation of the software (a command line option --cipher-algo, UI element, etc), v.s. making it depend on the attribute of a key.

This assumes that both sides "agree" to use the Suite-B profile. This is usually the case. Many other criteria must be met in order to be in highly regulated Suite-B profile, especially for Top Secret or classified category. These additional requirements include the type of authentication to local keys (which AFAIK must be hardware protected path authentication).

However, I do see the benefit of a feature. If it were to make into the document I suggest to make it more generic and not Suite-B specific. The following alternatives achieve the same what Davit proposed but are easier do understand:

* this key has no implicit default algorithms
* this key replaces 3DES implicit algorithm with AES-128

David Crick wrote:
"11.3. Interoperability with Suite-B profile" currently states:

   "If TripleDES is the only shared algorithms for a set
   of recipients, no Suite-B compliant recipient can be added to the
   mentioned recipient set."

but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the

I therefore have a suggestion:

implement a key-packet preference flag that says "strict SuiteB"

If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.

This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.

Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox

thoughts people?

(as an aside, re my "editorial [readability] changes," I might be
able to sit down and have a go at them on Monday or Tuesday.)