Subject: Re: agenda items..

From: Markus Friedl <[email-masked]>
Date: Sun, 3 Dec 2000 12:43:52 +0100

On Thu, Nov 30, 2000 at 04:11:05PM -0500, Bill Sommerfeld wrote:
> I expect that we'll spend most of the time discussing the core drafts.

i just read the drafts, in draft-ietf-secsh-connect-08.txt

  4.10.  Returning Exit Status

  [...]

  Additional signal names MAY be sent in the format "sig-name@xyz", where
  `sig-name' and `xyz' may be anything a particular implementor wants
  (except the `@' sign). However, it is suggested that if a `configure'
  script is used, the non-standard signal names it finds be encoded as
  "[email-masked]", where `SIG' is the signal name without the "SIG"
  prefix, and `xyz' be the host type, as determined by `config.guess'.

should the standard speculate about details of specific implementations
of certain configure scripts? why talk about 'config.guess'? why not
remove this?

-markus

---

From: Sami Lehtinen <[email-masked]>
Date: Sun, 3 Dec 2000 18:06:27 +0200 (EET)

Markus Friedl, on December 3. 2000, wrote:
  : On Thu, Nov 30, 2000 at 04:11:05PM -0500, Bill Sommerfeld wrote:
  : > I expect that we'll spend most of the time discussing the core drafts.
  : 
  : i just read the drafts, in draft-ietf-secsh-connect-08.txt
  : 
  :   4.10.  Returning Exit Status
  : 
  :   [...]
  : 
  :   Additional signal names MAY be sent in the format "sig-name@xyz", where
  :   `sig-name' and `xyz' may be anything a particular implementor wants
  :   (except the `@' sign). However, it is suggested that if a `configure'
  :   script is used, the non-standard signal names it finds be encoded as
  :   "[email-masked]", where `SIG' is the signal name without the "SIG"
  :   prefix, and `xyz' be the host type, as determined by `config.guess'.
  : 
  : 
  : should the standard speculate about details of specific implementations
  : of certain configure scripts? why talk about 'config.guess'? why not
  : remove this?

It is a suggestion. It is not even a SHOULD.

Tero and Niels had a dialogue about signals on this list, and nobody
commented (for or against) on that. I decided to put the results of
that dialogue to good use.

The `config.guess' is part of the autoconf package, and it is supposed
to be used by configure scripts. AFAIK, it is not going anywhere.

-- 
[[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: RJ Atkinson <[email-masked]>
Date: Sun, 03 Dec 2000 11:57:45 -0500

Markus,

        Implementation notes are legitimate for an RFC.
If consensus wer that they are distracting in the main
body, they could always be moved to an Appendix or
some such.

        For my part, I find that RFCs with more implementation
hints tend to have more interoperability than those with
fewer hints.

        On the specific topic below, it would be nice if
a clear and precise mapping of POSIX.1 signals with the 
SSH signals would get documented, by the way.

At 06:43 03/12/00, Markus Friedl wrote:
>should the standard speculate about details of specific implementations of certain configure scripts? 

        It is certainly legitimate to do so in an IETF RFC.

>why talk about 'config.guess'? why not remove this?

        More implementation hints are better.  Though perhaps
an implementation hint should be more clearly marked as
not normative.

Ran

---

From: [email-masked] (Niels M�ller)
Date: 03 Dec 2000 19:13:20 +0100

Bill Sommerfeld <[email-masked]> writes:

> Folks who have something they want on the agenda should send requests
> to me.  Thanks.

I'm afraid I'll not be able to attend.

But I think the most serious problem with the current (transport)
draft is the unclear specification of the "algorithm guess" feature. 

The first paragraph of section 5 says that "all" algorithms have to be
gussed right, or an implementation MUST ignore any optimistically sent
key exchange packet (which seems bogus, as the algorithms for bulk
encryption or compression are clearly irrelevant to key exchange)
while section 5.1, describing the kex_algorithms field, seems to imply
that a guess is considered successful iff the advertised key-exchange
methods match (which also seems bad, as encryption/signature
capabilities of the hostkey algorithms also have to be taken into
account).

I hope you can sort that out (or else, the first version spec should
probably discourage use of that feature).

The second most serious problem is that the algorithm names openpgp,
x509v3 and spki are defined, even though those definitions doesn't
match the requirements (section 4.6) on a public-key algorithm name
(more precisely, an algorithm name, by itself, should provide
information about the algorithms used (rsa/dsa etc), key usage). Both
"x509v3" and "spki" are ambiguous (I'm not sure about openpgp, but I
suspect that is just as bad): they only provide information about the
*encoding* of keys and certificates. (What is *needed* from an
algorithm name is actually different for host keys and user keys, but
unless the spec spell out that distinction, the most harsh
requirements (that apply primarily for host keys) must be applied to
all public-key algorithm names).

This second problem is in some ways more fundamental, but perhaps less
urgent to solve as not many use the other formats (lsh uses spki
formats, but with no real certificate support yet. Nobody else uses
spki formats for secsh as far as I know)

/Niels

---

From: Sami Lehtinen <[email-masked]>
Date: Sun, 3 Dec 2000 21:39:36 +0200 (EET)

RJ Atkinson, on December 3. 2000, wrote:
  :         On the specific topic below, it would be nice if
  : a clear and precise mapping of POSIX.1 signals with the 
  : SSH signals would get documented, by the way.

The signal names documented in "exit-signal" (and used in the same way
in "signal") are the POSIX.1 signals, without the "SIG" prefix.

Was this what you meant?

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 4 Dec 2000 18:06:14 -0700

> probably discourage use of that feature).

I too would like to sorted this out; this seems one of the
biggest remaining holes in the draft.

I'm not sure anyone outside of the SSH Communications
people is actually using this feature...

Perhaps the SSH Communications people could comment on when
their software actually retransmits the first key exchange
packet, and that would give us a starting point for clarifying
this language?

> spki formats for secsh as far as I know)

Again, I am very eager to see this problem resolved.

Do we just need to change the names... for example,
x509v3-dsa and x509v3-rsa?

Has there been a solution to this problem proposed on the
list?

Joseph

---

From: [email-masked] (Niels M�ller)
Date: 05 Dec 2000 16:47:14 +0100

> x509v3-dsa and x509v3-rsa?

That's a start, but I'm not sure it is enough. Consider a server that
has a certificate chain for its hostkey, and the chain includes both
rsa and dsa signatures.

> Has there been a solution to this problem proposed on the

Not that I recall.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 06 Dec 2000 16:36:59 -0500

> encryption or compression are clearly irrelevant to key exchange)

When this was discussed in the working group meeting, the consensus in
the room seemed to be that while matching all algorithms may be
excessively conservative, excessive conservatism in this case was not
a problem from the point of view of interoperability.

> methods match

I don't get that implication from section 5.1; however, some
clarification may be in order.

> (which also seems bad, as encryption/signature capabilities of the
> hostkey algorithms also have to be taken into account).

right, but the hostkey algorithms are also included in the
SSH_MSG_KEXINIT message; since all algorithms have to match (as is
stated in section 5) this ceases to be a problem.

> information about the algorithms used (rsa/dsa etc), key usage). 

This was raised as an issue last time around.  my personal take on the
situation [wg chair hat off] is that the current transport protocol
draft conflates public key formats and certificate formats, and that
before certificates of any format (pgp, spki, x.509) can be used with
ssh, these need to be disentangled.

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 06 Dec 2000 16:40:37 -0500

> I would say that if you support x509v3, then you must support both DSA 
> and RSA signatures inside the certificates. 

This is problematic from the point of view of someone looking to do a
reduced-size implementation (think embedded systems here) supporting
either RSA or DSA but not both.

	x509v3-sign-rsa
	x509v3-sign-dss
	x509v3-sign-...

					- Bill

---

From: [email-masked] (Niels M�ller)
Date: 07 Dec 2000 00:25:16 +0100

Tero Kivinen <[email-masked]> writes:

> and RSA signatures inside the certificates. So I would change the

That would be an improvement, but I don't think it is a solution. Do
you want to make an analogous change to spki (I am personally more
interseted n spki certificates than x509)? Neither x509 nor spki make
any strong requirements on which algorithms can or cannot be used, as
far as I remember.

For a start, it makes it impossible for an implementation to support
x509, RSA only (which kind of makes sense to me, as most x509
certificates seen use only RSA, RSA is generally easier, and it's no
longer patented).

And it doesn't scale well when new signature algorithms are
introduced. Consider an implementation that supports x509 using some
elliptic curve algorithm (and perhaps also one, but not both, of RSA
and DSA). What should that implementation advertise?

And at last, you don't say anything about certificates that certify an
encryption-capable key. The spec makes it clear that such properties
should be evident from the _name_, and they are not.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 07 Dec 2000 00:58:22 +0100

> a problem from the point of view of interoperability.

In any case, the conditions need to be clarified. And I'd prefer
saying that the test for the success of a guess includes only the
key_exchange and server_host_key parts, not including bulk encryption
algorithms, compression algorithms or language tags...

Which of these are intended to be referred to by "all" is not clear
from the spec, and if implementations uses different success-criteria,
that breaks interoperability.

> clarification may be in order.

Try ripping it a just a little out of context,

:     kex_algorithms
: 	Key exchange algorithms were defined above.  The first algorithm
: 	MUST be the preferred (and guessed) algorithm.  If both sides make
: 	the same guess, that algorithm MUST be used. Otherwise, the

> ssh, these need to be disentangled.

Do you think that can be fixed without either breaking backwards
compatibility and architecture, or doing something ugly?

I think there are three components:

* The kind of certificate (implying the rules for validation, encoding
  rules for certificates related objects),

* The algorithms that has to be supported to process the
  certificate(s) (advertised by the sending side), and available
  algorithms (advertised by the receiving side).

* The algorithm and properties (e.g. key usage) of the certified key.

At least the first two could be represented using algorithm names like
"spki:dsa;rsa", without breaking too much. But it gets a little messy
to fit all three into an identifier, in particular if one ever wants to be
able to introduce new properties besides signature/encryption
capability.

/Niels

---

From: Markus Friedl <[email-masked]>
Date: Mon, 11 Dec 2000 22:00:24 +0100

re: draft-ietf-secsh-transport-08.txt

defining twofish-cbc with 256 bit keys is a bad idea.  it should
really be called
	twofish{128,192,256}-cbc
similar to AES.  the current keyexchange definitions do not provide
256 bits of entrophy, since the sha1 output from diffie-hellman-group1-sha1
is only 160 bits.

---

From: Darren J Moffat <[email-masked]>
Date: Mon, 11 Dec 2000 06:38:13 -0800

> 256 bits of entrophy, since the sha1 output from diffie-hellman-group1-sha1

I'd like to back this up.  It is important for US Export compliance to
be able to "cap" algorithms at a certain key lengths.  All algorithm
names
thus need to have the keylength included so that US domestic and
international
clients have a chance to interoperate.  eg.  A US domestic ssh client
may
support twofish-256-cbc but it is connecting to an ssh server that only
supports twofish-128-cbc because it is located outside the US.

Currently blowfish is listed in the draft only for 128, I suggest that
the name be blowfish-128-cbc similarly for any other algorithms.

--
Darren J Moffat

---

From: Markus Friedl <[email-masked]>
Date: Tue, 12 Dec 2000 08:41:49 +0100

On Tue, Dec 12, 2000 at 02:56:33AM +0200, Tero Kivinen wrote:
> And the standard 1024 bit Diffie-Hellman group only gives you about 80 
> bits of entrophy.

so you agree that
	draft-provos-secsh-dh-group-exchange-00.txt
should be considered?

-markus

---

From: Mika Kojo <[email-masked]>
Date: Tue, 12 Dec 2000 20:09:29 +0200 (EET)

Hello all,

I have few questions and comments on

   draft-provos-secsh-dh-group-exchange-00.txt.

There it reads:

      Either side MUST NOT send or accept e or f values that are not in the
      range [1, p-1]. If this condition is violated, the key exchange
      fails.

My question is whether [1, p-1] is justified for the protocol. I would
understand (1, p-1), but perhaps someone can shortly explain the need
for also 1 and p-1. 

Also why does these protocols insist that server should select y from
(0,q) when most other protocols simply take it from (1,q)?

The suggested protocol makes the client choose the lower bound for the
subgroup. However, there is no need to include this information to the
hash as it contains already p (and g). It should be specified that the
client is required to check that p is of sufficient size.

In the specification it reads that:

   If the order is p - 1, then the exponents generate all possible
   public-values, evenly distributed throughout the range of the
   modulus p, without cycling through a smaller subset.

I suspect "evenly distributed" would read better as "uniformly
distributed". Although it is true that g^x is uniformly distributed,
it is clearly not true that (g^x)^y would be, for fixed x, if g is of
order p-1. 

Although having safe primes is fine, I think that some additional
benefit would be achieved from use of q << p. This would satisfy still
the "uniformly distributed" requirement (in the subgroup) and obtain
additional efficiency. Most implementations sacrifice the uniform
distribution for speed, and in a sense this is unfortunate.

-- 
Mika Kojo
SSH Communications Security Corp