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

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> [...]
> Take some person who's implementing newmodes.

Is there such a thing?  That's the sort of thing people have been
saying all along, and I really don't think it makes any sense.

Take my implementation.  I've implemented a handful of things whose
spec is in newmodes; I've ignored a handful more.  Have I "implemented
newmodes"?  According to the criterion given upthread - "any cipher
from newmodes" - I have, but I certainly never thought of it that way.

> What do we lose by making it REQUIRED?

I can see two things.

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.

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

How strong those effects are - and whether there are others - I'll
leave up to others.

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

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

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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B