Subject: latest drafts

From: der Mouse <[email-masked]>
Date: Sun, 20 Mar 2005 21:14:19 -0500 (EST)

I just finished reading over the latest set of drafts.  I seem to have
missed a set before the latest; all my comparisons were to two drafts
back (eg, userauth-27 is compared to userauth-25, not -26).  Here's the
latest round of things I notice.

userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he
message may consist of multiple lines", but gives no indication how
line breaks are to be encoded.  Most notably, it's not clear whether
CRLF or bare NL should be used, nor whether there are other
possibilities that implementations should be prepared for.  (Note that
transport-24's description of SSH_MSG_DEBUG explicitly says to use
CRLF.)

Various places speak of doing control character filtering as discussed
in [SSH-ARCH].  I've been unable to find the referenced discussion in
architecture-22.  Searching for "filter" returns no hits; searching for
"control" returns only false positives.  I even went so far as to read
the whole document through, and while I could have missed something, I
feel confident in saying that at the very least the discussion is
hidden excessively well.

architecture-22 section 8 says "which may be superceded in the future";
the word is actually spelled "superseded".

architecture-22 has a line
   the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of
which is missing a sentence-end period.

architecture-22 9.3.5 says that publickey makes no server security
assumptions.  But this is not quite true; a compromised server may be
able to use a publickey authentication attempt to play MitM to
authenticate to another host as if it held a public key it does not in
fact hold.  I'm not sure how feasible this is, because public-key
signatures are over data blobs including session-specific portions, but
it's certainly not obvious to me that it's impossible.

connect-25 6.10 has a message description with a "o" bullet for each
line; the rest of the message descriptions look different.

conenct-25 7.1 sez
   address or domain name and port to which the socket to be listened is
[page break]
   bound.
I'd prefer to see "is to be bound"; there also seems to be a "to"
missing after "listened".  (I'm not entirely sure I like to see
"socket" here, since there is no requirement that the TCP interface in
question be sockets.  I'm not sure this is worth fixing.)

Various specifications in transport-24 break rather badly if the cipher
in use has a block size that is less than 8 bytes but which does not
divide evenly into 8 bytes.  The spec for per-packet padding is perhaps
the most obvious, but by no means the only, such; I can go through and
extract a full list if desired.

/~\ 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: Ben Harris <[email-masked]>
Date: Mon, 21 Mar 2005 12:06:05 +0000

In article <[email-masked]> you write:
>architecture-22.

It looks like it got lost when the Security Considerations section was
rewritten in architecture-14 (2003-07-14).  Before that, it said:

   When displaying text, such as error or debug messages to the user,
   the client software SHOULD replace any control characters (except
   tab, carriage return and newline) with safe sequences to avoid
   attacks by sending terminal control characters.

>it's certainly not obvious to me that it's impossible.

The protocol is designed to make this kind of attack impossible.  publickey
signatures are over (amongst other things) the session ID.  For a server to
MITM a publickey authentication, it would have to get the session IDs for
the two connections to be the same, which would mean getting two hashes with
partially different inputs (since some input in each case is the other
side's KEXINIT cookie) to have the same output.  This is at least as hard as
finding a collision in the hash, which is assumed to be sufficiently
difficult.  If it isn't sufficiently difficult, you need a stronger exchange
hash.

>extract a full list if desired.

I think the simple answer is that you can't use such a cipher with SSH,
which seems fine to me.

-- 
Ben Harris

---

From: [email-masked] (Niels Möller)
Date: 21 Mar 2005 14:59:33 +0100

> it's certainly not obvious to me that it's impossible.

I agree it would be desirable to clarify this, as it's not crystal
clear what the MiTM can do and can't do in the scenario with no host
authentication, and publickey userauth.

> divide evenly into 8 bytes.

I think this is a non-issue. There's no exisitng block cipher in wide
use that have a block size that isn't a power of two, as far as I'm
aware. And block ciphers that are adopted in the future ought to have
a block size no smaller than 8 bytes, for the same reasons that AES
uses a larger block size.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 21 Mar 2005 07:22:17 -0800 (PST)

Hi,

> transport-24's description of SSH_MSG_DEBUG explicitly says to use

Suggestions from anyone?

> feel confident in saying that at the very least the discussion is

This text appeared in [ARCH]-11:

There were three paragraphs in the Security Considerations section.

This text appeared in [ARCH]-12:

There were 4 paragraphs then.  After that, the WG revised the Security
Considerations section so that the security considerations of all other
documents were incorporated into the Security Considerations section of
[ARCH].  Such text does not seem to appear in any of the IDs at this time.
Should it be restored in the general Security Considerations section like
the section on "Pseudo-Random Number Generation", or should it be restored
within a particular section (Transport, Connection, User Auth)?

> the word is actually spelled "superseded".

The spellchecker in kate doesn't object to it.  Nontheless, I'll change
it.

> which is missing a sentence-end period.

OK.

> it's certainly not obvious to me that it's impossible.

Does Ben's note cover this?

> line; the rest of the message descriptions look different.

Yuck.  I'll fix it.

> missing after "listened".

Which do you want;
   The 'address to bind' and 'port number to bind' specify the IP
   address or domain name and port to which the socket to be listened to
   is bound.  Some strings used for the 'address to bind' have
   special-case semantics.
-or-
   The 'address to bind' and 'port number to bind' specify the IP
   address or domain name and port to which the socket is to be bound.
   Some strings used for the 'address to bind' have special-case
   semantics.

> (I'm not entirely sure I like to see

If we can get some quick consensus we can probably squeeze it in.

> extract a full list if desired.

Does Ben's note address this?

Thanks,
Chris

---

From: der Mouse <[email-masked]>
Date: Mon, 21 Mar 2005 12:02:17 -0500 (EST)

>> assumptions.  But this is not quite true; a compromised server may
>> be able to use a publickey authentication attempt to play MitM to
>> authenticate to another host as if it held a public key it does not
>> in fact hold.

I must have been short of sleep when I wrote this.  What I had in mind
was authenticating via some other protocol, not via ssh, using the ssh
client connection as a public-key engine.  But of course the defenses
put in place to prevent MitM use this way for ssh also prevent its use
as a general-purpose signing engine - anything that allows an ssh
client connection to be used as a generic public-key engine will of
necessity work perfectly well to perform MitM attacks on ssh as well.

So please ignore that paragraph.

>> Various specifications in transport-24 break rather badly if the
>> cipher in use has a block size that is less than 8 bytes but which
>> does not divide evenly into 8 bytes.  [...]
> I think the simple answer is that you can't use such a cipher with
> SSH, which seems fine to me.

Yes, but I would prefer to see this stated explicitly.  Otherwise
someone reading it could wonder, as I did, "but what about, say, a
cipher with 7-byte blocks, how would I add that to my implementation?".
Or a cipher with a block size that's not a multiple of 8 bits.

Before you laugh too hard at the idea that such a cipher might exist,
note that DES has 7-byte keys (though they're normally stored as 8
bytes with 7 bits/byte, for hysterical raisins).  While keys != blocks,
it does indicate to me that there is nothing holy about powers of two.
I could imagine, for example, a cipher depending on number-theoretic
properties of 2^56 that 2^64 doesn't have.  (I'm thinking in particular
of the way IDEA dependens on 2^16+1 being prime, and the difficulty of
converting it to 32-bit basic blocks because 2^32+1 isn't.)

I'm perfectly satisfied with "you can't do that with ssh" as the
response; I just think it'd be good to see it stated explicitly.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Mon, 21 Mar 2005 12:22:32 -0500 (EST)

>> line breaks are to be encoded.
> Suggestions from anyone?

I'd argue for CRLF line breaks, largely for the sake of uniformity.
Maybe

	The message may consist of multiple lines, with line breaks
	indicated by CRLF pairs.

(Of course, implementations need to be prepared to have arbitrarily
nasty binary data thrown at them in such places - this gets into the
control character filtering topic.)

>> Various places speak of doing control character filtering as
>> discussed in [SSH-ARCH].  I've been unable to find the referenced
>> discussion in architecture-22.  [...]
> [...].  Such text does not seem to appear in any of the IDs at this
> time.  Should it be restored in the general Security Considerations
> section like the section on "Pseudo-Random Number Generation", or
> should it be restored within a particular section [...]?

I'd prefer to see it as a general security consideration, since it
applies anywhere where an implementation may try to print a string
received from the peer, and that's lots of places.  But as long as it's
easy to find from the table of contents, I'd be content.

>> architecture-22 section 8 says "which may be superceded in the
>> future"; the word is actually spelled "superseded".
> The spellchecker in kate doesn't object to it.  Nontheless, I'll
> change it.

Well, I wasn't sure.  Dictionary.com produces nothing when asked for
"superceded" and finds it when asked for "superseded", which provoked
my note.  Checking my own 2600-page paper dictionary now shows
"supercede  var of supersede"; it probably would be defensible to keep
it, but if a non-anglophone starts looking puzzling words up online, I
suspect the "supersede" version will make things easier.

>> assumptions.  [MitM concerns]

Yes (with my own realization), as noted in my reply to Ben.

>    Some strings used for the 'address to bind' have special-case

Between those two, I'd prefer the former - but see below.  It's
wordier, but, trying to get my head into the new-reader headspace, I
expect the latter to produce more of a "...socket? this is the first
I've heard of any socket!" response.  (Logically, the former should
too, but I think it will do so significantly less.)

>> (I'm not entirely sure I like to see "socket" here, since there is
>> no requirement that the TCP interface in question be sockets.  I'm
>> not sure this is worth fixing.)

Hmm.  How about this?

   The 'address to bind' and 'port number to bind' specify the IP
   address (or domain name) and port on which connections for
   forwarding are to be accepted.  Some strings used for 'address to
   bind' have special-case semantics.

(Note the added parens, which make it a little clearer that it's not
"(IP address) or (domain name and port)", but rather "(IP address or
domain name) and port".  I also dropped a "the" in the last sentence,
though I wouldn't object if you want to leave it present.)

>> cipher in use has [block-size properties].

Mostly.  See my list message in response to Ben's.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Jacob Nevins <[email-masked]>
Date: Mon, 21 Mar 2005 18:14:08 +0000

If we're considering changes to the drafts, I have a trivial typo in
draft-ietf-secsh-transport-24 sec 6.6 "Public Key Algorithms":

   The certificate part may have be a zero length string, but a public
   key is required.  [...]

should probably be

   The certificate part may be a zero length string, but a public
   key is required.  [...]

(remove "have")

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Mar 2005 14:43:33 -0500

> Or a cipher with a block size that's not a multiple of 8 bits.

I do not believe this comment is particularly timely.

The current versions of the documents are before the IESG again, up for
approval in their next concall (on Thursday, march 31st).  

Typographical errors can be corrected by the RFC editor, but it's really
the wrong time for substantive changes of this form.

Moreover, block ciphers with non-power-of-two blocksizes are, to the
best of my knowledge, not used anywhere of note.  And we already support
a very large number of ciphers in the spec (perhaps too many).

						- Bill

---

From: [email-masked] (Niels Möller)
Date: 22 Mar 2005 00:25:42 +0100

> I'd argue for CRLF line breaks, largely for the sake of uniformity.

I'd agree with this. I believe all places elsewhere in the protocol
where line breaks are specified, it's CRLF. (Although I haven't made
any full search for such places).

> received from the peer, and that's lots of places.

Except when channel data is directed to the terminal, in particular if
the channel is a session channel on which a pty request succeeded
(this is the common case where the client puts the local terminal into
raw mode, and wants to have it controlled by the remote end).

One might consider control character filtering on channels that (i)
are directed to a terminal, and (ii) for which the client haven't
requested a pty. But I doubt it's a good idea. It will be confusing if
"ssh host echo-some-control-chars" and "ssh host
echo-some-control-chars | cat" gives different results, just because
in the first case the stdout is a terminal, and in the second it
isn't.

/Niels

---

From: der Mouse <[email-masked]>
Date: Mon, 21 Mar 2005 23:06:06 -0500 (EST)

>>> [unusual cryptosystems incompatible with transport-24]
>> Yes, but I would prefer to see this stated explicitly.  [...]
> [I]t's really the wrong time for substantive changes of this form.

Ah well.  If it's believed more important to get these out this time
around than to "correct" minor "problems" (quotes because I'm not
totally convinced this really is a problem that needs correction), then
please, feel free to ignore this point.  Given what you say about the
timing, I suspect this is the case for this point.

> best of my knowledge, not used anywhere of note.

All the more reason to consider it not worth fixing. :)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Tue, 22 Mar 2005 05:14:29 -0500 (EST)

>> I'd prefer to see [control character filtering] as a general
>> security consideration, since it applies anywhere where an
>> implementation may try to print a string received from the peer, and
>> that's lots of places.
> [Except for channel data]

Well, yes; I guess I don't think of normal channel data traffic as "a
string received from the peer", though of course there's no reason it
can't be thought of that way.  I agree that control-character filtering
applied to normal data traffic would be Weird and Wrong.  (At least
absent explicit configuration that way, and that's a configuration
option I see no need for an implementation to provide.)

What channel data - or string data, for that matter - is directed to on
the client side should not, I think, matter, but that's a quality of
implementation issue, not something I think the WG should specify.

> requested a pty.  But I doubt it's a good idea.

Me too.  "ssh my-home-box cat term-stuff/$TERM/init-it" ought to do
what it looks as though it's doing, just like "ssh my-home-box"
followed once the prompt appears by "cat term-stuff/$TERM/init-it".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign