ietf-openpgp
[Top] [All Lists]

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

2008-04-14 12:05:53

Ian G wrote:



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."


I had to look at all of 11.3 to try and make sense of this, and found that whole subsection to be hopelessly confusing. Can we have a simple statement as to whether an OpenPGP-ECC key can be used with TripleDES or not? Can messages be mixed-mode or not?
OK, the suggestion noted. The support for TrippleDES follows from RFC 4880.


It seems to me that if an application creates and exports an OpenPGP-ECC key (only) then that public key cannot be used with TripleDES, as the document does not suggest it anywhere (and implies it is ruled out). Which means there should be a specific claim that this ECC draft overrules the "guarantee" of TripleDES intersection in RFC4880.

The quote above is an example. It has an "IF" in it. I didn't imply in 11.3 to rule TrippleDES out.
(To me, this seems like a reasonable price to pay to get a good, clear result.)
I think it is important that new keys seamlessly integrate with existing keys and deployed applications. It's a good cause to allow non-government users to increase the strength of their public keys at lower cost that ECC provides.

We have similar issue with FIPS.

Alternatively, there should be a specific claim permitting use of TripleDES and describing how/what.

I will add an assertive statement about TrippleDES.

(I should note that I do not recall the discussions of a few months back. This should be a "good thing" because it allows me to view it as a first time reader. My routine excuse is that if I can't understand it from a simple reading then I suspect we are putting an unnecessary burden on first time readers, but not many agree with that!)


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


Personally, I would have said that the recipient should reject the message with an error. If there is a mixed mode message, then the sender is in error, allowing for a potential attack. We might not be able to stop the attack through a misbehaving client, but we should red-flag it when we see it.

(but I've not seen the full sense yet, I may be wrong.)

(Apps have these flags to decrypt even when there are errors in modes, so that's ok.)


I agree. When Suite-B profile is involved user may not be able to send out (encode). Splitting a message into two, one using 3DES and another one using AES, is not an option. Depending on how the discussion about choosing the Suite-B goes (key or software?), I will add stricter statement about the the failure on the sender's side.

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?


these complexities will roll forward in history :( ...


iang