Re: Your DISCUSS on draft-ietf-secsh-newmodes-05

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> i.e. were the day to come and we deprecate (and eventually turn off)
> *-cbc, we still have interoperability.

No; you have that only if people actually do implement some common
cipher.  Using REQUIRED instead of RECOMMENDED might make that a little
more probable, but I think it would be only a little, especially if we
not only strongly recommend (say) 3des-ctr but explain *why*.

>>> "we'd really, really like you to implement this, but we recognize
>>> that not everyone's hardware is going to be big enough to squeeze
>>> in both 3des and aes implementations".
>> That's what SHOULD means.
> I was thinking of something a little stronger, but maybe no such
> thing exists.

I don't think so, at least not within RFC2119 language.

>> I really see no benefit to a requirement in which, if a particular
>> algorithm is supported, then some other alternative algorithm must
>> also be supported.
> It indicates direction and achieves interoperability for the future.

We can indicate direction without a REQUIRED, and a REQUIRED won't
achieve interoperability; only actually getting some cipher
(near-)universally implemented (and offered by default) will do that.

A REQUIRED might lead to that, but it also might not - and the same
applies to any other language we might use.  It's just a judgement call
as to whether the additional push in that direction (if any) is worth
condemning implementations who ignore it.

> Just because it says REQUIRED in a document, doesn't mean people are
> going to slavishly follow it.

Right - but the arguments you're presenting assume it does.

> Question back: if we don't set any of these ciphers to REQUIRED, what
> happens interoperability-wise when CBC gets deprecated?

Nothing, same as if we do.  Formally deprecating the CBC ciphers will
either be acknowledging a already-present status quo, in which case
pragmatics will mean we already have some suitable cipher (which may
3des-ctr, but also may not - vide infra), or it will be an attempt to
lead things in that direction, in which case I think we'll be in a much
better position to figure out what a good cipher will be then than now.

I also don't much like mandating anything DES-based.  As well-tested as
DES is, it is a rather software-hostile cryptosystem, as compared to
ciphers like (say) Rijndael or Blowfish.  It wouldn't surprise me if,
by the time deprecating the CBC modes looks practical, DES were also a
fairly dead letter, with the current REQUIREment for 3des-cbc widely
ignored.

That said, I think this is rather a tempest in a teapot.  Whatever
language we put in newmodes, implementors will go off and do whatever
they want anyway, and interoperate - or not.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B