ietf-openpgp
[Top] [All Lists]

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

2008-05-02 10:50:30

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


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.


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?

Will do.


(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??!

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.



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

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.