IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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





On Thursday, September 08, 2005 08:21:41 +0200 Jon Bright <jon%siliconcircus.com@localhost> wrote:

Jeffrey Hutzelman wrote:


On Wednesday, September 07, 2005 08:57:20 AM +0200 Jon Bright
<jon%siliconcircus.com@localhost> wrote:

Having read various other comments and thought about it a bit, my
favoured solution is to REQUIRE 3des-ctr if *any* of the newmodes
ciphers are implemented.

Why?  What security or interoperability purpose would be served by such
a requirement?

Security purpose: none.  Interoperability: we (should) get a counter-mode
cipher that's supported by anyone who supported any of the counter-mode
ciphers.  i.e. were the day to come and we deprecate (and eventually turn
off) *-cbc, we still have interoperability.

Except we don't, because having a counter-mode cipher that's supported by anyone who supported any of the counter-mode ciphers is not the same as having a counter-mode cipher that's supported by anyone with a compliant SSH implementation. If/when we want to deprecate *-cbc, we need to update the requirements for implementations of the SSH standard-to-be. This document could do that, but it does not presently claim to do so; it simply defines some additional encryption algorithms.




Additionally, would a conditional REQUIRE be possible
for aes128-ctr?  Something along the lines of "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.

The RFC2119 SHOULD is actually quite strong, and means almost exactly what you described. It does not mean "we think this is a good idea"; it means "you have to do this unless you have a really good reason not to and fully understand the implications".





If we don't have a REQUIRED cipher, then the day that the cbc ciphers are
deprecated, we don't any longer have an interoperable cipher.

That's true when speaking of the ssh protocol as a whole. But the ssh protocol will always have a REQUIRED cipher, and I think it's safe to say that anyone who "implements newmodes" will also implement the core ssh protocol, and meet its requirements.


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

I think I answered that above.

-- Jeff



Home | Main Index | Thread Index | Old Index