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

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 01 Sep 2005 17:30:05 -0400

All of the encryption modes described in this document are
RECOMMENDED
   or OPTIONAL.  Why isn't one of them REQUIRED?

This has been discussed within the working group, and there is little
support for and strong opposition at this point to defining one
algorithm as REQUIRED.  (My personal view on this point puts me in the
clear minority of those who have spoken up so far).  

It appears that a document listing one as REQUIRED would be unlikely to
have the consensus of the WG.  

I'll collect the arguments made against it so far:

argument 1:

    It's one thing to say "if you support ssh then you MUST support     
    3des-cbc".  It's quite another to say "if you support 3des-ctr then
you
    MUST also support aes128-ctr" or vice versa. The former insures that
ssh
    implementations will be interoperable; the latter does not appear to
me
    to add any value.

argument 2:

    Because it's not appropriate; newmodes is not so much a thing to
    implement or conform to in its own right as it is a collection of
    individual things to implement or conform to.  Thus, making (say)
    des3-ctr REQUIRED is really just saying "you cannot claim to do
    newmodes if you don't do des3-ctr", but since claiming to implement
    newmodes is not a useful thing (as opposed to claiming
    implementation of particular things defined in newmodes), this is
    not useful.

argument 3: (against my proposed aes128-ctr REQUIRED):

   I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH
   implementations are required to have 3DES code around anyway to
support
   3des-cbc, so anyone implementing newmodes can put in 3des-ctr support
   trivially, whereas aes128-ctr might be a lot more effort or even    
   impossible (imagine a small implementation without room for both 3DES
and
   AES).

   This does raise the question of how to arrange a transition to AES
(or
   whatever) in the longer term, but I don't think it should be done on
the
   back of newmodes.
    ...
   Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all 
   that I think it's unnecessary.  I _am_ opposed to making aes128-ctr
   REQUIRED.

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Sep 2005 14:00:55 -0400

Bill:

I decided not to respond immediately to your note.  Instead, I thought 
about it over the weekend.  Here is my argument for selecting at least one 
of these modes as REQUIRED.

We know that the current REQUIRED algorithm is not as robust as we would 
like.  It is not so flawed that we need to rush to a new one, but we should 
plan an orderly migration.  By making one of these algorithms REQUIRED, we 
are telling implementors where we are going.

I would like to see AES128-CTR be REQUIRED.

Russ

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 06 Sep 2005 14:37:23 -0400

> I would like to see AES128-CTR be REQUIRED.

<wg chair hat off>
"me too."  
<wg chair hat on>

Anyone with an opinion on this topic who has *not* yet spoken up should
do so sooner rather than later.  Please keep Russ CC:ed in this
discussion.

					- Bill

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 6 Sep 2005 22:08:39 +0100

> do so sooner rather than later.  Please keep Russ CC:ed in this

Oh all right the :-)  I tend to agree - one of the AES ciphers should be
required.

So given that CTR are to be preferred over CBC I'd also support AES128-CTR as REQUIRED.

DF

---

From: Ben Harris <[email-masked]>
Date: Tue, 06 Sep 2005 23:47:54 +0100

>of these modes as REQUIRED.

Can we just get confirmation: Is your intention that this should be required
for all SSH implementations, required for all implementations that implement
any mode defined by newmodes, or required for all implementations that claim
to implement newmodes as a whole?

-- 
Ben Harris

---

From: Damien Miller <[email-masked]>
Date: Wed, 7 Sep 2005 09:34:51 +1000 (EST)

>> I would like to see AES128-CTR be REQUIRED.

I would prefer not to have any required. Failing that aes128-ctr would be 
my choice for a REQUIRED.

-d

---

From: Thor Simon <[email-masked]>
Date: Tue, 6 Sep 2005 21:34:56 -0400

> do so sooner rather than later.  Please keep Russ CC:ed in this

My opinion is that AES-CBC and AES-CTR ought to be REQUIRED.  I think
that the people objecting that it might be too hard to add support for
additional cipher should be, if they're speaking of their own
implementations, ashamed of themselves -- or if they're speaking of
some hypothetical "other" implementation, brought back in touch with
reality: adding support for another common cipher is just not difficult,
and for those who happen to be on the certifications bandwagon (e.g.
FIPS 140), can be very easily stuffed in to the next round of
recertifications, since they're not allowed to make *any* changed to
their product without recertifying in any event.

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Sep 2005 21:40:39 -0400

In the near term, I believe that it should be REQUIRED for implementations 
of the newmodes document.  However, I think this is an indication of where 
the group is going to replace the less robust cipher that is currently 
REQUIRED for all SSH implementations.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 07 Sep 2005 14:38:30 +1200

Thor Simon <[email-masked]> writes:

>My opinion is that AES-CBC and AES-CTR ought to be REQUIRED.  I think that
>the people objecting that it might be too hard to add support for additional
>cipher should be, if they're speaking of their own implementations, ashamed
>of themselves -- or if they're speaking of some hypothetical "other"
>implementation, brought back in touch with reality: adding support for
>another common cipher is just not difficult,

So they can just go out and update their deployed crypto hardware using a
strong magnifying glass and very small tweezers or something?  AES-CTR is
problematic because support for it in crypto hardware is practically
nonexistent (it's only just appeared as a recent update to PKCS #11, and I'm
not aware of any hardware that supports it), and it could be years (if ever)
before it's supported to a useful level.  CBC OTOH is mainstream, anything
that does AES does CBC.  So my preference would be to have none mandatory (for
the reasons given earlier), but if any are REQUIRED then only AES-CBC.  In
fact I wouldn't complain about MUST AES-CBC if people insist.

(Is there such a thing as POSSIBLY REQUIRED for AES-CTR?  If it ends up with
practically no HW support, like OAEP and some other "good idea but no killer
app" mechanisms have in the past, then directing people to it via REQUIRED
isn't doing anyone much of a service).

Peter.

---

From: der Mouse <[email-masked]>
Date: Wed, 7 Sep 2005 01:27:06 -0400 (EDT)

> that the people objecting that it might be too hard to add support
> for additional cipher should be, if they're speaking of their own
> implementations, ashamed of themselves --

Consider something like an implementation on a 68HC11 (an 8-bit
embedded controller I once had some brushes with), where doing ssh at
all, even with just DES, is a tight squeeze, and shoehorning in
Rijndael too is simply impossible.

> or if they're speaking of some hypothetical "other" implementation,
> brought back in touch with reality: adding support for another common
> cipher is just not difficult,

You are thinking of a rather restricted subclass of ssh implementations
when you consider that "reality": probably, implementations on "large"
hardware (32-bit CPUs, multiple megabytes of memory).  Speaking
strictly of such implementations, I agree with you - but I do not
believe they are all there is.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Wed, 7 Sep 2005 01:33:23 -0400 (EDT)

>> Can we just get confirmation: Is your intention that this should be
>> required for all SSH implementations, required for all
>> implementations that implement any mode defined by newmodes, or
>> required for all implementations that claim to implement newmodes as
>> a whole?

> In the near term, I believe that it should be REQUIRED for
> implementations of the newmodes document.

But what is an "implementation[] of the newmodes document"?

(1) Any ssh implementation after newmodes reaches RFC status?

(2) Any ssh implementation that supports any of the newmodes-specified
    ciphers?

(3) Any ssh implementation whose documentation claims support for any
    of the things specified in newmodes?

(4) Any ssy implementation whose documentation claims support for
    newmodes, without specifying exactly what portions of newmodes it
    supports?

(5) Some mix of the above?

(6) Something else?

This makes a difference to me as an implementor, and apparently to Ben
as well (though I suspect our reactions to "bad" meanings would be
different).  It's what I was trying to point out when I wrote that
newmodes qua newmodes was not a useful thing to "implement", that it is
really an umbrella under which to gather together a number of useful
things - a way to avoid a blizzard of 15 different drafts, one for each
cipher and each rekeying recommendation.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jon Bright <[email-masked]>
Date: Wed, 07 Sep 2005 08:57:20 +0200

> do so sooner rather than later.  Please keep Russ CC:ed in this

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.  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".  If that's not possible, my vote goes for just 
requiring 3des-ctr, since it's the thing that it's most likely to be 
possible to support across all implementations.

In an ideal world, I'd require aes256-ctr (and none of the others), but 
practicality leads me instead to the above approach...

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 07 Sep 2005 19:37:23 +1200

Jon Bright <[email-masked]> writes:

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

I think 3DES-CTR is even less likely to be supported in hardware than AES-CTR,
for AES it's a new(ish) cipher so people may at some point implement trendy
new modes, but 3DES has been consigned to the legacy bin and is unlikely to be
updated at any point.

Peter.

---

From: Jon Bright <[email-masked]>
Date: Wed, 07 Sep 2005 09:53:05 +0200

> new modes, but 3DES has been consigned to the legacy bin and is unlikely to be

So long as the hardware supports 3DES (or even DES) ECB, it shouldn't be 
more than a few instructions to get 3DES-CTR.  As far as I'm aware, 
there's plenty of hardware that does DES ECB...

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 07 Sep 2005 10:38:32 -0600

Russ Housley wrote:
> about it over the weekend.  Here is my argument for selecting at least 
> one of these modes as REQUIRED.
> 
> like.  It is not so flawed that we need to rush to a new one, but we 
> should plan an orderly migration.  By making one of these algorithms 
> REQUIRED, we are telling implementors where we are going.
> 

Rather than making newmodes specify a REQUIRED cipher as an
indication of direction, we could indicate it directly using
text of some form:

      It is widely recognized that the 3des-cbc cipher mode that
      is required by [TRANS] is a relatively weak cipher; however,
      other alternatives (such as the aes128-ctr mode described
      in this document) do not yet have the same level of common
      hardware based support as 3des-cbc or they may be too
      expensive to implement in hardware for some applications.
      As such, no cipher mode described in this document
      is REQUIRED; however, implementations SHOULD support
      at least aes128-ctr.

      At some future point, aes128-ctr may become a required
      cipher.

This would be my preferred solution.

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 17:52:38 -0400

On Wednesday, September 07, 2005 08:57:20 AM +0200 Jon Bright 
<[email-masked]> wrote:

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

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

   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.

Alternately, I'd like to echo der Mouse's question -- what does it mean to 
"implement newmodes" ?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 17:57:53 -0400

> This would be my preferred solution.

Note that the AES and 3DES modes are already RECOMMENDED, which means the 
same thing as SHOULD.  I agree that if we want to indicate direction, we 
should do so explicitly with text, rather than implicitly with a 
requirement.

The other thing I think we could reasonably do is update the RECOMMENDED 
and REQUIRED algorithms in SSH-TRANS when it advances to draft, including 
adding a normative reference to newmodes.  Of course, this would be 
possible only if there were interoperable implementations which met the new 
requirement.  And, it doesn't really address Russ's comment today.

-- Jeff

---

From: Jon Bright <[email-masked]>
Date: Thu, 08 Sep 2005 08:21:41 +0200

Jeffrey Hutzelman wrote:
> 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.

> That's what SHOULD means.

I was thinking of something a little stronger, but maybe no such thing 
exists.

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

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

---

From: der Mouse <[email-masked]>
Date: Thu, 8 Sep 2005 02:24:56 -0400 (EDT)

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

>>> "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".
> I was thinking of something a little stronger, but maybe no such
> thing exists.

I don't think so, at least not within RFC2119 language.

>> algorithm is supported, then some other alternative algorithm must
>> also be supported.

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.

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.

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

> happens interoperability-wise when CBC gets deprecated?

Nothing, same as if we do.  Formally deprecating the CBC ciphers will
either be acknowledging a already-present status quo, in which case
pragmatics will mean we already have some suitable cipher (which may
3des-ctr, but also may not - vide infra), or it will be an attempt to
lead things in that direction, in which case I think we'll be in a much
better position to figure out what a good cipher will be then than now.

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.

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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jon Bright <[email-masked]>
Date: Thu, 08 Sep 2005 09:30:12 +0200

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

> (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 :-)

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

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

> fairly dead letter, with the current REQUIREment for 3des-cbc widely

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.

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

---

From: der Mouse <[email-masked]>
Date: Thu, 8 Sep 2005 04:05:34 -0400 (EDT)

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

>> language we put in newmodes, implementors will go off and do
>> whatever they want anyway, and interoperate - or not.

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

---

From: Jon Bright <[email-masked]>
Date: Thu, 08 Sep 2005 14:13:28 +0200

> two ciphers will end up doing DES instead of something faster and more

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.

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

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

> 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" :-)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2005 09:22:28 -0400

>>>>> "Jon" == Jon Bright <[email-masked]> writes:

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

    Jon> But if they're implementing the core drafts and taking any
    Jon> notice of the REQUIRED entries, they'll already be doing DES.
    Jon> I'd *prefer* to REQUIRE aes-ctr, but given the situation in
    Jon> the core drafts, it's exactly to accomodate these people that
    Jon> I suggest requiring DES.

I think this is actually a compelling argument for not requiring
anything at the present time.  We want to require aes-ctr (or at least
I do), but we cannot get consensus to do so now.

We recommend aes-ctr and say that when we update the 2026
applicability statement for the core ssh protocol we expect to require
aes-ctr.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Sep 2005 11:00:29 -0400

On Thursday, September 08, 2005 08:21:41 +0200 Jon Bright 
<[email-masked]> wrote:

>>> ciphers are implemented.
> 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.

> I was thinking of something a little stronger, but maybe no such thing

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.

> happens interoperability-wise when CBC gets deprecated?

I think I answered that above.

-- Jeff

---

From: Jon Bright <[email-masked]>
Date: Thu, 08 Sep 2005 17:07:49 +0200

Jeffrey Hutzelman wrote:
> 
> 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.

....

> I think I answered that above.

I don't think you did.  You basically said "when we deprecate cbc, we 
require something else".  In my view the time between "we require people 
to implement a counter-mode cipher" and "we deprecate cbc" should be 
measured in years.  Unless I've misunderstood what you're saying, your 
proposal is to require the new interoperable cipher at the same time as 
taking the old one away.  This doesn't seem like a practical option to me.

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 Sep 2005 14:47:13 -0400

Take a look at 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt

This document is approved and waiting publication as a standards-track 
RFC.  In this document, Jeff Shiller
references RFC 2119, and then he further defines SHOULD+

  SHOULD+            This term means the same as SHOULD. However it is
                     likely that an algorithm marked as SHOULD+ will be
                     promoted at some future time to be a MUST.

This seems like it might offer a compromise point, excpet that in the 
context of this document, the algorithm might become required for all SSH 
implementations, not just all newmodes implementations.  This would need to 
be clear.

The working group would still need to decide if 3DES-CTR or AES128-CTR or 
both would receive this REQUIRED+ marking.

Russ

At 08:13 AM 9/8/2005, Jon Bright wrote:
>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" :-)

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Sep 2005 15:13:54 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> The working group would still need to decide if 3DES-CTR or
    Russ> AES128-CTR or both would receive this REQUIRED+ marking.

Russ, I would feel much more comfortable with the marking if it was
done in text rather than using should+.  Either solution is acceptable
but I would prefer the textual marking.  Would you be OK with that?

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 Sep 2005 15:20:15 -0400

Sam:

Yes, I am comfortable with the use of text to say the same thing.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Sep 2005 15:28:21 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Sam: Yes, I am comfortable with the use of text to say the
    Russ> same thing.

    Russ> Russ

OK.  Bill, do we have a consensus to decide on a direction for what
cipher we'll make mandatory to implement and to document that decision
in newmodes?

If so, do we have a consensus yet on what that direction is or do we
need to have more discussion on that?

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 09 Sep 2005 15:57:17 -0400

> cipher we'll make mandatory to implement and to document that decision

Yes, it looks that way.

> need to have more discussion on that?

I just reviewed this thread and the prior one on the same topic on the
specific question of aes vs 3des.  

By my count, 9 people have expressed an opinion leading one way or the
other; 6 were unambiguously in favor of aes128-ctr; one wants to wait
for hardware counter mode support to materialize but seems to be leaning
towards AES.  One prefers 3des now but expects a migration to aes
later.  One person supported either aes128-ctr or aes256-ctr.

Looks to me like we have rough consensus on aes128-ctr as opposed to
3des-ctr as a "SHOULD+" or "Most likely to replace 3des-cbc but not yet
REQUIRED".

My proposed edit is to extend the paragraph reading:

   The "aes128-ctr" method uses AES (the Advanced Encryption Standard,
   formerly Rijndael) with 128-bit keys [AES].  The block size is 16
   bytes.

with:

   At this time it appears likely that a future revision of this 
   specification will promote aes128-ctr to be REQUIRED; 
   implementation of this algorithm is very strongly encouraged.

							- Bill

						- Bill

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Sep 2005 16:06:01 -0400

> later.  One person supported either aes128-ctr or aes256-ctr.

Add me to the AES column.

>    implementation of this algorithm is very strongly encouraged.

s/this specification/the SSH transport protocol specification [SSH-TRANS]/

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 09 Sep 2005 16:14:08 -0400

On Fri, 2005-09-09 at 16:10, Russ Housley wrote:
> Bill:
> 
> I am not totally happy with this proposed text.  It could be interpreted to 
> mean an update to the newmodes document , but you really mean that a future 
> specification is likely to require aes128-ctr for all SSH implementations.
> 

How about we drop "revision of this", leaving:

       At this time it appears likely that a future
       specification will promote aes128-ctr to be REQUIRED;
       implementation of this algorithm is very strongly encouraged.

I think this resolves jhutz' concern as well.

					- Bill

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 Sep 2005 16:10:38 -0400

Bill:

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 Sep 2005 16:21:24 -0400

Bill:

I can live with this text or the text proposed by Jeff.

Russ

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Sep 2005 16:40:26 -0400

> I can live with this text or the text proposed by Jeff.

Me too

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 09 Sep 2005 16:41:55 -0400

> I can live with this text or the text proposed by Jeff.

I think we want the ability to amend the required/recommended algorithms
with a focussed document like draft-ietf-ipsec-ikev2-algorithms-05.txt

					- Bill

---

From: Ben Harris <[email-masked]>
Date: Sat, 10 Sep 2005 15:10:19 +0100

>       implementation of this algorithm is very strongly encouraged.

I like this.  It makes the future direction clear without committing us to a
particular route, and it doesn't introduce awkward concepts like
"implementing newmodes".

-- 
Ben Harris

---

From: der Mouse <[email-masked]>
Date: Sat, 10 Sep 2005 12:46:18 -0400 (EDT)

[Proposed wording for newmodes]
>>	At this time it appears likely that a future specification will
>>	promote aes128-ctr to be REQUIRED; implementation of this
>>	algorithm is very strongly encouraged.
[Ben Harris]
> I like this.  It makes the future direction clear without committing
> us to a particular route, and it doesn't introduce awkward concepts
> like "implementing newmodes".

"What he said."

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Anil Madhavapeddy <[email-masked]>
Date: Sun, 11 Sep 2005 01:42:45 +0100

>        implementation of this algorithm is very strongly encouraged.

Yes, I like this suggestion best.

Anil

---

From: Thor Simon <[email-masked]>
Date: Sun, 11 Sep 2005 18:47:36 -0400

> particular route, and it doesn't introduce awkward concepts like

I agree.

Thor

---

From: "Claudio Robles" <[email-masked]>
Date: Sun, 11 Sep 2005 22:03:22 -0400

Not sure if I can ask this question here....

  It is possible to use SCP under SSH2? and if this is the case, where can I 
find the SCP protocol?  I understand that the protocol is in fact, RCP 
protocol, but also I have not being able to find it....

  I have read all the drafts and found no mention to SCP.  I do understand 
that it was kind of replaced by SFTP, but I still imagine that it is 
possible to do a transfer with SCP, mainly because it does not require much 
from the client, just one command.

Thanks in advance.

Claudio Robles

---

From: Jon Bright <[email-masked]>
Date: Mon, 12 Sep 2005 10:31:32 +0200

>        implementation of this algorithm is very strongly encouraged.

Works for me.

---

From: Jon Bright <[email-masked]>
Date: Mon, 12 Sep 2005 10:37:14 +0200

Claudio Robles wrote:
> 
>  It is possible to use SCP under SSH2? 

Yes.

> and if this is the case, where can I find the SCP protocol?  

You pretty much need to read the source for scp.

>  I have read all the drafts and found no mention to SCP.  

The protocol never got standardised (at least, never got standardised as 
scp - and I don't believe it ever got standardised as rcp either).

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 12 Sep 2005 21:11:01 +1200

Jon Bright <[email-masked]>
>The protocol never got standardised (at least, never got standardised as scp
>- and I don't believe it ever got standardised as rcp either).

Yup, you need to find someone else's source and read it to reverse-engineer
the protocol details.  However before doing that, two questions:

1. Why do you need to run scp under SSHv2?
2. If there's really some need for this, why not tunnel rcp over SSH?

Peter.

---

From: Thor Simon <[email-masked]>
Date: Mon, 12 Sep 2005 13:02:32 -0400

> protocol, but also I have not being able to find it....

Unfortuantely, one of the longest-overdue documents from anyone to
anyone in this working group is my often-promised informational RFC
documenting the rcp protocol.

It's not hard to do, it's just mechanical work with the rcp source
code (the canonical version is the one in 4.4BSD-Lite2 tree -- what
one really wants is to describe that, then document the very slight
differences in behaviour of the other 4.3-derived code out there in
the wild).  If you are doing a from-scratch implementation and want
to produce such an RFC, please don't allow my failure to ever get
enough round tuits to stop you.

Thor

---

From: Thor Simon <[email-masked]>
Date: Mon, 12 Sep 2005 13:06:55 -0400

> 2. If there's really some need for this, why not tunnel rcp over SSH?

FreSSH did #2.  It worked fine.  Whether you call that "running scp
under SSHvWhatever" is largely immaterial -- after all, with the
command line arguments bashed appropriately, 4.4BSD 'rcp' will talk
perfectly happily to OpenSSH 'scp'; the protocol is really the same.

There are legitimate reasons to not implement sftp -- it's a pig (let us
leave aside whether it is a necessary pig or a useful pig; it is still a
pig).  There's nothing inherently wrong with rcp except that you have to
be careful about the server-side globbing -- but a small embedded
implementation would be entirely free to omit globbing entirely, and then
the problem disappears right along with it.  

It's unfortunate that rcp is not documented -- and largely my fault,
since I said I'd do it one of the first times this came up in the WG
but never produced the document.

Thor

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 12 Sep 2005 13:23:25 -0400

> but never produced the document.

It's not too late to correct this.  (Even if this WG is shut down for
being done, someone could still send in an Informational individual
submission documenting the scp and rcp protocol).

						- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 12 Sep 2005 13:55:04 -0400

Ok, based on the apparent outbreak of smooth consensus, we should move
forward with my revised edit, namely, to extend the paragraph reading:

with:

   At this time it appears likely that a future specification will
promote
   aes128-ctr to be REQUIRED; implementation of this algorithm is very
   strongly encouraged.

I assume this is something that can be dealt with using an RFC Editor
note, right?  Do you need anything else from the WG before moving
forward?

						- Bill

---

From: "Claudio Robles" <[email-masked]>
Date: Mon, 12 Sep 2005 20:01:55 -0400

Thanks a lot for all the answers, specially Sara.

  I do see that SCP could be used and take part of the market, since SFTP is 
a little big and continue growing.  Anybody knows of SFTP implementation 
(client or server) newer than version 4?

  I will take a look at OpenSSH to understand the details, in particular the 
time (second from when), modes(octal), and basename.

Thanks again.

Claudio Robles

----- Original Message ----- 
From: "Sara Golemon" <[email-masked]>
To: "Claudio Robles" <[email-masked]>
Sent: Monday, September 12, 2005 12:24 AM
Subject: Re: SCP under SSH2

> SCP is done over a "session"/"exec" channel (with the assumption that
> the "scp" command will be in the remote path.  Check OpenSSH's source
> for the specific conversation language.
>
> Generally for receiving files it's:
> exec: "scp -pf /path/to/file"
> C: \0    (Literally, send a null byte)
> S: T 99999 99999 99999 999999   (mtime.sec mtime.usec atime.sec 
> atime.usec)
> C: \0
> S: C 0999 99999999 SSSSS  (mode[octal] filelen basename)
> C: \0
> S: XXXXXXXXXXXXXXX   (File Data, <filelen> bytes)
>
> Sending is the same conversation with roles reversed
> exec: "scp -pt /path/to/file"
> S: \0    (Literally, send a null byte)
> C: T 99999 99999 99999 999999   (mtime.sec mtime.usec atime.sec 
> atime.usec)
> S: \0
> C: C 0999 99999999 SSSSSS  (mode[octal] filelen basename)
> S: \0
> C: XXXXXXXXXXXXXXX   (File Data, <filelen> bytes)
>
> In both cases, if the 'p' is ommitted from the options then
> mtime/atime is not sent.
>

---

From: Damien Miller <[email-masked]>
Date: Tue, 13 Sep 2005 11:12:45 +1000 (EST)

On Mon, 12 Sep 2005, Thor Simon wrote:

> pig).

I would say that the current drafts of sftp tend to the porcine, but the 
older ones are quite lean.

For example OpenSSH's sftp-server, which implements v.3 of the protocol, 
is under 30kb, and it could be shrunk if the buffer API and support code 
common with the rest of the implementation was linked into a shared 
library.

Actually, OpenSSH's scp binary is slightly larger:

[djm@fuyu djm]$ size /usr/libexec/sftp-server /usr/bin/scp
text    data    bss     dec     hex
23708   684     2436    26828   68cc    /usr/libexec/sftp-server
27750   752     896     29398   72d6    /usr/bin/scp

-d

---

From: "Claudio Robles" <[email-masked]>
Date: Mon, 12 Sep 2005 22:13:11 -0400

Sara,

  Yup, I was looking at the openssh source code and figure it out.  Being a 
little more specific, it seems that there is no blank space after the first 
letter, in "Tmtime.sec mtime.usec atime.sec, atime.usec\n", and in 
"Cpermission size name\n".

  Question, how do you transfer a file to/from an specific folder?

Thanks again.

Claudio

----- Original Message ----- 
From: "Sara Golemon" <[email-masked]>
To: "Claudio Robles" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 12, 2005 9:54 PM
Subject: Re: SCP under SSH2

> time: From the unix epoch (Jan 1, 1970 00:00:00 +0000)
> modes: What mode the received file has, or sent file should have (i.e.
> -rwxrwxrwx => 0777)
> basename: basename(/foo/bar/baz.ext) == baz.ext
>
> -Sara
>
> P.S. - Nothing wrong with echoing to list, it's what I meant to do but
> hit the wrong button.
>

---

From: Damien Miller <[email-masked]>
Date: Tue, 13 Sep 2005 19:24:30 +1000

Peter Gutmann wrote:
> Damien Miller <[email-masked]> writes:
> 
> 
> SFTP also exhibits the performance handbrake, whereas scp doesn't.  You have
> to do quite a bit of work (and the other side has to as well) to avoid
> performance penalties.

The "handbrake" is only effects naive implementations.

BTW "quite a bit of work" for OpenSSH was exactly:

  1 files changed, 227 insertions(+), 93 deletions(-)

for upload and download pipelining support. It would be less except for
the silly requirement of the protocol that the server be allowed to
reorder requests on a file handle.

Only the client has to implement this, the server doesn't need any extra
smarts at all (in fact, you can't even implement them there).

-d

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 Sep 2005 21:11:55 +1200

Peter.