der Mouse wrote:
One is that people working on implementations which don't have room for two ciphers will end up doing DES instead of something faster and more secure; see below.
But if they're implementing the core drafts and taking any notice of the REQUIRED entries, they'll already be doing DES. I'd *prefer* to REQUIRE aes-ctr, but given the situation in the core drafts, it's exactly to accomodate these people that I suggest requiring DES.
Two is the "pointing and laughing" factor, which I can perhaps summarize as "lookie, they're still trying to require something DES-based! and they expect to be paid attention to! how lame!".
This point can, I think, be covered in the text. Something along the lines of "Although the only cipher which is REQUIRED is 3des-ctr, we strongly RECOMMEND that any implementation technically able to implement aes-ctr do so. If both ciphers are implemented, aes-ctr SHOULD by default be preferred during cipher negotiation, leaving 3des-ctr only for interoperability purposes". (Possibly modifying that last bit, since as I recall, some people have objections to SHOULDing cipher negotiation order, arguing this should be left to the admin or implementor.)
I agree - but I also hear the view of the embedded/hardware people who can't squeeze both DES and AES in.Right, and which would you rather have? I'd sure rather see Rijndael, even restricted to AES, than DES, even triple-DES. Rijndael is faster in software and it's almost certainly more secure. Indeed, though I don't expect to see it happen, I'd actually prefer to see newmodes include language weakening the MUST in transport-24 and recommending that if only one fundamental cryptosystem is implemented that it be Rijndael rather than DES.
As above, I'd prefer AES, but as long as 3DES is REQUIRED in -transport, I don't think this is a plausible recommendation. Language altering the REQUIREment in -transport might be a sensible alternative if it's possible (what's the etiquette for these things?). The one risk with this approach is that we potentially lose interoperability between people who have just implemented the core drafts and those who've implemented newmodes ciphers. There's also the issue Peter raised about whether hardware capable of aes-ctr is yet sufficiently available.
Overall, though, I think I'd welcome such language (and would then support an AES REQUIRE).
Agreed - but that's approximately as true of RECOMMENDED/SHOULD language; <x> in such cases typically appears to have been implemented based on a spec scribbled on the back of a napkin in a language the implementor doesn't understand - and then sold by Microsoft (okay, okay, </cheapshot> - I had a brush with Windows telnet recently). There's not ignoring us, as in, paying attention to the meanings and doing something sensible in view of it, and there's not ignoring us, as in, obeying the letter of everything and the spirit of nothing. Which case(s) do you care about? I care about the former and not particularly about the latter, notwithstanding all the times I've jumped up and down and yammered about "buh-but it violates the RFC!". That's why I don't see any real harm in the weaker language.
Fair points (and yes, I hate Windows telnet too :-). Given all this and being that I don't think our positions differ all that much, I'd be willing to compromise on a RECOMMEND with explanatory text pointing out that of the modes listed, some people may only be able to do 3des-ctr and thus although it's only a RECOMMEND, it's a really, really strong one for interoperability reasons. Basically, text to give a kind of "RECOMMEND. Oh, and we're holding a really big stick. And watching you." feeling. Maybe RFC2119 needs a revision, adding "RECOMMEND-WITH-STICK" :-)
-- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com