On Sat, May 3, 2008 at 10:11 PM, Andrey Jivsov
<openpgp(_at_)brainhub(_dot_)org> wrote:
Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires
that
TOP SECRET must use AES-256
SECRET must use AES-128 or AES-256
Labeled security is usually required with these standards. Information is
labeled with certain classification, which assures that the processing of
this information will match the label as data travels through the system.
This results in:
TOP SECRET keys can receive TOP SECRET and SECRET information
SECRET keys can only receive SECRET information
Information | |
level | Keys | "Send to" action
--------------------------------------------
[TS] | [TS],[S] | fail
[S] | [TS],[S] | allow with AES-256
[TS] | [S] | fail
[S] | [TS] | allow with AES-256
[TS] | [TS] | allow with AES-256
[S] | [S] | allow with AES-256/128
Note that two first rows represent the same mix of keys but result in
different behavior. This aspect is orthogonal to OpenPGP.
Andrey, I really appreciate you putting the effort in to
flesh this out.
For completeness,
Key level | Key preferences
--------------------------------------------
[TS] | {AES-256}
[S] | {AES-256, AES-128}
Note, however, that the [TS]/[S] suites restrict not only the
symmetrical cipher but also the public key size and the size
of the SHA2 hash used too.
Your "key level" implicitly includes these further restrictions,
but it needs to be stated explicitly as well, and there would
be similar "fails" if the public key size was too small or (say)
you were doing conventional encryption and the hash used
for the passphrase was too small.
The current discussion has sprung from the "inheriting" of
3DES from 4880, however, so that was why the focus has
(so far) been on the fact that OpenPGP ECC COULD encrypt
using 3DES unless we provide some sort of mechanism or
policy to prevent this (and hence this particular document).
I see three approaches.
A. Use key notations "suite-b-key(_at_)pgp(_dot_)com"
Leave the interpretation of these values to applications.
(If all we have to say is the sentence under A, I would say we keep it out
of the document.)
I agree. In fact I would go further and say if A is the way
forward chosen then we should remove *all* mention of
Suite-B from the OpenPGP ECC proposal, except for
perhaps a paragraph noting that a subset of OpenPGP ECC
may be used as the basis for Suite B implementations.
===================================================================
B. Use feature bits of a key 0x02, 0x4 of
"5.2.3.24. Features" as follows:
0x02: The default symmetric alg. of the key is AES-128
0x04: The default symmetric alg. of the key is AES-256
These bits can be combined (i.e. they are not mutually
exclusive).
===================================================================
TOP SECRET (TS) must have 0x02
SECRET must have 0x02|0x04=0x06
The existence of 0x02 or 0x04 tells that the implicit default algorithm
TripleDES is replaced by (either of) corresponding AES algorithm(s).
this is all good.
This specification may appeal to these who don't want to see Suite-B
mentioned in the "protocol/format" document. It also specifies narrow
feature using the concepts compatible with the scope of RFC 4880.
The Suite-B meaning need to be layered on top of these bits.
interesting - I would say this was "a little bit less" than I was
originally intending, i.e. you've made it "profile" (e.g. Suite-B)
independent.
I'm fine with that as a half-measure; it will help us "remove"
3DES.
Yet, the proposals A and B lack following details:
* It is not sufficient to rely on key holder to tell which information
level it is eligible to receive. Everyone wants TOP SECRET. This statement
must come from a trusted source, like a certification by a trusted key or
looked up online. The above proposals A and B put data into a
self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be
needed. It is "may" because in some cases keys are managed, making this
notary signatures unnecessary, or keys may be looked up in some online
directory.
* Furthermore, what a sender does with the information and how it
interprets the flags on a key is not enforceable by a recipient. This must
be enforced by higher levels.
right, so this is where my original proposal was "stronger."
My original proposal was "strict suite-B flag[s] mean a
sender's implementation MUST NOT use anything other
than the appropriate ciphers [and hashes/public key sizes]
on the recipient[s]' key"
If you wish to add this as a further option to the ballot
then that's up to you.
Finally:
C. Higher layers of application will govern compliance
with Suite B. "ECC in OpenPGP" document will define
reasonable superset of features required for Suite-B
or similar government documents, but exact
specification of the policies to use ECC in OpenPGP
is out of scope.
Hmmm, your C reads very much like your A.
In fact now having looked at your C in more detail I actually
don't see any value in A - it's almost a "hint from the receiver"
that needs the human user on the sending side to see it
as such.
At least C means something to an implementer.
In other words, A and B are really C+policies. Regardless of which route we
take, we will need "protocol/format" document. This is what implementors
need first. This is what is needed to establish interoperability base. This
is what will make messages flow. This layer alone may get incorrectly
encrypted [TS] information with TripleDES, so higher layer will be needed.
This layer doesn't even care whether it's 3DES; it's not
"incorrect" at all for this layer.
Anyway, as with your "A" option, I see that if "C" is chosen
then (almost) all mention of Suite-B should be removed
from the OpenPGP ECC specification, aside from as I've
mentioned above ("a subset of OpenPGP ECC may be")
However, as an implementor I see value in splitting a Suite-B cloud into
layers that we can implement and test independently.
Well your original document was an AES strength ECC
with Suite-B capability along with it. What's come out of
it was that we either need to deal fully/properly (i.e. we
need to enforce ciphers somehow), *or*, we junk all
notion of Suite-B in OpenPGP ECC. If we don't "do" Suite-B
"properly" then we're not actually doing it at all (it either
supports Suite-B or it doesn't, i.e. there is scope for it to
wrongly-encrypt with 3DES, or there isn't).
Here is promised ballot. "x" for "yes".
As an editor I think that voting C will result in faster progress of the
document.
Possibly, although the removal of Suite-B from the text
will probably take just as long (longer?) than adding the
"features bit" (or the "stronger" SSB bit) to the text!
So, my vote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David Crick:
A: [_] (meaningless for an implementation spec)
B: [x] (ideally as a strict suite B MUST respect / MUST NOT deviate)
C: [_] (may as well just remove notion of Suite-B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iF4EAREIAAYFAkgdy1UACgkQNTbKPm/1JkC8VwD+ILAxlVcej7QfV4YVwyk+i4h4
4Fo5XnMoSPghxJtt7DwA/jVQuwzAwF5wow1k99+5+gE/qy0enRZP7C/V2EnLyVIA
=UEJU
-----END PGP SIGNATURE-----