Subject: ECC in OpenPGP proposal

From: Andrey Jivsov <[email-masked]>
Date: Mon, 18 Feb 2008 20:00:14 -0800

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.

---

From: Ian G <[email-masked]>
Date: Wed, 20 Feb 2008 11:12:12 +0100

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.

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

=====

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 21 Feb 2008 00:08:47 -0800

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

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.

---

From: Ian G <[email-masked]>
Date: Thu, 21 Feb 2008 12:45:00 +0100

> 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

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

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

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

> 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 

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

> "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

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 22 Feb 2008 22:12:48 -0800

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.

---

From: Jon Callas <[email-masked]>
Date: Tue, 26 Feb 2008 12:59:39 -0800

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

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

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

---

From: Ian G <[email-masked]>
Date: Wed, 27 Feb 2008 11:50:45 +0100

Hi Jon,

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

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

> 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]>
Date: Wed, 27 Feb 2008 14:35:53 -0800

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

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

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

---

From: Ian G <[email-masked]>
Date: Thu, 28 Feb 2008 15:38:20 +0100

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

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

> 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: Jon Callas <[email-masked]>
Date: Thu, 28 Feb 2008 15:14:10 -0800

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

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.

> OK, if you are happy to carry on this discussion ... what are the  
> 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