Re: ECC in OpenPGP proposal

["David Crick" <dacrick@xxxxxxxxx>]

On 3/4/08, Ian G <iang@xxxxxxxxxxxxx> wrote:
> OK, I think I found it.  Sorry for not keeping up!

no problem.

Also, note that yours and my emails have overlapped in
our composing/sending, and that I unintentionally sent
me last email to just you rather than the list.

Hopefully everyone can now re-follow the discussion!
>  Daniel A. Nagy wrote:
>  > I think, Andrey makes a very important point here. The option to use 3DES
>  > symmetric encryption, SHA1 digest and ZLIB compression must remain open until
>  > a formal process of phasing them out is initiated, with a clear road map.
>  > Right now, excluding these algorithms would break interoperability in a very
>  > bad way, as described by Andrey.
>
>
>
> I disagree, below :)

yes, I have also disagreed - and still do "in principle".

*However,* I can (now) accept that as a "way forward"
compromise we can have both ECC and some interoperability
with current OpenPGP.

I'm attempting to (subtly ;) ) try and implement wording for
us that similarly "encourages" use of AES over 3DES by having
an "implementations SHOULD try and match sym & pk key
lengths" bit, together if possible (help me here Ian ;) ) with a
further "longer lengths should be preferred".

Maybe we should even add an example:

  If Alice has a 1024 bit RSA key and Bob a 521-bit ECC key,
  and both Alice and Bob have AES256 as one of their
  possible cipher preferences, then implementations SHOULD
  choose this stronger cipher.

This is a hack on 4880's "implementations may choose any
method of selecting from the intersection of preferences" -
i.e., for ECC we are saying how implementations SHOULD
(but, note, not any stronger than SHOULD).  I feel this is both
within the spirit of 4880 *as well as* our best intentions to
encourage AES.




>
>
>
>  > Of course, SHA1 and 3DES are not without problems, but for most
>  > security-critical applications they are still perfectly adequate.
>
>
>
> Right.  The question is not about the security of the
>  algorithms (which are more or less Pareto-secure-ish).
>  Instead, it is about the business aspects of delivering the
>  most security to the most people.
>
>
>
>  > On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote:
>  >> David Crick wrote:
>  >> ...
>  >>> The ecc-pre-6.txt's section 2 pretty much says "this is how to
>  >>> do ECC with AES," and we've said that this proposal is a "MAY."
>  >>> In a sense this is therefore some kind of a fork (sub-superset?)
>  >>> of 4880, so we're not concerned with 3DES (or CAST), and - as
>  >>> with DSA - we can make specific restrictions in order to meet
>  >>> compliance.
>
>
> Yes.  This is a natural fork.

But it has been pointed out that we can still keep 4880 compliance
by inheriting its 3DES (and then "encouraging" AES when used with
Ecc).


>  It is for people who want
>  Suite B.

I think there are "people who want *ECC*" and *also* people
who want Suite B.

Personally, I'd like to *only* see Suite B ECC, but consider
people thinking "hey, OpenPGP only has 384-bit ECC, but
<other product/standard> has 521-bit.  OpenPGP sucks!"


>  Which means the various USG organisations.
>  Which before have not in the past been that impressed with
>  OpenPGP.  Actually, not impressed with anything in the open
>  world, I'd say.  We are really in new territory now that the
>  NSA/NIST people have opened their hearts and declared Suite B.

yes, we certainly are.


>  Which isn't to say that we shouldn't consider compatibility,
>  but to say that this is a good, natural fork.  We should
>  also think about taking it...
>
>  (I would.  I remember the pain that was PGP 5.)

We could "force" a split, *or*, we could orchestrate a slow
migration, through adding ECC ("hey, cool, PGP has a new
public key algorithm.  It must be better!"), and then perhaps
with V5 keys.

>  >> I think we need to be careful here. Let's examine a use case.
>  >>
>  >> I am a user of some RFC 4880 OpenPGP application. All algorithms are
>  >> available to me, e.g. I am not a government employee.
>  >>
>  >> * I use the application to encrypt mail to 5 recipients, my friends.
>  >> They use RSA/DSA/ElGamal keys.
>  >>
>  >> * I upgraded the application to the next version that happened to
>  >> implement "ECC in OpenPGP".
>  >>
>  >> I assume that we agree that if I encrypt to exactly the same 5 people
>  >> with new version, as far as algorithm selection is concerned, the result
>  >> is identical to the previous version.
>  >>
>  >> * I added 6th recipient to the list, which uses ECDH key.
>
>
>
> OK I see that.  If...
>
>
>  >> I hope we will agree that it must be possible to send single e-mail to 6
>  >> recipients. RFC 4880 specifies that the default encryption algorithm is
>  >> 3DES, thus, there is always a match. Why shouldn't single e-mail be sent
>  >> to 6 recipients with 3DES symmetric key?
>
>
>
> Sorry, I don't agree.  The RFC4880 specification is only for
>  applications that apply (more or less) to RFC4880!
>
>  Applications that implement both RFC4880 *and*
>  OpenPGP/ECC/Suite B are given no guarantee that this is
>  likely to be seamless and joyful and without any degradation
>  in their promised user experience.

we're now saying there's a way.

>
>  Just like S/MIME and RFC4880.
>
>  To imagine otherwise would be to say that RFC4880's promise
>  is that *all future work* is also compatible.  That's
>  hopeless.  How far do we want to take that promise?  OpenPGP
>  quantum key exchange?  What happens if the Russkies decide
>  they want an OpenPGP GOST and they decide it is incompatible
>  by definition with OpenPGP ECC?  Or, we can retitle S/MIME
>  as OpenPGP/S/Mime and insist on compatibility :)
>
>  My point:  It is *not* a given that people using OpenPGP
>  Suite B can talk to people using RFC4880.  Desirable, sure,
>  but not a given.
>
>  (I'd bet the NSA would prefer this *not* to be the case ;)
>
>  Example:  Consider properly written small-device platforms
>  using the ECC stuff:  They will likely implement the
>  AES128-ECC-SHA "small" profile, and not include 3DES at all.

Then they're not OpenPGP/4880 compliant/compatible/

>   The last thing anyone in the smart card / mobile world
>  wants is incompatibility forced by vestigial circumstances.
>   They want all *their* people talking, and that means one
>  system, one algorithm.  Talking to other people is a distant
>  second in most business plans, and a controversial one at that.

That one algorithm *at present* is 3DES.

>  >> If the application is operating in Suite-B mode, or FIPS more, etc, then
>  >> the situation is different.
>
>
>
> Yes, there are security ramifications.  Are we really
>  implementing Suite B if the application can leak info by
>  sending out emails encrypted in Suite B (strong) and in 3DES
>  to some 512 RSA key (not so strong)?

Going forward we need to re-establish what is considered
minimally secure.

With ECC we're effectively closing off SHA1 (as a hash; it'll
still be there for, e.g., the fingerprint, at least as I understand it).

With V5 keys we could vape SHA1 entirely, and set 2048 (IF/DLP)
/ 256 (ECC) public keys as the minimum lengths.

2030 is our next "target" - that will likely mark the point when we
need to shift from 3DES, SHA224 and 2048IFDLP/224ECC to (for
the lowest strength) SHA256-AES128-3072IFDLP/256ECC.





>
>  iang
>