[I sent it out incorrectly, re-sending]
A few comments to David Crick:
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.
I agree that there is inconsistency in that if we go with "C", i.e. we
anticipate another separate document (standard or just a best practices
write-up), then Suite-B text from ECC in OpenPGP document can be moved
elsewhere. At the same Suite-B and NSA are, as Jon Callas called them
"big elephant in the room" and from this point of view I can see value
in the current text that gives an idea of what is needed for Suite-B.
It seems that there is good consensus against increase in the text
referring to Suite-B in the document. I will wait and listen for a few
days regarding how to reduce/improve what currently have.
to David Shaw:
I'm not sure that option (B) is really selectable here. Or put
another way, I think option (B) already exists as part of the current
cipher preferences system.
For example, take the entire installed user base of OpenPGP programs
to date. That's a non-trivial amount of code in active use. Those
programs will not know about the new feature flags, and will thus
ignore them (meaning they will use 3DES as the default algorithm).
I meant to introduce it with ECC keys. Here we have an advantage that
these keys can only be understood by new software. This is better than
circumstances before the adoption of MDC.
Now take the case of an old key (default is 3DES) and a new key
(default is AES) as recipients to a message. Let's assume that there
is no agreement on ciphers, so the cipher of last resort must be
used. A sender using the 4880-compliant program will (correctly) use
3DES, as it knows nothing about the feature flag telling it do behave
otherwise. A new OpenPGP program might not have 3DES (why bother
since AES is the new default), so one of the recipients won't be able
to read the message. Okay, so we can fix that: we can enhance (B)
with a rule saying that 3DES is still a MUST-implement cipher, to
cover that case.
Correct, RFC4880 MUSTs are carried over in general.
Now take the reverse case: the same two recipient keys, but the
sender is a new OpenPGP program that believes AES to be the default.
In the case above, the message will *still* be 3DES, as the older key
does not have the necessary feature flag, so the new program can't
use this new feature across the entire recipient set.
The though was that since the feature removes 3DES as implicit default,
the two subsets of recipients -- one with 3DES common algorithm and
another with AES -- will get empty intersection. This will result in a
sending error.
So given that new programs will need to have 3DES anyway to cover the
transition case, and given that messages sent to a mixture of old
and new keys that are forced to use the cipher of last resort will
end up as 3DES.... how is (B) different than the current cipher
preference system with AES listed before 3DES?
It is different in one important feature: it allows the removal of
legacy algorithm from the default. This is not a panacea and will break
interoperability in some cases.
Unless I misunderstand, isn't A really the same as C (or to be very
accurate, isn't A a possible implementation of C?)
"A" is a way to have specific Suite-B flag, unlike B, which is more
aligned with RFC 4880 and really deals with 3DES-AES succession. There
are many "A"s possible, the one given is the bare minimum, since it
doesn't say much. C basically says that A and B are out of scope.
This sort of thing risks putting restrictions in places that can't
always handle those restrictions. Take the restriction where the
implementation, in its Suite-B mode, must not allow the sending of
messages to keys that can't handle Suite-B: so much so that it's even
verboten to send two messages. Now take real-world examples like
that of Enigmail, which uses GPG as its crypto engine. How on earth
is GPG, the "OpenPGP implementation" in that system, supposed to stop
Enigmail from doing that? Forget GPG even - outside of a locked down
environment, how is any implementation supposed to stop the user
from doing that?
Yes, this thread shows that there is clearly more to Suite-B than a few
web pages that NSA has put up.
Many of these issues, such as the security level of information, is
outside of traditional domain of OpenPGP. I suppose an e-mail
application in Suite-B environment might have a UI combobox with
SECRET/TOP SECRET choices in the compose window that magically (based
on content or at worst manually) are set to the correct level. The rest
is easier to program: this would allow software to check that [TS]
information is being sent to [S] key(s) and block it.
Thank you everybody else, Jon, Werner, and Ian, for their comments.