Re: I have a technical idea/change for the ECC draft

["David Crick" <dacrick@xxxxxxxxx>]

On Tue, Apr 15, 2008 at 3:22 AM, Jon Callas <jon@xxxxxxxxxx> wrote:
>
> On Apr 14, 2008, at 3:33 PM, David Crick wrote:
>  >> * I like David Crick's suggestion of a preference that says, "I'm
>  >> going to be strict about Suite B." This is a legislative solution,
>  >> and
>  >> it would work well, it's simple, and elegant. End of story.
>  >
>  > are you referring to a "key" or "application" preference (or both?!)
>
>  I was thinking a signature subpacket of some sort. That's a "key"
>  preference.

good.

>  Any application-level things are beyond the scope of this group.

again, this is what I was expecting.

>  We did this with DSA/DSS. If you want to be strictly FIPS, you always
>  use DSA with SHA-1, etc. and that gives you DSS. If, however, you look
>  askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit
>  and implicit issues with that, but you can do it within 4880.
>
>  We could similarly just not worry about it. Let the implementers
>  handle it. Thems what care about strict-SB can implement it the right
>  way.
>
>  I like the legislative solution, but I prefer doing nothing and
>  letting the implementers handle it. This is a style issue. I believe
>  that a standard exists for interoperability, and to make sure you
>  don't end up with two implementations that *cannot* talk to each
>  other. Beyond that, I am a minimalist. A standard is not a how-to
>  guide for an implementer.
>
>  I were an implementer, I would not generate a "loose-Suite-B" message,
>  *ever*. I'd decrypt them, but I wouldn't give my users the option to
>  create them.

I agree with you on all the above.

>  >> Even better would be for implementations to just not offer an
>  >> alternative.
>  >
>  > yes!
>  >
>  > If all applications were to by default add AES (one or both) to
>  > the head of any ECC generated keys, *and* prefer AES over
>  > 3DES as implicit, *but* still be able to "understand" messages
>  > that are encrypted by non-AES ciphers.
>
>  Frankly, I believe that an application should prefer AES or Twofish
>  over 3DES, period.

It's what NIST says (of AES and 3DES; AES is the FIPS, while
3DES has been downgraded to a Special Recommendation).

NSA's blessing of AES (first for classified usage, and then an
even stronger endorsement through Suite B) as far as I'm
concerned is a very clear signal.  In fact, Suite B itself (and I
include SHA2 here, despite people's misgivings given SHA1)
is a strong signal about "what" we (crypto implementers)
should be doing - and why I've been pushing for us to focus
on Suite B (and AES with it) when looking at OpenPGP ECC.

>  Note that 4880 *explicitly* says that you take the intersection of
>  Alice's and Bob's preferences and resolve them any way you see fit. It
>  is acceptable for an implementation to use 3DES only when nothing else
>  exists. It's acceptable for an implementation, thus, in Suite B, to
>  always be strict. (To do Suite B, you have to have AES as an option.)

yes, although there *is* a section in 4880 that says about
the preference listing being ordered.  The two things together
*aren't* incompatible; rather they say, together, that here's
some information you *could* use, but really it's up to you.


>  That's the way I'd do it. I'd do it in the code, not in the standard.
>
>  However, I realize that not everyone has my matters of taste, and so
>  therefore, I support the legislative solution.

I think the legislative solution should give clear enough
guidelines to the implementers about what they should
be doing!