[Top] [All Lists]

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

2008-04-14 12:18:09

David Crick wrote:
 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

This second one (AES-128 replaces 3DES) *really* appeals to me.

It should also further appeal to resource-constrained environments,
where (therefore) not having to implement (or use) 3DES would be
a bonus.

Actually, maybe we need to add / reconsider having a section
in the ECC doc that says

"if AES-128 is not explicitly in the set of preferred algorithms, then
it is implicitly added at the end.  If neither AES-128 or 3DES are
explicitly listed, then both of them are implicitly added, with 3DES

NB, this is weaker than the idea of a "strict suiteB flag" (my original
proposal), and slightly weaker than your "AES128 replaces 3DES."

I find implicit rules of the RFC 4880 controversial. They could have been like this: if there is no encryption keys preferences, only then 3DES is implicitly present. That is, it would be limited to old keys. I would favor explicit rules, if possible.

Besides, even without this thought, I don't see how your latest proposal gives an ECC public key holder a mechanism to block transmission with 3DES (because 3DES sneaks in as an alg. for ECC keys, it may be chosen by the sender).