Subject: A comment on certificate-based server authentication and multiple DNS names

From: [email-masked]
Date: Wed, 6 Sep 2000 09:15:44 +0000

I have a comment on current draft as it relates to certificate-based
server authentication.
As the protocol stands today, the combined diffie-hellman-group1-sha1
key-exchange and server authentication algorithms will purportedly extend
to cover certificate-based signature schemes. There is however a problem
when a single server host may respond to more than one DNS name. This
problem is analogous to the one in initial versions of the HTTP protocol,
which made it impossible to serve multiple domains from a single IP number.
  Now, it would be entirely possible to devise a new key exchange scheme,
which would carry the DNS name the client intends to connect to, in order
to allow the server host to select the corresponding private key and
certificate to respond with. However, it seems that it might be possible to
extend the current diffie-hellman-group1-sha1 in a backwards compatible
manner to include an optional string parameter in the DH_INIT packet:

  byte      SSH_MSG_KEXDH_INIT
  mpint     e
  string    server dns name (optional)

  Comments?

---

From: [email-masked] (Niels M�ller)
Date: 06 Sep 2000 13:34:50 +0200

[email-masked] writes:

> There is however a problem when a single server host may respond to
> more than one DNS name. This problem is analogous to the one in
> initial versions of the HTTP protocol, which made it impossible to
> serve multiple domains from a single IP number.

I don't see this as big problem; I don't think people usually do large
scale "virtual hosting" for ssh. There's no problem if you can assign
one ip-number for each name, and the reason people can't always do
that for http is that they have quite a large number of names for a
single machine say (a web hosting service with with 100+ customers).

>   string    server dns name (optional)

I prefer not adding complexity to security protocols. If one really
wants to do this, one should also consider whether or not the name
should be included in the definition exchange hash.

There's also a client-side way to solve the problem: Have an option to
the client that looks up a "canonical name" for the host (whatever
that means: following CNAMES in DNS, or performing reverse-lookup on
the ip-address of the target, or some such), and if it differs from
the hostname as written by the user, the client will

  (i) display the canonical name to the user, and
 (ii) use that name when verifying certificates.

/Niels

PS. Your mail looked quite anonymous, with a from address of
"[email-masked]" and no name or .signature. I can't say if that a
clinet.fi mailing-list problem, a Lotus Notes problem, or a local
oz.is configuration error?