On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov
<openpgp(_at_)brainhub(_dot_)org> wrote:
David Crick wrote:
> 11.1 I would like to see "MAY implement curve ID 2" explicitly stated
> (this *is* mentioned in section 12, but would like to see it here too)
are you not going to add "MAY .. curve 2" into 11.1?
both Ian and I have requested this, and I have previously
pointed out that for *all* algos (asym, sym, hash) 4880
adds a "MAY implement any other" to the end of each
section (where for ours, there IS only one other, so may
as well be mentioned specifically, i.e. MAY curve 2)
> 11.3 says "The best remedy to this .. is to add .. AES-256"
>
> not sure about "best" - perhaps "simplest"? The reason being is
> that as AES128 is an ECC must, then this guarantees us *a* Suite
> B acceptable cipher, although - as you're trying to get at - having
> AES256 means that we'd cover *both* Suite B profiles.
>
Corrected.
great, this is now better.
> 12 "It is generally advisable to list at the head of the preference list
> a symmetric algorithm of strength corresponding to the public key."
I watered down this statement to leave that at least the algorithm
should be there.
I *preferred* the original version ("at the head")! ....
> Again, I see what you're trying to say, but as is noted elsewhere in
> the ECC doc, it's merely the intersection - it's up to the implementation
> to make its own decision thereafter (and so take advantage of any
> ordering information).
As a side note, per RFC4880 this "is an ordered list of octets with the
most preferred listed firs". If each recipient has the same set of
symmetric algorithms, shouldn't the intersection remain ordered? I think
"merely an intersection" is not strictly correct, although I can agree
with "in practice" or "in most cases" clarification.
... I was referring to THIS bit in 4880 (13.2):
"The implementation may use any mechanism to pick an
algorithm in the intersection."
Thus, while the section you quote (5.2.3.7) is *also* correct,
what 13.2 is saying is "well, there's information you COULD
use, but it's really up to you [the implementation] to pick an
algorithm."
Therefore, I was *happy* with your original wording (and would
prefer to see it re-instatad!), but was just pointing out that it
was only part of the (i.e. [4880] rfc) story.
> I think section 12 also needs to explicitly deprecate AES-192, saying
> that it's not necessarily going to be fielded widely (bring in the fact
> that it is only a MAY here might help), isn't one of the Suite B ciphers,
> and that it's probably only suitable if for some reason you *really*
> need a 192-bit cipher: otherwise go for AES256 for security or -128
> for performance.
I hope that we find a consensus in not explicitly promoting AES-192
instead. There are many reasons why mobile/weak hardware devices may
wish the middle-of-the-road approach with AES-192/ECC-384.
For SSL it was decided to just go with AES128 and AES256:
"The AES supports key lengths of 128, 192 and 256 bits.
However, this document only defines ciphersuites for 128-
and 256-bit keys. *This is to avoid unnecessary proliferation
of ciphersuites.*" (rfc3268)
(Similarly, with Camellia added to SSL again only the 128 and
256 length keys were added (rfc4132), again mentioning
that just the 128+256 are being done, despite 192 exisiting.)
With Suite B, NSA have chosen to also just go with 128 and
256, despite the other elements of the larger algo set being
192-equivelent in size. From their footnote 1:
"CNSSP-15 correctly states that 192-bit AES keys are sufficient
for protecting even TOPSECRET information. However, Suite B
uses only 256-bit keys *to enhance interoperability*."
Our MUST is AES-128, our SHOULD is AES-256. I think we should
be following the trend in promoting just 128 and 256 bit ciphers,
and by deprecating AES-192 - which we NEED to do with the
stronger Suite B set (perhaps possible the "only" reason to
implement Curve 2, give our MUST on C1 and SHOULD on C3).