Re: latest drafts

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

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

>> architecture-22 9.3.5 says that publickey makes no server security
>> assumptions.  [MitM concerns]
> Does Ben's note cover this?

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

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

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.)
> If we can get some quick consensus we can probably squeeze it in.

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

>> Various specifications in transport-24 break rather badly if the
>> cipher in use has [block-size properties].
> Does Ben's note address this?

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

/~\ 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