Subject: Re: ECC in OpenPGP -00.txt is posted as a draft

From: "David Crick" <[email-masked]>
Date: Thu, 1 May 2008 22:44:53 +0100

>  The discussions we had on pre-submission version of the specification can
> continue with the draft.

The submitted version doesn't (yet) have mention of the
proposed (and generally, it seems, well-received notion of)
a StrictSuiteB flag / flags.  Discussions tailed off on this, but we
(still) need(ed) to give the whole interoperability thing a long
hard look, as per your last message on this topic.

Some comments from me on the (latest) submitted draft:

|    While TripleDES ensures interoperability between applications
|    complaint with OpenPGP and ECC specifications, it doesn't help
|    interoperability with Suite-B profile.  Suppose TripleDES is the
|    only shared algorithm within a set of recipients.  If Suite-B
|    compliant recipient is added to the mentioned recipient set, the
|    sender SHALL NOT send out a message.

shouldn't this be MUST NOT?

(continuing to quote section so people can see the context)
|    This is because TripleDES is
|    excluded from Suite-B and sending out two copies of the same
|    message, one encrypted with TripleDES and another with AES-128 or
|    AES-256, would mean that the same information that must have been
|    protected with Suite-B compliant algorithm was protected instead
|    with non-compliant TripleDES.  This restriction covers other cases
|    in which none of recipients' shared algorithms are allowed by
|    Suite-B.  One of available methods to a recipient to help ensure
|    interoperability with Suite-B is to include one of two Suite-B
|    symmetric algorithms, AES-128 or AES-256, or both, in the set of
|    preferred algorithms.
(end of that section).

But how *on earth* are you going to "enforce" people NOT sending
two copies of the same message under different ciphers??!

Meanwhile, this new bit:

|    While some statements in this specification refer to TripleDES
|    algorithm, this is only done to help interoperability with existing
|    application and already generated keys; AES-256 is the recommended
|    alternative to TripleDES in all circumstances when AES-256 is
|    available.

I (really) like, but probably needs to have added onto the end of it:

Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC,
and may be preferred in more constrained environments.  However,
AES-128 is not allowable when the larger Suite-B profiles are required,
so AES-256 may still need to be implemented for this interoperability.

(But, as I stated at the start of this email, this whole topic still needs
further thought.)

---

From: Derek Atkins <[email-masked]>
Date: Fri, 02 May 2008 09:32:51 -0400

David,

> hard look, as per your last message on this topic.

Actually, it was not well received.  The "OpenPGP way" of doing this
is an application putting in the "accepted ciphers" into the public
key notation.  This document doesn't need to describe that because
it's already well documented in RFC 4880.

Using the notation packet also allows us to support different "Strict
Suites"..  If some other country wants their own stuff in there we don't
need to extend anything; applications just set the appropriate
supported cipher list.  Et Voila, you've got your "flag".

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "David Crick" <[email-masked]>
Date: Fri, 2 May 2008 15:01:56 +0100

On Fri, May 2, 2008 at 2:32 PM, Derek Atkins <[email-masked]> wrote:
>  > a StrictSuiteB flag / flags.
>
>  Actually, it was not well received.

oh.  I counted at least (quick search of the archive):

Jon Callas:
I don't think this is a bad idea at all
...
* I like David Crick's suggestion of a preference that says, "I'm
going to be strict about Suite B." This is a legislative solution, and
it would work well, it's simple, and elegant. End of story.

Werner Koch (quoting the "i like David Crick's" paragraph above):
I support this.

Further, Andrey Jivsov continued the discussion:
One additional issue I realized that we didn't address is the mixing
of keys for two levels of Suite-B profile. It is similar to the issue
of mixing non-Suite-B and Suite-B keys.

TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We
cannot make TOP SECRET keys use AES-128, yet this is what happens with
implicit AES-128. Making AES-256 implicit will not work either,
because now SECRET keys will be picked as compatible with TOP SECRET
keys. Finally, having no implicit preferences disallows TOP SECRET
keys to receive SECRET information.

Do we now need two Suite-B flags?
(end quoting Andrey)

so I thought this had some momentum behind it?

> The "OpenPGP way" of doing this

but the problem was that a recipient currently has no
way of saying "strict suite B" beyond setting one/both
of the AESes as higher up in their preference list and
then *hoping* all of the implementations that ever
send messages use this "advisory" information rather
than (legitimately) taking some other arbitrary intersection
of recipient preferences and choosing something other
than the AES of the correct length.

>  supported cipher list.  Et Voila, you've got your "flag".

perhaps I'm not using correct terminology here?  My "flag"
(or "flags," if we decide we need one for each of the Suite
B profiles, as per Andrey's last message, quoted above)
was intended to be "something" on the key that the user
can set to say "Strict Suite-B."  Is my "flag"/key "something"
the same as what you are calling a "notation packet" ?

I don't think it is?

But I emphasis again that the key cipher preference list
*cannot* be guaranteed to make us Suite-B compliant,
as implementations can choose their own intersections.

So we need something "more."

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 02 May 2008 10:29:57 -0700

> hard look, as per your last message on this topic.

Given later comments by Derek and your subsequent replies, I think we 
may need separate discussion on this. Without assumption that additional 
key properties is the way to go and where this description should be, I 
thought it will be helpful to submit more detailed proposal on how this 
could be done and what are the issues we need to worry about. I will do 
this before coming Monday. We can then have some sort of vote on this 
subject.

> shouldn't this be MUST NOT?

Will do.

> two copies of the same message under different ciphers??!

I meant to provide a warning to implementors that once crypto/messaging 
layer detects sending conflict to a group of recipients, the conflict 
cannot be resolved by sending two separate messages. While each of two 
messages with appropriate subset of recipients can satisfy constrains of 
  crypto/messaging layer, this is not the right thing to do from the 
point of view of information protection.

For example, I thought that the following message misses this point:

Len Sassaman wrote this in Mar 2008:
> Breaking compatibility on the protocol level doesn't mean breaking it on
> the actually application level. In a different thread, there as discussion
> of people using "regular" DSA/EG keys and then adding a recipient who uses
> ECC. So what? The application can encrypt twice, and send the properly
> encrypted messages to the appropriate people.

> (But, as I stated at the start of this email, this whole topic still needs

I would say that, overall, AES-128 should remains the lowest common 
denominator in this specification. It is needed to cover the mix of 
recipients with smartcards, cellphones, etc. Hopefully, "TOP SECRET 
Suite-B profile keys" will not be issued on constrained smartcards. 
Another point, when TOP SECRET keys receive TOP SECRET information, this 
is when AES-256 must be used, only TOP SECRET keys can be in the list of 
recipients. AES-256 SHOULD be in the set of preferred algorithms on each 
key in this case.

---

From: "David Crick" <[email-masked]>
Date: Fri, 2 May 2008 19:00:24 +0100

...
> > StrictSuiteB flag / flags.

>  Given later comments by Derek and your subsequent replies, I think we may
> need separate discussion on this.

An alternative that I've just thought of is to do some sort of
"layering":

rfc4880 (base)
   -> OpenPGP ECC ("anything goes")
      -> Suite-B, and other (e.g. national) "profiles"

So the current "OpenPGP ECC" doc could be completely
re-written, stripping out references to Suite-B (but still
retaining a "relative strengths" section).  This would also
simplify the specification.

*Then* we could write a standalone Suite-B doc, which
would specify a constrained sub-set of OpenPGP ECC.

Note, we'd *still* have the "how to make Suite-B strict"
problem, so *still* might require some sort of kludge.

And/*or* we could even just "avoid" the Strict Suite B
issue altogether, and leave it for the implementers!
Since Suite-B users will (by definition) only want to
communicate with other Suite-B users, then they will be
a self-contained userbase, and so can simply not
implement 3DES [and other ciphers].

Meanwhile the rest of us just set AES-256 and AES-128
at the head of our cipher preferences and put up with the
fact that someone may send us 3DES messages (or using
any other cipher for that matter, if they over-ride using
[e.g., in gnupg] --cipher-algo and disregard the warning).

---

From: Jon Callas <[email-masked]>
Date: Fri, 2 May 2008 15:08:44 -0700

> I don't think this is a bad idea at all

Since I'm being invoked, I must clarify. I don't think it's a bad idea  
at all. But I think in the interests of minimalism, nothing is better  
than something.

In other words, leaving as much to the implementation as possible is  
good.

But that also includes some flag that says the implementation does  
SuiteB strictly. It's good to have it, but I'm not sure much more  
needs to be said. It isn't our job to go into the gory details of what  
that means.