All of the encryption modes described in this document are
RECOMMENDED
or OPTIONAL. Why isn't one of them REQUIRED?
This has been discussed within the working group, and there is little
support for and strong opposition at this point to defining one
algorithm as REQUIRED. (My personal view on this point puts me in the
clear minority of those who have spoken up so far).
It appears that a document listing one as REQUIRED would be unlikely to
have the consensus of the WG.
I'll collect the arguments made against it so far:
argument 1:
It's one thing to say "if you support ssh then you MUST support
3des-cbc". It's quite another to say "if you support 3des-ctr then
you
MUST also support aes128-ctr" or vice versa. The former insures that
ssh
implementations will be interoperable; the latter does not appear to
me
to add any value.
argument 2:
Because it's not appropriate; newmodes is not so much a thing to
implement or conform to in its own right as it is a collection of
individual things to implement or conform to. Thus, making (say)
des3-ctr REQUIRED is really just saying "you cannot claim to do
newmodes if you don't do des3-ctr", but since claiming to implement
newmodes is not a useful thing (as opposed to claiming
implementation of particular things defined in newmodes), this is
not useful.
argument 3: (against my proposed aes128-ctr REQUIRED):
I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH
implementations are required to have 3DES code around anyway to
support
3des-cbc, so anyone implementing newmodes can put in 3des-ctr support
trivially, whereas aes128-ctr might be a lot more effort or even
impossible (imagine a small implementation without room for both 3DES
and
AES).
This does raise the question of how to arrange a transition to AES
(or
whatever) in the longer term, but I don't think it should be done on
the
back of newmodes.
...
Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all
that I think it's unnecessary. I _am_ opposed to making aes128-ctr
REQUIRED.