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. Waiting for the day that we want to turn *-cbc off to change the RECOMMENDED to a REQUIRE might be theoretically nice, but I don't view it as sane in practice. 3DES, I chose because 3DES is already required in the core drafts. Anyone who has 3DES/DES hardware, assuming it doesn't *just* do CBC, should be able to implement 3des-ctr. Anyone in a tiny embedded system who's implemented the core drafts should still be able to squeeze in 3des-ctr.
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.
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. I will note that RFC2119 says:
It indicates direction and achieves interoperability for the future.
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.So, please, show me either an interoperability need that is served or a potential for causing harm that is limited by making one encryption algorithm a prerequisite for another.
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.
Alternately, I'd like to echo der Mouse's question -- what does it mean to "implement newmodes" ?
Implementing any cipher. Just because it says REQUIRED in a document, doesn't mean people are going to slavishly follow it. But if we say "you're putting in the effort to add (a) counter-mode cipher(s) to your implementation, please note that whatever cipher you choose (and maybe prefer in your keyex packets), you MUST also implement 3des-ctr, so that we have an interoperable cipher for the future", then we've at least done our best to keep interoperability. If people ignore our REQUIRED, well they might not be interoperable in future.
Question back: if we don't set any of these ciphers to REQUIRED, what happens interoperability-wise when CBC gets deprecated?
-- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com