Subject: New drafts (TODO)

From: Sami Lehtinen <[email-masked]>
Date: Tue, 17 Oct 2000 04:22:08 +0300 (EEST)

Here's the minutes and some other things I bundled with it. The items
marked with "%" are basically done. There are still issues open,
though. I compiled them to the end.

Please find the items, and my comments, below.

    Open issues/proposed resolutions:
    
    draft-ietf-secsh-architecture-05.txt
    %	dangling reference to ssh-agent draft
    		    - rip out until agent draft exists.
    %	anti-dns language in section 4.1
    		    - rip out section 4.1; dead code.
    
    draft-ietf-secsh-transport-07.txt
    %	eliminating redundant length fields	- just do it.
    %	add ssh-rsa key type			- just do it.
[done basically according to the spec I sent to the list earlier.]
    %	arcfour					- add cautionary text
    %	key stretching clamps entropy to hash size
    		    - ok as is given current threat models, but document as such
[cautionary text is in essence what Niels said here earlier]
    %	packet size fuzz factor
    		    - document 35000 as arbitrary value larger than
    		      uncompressed size
    %	secrecy of exchange hash
    		    - document that its best to keep it secret 
    %	dangling references to pkix, spki 
    		    - both are now rfcs; correct references.
    %       hmac-sha-96 => hmax-sha1-96
    %       HMAC key and digest length clarification
[again, as Neils proposed]
    %       aes and serpent algorithms
[it's AES]

    draft-ietf-secsh-userauth-07.txt
    	any certificate implementation experience?
    		    - none yet, but that's ok for now.
    
    draft-ietf-secsh-connect-07.txt		
    %	signal encoding
    		    - extend format, include optional string with 
    		      signal name w/o SIG prefix.
    		    SIGBUS -> "BUS"
[this is done as discussed in the WG meeting. Neils commented on this,
 but no one commented back. More thoughts on this?]
    %	need references to X11, POSIX drafts
    		    - just add them.
    %	ssh agent forwarding dangling references
    		    - remove for now until agent draft appears.

Still open:
draft-ietf-secsh-architecture-05.txt
    iana considerations section ok?
		    - waiting for answer from AD

draft-ietf-secsh-transport-07.txt
    optimistic algorithm negotiation	- discuss on list.

    Should concatenated string encoding specify length of each string?
		    (transport, section 6)
		    - [chair couldn't find context; will take to list]
    DH parameter selection clarification
		    - [chair couldn't find context; will take to list]

Comments, please. Especially for the issues still open.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 16 Oct 2000 23:34:00 -0400

> 		    - waiting for answer from AD

I just ping'ed the AD's.

				- Bill

---

From: [email-masked] (Niels M�ller)
Date: 18 Oct 2000 16:41:44 +0200

>  but no one commented back. More thoughts on this?]

Could someone explain the rational for the proposal? In general, I
think that it is nice to include both a machine-friendly field (signal
names, error codes, etc) and human-friendly ones in the same message.
But is the optional name intended to be machine-friendly (in which
case the old numeric field is redundant and should be obsoleted) or
human-friendly (in which case the "machine-friendly" field is still
broken, see below)?

The problem with the current spec on signals is that the signal number
field, which is intended to be machine-friendly, is broken. This is
because the numbers assigned even to standard signals is
implementation specific.

When changing the signal encoding, the primary goal must be to fix the
supposedly "machine-friendly" field; when that is done we can consider
adding a human-readable field as well.

As far as I can see, the change above doesn't solve the problem, and
it doesn't add much value. So I would prefer that we either

(1) leave the spec as is on this point,

(2) or implement a change that does solve the problem.

Alternative solutions could be to define "network signal numbers" as I
have proposed earlier, or replace the signal number with a symbolic
name. The latter approach has the advantage that non-standard signals
could be encodeed as "name@domain", using the same extension mechanism
as in the rest of the protocols, while the former approach offers some
backwards compatibility.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 18 Oct 2000 16:51:06 +0200

>     optimistic algorithm negotiation	- discuss on list.

I think this is the single biggest problem in the current set of spec
(the second is that all specified algorithm names should specify what
algorithms are involved, but the definitions of names like "spki" and
"openpgp" fail to do that).

For optimistic algorithm negotiation, I think the ones who want this
feature and have implemented it should be able to clearify exactly how
it is supposed to work. In particular, we need an algorithm that takes
two SSH_MSG_KEXINIT packets as input, and determines whether or not
any guesses in those messages should be considered "successful".

Without this, I think we should consider dropping that feature (i.e.
we specify that the first_kex_packet_follows field should always be
false in this version of the protocol, and leave the definition of the
behaviour when that field is true for the next version of the
protocol, or something like that).

BTW, what is our current schedule? From the IETF 48 minutes

: Schedule
: 
: Sep 00   Finalization of core drafts
: Oct 00   Last calls
: Oct 00   Submit core drafts to IESG
: Oct 00   Determine schedule for extensions
: Nov 00   Submit extension drafts for discussion
: Dec 00   Meet in SD
: Sep 01   Submit core drafts for publication as draft standard

we're trying to have the core drafts finished this month. But the
milestones at http://www.ietf.org/html.charters/secsh-charter.html are
not updated.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 18 Oct 2000 17:41:56 -0400

> Could someone explain the rational for the proposal? 

It's an attempt to avoid the need to create a canonical signal
numbering space.

> In general, I think that it is nice to include both a
> machine-friendly field (signal names, error codes, etc) and
> human-friendly ones in the same message.

The string name is not intended to be human-friendly.

> case the old numeric field is redundant and should be obsoleted) 

This was the intent; the old numeric field is left in place in the
encoding so as to not cause an interoperability problem with existing
implementations.

					- Bill

---

From: Markus Friedl <[email-masked]>
Date: Thu, 19 Oct 2000 10:42:46 +0200

> It's an attempt to avoid the need to create a canonical signal

this is a very good idea. but i think the signal numbers
should be dropped.

> [...]

i don't think this is necessary: secsh should not be bloated
by this kind of legacy applications, so the new message should
look like this:

	uint32    recipient channel
	string    "signal"
	boolean   FALSE
	strings   signal type

if you are talking to old implementations you can tell
from the message size that the signal is encoded with a "uint32"
instead of a string, but having a signal number without a
defined mapping of signal to number is pointless.

a part from this, adding a string to the signal message would
break old implementations if they are checking the size of
the message, so you have to deal with backward compatibility in
some different way (e.g. using the version strings, like many
implementations currenly do).

so either define a mapping of signals to numbers or switch to
the usage if strings only.

-markus

---

From: [email-masked] (Niels M�ller)
Date: 19 Oct 2000 10:59:18 +0200

> the usage if strings only.

I agree. The only reason to include both a (broken) number and a
string is to make it easier for an implementations to interoperate
both with implementations that follow the spec and those that follow
old drafts (i.e. all implementations that exist today).

However, as Markus points out,

1. We still don't get complete backwards compatibility, as current
implementations should consider extra junk in messages as protocol
errors, and

2. The level of backwards compatibility that can be achieved that way
can just as well be done by looking at the packet length.

Actually, there's one subtlety with (2): Signal number 0 (encoded
according to the current drafts) and the signal name "" (encoded
according to an improved spec using strings) will look exacltly the
same. But I don't think that is a problem: Both 0 and "" of
questionable usefulness, and if handled at all both should be treated
as some kind of "unspecified signal", and it doesn't matter if the
sending part thought it was sending a zero or an empty string. lsh
actually uses signal number 0, namely for signals that can't be mapped
to its "network signal numbers".

If we go for strings, should we specify a list of "standard" signals
and require extension syntax (signal@domain) for signals not in that
list?

/Niels

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 19 Oct 2000 11:14:22 -0600

> implementations currenly do).

I'd prefer to see us change the name of the request if we
change it's format at this late date.

This avoids all compatibility problems with the least
amount of fuss.

Old implementations should either ignore of fail the new
request (based on the boolean flag.)

New implementations seeking compatibility with old
implementations can send the new request, and if that
fails, send the old request, or just always send both.

But, the point is, I don't have to burden my
implementation with nasty cruft to detect whether the
packet is one format or another... I just add an
additional request type, which is pretty clean.

So I would suggest we remove "signal" from the draft
and replace it with "named-signal" or "signal2" ...
does anyone have a better name?

Thanks,

Joseph Galbraith
[email-masked]

---

From: Sami Lehtinen <[email-masked]>
Date: Thu, 19 Oct 2000 22:17:03 +0300 (EEST)

Joseph Galbraith, on October 19. 2000, wrote:
  : I'd prefer to see us change the name of the request if we
  : change it's format at this late date.
  : 
  : This avoids all compatibility problems with the least
  : amount of fuss.
  : 
  : Old implementations should either ignore of fail the new
  : request (based on the boolean flag.)
[...]
  : So I would suggest we remove "signal" from the draft
  : and replace it with "named-signal" or "signal2" ...
  : does anyone have a better name?

Somehow I don't like this. Yes, it may be clean in the implementation,
but inventing new names in place of the old doesn't sound nice,
IMHO. And remember, there is also "exit-signal". Should that be
"named-exit-signal" or "exit-signal2" in the new draft?

I think we should keep the old messages (and change the format), and
deal with the incompatibilities. Because no matter what we do with the
drafts at this point will lead to incompatibility with the old drafts
(and implementations).

---

From: [email-masked] (Niels M�ller)
Date: 25 Oct 2000 14:30:34 +0200

Tero Kivinen <[email-masked]> writes:

> Sami Lehtinen writes:
> I agree. Has anybody really implementing the "signal" request? I mean
> in addition to just ignore it if you see one? The "exit-signal" is
> propably implemented, but it is not used that much (the case where the
> the other end exited because of the it dumped core because if SIGBUS,
> should not happen that often :-), and think we can just change the
> format and be done with it.

I agree too. (And I haven't implemented "signal"). 

> I would say we just change the number to string and define that it can
> have "standard" signal names (listed in the draft), or it can have
> [email-masked] type of signals.

I think the latter part is overspecification. It's better to say that
the string should either be a "standard" signal name (listed), or a
signal@domain for locally defined or extended signals.

If you want to encode the system type into the domain, you could say
that you intend to use some *particular* domains for that, for
instance by naming signals like

  "[email-masked]"
  "name@`config.guess |sed s/./-/`.hosttype-by-config-guess.hut.fi"

But it seems very unnecessary to me to mandate that structure on *all*
domains that might be used. That's contrary to the idea of using
hierarchical domain names as namespaces, as it attaches a meaning to
the *first* component of the domain, independent of the latter
components which represents parents in the dns tree.

If I want to support some signals that exists on several systems but
under different names, I'd like to use a clean "@domain" namespace for
assigning machine-independent names to those signals. A required
hosttype component will be in the way.

/Niels

---

From: Markus Friedl <[email-masked]>
Date: Wed, 25 Oct 2000 17:01:51 +0200

On Wed, Oct 25, 2000 at 05:01:03PM +0300, Tero Kivinen wrote:
> Anyways this is not a very important issue, and I think we can just
> ignore this whole issue as obscure feature not really needed...

so, why not drop signals from the spec?

if it's not really needed it should not be in the protocol.

-markus

---

From: [email-masked] (Niels M�ller)
Date: 25 Oct 2000 17:40:21 +0200

> if it's not really needed it should not be in the protocol.

I think something like exit-signal is needed; clients should have some
way to find out how a remote process died. This is particularly
important if you run a program with more than two valid exit codes
(otherwise one could just send an exit-status with any non-zero status
code if a process crashes).

So the alternative to keeping exit-signal is to add something to
exit-status message to distinguish normal and abnormal process
termination. I think fixing the signal encoding is a smaller change
than extending the exit-status message.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 25 Oct 2000 17:31:10 +0200

Tero Kivinen <[email-masked]> writes:

> > domains that might be used.
> 
> I think my previous email I said SHOULD. If I accidently said MUST,
> then that was my error...

I think even a SHOULD is too strong.

> > That's contrary to the idea of using hierarchical domain names as
> > namespaces, as it attaches a meaning to the *first* component of
> > the domain, independent of the latter components which represents
> > parents in the dns tree.
> 
> Not really. The idea is that two implementations can map also the
> unstandard signal names between themself on the same architecture.
> Lets say the implementation 1 uses the *.foo.com domain for all its
> privately own information. The implementation 2 uses the *.zappa.net
> domain.

If they want to use the same encoding, they should either agree on a
common namespace to use, or keep a list of domains known to use that
encoding. I'm objecting to the idea that one should try to interpret
names under an unknown domain. I.e. if one doesn't know the "foo.com"
domain, one shouldn't try to guess what names like
"[email-masked] means.

I want to be able to assign names under @my.domain any way I see fit,
without having to having to worry that some other implementation that
doesn't know anything about what conventions I use may try to guess.
If I implement a signal "[email-masked]", which performs something
useful for some ssh server under some circumstances, I want my clients
to be able to send that signal safely, knowing that any server that
haven't implemented that feature will safely ignore it.

> You can do it, but that is going to be hard. The signal names are not
> related to the implementations, they are related to the architecture
> where the implementation is executed. Somebody might compile the
> implementation on environment that you have never heard of and there
> might be new signal TEMP (temperature alert) that is mapped to number
> 42.

I wouldn't call the signal "[email-masked]", I'd rather use
"[email-masked]". And similarly for
temporarily-suspended, time-memory-integral-limit-exceeded, etc. Names
for nonstandard signals will have to be more verbose.

> ignore this whole issue as obscure feature not really needed...

I would prefer that the spec not recommend applying the encoding
conventions you propose to random domains. It's fine to mention one or
a few domains that does use the encoding. And if people want to do
this (I agree that it could be useful), the spec could spell out the
encoding details so that it will really interoperate.

But for now I think it would be fine to just say that we use the same
namespace mechanism for non-standard signal names as for all other
names in the protocols.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 26 Oct 2000 15:47:30 +0200

Tero Kivinen <[email-masked]> writes:

> You can do that. SHOULD does not prevent you doing that. It just says
> that there might be reason to do it otherwise.

I can't do that if we recommend that the other implementations try to
guess the meaning of names in random namespaces, including mine.

> So we create @xxx.config.guess domain that will be used for those
> systems that automatically detect unknown signals at the configure
> time, and the xxx is going to be the output of the config.guess for
> the system. 

That's fine with me. You also have to specify the details (like what
to do when config.guess outputs a name with characters like '.' that
are not allowed in a dns label).

/Niels