Subject: Re: ECC in OpenPGP proposal

From: "David Crick" <[email-masked]>
Date: Thu, 28 Feb 2008 19:02:18 +0000

Ian wrote:

> Hmmm... you raise an interesting point. I had thought that this
> was going to be a new document, and as it is not referred to in
> the existing core RFC, then ECC/Suite B was going to be a MAY by
> definition.
>
> Within that new (MAY) document, there would be several choices
> for MUST, SHOULD, MAY, etc.
>
> Or so I thought ... but I'm not fully aware of how these things interact.

and further:

> > I don't see how we can simplify past dropping 192.
>
>
> OK, if you are happy to carry on this discussion ... what are the
> reasons for including the 128-bit profile?

assuming the may -> whatever chain above holds, what about:

MAY implement ECC
  o MUST implement AES256-SHA384-384ECC
  o SHOULD implement AES128-SHA256-256ECC
  o MAY implement AES256-SHA512-521ECC
    [and/or any other combinations, but these might be "unbalanced"]

we currently *have* 3072 RSA/DSA strength (or 4096 RSA/ElG for
those wanting a bit of extra headroom); higher size DSA isn't in
any [e.g. NIST] standard, and >=4K RSA/ElG public key ops begin
to take a noticeable time even on my desktop (so while 7K RSA
keys are a simple source-change in GnuPG, ECC would definitely
make sense to achieve a balanced crypto system at this strength).

Now, for "embedded"/constrained systems there may only be the
chance to do AES128-SHA256-256ECC, which would conflict with my
"SHOULD" suggestion above.  So there would probably be scope for
the AES128 set to be a SHOULD as well, or even the MUST instead.

To be honest I think having AES256-SHA384-384ECC *and*
AES128-SHA256-256ECC in *some* form of MUST/SHOULD *is*
desirable: it covers both the two "Suite B" available
balanced set of algorithms, which may be important to
some people (and is certainly more "marketable" anyway).

I wouldn't personally "protest" if AES256-SHA512-521ECC
were also included, but I think anything more than these
three balanced sets is "silly."

---

From: Jon Callas <[email-masked]>
Date: Fri, 29 Feb 2008 01:08:31 -0800

>    [and/or any other combinations, but these might be "unbalanced"]

I think you have the polarity wrong.

AES256-SHA512-521ECC is desirable because it's the most secure.

AES128-SHA256-256ECC is desirable because it's fast, and it's what is  
most likely to be in constrained environments.

AES256-SHA384-384ECC (which I think should actually be AES192- 
SHA384-384ECC), is slow and not as secure. It's neither fish nor fowl.

However, for completeness, eliminating it is likely not wise. As much  
as I sneer at NIST's fondness for 192-bit security (especially when it  
runs at the same speed as 256-bit security), it's foolish to eliminate  
it from the spec. That's the sort of thing that might bite us in the  
ass years from now. The probability that I'll get a cogent,  
enlightening explanation of why 192-bit security is a Good Thing is  
directly proportional to the probability of our excluding it.

	Jon

---

From: Ian G <[email-masked]>
Date: Fri, 29 Feb 2008 13:43:22 +0100

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----

> directly proportional to the probability of our excluding it.

OK, so Jon argues that the market forces will push a full 
set of profiles, regardless of the damage done to security. 
  OK, I accept that, it's a devil's choice.  Do we work with 
the "best practices" mafia or do we try and meet the needs 
of the real users who just want the darned stuff to boot up 
and work?

If there are going to be 2 profiles, then there may as well 
be all 3.  There is no real saving between 2 and 3.

So the remaining question would be, what are the 
recommendations?

If we are including the "mobile" profile of 128, then it 
makes no sense to me to say that any other profile is a MUST 
... because then the mobile guys will have to implement the 
stronger ones to get the gold star.  Which they won't use or 
want because it's too slow.

Which would mean that only the mobile profile is a MUST and 
the other two are lesser?  So I see:

MAY implement ECC
    o MUST implement   AES128-SHA256-256ECC   (mobile)
    o SHOULD implement AES256-SHA512-521ECC   (strong)
    o MAY implement    AES256-SHA384-384ECC   (pretty)

iang

PS: mobile above includes smartcards and HSMs, it's just a 
label for those who want "fast" not pareto-complete.

---

From: Ian G <[email-masked]>
Date: Fri, 29 Feb 2008 16:31:21 +0100

David Crick wrote:

> How hard-coded do we want/need to make the[se] cipher-hash-curve
> combinations?  For Suite B compatibility/marketability we need
> them "fixed" (especially in light of pointing out the higher
> relative MAY cipher size) and the hash fixed as SHA2 (as opposed
> to, say, a hypothetical Whirlpool; SHA3 could be added later).

Me:  hardcoded.  Nobody ever showed that SHA wasn't good 
enough for the job * and NIST/NSA is happy with it, until 2012.

(I don't expect everyone to agree though :)

I noticed that there is this discussion to use Suite B for 
other purposes (variously, ECC is cool, speed, 
Euro-profiles, mobile, smart cards, HSMs, ... etc).  That is 
bad, to my mind.  This is a profile proposed for Suite B and 
that's what it should do: Suite B.

If the Europeans want to propose a EuroSuite, let them. 
Let's not jump on the bandwagon and make the profile 
all-things-for-all-humanity.

iang

* to a 99% confidence level.  SHA0 was the 1%.  The rest is 
crypto-academic stuff which shouldn't impact actual use.

---

From: "David Crick" <[email-masked]>
Date: Fri, 29 Feb 2008 16:20:38 +0000

On 2/29/08, Ian G <[email-masked]> wrote:
>  enough for the job and NIST/NSA is happy with it, until 2012.
...
>  all-things-for-all-humanity.

I'm 1000% happy with fixing the curve-hash sizes *and* only SHA2.

*I* would also be 100% happy fixing the cipher sizes with only AES.

*However*, are we ( <waits for other people to pipe up> ) willing to
insist that for OpenPGP ECC you *absolutely* MUST use AES *and*
at these specific sizes for the corresponding algorithm sets below?

MAY implement ECC
   o MUST implement   AES128-SHA256-256ECC
   o SHOULD implement AES256-SHA512-521ECC
   o MAY implement    AES256-SHA384-384ECC

Aside from the side-effect of 4880 (and predecessor's) 3DES MUST,
this would be the first time that we are mandating specific cipher
usage.  We're not saying "SHOULD" (and WARN the user if they do
otherwise), we're saying MUST.  (A watered-down compromise would
be to say "for Suite B compliance, AES MUST be used," just as we've
said for DSS compliance SHA must be used [and at certain sizes]).

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 29 Feb 2008 13:22:07 -0800

I think that the scope of ECC document is not to define the perfect 
combination of symmetric algorithm/hash/public key algorithm. The issue 
of relative strength applies equally well to RFC 4880. We should discuss 
the relative strength issue and how the ECC fits into this and we can 
recommend certain combinations, but should avoid mandating exact 
permutations. These combinations are not permanent and subject to 
opinions, mostly because of public key component. Balanced today 
AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future.

Let's also not forget about the issue of encoding to multiple 
recipients. Remember that the message gets encoded to a single symmetric 
key. "Walking up" from this algorithm, which may be other than AES (in 
fact, the 3DES is the fallback default), we may legitimately end up with 
pairs of symmetric/public tupples that don't match the "perfect" 
profile. In other words, if we have two recipient keys:

   ECDH public key            symm. alg
   --------------------------------------------
   P-256                             AES-128, CAST5
   P-521                             AES-256, AES-128

RFC 4880 mandates that we use AES-128/P-521 for the second recipient. In 
some cases we cannot "insist" on using a particular algorithm.

I think the best way to add longevity to this document is to pick up a 
few core permutations and then make its *components* MUST. In 
particular, there seem to be consensus on Curve ID 1 as MUST. I also 
have curve ID 2 as MUST for OpenPGP, which gives some room to shuffle 
the tupple. I also put SHA256 and SHA384 as MUST. I am OK with relaxing 
this to Curve ID 2 and SHA384 as SHOULD for OpenPGP profile. It is 
SHOULD and not MAY because of multiple recipient issue (if it is MAY to 
generate P-384, it is effectively MUST to be able to encode to it).

---

From: Jon Callas <[email-masked]>
Date: Fri, 29 Feb 2008 14:37:15 -0800

> OK, so Jon argues that the market forces will push a full set of  
> profiles, regardless of the damage done to security.

That's not at all what I argue, and I'm miffed at characterizing it  
that way.

If I am arguing anything it is that choices have consequences.

I have *observed* that if we don't do ECC at all, then people who want  
ECC have to use some other protocol. We seem to be in rough consensus  
that that is a bad thing.

I have *observed* that if we do only the strong profile, then we cut  
out smart cards and bounded devices.

I have *observed* that if we don't do the middle profile (which I have  
no personal love for), then we expose ourselves to missing out on  
something because of good reasons that we do not understand.

The consequence of these three observations is that if we push to  
minimalism, we run the risk of missing the needs of the end users.  
That could mean that we've wasted our time.

I have also *observed* that any labeling this as MAY, SHOULD, or MUST  
is mostly an illusion. ECC is an option. Options within options is  
really not possible. I support minimalism, as well as guidance, but  
there are also consequences.

It would be bad for OpenPGP to have a standard that could not be  
implemented on light bulbs (I used to say cell phones, but they're now  
400MHz devices), forcing the light bulb people to use something else.  
It would be bad for OpenPGP to lose another potential market because  
we took out something we're not happy with. (I am not happy with 192- 
bit security systems, as I've said. I'm also a realist.)

I worry a lot about what I call architectural arrogance. That  
arrogance comes from presuming that because we're smart people, we are  
therefore the smartest people, and to disagree is to be wrong. I agree  
with you that all things being equal, 256-bit security is better than  
128-bit security. I think that all things being equal, that's the way  
to go. However, engineering is all about tradeoffs in the real world,  
and in the real world all things are seldom equal.

A statement that says, "well, you can do P-256, but only if you do  
P-521, too" (which is an expression in English of P-512=MUST,  
P-256=MAY) is awfully close to architectural arrogance. In symmetric  
crypto, we've slid to 256-bit security because it has a relatively  
minimal incremental cost. We need to understand that that cost-benefit  
win does not imply that AES-128 is "damaged" in its security.

In the absence of a real world, I think taking a hard stand (256-bit  
or bust) is virtuous. In the presence of the real world I live in, a  
concession about 128-bit crypto is necessary. I don't like the fact  
that in the real world people whom I want to use OpenPGP live in, a  
concession about 192-bit is necessary.

One of my co-workers has a statement that she sometimes says. She  
says, "Do you want to be right, or do you want to be effective?" At  
the end of the day, I want to be effective.

So therefore, what I am arguing is that the *consequences* of purity  
that I agree with is an outcome that would be ineffective.

	Jon

---

From: "David Crick" <[email-masked]>
Date: Sat, 1 Mar 2008 00:22:17 +0000

>  AES128/SHA256/EC P-256 may need to be AES128/SHA256/EC P-384 in the future.

We have guidelines from NIST and NSA on current balanced
strengths.  Suite B in particular is very specific (selective).
(Yes, it has its higher cipher size oddity, but thems the rules.)

>    ECDH public key            symm. alg

So far we have erred towards [128-]256-256 as a MUST because
of low spec devices.  However, someone on here (I think it was)
was complaining that they couldn't even use AES-128 on a small
Nokia (and so were using RC4) - so there's already examples of
OpenPGP being, um, "adapted" to fit needs.

With DSA in OpenPGP we're making public key and corresponding
hash size restrictions (at least for DSS compliance), so why not
for the cipher with ECC? (which Suite B does).

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.

Dependant on the "low spec" argument/evidence, we could just
make one of the larger curve-hash pairs as the MUST, and make
AES256 as the must cipher.  Then if we need to encrypt to one
of the two bigger curves *and* a smaller curve then we just
"up" the cipher to AES256 for the small curve recipient.

As has probably been apparent, I'd like to see "OpenPGP-SuiteB";
just two curves, hash sizes, ciphers and public key algorithms,
with AES256 used in the event of both small curve and big curve
recipients.  (Maybe if we're also communicating with a non-ECC
key person then we "force" one of the AESes over 3DES.  Or just
say we can't communicate if they don't have an AES preference.)

Heck, I'd be all for making this into a "V5 key" thing and getting
rid of SHA1 and 3DES completely and all the other things we've
talked about.

Suite B really is the closest to Ian's "one cipher system" (albeit
with two of everything!).  My initial suggestion was to make the
AES256-SHA384-ECC384 as the MUST, since that's the stronger
(and since we already have AES128-SHA256-DSA2_RSA_ElG3K
strength in OpenPGP).  If some people can't use AES128 on
small systems *right now* then this doesn't change anything for
them.

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 29 Feb 2008 21:36:11 -0800

David Crick wrote:
...
> with DSA - we can make specific restrictions in order to meet

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.

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?

If the application is operating in Suite-B mode, or FIPS more, etc, then 
the situation is different.

> "up" the cipher to AES256 for the small curve recipient.

RFC 4880 currently grants to a user of embedded device a method to say 
"don't do AES-256 to me" by using cipher preferences that exclude AES 
256. We should respect this. We cannot change the fact that there are 
hardware platforms that don't implement or don't like AES 256.

Date: Fri, 29 Feb 2008 21:36:11 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
CC: David Crick <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

David Crick wrote:
...
> with DSA - we can make specific restrictions in order to meet

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.

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?

If the application is operating in Suite-B mode, or FIPS more, etc, then 
the situation is different.

> "up" the cipher to AES256 for the small curve recipient.

RFC 4880 currently grants to a user of embedded device a method to say 
"don't do AES-256 to me" by using cipher preferences that exclude AES 
256. We should respect this. We cannot change the fact that there are 
hardware platforms that don't implement or don't like AES 256.

Date: Sat, 1 Mar 2008 00:22:17 +0000
From: "David Crick" <[email-masked]>
To: [email-masked]
Subject: Re: ECC in OpenPGP proposal
Cc: "Andrey Jivsov" <[email-masked]>, "Ian G" <[email-masked]>
Sender: [email-masked]

>  > said for DSS compliance SHA must be used [and at certain sizes]).

Cc: [email-masked], David Crick <[email-masked]>
From: Jon Callas <[email-masked]>
To: Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Date: Fri, 29 Feb 2008 14:37:15 -0800
Sender: [email-masked]

	Jon

Date: Fri, 29 Feb 2008 13:22:07 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
CC: David Crick <[email-masked]>, Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

> said for DSS compliance SHA must be used [and at certain sizes]).

Date: Fri, 29 Feb 2008 16:20:38 +0000
From: "David Crick" <[email-masked]>
To: "Ian G" <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Cc: [email-masked]
Sender: [email-masked]

...

MAY implement ECC

Date: Fri, 29 Feb 2008 16:31:21 +0100
From: Ian G <[email-masked]>
To: David Crick <[email-masked]>
CC: [email-masked]
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

iang

Date: Fri, 29 Feb 2008 13:43:22 +0100
From: Ian G <[email-masked]>
To: [email-masked]
CC: Jon Callas <[email-masked]>, David Crick <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

MAY implement ECC

iang

Cc: [email-masked]
From: Jon Callas <[email-masked]>
To: David Crick <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Date: Fri, 29 Feb 2008 01:08:31 -0800
Sender: [email-masked]

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Date: Thu, 28 Feb 2008 15:14:10 -0800
Sender: [email-masked]

>
> Hmmm... you raise an interesting point.  I had thought that this was  
> going to be a new document, and as it is not referred to in the  
> existing core RFC, then ECC/Suite B was going to be a MAY by  
> definition.
>
> Within that new (MAY) document, there would be several choices for  
> MUST, SHOULD, MAY, etc.
>

At least in theory, we could make ECC be the MUST. But as I said  
before, there really isn't a good process to change those things in  
the IETF.

> reasons for including the 128-bit profile?

There's nothing wrong 128-bit security. It's also faster. It competes  
against 3Kbit integer keys.

If you're doing smart cards, HSMs, mobile phones, etc. they will  
likely need 128-bit security for speed reasons.

	Jon

Date: Thu, 28 Feb 2008 19:02:18 +0000
From: "David Crick" <[email-masked]>
To: [email-masked]
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

MAY implement ECC

Date: Thu, 28 Feb 2008 15:38:20 +0100
From: Ian G <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

>> The short summary of my argument is that there should one and only  
>> one MUST profile for Suite B, and that it should be the strong one /  
>> Top Secret.

> For a number of reasons, ECC/Suite B is going to be a MAY. You will be  
> permitted to make an OpenPGP application that doesn't do it.

Hmmm... you raise an interesting point.  I had thought that 
this was going to be a new document, and as it is not 
referred to in the existing core RFC, then ECC/Suite B was 
going to be a MAY by definition.

Within that new (MAY) document, there would be several 
choices for MUST, SHOULD, MAY, etc.

Or so I thought ... but I'm not fully aware of how these 
things interact.

> Like many things coming out of NIST, they come in three flavors, 128- 
> bit security, 192-bit, and 256-bit. I have no objection myself to  
> canning the 192-bit ones. I'm of the opinion that if you need more  
> than 128, you should go to 256. In many cases, there isn't even a  
> performance win on the 192-bit system.
> 
> However, there are very good arguments for doing 192-bit as well, and  
> one of those arguments is that it may be easier to do the 192-bit  
> versions than to explain why you didn't.

In the sense that it exists, and people think it has to 
exist, yes.  "why go against the flow, it's only security 
after all..."  Yes, I agree.  In that market, that is the 
pressure you will get.

> I don't see how we can simplify past dropping 192.

OK, if you are happy to carry on this discussion ... what 
are the reasons for including the 128-bit profile?

(I know I'm exceeding my noise quota here .. but I hate the 
thought that we are happily reducing overall security by 
providing users too many options for them to achieve 
compatibility with each other.)

iang

From: Simon Josefsson <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: [email-masked], Werner Koch <[email-masked]>
Subject: Re: ECC curve ID
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 28 Feb 2008 11:04:35 +0100
Sender: [email-masked]

Andrey Jivsov <[email-masked]> writes:

> OpenPGP application is not required to understand ASN.1 /
> DER.

You don't need to support ASN.1 or DER to support OIDs as identities for
curves.  Just use memcpy or memcmp with a fixed string.
>
> Besides, I thought that once the group agrees on an ID, the IETF
> process shouldn't take longer than a quarter.

I think that is quite optimistic.  Further, the problem with the process
is that you don't get the actual ID number until after that process has
finished.  This seriously delay deployment and early testing.  If IANA
could reserve numbers early for experiments, this wouldn't have been
such a big problem.

Finally, I'd like to +1 Werner's suggestion to use OID's.

/Simon

Date: Wed, 27 Feb 2008 15:31:09 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
CC: Werner Koch <[email-masked]>
Subject: Re: ECC curve ID
Sender: [email-masked]

Hello Werner, thank you for your comments.

Werner Koch wrote:
> Hi,
>
> altough I am aware of the discussion about limiting the number of
> algorithms/profiles in a future ECC option, I am not happy with section
> 10 of the draft:
>
>   10. ECC curve ID
>
>    The parameter ECC curve ID is an integer that defines the named
>    curve.
>
>        ID      Curve description                      Curve name
>         0      Reserved
>         1      NIST Curve P-256 [FIPS 186-2]          "NIST P256"
>         2      NIST Curve P-384 [FIPS 186-2]          "NIST P384"
>         3      NIST Curve P-521 [FIPS 186-2]          "NIST P521"
>      100-110   Private/Experimental curves
>        255     Reserved for future expansion
>
>
> Although this uses the same scheme we use all over OpenPGP, we should
> make future life easier for all by not using registered IDs but use
> other identifiers here.  For registering IDs we need to informal agree
> on a new identifier, implement that one and then wait a couple of
> months/years until it gets really assigned.  The private/experimental
> IDs are not really useful for this because they can't be used after the
> algorithm has been offically registered.
>
> Thus, I propose to use ASN.1 object identifiers for the curves; i.e.:
>
>     1.2.840.10045.3.1.7  NIST P-256   (Not sure about this OID)
>     1.3.132.0.34         NIST P-384  
>     1.3.132.0.35         NIST P-521  
>
> and declare some of them as MUST be implemented if ECC is implemented.
>
> Having object identifiers allows us to add other curves.

I think that support for arbitrary curves has some merits. On the other 
hand, these benefits must be compared against possibility of ever 
getting the ECC support in OpenPGP applications.

OpenPGP application is not required to understand ASN.1 / DER. 
Essentially, this proposal means that we are replacing one-byte ID by 
multi-byte ID. Would it be good to agree on new curve anyway and how it 
fits relative strength, what are legal issues, what are implementation 
issues, which MAY/SHOULD keyword it will be carrying, and so on? If we 
cannot agree on this on the list, it is unlikely that applications will 
be able to interoperate using curves we disagree on. The freedom will be 
detrimental to interoperability. (Conversely, the small subset will 
allow greater speed optimizations.)

While I think we need to start from "core" version of the standard and 
cut options, perhaps in the future we need to allow named curves in 
companion proposal or in the next version of the document. For example, 
ID 254 might mean that there is an ASN.1 structure referencing the 
curve, inserted somewhere into the sequence of currently defined fields. 
(If you find it worthwhile, I can be more specific in the draft about 
the extension path for future curves.)

Besides, I thought that once the group agrees on an ID, the IETF process 
shouldn't take longer than a quarter.

>   Well, you will
> now say, we should limit that to the NIST defined curves.  May I now
> remind you that there other national standard bodies which require the
> use of other curves.  In Europe we have a tendency to prefer our own
> algorithms and sometimes it is a hard requirement not rely on foreign
> crypto standard (cf. the use of RIPE-MD160).
>   

Please note that proposed curves are a part of major international 
standards: ANSI X9.62 (multiple updates) and industry standard SECG, 
among others. It is a part of any ECC-related IETF standard. They come 
with Windows Vista, Linux (openssl), etc. Which ECC standard *excludes* 
the curves specified in the proposal? I claim that the proposed subset 
of curves is the most widely supported subset of any standard. I suggest 
that in the interest of adoption we start from core set and once we 
deployed the applications that interoperate, we start adding marginal 
improvements.

> I know that interoperability will be limited but as long as other curves
> are declared optional this is not a major issue.  S/MIME users will
> suffer from the same problem.
>   

I note that this seems exactly opposite to what Ian wants, so I propose 
the idea of core set + extensions as a compromise...

> I have not yet looked at the preference system and how to integrate
> curve names into it.  I doubt that it is really required because we
> don't have preference for key length eithers.
>   

This is where freedom will make interoperability problematic. It is hard 
to come up with preferences that control the structure of 
self-signatures, because preferences themselves are stored in 
self-signatures. The only solution to this chicken-and-egg problem is to 
establish small core set of curves, the two ones I proposed in the 
draft, and focus on supporting these curves first.

> Shalom-Salam,
>
>    Werner
>
>
>
> p.s. 
> I don't think that the notion of "Top Secret" And "Secret" belongs into
> an RFC.  I could also ask to add "VS/NfD", which is a secrecy level used
> in Germany

This seems reasonable. If any of 3 curves in the proposal satisfy 
another standard that the group thinks worth mentioning, such a standard 
can be noted in the spec. (These references to non-OpenPGP profiles are 
informative, BTW)

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Date: Wed, 27 Feb 2008 14:35:53 -0800
Sender: [email-masked]

> For the record, I agree there should be a Suite B !  It is an  
> economic reality, a real-world requirement.  When NIST/NSA speaks,  
> that's it.
>
> The short summary of my argument is that there should one and only  
> one MUST profile for Suite B, and that it should be the strong one /  
> Top Secret.
>
> Other lesser profiles could be MAY, or if you let the agility nazis  
> have their way, absent, as they have no economic use and lots and  
> lots of costs to users.
>
> (The reason I say that 'Secret' could be a MAY is that there are  
> complicated blah blahs in the government/security world that  
> sometimes force suppliers to provide several modes, against good  
> security practice.)
>
> (I'm aware of the "mobile" argument that was raised in the previous  
> post.  I would say that the mobile boys propose a "mobile" profile.   
> That's because mobile has other aspects that aren't necessarily  
> considered in Suite B.)

Excellent.

For a number of reasons, ECC/Suite B is going to be a MAY. You will be  
permitted to make an OpenPGP application that doesn't do it.

(Presently, our MUST algorithms are DSA, Elgamal, 3DES, and SHA1.  
Changing MUSTs is a can of worms and I don't think any IETF standard  
is handling it well.)

Like many things coming out of NIST, they come in three flavors, 128- 
bit security, 192-bit, and 256-bit. I have no objection myself to  
canning the 192-bit ones. I'm of the opinion that if you need more  
than 128, you should go to 256. In many cases, there isn't even a  
performance win on the 192-bit system.

However, there are very good arguments for doing 192-bit as well, and  
one of those arguments is that it may be easier to do the 192-bit  
versions than to explain why you didn't.

>
>
>
>> There are also other changes we will need to do on the horizon.  
>> For  example, someday there will be an AHS hash algorithm set from  
>> NIST. Do  we not to that, either? The argument you give is to have  
>> no choices.
>
>
> Yes.  AHS is years away, if AES was any guide.  AHS won't improve  
> overall security markedly over SHA256-512 family. NIST/NSA will also  
> have to update Suite B when AHS comes out.
>
> When all that dust settles, then is the time to reconsider it.  I  
> would plan on Suite B (one profile) now and know that in 5 or 7  
> years we will need to do a Suite B-bis.

The NIST schedule has a decision made in 2012. The submissions must be  
made this August.

>
>
>
>> For the people who want more, is to use S/MIME? If so, and if  
>> that's  the decision of the working group -- well, I disagree, but  
>> rough  consensus is rough consensus. My company does both OpenPGP  
>> and S/MIME.  If the answer to people who want Suite B is that we  
>> support it with S/ MIME, that's fine. It is also a huge  
>> disappointment, because I would  like to satisfy people's ECC and  
>> Suite B needs with OpenPGP, but we  can always migrate people to S/ 
>> MIME who need that.
>
>
> I think there should be a Suite B, in OpenPGP.
>
> And, to forestall the outrage, I fully expect to not get consensus  
> on my plea to reduce agility :)  We waited for 10 years to get the  
> current OpenPGP draft, so we can wait another 10 years to find out  
> why it took 10 years...

Cool.

	Jon

Date: Wed, 27 Feb 2008 12:54:39 -0600
To: Werner Koch <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: Re: ECC curve ID
Cc: [email-masked]
Sender: [email-masked]

At 09:51 AM 2/27/2008, Werner Koch wrote:
>     1.2.840.10045.3.1.7  NIST P-256   (Not sure about this OID)

Werner: We think that this is correct -- at least it's what we've been using
for quite some time and have received no complaints to date (and have witnessed
no conflicts between our code and everything we've been able to access for
compatibility testing).

Microsoft agrees (and our P-256 ECC certs are accepted by Vista IE):
   "XCN_OID_ECC_CURVE_P256 (1.2.840.10045.3.1.7) "
http://msdn2.microsoft.com/en-us/library/aa379070(VS.85).aspx

Also, if you need an official NIST reference, SP 800-78-1 lists this OID on
page 9 (table 3-6):
   http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

In hex, it's "0x2A8648CE3D030107."

Cheers,
Michael

==========
Michael J. Markowitz, Ph.D.        Email: [email-masked]
Vice President R&D                 Voice: 708-445-1704 (Oak Park)
Information Security Corporation          847-405-0500 (Deerfield)
1011 Lake Street, Suite 425        Fax:   708-445-9705
Oak Park, IL  60301                WWW:   http://www.infoseccorp.com    

From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: ECC curve ID
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 27 Feb 2008 16:51:50 +0100
Sender: [email-masked]

Hi,

altough I am aware of the discussion about limiting the number of
algorithms/profiles in a future ECC option, I am not happy with section
10 of the draft:

  10. ECC curve ID

   The parameter ECC curve ID is an integer that defines the named
   curve.

       ID      Curve description                      Curve name
        0      Reserved
        1      NIST Curve P-256 [FIPS 186-2]          "NIST P256"
        2      NIST Curve P-384 [FIPS 186-2]          "NIST P384"
        3      NIST Curve P-521 [FIPS 186-2]          "NIST P521"
     100-110   Private/Experimental curves
       255     Reserved for future expansion

Although this uses the same scheme we use all over OpenPGP, we should
make future life easier for all by not using registered IDs but use
other identifiers here.  For registering IDs we need to informal agree
on a new identifier, implement that one and then wait a couple of
months/years until it gets really assigned.  The private/experimental
IDs are not really useful for this because they can't be used after the
algorithm has been offically registered.

Thus, I propose to use ASN.1 object identifiers for the curves; i.e.:

    1.2.840.10045.3.1.7  NIST P-256   (Not sure about this OID)
    1.3.132.0.34         NIST P-384  
    1.3.132.0.35         NIST P-521  

and declare some of them as MUST be implemented if ECC is implemented.

Having object identifiers allows us to add other curves.  Well, you will
now say, we should limit that to the NIST defined curves.  May I now
remind you that there other national standard bodies which require the
use of other curves.  In Europe we have a tendency to prefer our own
algorithms and sometimes it is a hard requirement not rely on foreign
crypto standard (cf. the use of RIPE-MD160).

I know that interoperability will be limited but as long as other curves
are declared optional this is not a major issue.  S/MIME users will
suffer from the same problem.

I have not yet looked at the preference system and how to integrate
curve names into it.  I doubt that it is really required because we
don't have preference for key length eithers.

Shalom-Salam,

   Werner

p.s. 
I don't think that the notion of "Top Secret" And "Secret" belongs into
an RFC.  I could also ask to add "VS/NfD", which is a secrecy level used
in Germany.

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

Date: Wed, 27 Feb 2008 11:50:45 +0100
From: Ian G <[email-masked]>
To: Jon Callas <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

Hi Jon,

Jon Callas wrote:

>> http://iang.org/ssl/h1_the_one_true_cipher_suite.html
> 
> Ian,
> 
> I agree that there is virtue in limiting choice. However, there are a  
> lot of people who want ECC, particularly in the context of Suite B. In  
> the not-to-distant future, this will be a requirement.

For the record, I agree there should be a Suite B !  It is 
an economic reality, a real-world requirement.  When 
NIST/NSA speaks, that's it.

The short summary of my argument is that there should one 
and only one MUST profile for Suite B, and that it should be 
the strong one / Top Secret.

Other lesser profiles could be MAY, or if you let the 
agility nazis have their way, absent, as they have no 
economic use and lots and lots of costs to users.

(The reason I say that 'Secret' could be a MAY is that there 
are complicated blah blahs in the government/security world 
that sometimes force suppliers to provide several modes, 
against good security practice.)

(I'm aware of the "mobile" argument that was raised in the 
previous post.  I would say that the mobile boys propose a 
"mobile" profile.  That's because mobile has other aspects 
that aren't necessarily considered in Suite B.)

> There are also other changes we will need to do on the horizon. For  
> example, someday there will be an AHS hash algorithm set from NIST. Do  
> we not to that, either? The argument you give is to have no choices.

Yes.  AHS is years away, if AES was any guide.  AHS won't 
improve overall security markedly over SHA256-512 family. 
NIST/NSA will also have to update Suite B when AHS comes out.

When all that dust settles, then is the time to reconsider 
it.  I would plan on Suite B (one profile) now and know that 
in 5 or 7 years we will need to do a Suite B-bis.

> For the people who want more, is to use S/MIME? If so, and if that's  
> the decision of the working group -- well, I disagree, but rough  
> consensus is rough consensus. My company does both OpenPGP and S/MIME.  
> If the answer to people who want Suite B is that we support it with S/ 
> MIME, that's fine. It is also a huge disappointment, because I would  
> like to satisfy people's ECC and Suite B needs with OpenPGP, but we  
> can always migrate people to S/MIME who need that.

I think there should be a Suite B, in OpenPGP.

And, to forestall the outrage, I fully expect to not get 
consensus on my plea to reduce agility :)  We waited for 10 
years to get the current OpenPGP draft, so we can wait 
another 10 years to find out why it took 10 years...

iang

From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Date: Tue, 26 Feb 2008 12:59:39 -0800
Sender: [email-masked]

On Feb 21, 2008, at 3:45 AM, Ian G wrote:

>
> Andrey Jivsov wrote:
>> Hello Ian, thank you for your comments.
>
>
> Thanks for response.  I have not responded in detail to all your  
> responses, we might be better off both seeing how the rest of the  
> group chimes in.  Instead I've just amplified my points where there  
> was some divergence.
>
> On background, when it comes to agility, I am a little bit of a  
> nazi.  To me, choice is bad, nasty, evil.  This is because the  
> choice does no good for the user, and lots and lots of bad.
>
> http://iang.org/ssl/h1_the_one_true_cipher_suite.html

Ian,

I agree that there is virtue in limiting choice. However, there are a  
lot of people who want ECC, particularly in the context of Suite B. In  
the not-to-distant future, this will be a requirement.

There are also other changes we will need to do on the horizon. For  
example, someday there will be an AHS hash algorithm set from NIST. Do  
we not to that, either? The argument you give is to have no choices.

For the people who want more, is to use S/MIME? If so, and if that's  
the decision of the working group -- well, I disagree, but rough  
consensus is rough consensus. My company does both OpenPGP and S/MIME.  
If the answer to people who want Suite B is that we support it with S/ 
MIME, that's fine. It is also a huge disappointment, because I would  
like to satisfy people's ECC and Suite B needs with OpenPGP, but we  
can always migrate people to S/MIME who need that.

	Jon

Date: Mon, 25 Feb 2008 23:33:33 +0200
From: Nikos Mavrogiannopoulos <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: updated TLS-Openpgp protocol
Sender: [email-masked]

I've updated the experimental protocol for openpgp keys. The updated 
version can be found at:
http://www.ietf.org/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-00.txt

The main addition is that it adds support for using subkeys instead of 
the main key of the openpgp certificate. For this reason i'd like to 
revive this protocol as a TLS WG item. For this to be possible there 
must be interest on this protocol, so if there are there people in this 
list supporting this protocol please express it.

Of course comments are always welcome.

regards,
Nikos

PS. Currently there is a module for the apache web server implementing 
the openpgp-tls protocol, available at: 
http://www.outoforder.cc/projects/apache/mod_gnutls/

Date: Fri, 22 Feb 2008 22:12:48 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
CC: Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

Hello Ian,

I appreciate your pragmatism regarding algorithm agility. There are two 
practical issues we need to worry about: steady increase in processing 
power and the difference in processing power on various hardware.

A proposal with single ciphersuite cannot remain adequate indefinitely. 
We need ability to roll forward the strength of public key crypto as 
yesterday's strength declines over time.

We have impressive breadth of hardware that supports ECC today: from 
servers to smartcards. These devices demand some breadth of choices for 
ECC curves: servers might want the ultimate crypto strength, while 
smartcards are usually trying to meet set manufacturing cost at OK 
performance.

The document we discuss has three "ciphersuites" with two of them as 
MUST. As I said, I am OK with making only one MUST. I am inclined toward 
weaker one, since it has to be the lowest common denominator.

Date: Thu, 21 Feb 2008 12:45:00 +0100
From: Ian G <[email-masked]>
To: Andrey Jivsov <[email-masked]>
CC: [email-masked]
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

Andrey Jivsov wrote:
> Hello Ian, thank you for your comments.

Thanks for response.  I have not responded in detail to all 
your responses, we might be better off both seeing how the 
rest of the group chimes in.  Instead I've just amplified my 
points where there was some divergence.

On background, when it comes to agility, I am a little bit 
of a nazi.  To me, choice is bad, nasty, evil.  This is 
because the choice does no good for the user, and lots and 
lots of bad.

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

A few points below:

>>   ... "SHOULD support ECDH"
>>
>> what is the point of not supporting ECDH?  I recommend MUST.
>>
> 
> I can support this.
> 
> However, please note that the signature has more weight by being a tool 
> of certifications, i.e. self-signatures depends on it. Without support 
> for ECDSA we cannot have functional EC keys, while we can have sign-only 
> keys without ECDH. It is possible to have sign+encrypt keys with ECDSA 
> top key and modp ElGamal DH.

Is your argument here that it is possible to do 
signature-only applications with just ECDSA?  So this opens 
a window for a simplified implementation?

I would not be in favour of such an optimisation for the 
simple reason that signature-only applications are not 
common nor popular (nor well built IMHO).  We are here to do 
encryption.  Signature-only concepts are something that 
people talked about and failed to make good on the talk.

So I see this as a throw-back to the 1990s and DoJ ideas 
about everyone having a digital signature and the world 
being a better place and many other blind alleys.  Didn't 
happen, not useful.

> Also note that ECDH brings with it the need to implement KDF and key 
> wrapping methods, because there is no ElGamal alternative in ECC field. 
> ECDSA should be easier to implement than ECDH.

OK, so there is more work if it is a MUST.  To summarise, we 
are here for the encryption.  Digsigs are the option, not 
the other way around.  Therefore I recommend it as a MUST.

>> =====
>>
>> 6.  ... "the KDF hash function MAY be any hash function defined in 
>> [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used."
>>
>> What is the point in permitting alternatives?  If there is a good 
>> reason, I would prefer to see them enumerated for better understanding 
>> and for certainty.
> 
> This is to continue good tradition of algorithm agility in OpenPGP.

Ouch :)  That tradition was born of a bunch of hackers and a 
bunch of cryptographers who sat around and hacked and drank 
wine and promised the world that it would be better.  I 
know, I was one of them.

OpenPGP these days is more a business area.  People 
implement OpenPGP not because it is sexy and they like wine 
but because it solves problems for users and can help to 
sell product.

In business we do not want "agility".  What we want to give 
our users is a product that boots up and runs, securely, out 
of the box.  There is only one mode, and it is secure. 
There is no place for agility in the world of business.

Agility never solved anything, I posit (a debate over wine, 
ever there was one), and it sure created a lot of problems. 
  If there was a chance to to do it all again, I would (and 
do) propose this as a rule:  one true cipher suite, and 
that's it.

> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

OK, read that, thanks.  I suggest only one profile is 
needed: "Top Secret".  (I would do it as your ID 3.)

>> 11.2  I don't see any point in providing both Secret and Top Secret?  
>> This seems like a way to create comaptibility problems for zero 
>> payoff.  I suggest the full Top Secret as the only profile, and that's 
>> it.
> 
> I think that the incremental cost to achieve Secret level of Suite-B is 
> insignificant, given that an application has implemented Top Secret 
> level.

The incremental cost of "Top Secret" instead of "Secret" is 
truly insignificant, yes, and the same in reverse.

My point is that the cost of two profiles over one profile 
is huge.  And I'm not talking about the implementors but the 
users.  Implement one "Top Secret" profile and be done with it.

Say that OpenPGP Suite-B is rated for all traffic, and save 
the users a headache, for every message they must send, for 
all time.

> This proposal offers the least choice of ECC parameters of any IETF 
> standard.

I like it better for that :)  The IETF has not been 
particularly successful at crypto, so I don't mind drifting 
a long way from their views...

> At present the only MUST for OpenPGP are curves ID 1 and 2. It also says 
> that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These 
> are the curves/hashed approved by Suite-B. I can accepts that we reduce 
> the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B 
> "Secret" level and drop "Top Secret".

No, I'd suggest the reverse:  "Top Secret" and drop or 
downgrade "Secret".

If you must implement multiple profiles, then "Top Secret" 
should be the MUST, and the lower one MAY.  No point in 
encouraging people to add agility, although there is a 
potential market for the mobile phone people to implement a 
lower profile.

iang

Date: Thu, 21 Feb 2008 00:08:47 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
CC: Ian G <[email-masked]>
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

Hello Ian, thank you for your comments.

Ian G wrote:
>
> Hi all,
>
>
> Some comments.  Caveat:  I wouldn't know an EC if someone hit me over 
> the head with it...
>
> Big comment:  far too much variability, for little gain.
>
>
>
>
>
>
> Andrey Jivsov wrote:
>>
>> Hello OpenPGP list,
>>
>> as Hal Finney had mentioned earlier, here is the draft:
>>    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt
>>
>> Unless you read this on a text terminal, here is the document in 
>> alternative formats that offer cross-references as navigation links:
>>    http://brainhub.googlepages.com/pgp
>
>> Why do we need ECC? The main reason is better alignment with the 
>> strength of symmetric key. Given that US government has chosen ECC in 
>> favor of modp for larger key sizes, this proposal is carefully 
>> written to comply with NSA Suite-B.
>
> I think it is sufficient to state that you want a Suite-B compatible 
> profile.

Suite-B offers fewer choices than this spec does. Some of restrictions 
imposed by Suite-B are debatable.

The purpose of this draft is to match the strength of AES-128, AES-192 
and AES-256. See section 12 for corresponding sizes for hashes and 
curves (which are "double width" of AES key sizes).

http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html#toc15 

Suite-B only lists AES-128 and AES-256, EC P256 and P384, SHA-256 and 
SHA-384. This creates a shift in relative strength. To illustrate this 
using the table in section 12, NSA dropped the row with AES-256 and 
replaced AES-192 with AES-256 in the second raw, resulting in weaker top 
public key algorithm.

Suite-B allows some patented techniques that were excluded.

This leaves us with two curves for Suite-B, but since we must have two, 
why not add next strongest one as SHOULD for better symmetry?  Without 
EC P521 addition applications will be left with 15K RSA/ElGamal key or 
weaker EC P384 to match AES-256.

>   ... "SHOULD support ECDH"
>
> what is the point of not supporting ECDH?  I recommend MUST.
>

I can support this.

However, please note that the signature has more weight by being a tool 
of certifications, i.e. self-signatures depends on it. Without support 
for ECDSA we cannot have functional EC keys, while we can have sign-only 
keys without ECDH. It is possible to have sign+encrypt keys with ECDSA 
top key and modp ElGamal DH.

Also note that ECDH brings with it the need to implement KDF and key 
wrapping methods, because there is no ElGamal alternative in ECC field. 
ECDSA should be easier to implement than ECDH.

> =====
>
> 6.  ... "the KDF hash function MAY be any hash function defined in 
> [FIPS 180-2] or its successor, except that SHA-1 MUST NOT be used."
>
> What is the point in permitting alternatives?  If there is a good 
> reason, I would prefer to see them enumerated for better understanding 
> and for certainty.

This is to continue good tradition of algorithm agility in OpenPGP. I am 
sure TLS designers would like to get rid of MD5, hardwired into their 
analog of KDF.

Implementors are advised to follow the recommendations set in the table 
of section 12, which will mean that there are 3 ways to set up KDFs, 
parameterized by different hash algorithms, for each of 3 sizes of 
symmetric keys. The hash algorithms have already been implemented in 
vast majority of OpenPGP applications. The code to use KDF should be 
written using generic hash API, so that there will be no difference 
which hash algorithm is passed to initialize this API. Overall, I think 
the benefits overweight the slightly more complex format.

>
> I especially don't like "or its successor."

I can drop this clause. I attempted to write a spec that doesn't need to 
be updated after NIST introduces new hashes. I wanted to make external 
the definition of what the right hashes for AES-128, AES-192, and 
AES-256 are.

> I ask ... without expecting to understanding the answer ... why it is 
> that it is useful or necessary to permit any variability in the KDF?

In summary, this follows from the need to support every AES key size. No 
other variability is allowed in section 6.

>
> =====
>
>
>
> 11.2  I don't think it makes sense for OpenPGP WG to suggest that it 
> knows what "Secret" and "Top Secret" means, nor that it can "achieve" 
> this.  The normative place for that is NSA.  If some guidance of 
> intentions is useful, it should be in the sense of a comment.  "This 
> profile is intended to be compatible with Suite B."  If the NSA can be 
> convinced to make a statement as to what works for them, include that too.

These Secret/Top Secret classifications are from Suite-B page. I can add 
your suggestion and the phrase "[SUITE-B] is the normative source of the 
definition" to section 11.2.  We need a way to say what an OpenPGP 
application shall do to comply with each level of Suite-B security.

http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

> ====
>
> 11.2  I don't see any point in providing both Secret and Top Secret?  
> This seems like a way to create comaptibility problems for zero 
> payoff.  I suggest the full Top Secret as the only profile, and that's 
> it.

I think that the incremental cost to achieve Secret level of Suite-B is 
insignificant, given that an application has implemented Top Secret 
level. In addition, because I've dropped some of patented methods 
allowed by Suite-B, in my mind the scale is tipped to offer more 
choices. Also, Top Secret has less symmetry in the sense of relative 
security than Secret, as mentioned above.

> ====
>
> 11.  Indeed, what is the point in allowing people to fiddle around 
> with different curves, KDFs, and hashes?  Nobody has ever cracked any 
> of them, or nobody that we care about (which excludes the NSA, 
> perversely).  Set one and leave it as that.
>
> This "profile" proposes 2 different public key algorithms, 3 different 
> curves (plus future ones), 3 different hashes (plus future ones), 3 
> different AES strengths, MDC on or off, It/Salt as a SHOULD.

My goal was to limit as much as I can. Let me explain how I arrived at 
the present set. I will leave MDC and S2K out of this section.

Here is what have now:

  We want to support 3 sizes of AES algorithms.
  AES algorithms pair with 3 hashes and 3 curves in the sense of 
relative security.
  We need encryption and signing, and this is achieved with two new 
public key algorithms.

Let's put this into perspective and sketch what it could have been. In 
addition to above:

  Point compression format.
  Curves in binary field, using polynomial or normal basis representations
  Curves in prime field that allow the choice of the prime; there is no 
limit to customization, up to the random curves over random underlying 
fields
  ECDH with cofactor; ECMQV (both patented)
  Multiple KDF or key wrapping method in conjunction with ECDH

Another way to look at how flexible or constrained current proposal is 
is by comparing its flexibility with, for example, current modp ElGamal 
encryption in OpenPGP. An OpenPGP application today generates its own 
prime and is not constrained by the allowed size of such a prime 
(usually in a range of 1024-4096 bits). In this ECC proposal we 
essentially folding infinite number of primes into 3 predefined primes.

This proposal offers the least choice of ECC parameters of any IETF 
standard.

> I suggest you would half the entire workload by reducing all above 
> choices to 1 MUST, and reduce the compatibility problems to about a 
> tenth.
>
> It would then have a good chance of being a really useful profile.  To 
> business folks who don't care for the tea-room discussion about key 
> lengths and rights to be compatible but uncommunicative...

At present the only MUST for OpenPGP are curves ID 1 and 2. It also says 
that SHA-256 and SHA-384 are MUST. All this is in section 11.1. These 
are the curves/hashed approved by Suite-B. I can accepts that we reduce 
the OpenPGP profile to ID 1 and SHA-256. This will match Suite-B 
"Secret" level and drop "Top Secret".

The section 11.2 is for Suite-B compatibility. The MUSTs there are for 
applications implementing Suite-B profile. I should put a sentence into 
11.2 that makes this clear. I wasn't trying to tell an applications 
which Suite-B profile to use (for this there is section 12).

> =====
>
> 12.  "MDC SHOULD be used when symmetrical encryption key is protected 
> by ECDH."
>
> Is there any good reason to permit it to be dropped?  Remove a 
> compatibility complaint, make it a MUST?

Hal Finney had a reservation that MDC and S2K are orthogonal to ECC, so 
I changed the key word to SHOULD. The proponents of MUST would take an 
opportunity to tighten the security, because only recently updated 
applications can understand the ECC key. I will go with the consensus, 
and if there is none, I am happy to remove these references.

 > Iterated and Salted S2K ... Ditto.

I looks forward to see other responses. I am flexible on many of these 
issues in the interest of the consensus.

Date: Wed, 20 Feb 2008 11:12:12 +0100
From: Ian G <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: [email-masked]
Subject: Re: ECC in OpenPGP proposal
Sender: [email-masked]

Hi all,

Some comments.  Caveat:  I wouldn't know an EC if someone 
hit me over the head with it...

Big comment:  far too much variability, for little gain.

Andrey Jivsov wrote:
> 
> Hello OpenPGP list,
> 
> as Hal Finney had mentioned earlier, here is the draft:
>    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt
> 
> Unless you read this on a text terminal, here is the document in 
> alternative formats that offer cross-references as navigation links:
>    http://brainhub.googlepages.com/pgp

> Why do we need ECC? The main reason is better alignment with the 
> strength of symmetric key. Given that US government has chosen ECC in 
> favor of modp for larger key sizes, this proposal is carefully written 
> to comply with NSA Suite-B.

I think it is sufficient to state that you want a Suite-B 
compatible profile.

4.  ... "SHOULD support ECDH"

what is the point of not supporting ECDH?  I recommend MUST.

=====

6.  ... "the KDF hash function MAY be any hash function 
defined in [FIPS 180-2] or its successor, except that SHA-1 
MUST NOT be used."

What is the point in permitting alternatives?  If there is a 
good reason, I would prefer to see them enumerated for 
better understanding and for certainty.

I especially don't like "or its successor."

I ask ... without expecting to understanding the answer ... 
why it is that it is useful or necessary to permit any 
variability in the KDF?

=====

11.2  I don't think it makes sense for OpenPGP WG to suggest 
that it knows what "Secret" and "Top Secret" means, nor that 
it can "achieve" this.  The normative place for that is NSA. 
  If some guidance of intentions is useful, it should be in 
the sense of a comment.  "This profile is intended to be 
compatible with Suite B."  If the NSA can be convinced to 
make a statement as to what works for them, include that too.

====

11.2  I don't see any point in providing both Secret and Top 
Secret?  This seems like a way to create comaptibility 
problems for zero payoff.  I suggest the full Top Secret as 
the only profile, and that's it.

====

11.  Indeed, what is the point in allowing people to fiddle 
around with different curves, KDFs, and hashes?  Nobody has 
ever cracked any of them, or nobody that we care about 
(which excludes the NSA, perversely).  Set one and leave it 
as that.

This "profile" proposes 2 different public key algorithms, 3 
different curves (plus future ones), 3 different hashes 
(plus future ones), 3 different AES strengths, MDC on or 
off, It/Salt as a SHOULD.

I suggest you would half the entire workload by reducing all 
above choices to 1 MUST, and reduce the compatibility 
problems to about a tenth.

It would then have a good chance of being a really useful 
profile.  To business folks who don't care for the tea-room 
discussion about key lengths and rights to be compatible but 
uncommunicative...

=====

12.  "MDC SHOULD be used when symmetrical encryption key is 
protected by ECDH."

Is there any good reason to permit it to be dropped?  Remove 
a compatibility complaint, make it a MUST?

Iterated and Salted S2K ... Ditto.

=====

Date: Mon, 18 Feb 2008 20:00:14 -0800
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
Subject: ECC in OpenPGP proposal
Sender: [email-masked]

Hello OpenPGP list,

as Hal Finney had mentioned earlier, here is the draft:
    http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt

Unless you read this on a text terminal, here is the document in 
alternative formats that offer cross-references as navigation links:
    http://brainhub.googlepages.com/pgp

This submissions considers comments of the group to earlier Elliptic 
curve Cryptography (ECC) draft submissions. A couple of issues that were 
raised then are the justification for ECC in OpenPGP and how the larger 
set of ECC parameters can be managed.

Why do we need ECC? The main reason is better alignment with the 
strength of symmetric key. Given that US government has chosen ECC in 
favor of modp for larger key sizes, this proposal is carefully written 
to comply with NSA Suite-B. Informally, this is a proposal for these who 
are concerned that the use of SHA2-512 and AES-256 will need something 
stronger that RSA 1024. By optimistic estimates users should use at 
least RSA 4096 with AES 256, while it is a common assumption that RSA 
8192 is more appropriate. In practice, many sites today are not able to 
use RSA keys of sizes greater than 4096. ECC offers alternatives to 
larger modp key sizes. Another advantage of ECC is an opportunity to 
expand the set of hardware on which OpenPGP can be implemented. The 
security of AES-128 with corresponding ECC public key may be more 
attractive for "weak" devices, as opposed to RSA public keys, especially 
because the ECC curves introduced by this standard are already supported 
by TLS, IKE, PKIX, and SSH. Any system that communicates over slow 
medium will benefit from smaller keys and ESKs as well.

This paragraph describes the direction chosen by the proposal in 
reference to the issue of magnitude of ECC parameters and options. One 
possible approach an ECC standard can take is to define all possible 
formats in one RFC, a "toolbox" approach. One can argue that smartcard 
devices may prefer ECC in binary fields, while software implementations 
would like to work in generalized Mersenne prime fields. Another group 
of OpenPGP applications may wish to generate its own random curves as 
part of a protocol, and so on. While it may be possible to create such a 
broad standard that will make each concerned implementer happy, it 
creates more interoperability issues. This puts burden on an 
implementation that wants to support every type of ECC key. The 
performance and security issues associated with generation and 
verification of random ECC curves creates new order of complexity. It 
seems to me that in the short run there are two likely outcomes 
resulting from implementing a "toolbox" approach. In the first one, 
there will be no interoperability between different OpenPGP 
implementations. The second possibility is that there will be a core set 
of parameters that will be implemented by everybody who claims ECC 
support. This second possibility is probably wishful thinking. Consider 
the fact that in OpenPGP there is no method to advertise public key 
support, yet alone, a method to advertise a nuance of public key 
support. For example, what an application should use for a top key, so 
that self-signatures and certifications by this key are broadly 
understood? It is rare to see SHA2-512 used for these signatures. I 
think the following approach will help speed up adoption of the 
standard: we define core set of ECC parameters and make them MUST. This 
will be lowest common denominator of all possible ECC configurations 
(within the acceptable security strength). This will not be the optimal 
field for every application, yet, it will be good compromise to achieve 
faster adoption. Future advances in computing will drive the upgrade of 
the core set, but by then there will be a path by which ECC-capable 
applications can transition to other formats. The draft doesn't preclude 
the existence of companion proposals that define ECC in other fields, 
moreover, the draft provides a framework for these extensions.

Finally, only patent-free techniques were chosen for this proposal. The 
requirement to be in unencumbered field further reduced the acceptable 
ECC methods.

To summarize, this document offers narrow core set of functionality and 
focuses on matching AES strength and on Suite-B support. There are lots 
of MUSTs, very few SHOULDs in the interest of interoperability and 
patent clarity.

I would appreciate if the group reviews the document. Thank you.