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

[Jon Bright <jon%siliconcircus.com@localhost>]

der Mouse wrote:
> > 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*.

I certainly think we should explain why, but I think it should be why 
it's REQUIRED, not why it's RECOMMENDED.  Obviously we only have 
interoperability if people take any notice of what the document says - 
but if we only RECOMMEND it, then people can take notice of us and 
*still* not be interoperable.

> > > 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.

Take some person who's implementing newmodes.  If we just recommend that 
3des-ctr be implemented, that person is comparitively more likely to 
blow off the recommendation with whatever justification ("Pfft, 3DES - 
so 90s") than if it's required.  If 3des-ctr is required, it might still 
not get implemented.  But it's likely to give someone more pause, to 
make them look a little more at the background (and to come upon the ML 
archive of this thread :-)

> 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.

OK. What do we lose by making it REQUIRED?  (Assuming all explanatory 
text is present whether it's REQUIRED or RECOMMENDED.)

> > 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.

No, my arguments say that making it REQUIRED makes it less likely that 
someone blows off the one cipher of the group that pretty much 
everyone's likely to be able to support.

> 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.

I agree - but I also hear the view of the embedded/hardware people who 
can't squeeze both DES and AES in.  As I said in my first mail, in a 
perfect world, I'd REQUIRE aes256-ctr as being (imo) the best compromise 
between future-proofness and widespread availability.

> 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.

Agreed - but I think it has value that if they *don't* ignore us, the 
result is interoperable.  "I did everything the RFCs said and I still 
can't interoperate with <x>" is common enough already.

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com