Re: ECC in OpenPGP proposal

I respectfully remind you that the target of this proposal is 1) to 
better match AES key strength with OpenPGP by extending RFC 4880, 2) to 
meet Suite-B, 3) to offer more usable alternative for mobile/embedded 
systems.
Suite B is limited to section 11.2. Suite B will have limited 
interoperability with RFC 4880, just like currently FIPS certification 
is incompatible with RFC 4880. Most of your comments in this e-mail 
apply to small section 11.2.
The discussion earlier was mostly about OpenPGP ECC keys that are 
compatible with RFC 4880.
Ian G wrote:
> OK, I think I found it.  Sorry for not keeping up!
>
>
>
> 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 :)
>
>
> > 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.  It is for people who want Suite B.  
> 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.
> 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.)
>
>
> > > 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.
> 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.  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.
>
> > > 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)?
> iang