Re: Last ditch proposal for crypto suites

[Charlie_Kaufman@notesdev.ibm.com]

> That suggests that even if we
> stick with a la carte, we should specify which combinations MUST be
> offered, from among the standard algorithms (subject to administrator
> security override, of course).
>
> Aside -- and donning my AD hat for a moment -- I've become increasing
> concerned about interoperability.  We need to ensure that our
> standards, as well as being technical correct and secure, specify
> a minimum set of mandatory-to-implement mechanisms that will always be
> there.  Specs that say "you can solve this problem by doing (a) or (b)"
> are not acceptable, since different vendors will make different choices.

Absolutely. That's a given whatever else we decide to do. If the spec
says you MAY do (a) or (b), then the spec must also say that you
MUST accept both (a) and (b) should the other end choose them.

The current draft mandates a single suite even though it is expressed
ala carte. It's AES128, SHA-1, D-H w/1536 bit fixed p, X.509 certs,
and RSA keys. The current draft *claims* that the mandatory algorithms
for ESP and AH are specified in those documents. Is that true? If not,
would it be appropriate to list mandatory algorithms for them here?

I would like for it to be impossible to be compliant without being
interoperable with everything else that is compliant. (This at the
level of implementations not deployments... this is a security
protocol after all and you have to be able to configure the system
to refuse to talk to peers that don't have keys you like).

          --Charlie

Opinions expressed may not even by mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).