Subject: Feedback from uri list

From: Steve Suehring <[email-masked]>
Date: Fri, 9 Oct 2009 15:37:14 -0500

Hello,

I also submitted the pre-draft copy of the ssh uri proposal to the uri 
mailing lists and received some feedback, one of which I want to get 
back in front of this group.

The reviewer suggested using this format for the fingerprint:

       ssh://[email-masked]?fingerprint=ssh-dss-c1-b1-30-29-d7-
           b8-de-6c-97-77-10-d7-46-41-63-87

Whereas the previous drafts had used this format:

        ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-
             [email-masked]

The suggestion seems to make sense to me but I'm unsure if there are 
implementations that have adopted the original format and what the 
implications of moving forward with a draft using the suggested format 
would be.  Can anyone shed light on whether they have or know of an 
implementation using the fingerprint in the 'userinfo' section?

Steve

---

From: Jacob Nevins <[email-masked]>
Date: Sun, 11 Oct 2009 21:53:17 +0100

Steve Suehring writes:
> The suggestion seems to make sense to me

Me too. I don't know the rationale from the URI people, but the host key
fingerprint isn't a property of the user, so doesn't really belong in
userinfo.

(From the list archives, I think it was originally moved into userinfo
from a position similar to the proposal because the syntax originally
used -- delimited with a semicolon -- was illegal in URIs, or something
like that. Using a question mark sidesteps this, I think.)

> but I'm unsure if there are implementations that have adopted the
> original format and what the implications of moving forward with a
> draft using the suggested format would be.  Can anyone shed light on
> whether they have or know of an implementation using the fingerprint
> in the 'userinfo' section?

I'd also be interested to know whether there are any extant
implementations; I don't know of any, and a quick Google didn't turn any
up.

The reason for my interest is a theoretical ambiguity in the
"host-key-alg-fingerprint" parameter format, which I alluded to in my
other post (but now wish I hadn't, for reasons that will become clear).

The octets within the fingerprint are delimited by hyphens, as is the
separation between algorithm name and fingerprint. I've just realised
that this isn't ambiguous with fingerprints as currently defined by
RFC4716, since there are exactly 16 octets and you can thus work
backwards to get the algorithm name.

To attempt to salvage this post :) I'll bring up the possibility of a
different number of octets being used to represent the fingerprint in
future, for instance as a result of switching to a hash other than MD5.
Even then it's hard to come up with examples where the ambiguity would
matter (especially as such a representation would presumably either only
be usable with new host-key-algs, or would require definition of new
connection parameters).

Convenient characters other than hyphen for delimiting/separation appear
to be the other "unreserved" URI characters -- "." / "_" / "~". (All of
these are valid in host key algorithm names.)

In any case, I think none of this would be worth disturbing existing
implementations for.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 12 Oct 2009 21:05:52 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jacob Nevins
> Sent: Sunday, October 11, 2009 1:53 PM
> To: [email-masked]
> Subject: Re: Feedback from uri list
> 
> Steve Suehring writes:
> Me too. I don't know the rationale from the URI people, but 
> the host key fingerprint isn't a property of the user, so 
> doesn't really belong in userinfo.
> 
> (From the list archives, I think it was originally moved into 
> userinfo from a position similar to the proposal because the 
> syntax originally used -- delimited with a semicolon -- was 
> illegal in URIs, or something like that. Using a question 
> mark sidesteps this, I think.)
> 
[Joe] I don't remember why we went with this format, but I agree that
the fingerprint does not belong with user info.  The suggested format
looks OK to me.  

> implementations; I don't know of any, and a quick Google 
> didn't turn any up.
> 
> "host-key-alg-fingerprint" parameter format, which I alluded 
> to in my other post (but now wish I hadn't, for reasons that 
> will become clear).
> 
> The octets within the fingerprint are delimited by hyphens, 
> as is the separation between algorithm name and fingerprint. 
> I've just realised that this isn't ambiguous with 
> fingerprints as currently defined by RFC4716, since there are 
> exactly 16 octets and you can thus work backwards to get the 
> algorithm name.
> 
> To attempt to salvage this post :) I'll bring up the 
> possibility of a different number of octets being used to 
> represent the fingerprint in future, for instance as a result 
> of switching to a hash other than MD5.
> Even then it's hard to come up with examples where the 
> ambiguity would matter (especially as such a representation 
> would presumably either only be usable with new 
> host-key-algs, or would require definition of new connection 
> parameters).
> 
> Convenient characters other than hyphen for 
> delimiting/separation appear to be the other "unreserved" URI 
> characters -- "." / "_" / "~". (All of these are valid in 
> host key algorithm names.)
> 
> In any case, I think none of this would be worth disturbing 
> existing implementations for.

[Joe] I don't know of any existing implementations, however this thread
does bring out some issues.  In addition to the one you raised its not
clear that we could move to a hash other than MD5.  This is hard coded
in RFC 4716.  While this probably isn't a problem know it could be a
weakness in the future.  I'm pretty sure I've run into SSH
implementations that display SHA-1 fingerprints as well.   I suppose we
could have an encoding that was something like
host-key-alg-hash-alg-fingerprint.  In order to parse this you would
have to have a list of known host-key-algs and hash-algs.  If you didn't
recognize them then you would ignore the finger print.  There still is a
problem in that there could be some ambiguity where host-key-algs or
hash-algs derive from a common prefix.  At this point, I'm not sure what
to do here or how big of a problem this is.

---

From: [email-masked] (Niels Möller)
Date: Tue, 13 Oct 2009 15:22:38 +0200

> these are valid in host key algorithm names.)

Hmm. The draft says

      fingerprint format is
      [RFC4716].  For use in a URI, the fingerprint shall use a single 
      dash "-" as a separator instead of the colon ":" as described in
      [RFC4716].

If we can't use the separator specified in RFC4716, maybe its simpler
to just drop the separator rather than replace it? I.e.,

  ssh://user;fingerprint=[email-masked]

or

  ssh://[email-masked]?fingerprint=ssh-dss-c1b13029d7b8de6c977710d746416387

That would eliminate the syntactic ambiguity: whatever comes after the
last dash is the actual fingerprint, and whatever comes before is the
host key algorithm. Maybe not so human-friendly, though. But it should
work fine with . as fingerprint separator too.

One could also do it like

  ssh://[email-masked]?hostkey-alg=ssh-dss&fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87

but to support multiple fingerprints would would need to make the
ordering of parameters significant. I think it makes sense to reuse
the URI-way of separating different items, although I haven't thought
deeply about the issues.

Regardss,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Tue, 13 Oct 2009 15:26:39 +0200

"Joseph Salowey (jsalowey)" <[email-masked]> writes:

> In addition to the one you raised its not
> host-key-alg-hash-alg-fingerprint.

To upgrade from md5, I think the simplest way is to use a new
parameter name, like

  ssh://[email-masked]?fingerprint-sha1=ssh-dss-xxxx...xx

or

  ssh://[email-masked]?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx

whenever there's a proper spec for non-md5 fingerprints.

/Niels

---

From: Steve Suehring <[email-masked]>
Date: Wed, 14 Oct 2009 08:23:24 -0500

>   ssh://[email-masked]?fingerprint-hash-of-the-day=ssh-dss-xxxx...xx

What about another parameter, like:

ssh://[email-masked]?alg=md5&fingerprint=b1-e1-...

If alg is not present, MD5 MUST be used.  If alg is not understood (?)

Steve

---

From: "t.petch" <[email-masked]>
Date: Wed, 14 Oct 2009 14:12:18 +0200

----- Original Message -----
From: "Niels Möller" <[email-masked]>
Sent: Tuesday, October 13, 2009 3:26 PM

> whenever there's a proper spec for non-md5 fingerprints.

syslog had a need for fingerprints, albeit not as part of a URI, and used
the registry from RFC4572 for the hash algorithm.  syslog mandates sha-1
and the fingerprint has the format
    sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
upper case, colon separated.

Tom Petch

---

From: [email-masked] (Niels Möller)
Date: Wed, 14 Oct 2009 16:30:16 +0200

> ssh://[email-masked]?alg=md5&fingerprint=b1-e1-...

Could work, but I think fingerprint-md5 is simpler, and hence a
somewhat better choice.

If you want a separate parameter, keep in mind that

(i) it should probably be "fingerprint-alg", since you might want to
    specify an algorithm for other purposes.

(ii) if you want to support multiple fingerprints, you must specify
     that the order of the parameters is significant (whether or not
     that would deviate from URI conventions, I don't know. A repeated
     "fingerprint" parameter might also be non-koscher?).

/Niels

---

From: Terra Frost <[email-masked]>
Date: Wed, 14 Oct 2009 11:49:06 -0500

> fingerprint isn't a property of the user, so doesn't really belong in

The username, however, is a property of the user and it's not in userinfo.

What about something like this?:

ssh://[email-masked]?user=user

It's not without precedent, either.  When you log into a website, you
generally do so via an HTML form that submits stuff via POST.  The
above is in a format more analogous to GET, but still...  GET and POST
are pretty similar, as is, anyway.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 15 Oct 2009 04:31:04 -0400

> ssh://[email-masked]?fingerprint=ssh-dss-c1b13029d7b8de6c977710d746416387

I like that proposal because I think the separator characters in the 
fingerprint (such as '-' or ':') are superfluous, unnecessary, 
redundant. :)

I suggest the following variation - wrapped for clarity:

ssh://[email-masked]
  ?fp-md5-ssh-dss=c1b13029d7b8de6c977710d746416387
  &fp-sha1-ssh-rsa=0c112b31435062798d7b8de6c977710d746416387

Nice, short, and to the point.

Everything after "fp-" and before the second dash is the hash algorithm. 
Everything after the second dash is the host key algorithm.

This allows more freedom for the host key algorithm than the hash. I 
expect it's more likely that important use cases will require unusual 
host key algorithms (e.g. certificates, eliptic curves) than that they 
will require unexpected hashes.

I suppose you need the "ssh-dss" or "ssh-rsa" part so that you can pick 
the right algorithm(s) for host key negotiation.

denis

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Oct 2009 09:24:03 -0400

> Everything after "fp-" and before the second dash is the hash algorithm.

This presupposes that hash algorithm names contain no dashes.

> will require unexpected hashes.

It's not about "unusual" or "unexpected".  An algorithm name is not 
"unusual" because it contains dashes; in fact, every cryptographic 
algorithm name defined in RFC5052 includes at least one dash, except the 
"none" algorithms.

> the right algorithm(s) for host key negotiation.

No, you don't.  SSH has algorithm negotiation; a client doesn't need to be 
told up front what algorithms to use.  However, you might want it to aid in 
matching the offered host key to one of several fingerprints on hand.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 15 Oct 2009 15:15:25 -0400

> This presupposes that hash algorithm names contain no dashes.

No, it presupposes that new hash algorithms come around infrequently 
enough that people can settle on names for them that don't contain 
dashes.

> > I suppose you need the "ssh-dss" or "ssh-rsa" part
> > so that you can pick the right algorithm(s) for host
> > key negotiation.
> No, you don't.  SSH has algorithm negotiation;
> a client doesn't need to be told up front what
> algorithms to use.

Yes, you do. SSH has algorithm negotiation. The SSH URL specifies a 
fingerprint of one or more of the server's public keys. If the client 
doesn't know in advance the algorithm of the host key for which the 
fingerprint is provided, the client might negotiate the wrong host key 
algorithm, and end up with a different key that is a mismatch to the one 
for which the client has the fingerprint.

If you are okay restrict yourself to only ONE hash and host key 
algorithm combination per SSH URL, then a syntax such as the following 
would be cleanest:

ssh://[email-masked]
  ?fp=c1b13029d7b8de6c977710d746416387
  &hash=md5
  &keyalg=ssh-dss

But this restricts you as explained above.

If you want it possible for an SSH URI to contain an unrestricted 
combination of fingerprints for various host key algorithms and using 
various hash functions, then you need something like I proposed before:

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Thu, 15 Oct 2009 15:24:50 -0400

I wrote:

> No, it presupposes that new hash algorithms come around
> infrequently enough that people can settle on names for
> them that don't contain dashes.

To go further - you could just make it a rule that any algorithm names 
that contain dashes get the dashes stripped.

I don't know of any case where a dash contributes to the uniqueness of 
an algorithm name.

Thus my previous example becomes:

ssh://[email-masked]
  ?fp-md5-sshdss=c1b13029d7b8de6c977710d746416387
  &fp-sha1-sshrsa=0c112b31435062798d7b8de6c977710d746416387

There we go, nice and dandy. :)

---

From: [email-masked] (Niels Möller)
Date: Thu, 15 Oct 2009 22:03:49 +0200

> that contain dashes get the dashes stripped.

I think it's very ugly to specify such an arbitrary munging of
characters. There is a well defined namespace and procedures for ssh
algorithm names. When refering to algorithms used in the SSH protocol,
those names ought to be used, and used properly.

This URI syntax should defined so that either we need no separator
character to separate multiple algorithm names within a parameter or
value, or we use the single separator character which is not allowed in
an ssh name, ",". Ok, that's not allowed in an URI (at least a
previous mail in this thread said so), but it can be hex-escaped,
right?

Anyway, I'd favor

  fp-md5=ssh-dss-c1b13029d7b8de6c977710d746416387

or the more verbose

  fingerprint-md5=ssh-dss-c1b13029d7b8de6c977710d746416387
  
Theres no ambiguity in the value, since the fingerprint value can't
contain any dashes. The string before the last dash in the value is a
proper ssh parameter name (and if anybody defines a name including &
or ? or other uri magic characters, they should obviously be
hex-escaped. Thinking about it, @ seems to be the most likely
problematic character in practice, if that character is still magic in
this context. Unfortunately, I'm not so familiar with URI syntax
details).

And for the parameter name, don't think about it as family
fingerprint-<arbitrary hash algorithm name>, but as one *particular*
parameter, the meaning of which is defined precisely in the ssh-uri
document. The meaning of fingerprint-hash-of-the-day is at this point
not specified at all.

And I think another reason why I dislike

  fp-md5-sshdss=

is that it in seems to defines a whole family of parameters. I'd prefer
a small and *limited* set of parameter names, and then everything that
is intended to be general and unlimited, such as "any hostkey algorithm
that can be used in some current or future implementation of the SSH
protocol" belongs in some *value*, not in a parameter name.

Regards,
/Niels

---

From: der Mouse <[email-masked]>
Date: Thu, 15 Oct 2009 16:22:35 -0400 (EDT)

>   fp-md5=ssh-dss-c1b13029d7b8de6c977710d746416387

The problem with that (or the more verbose form) arises as soon as you
try to express "here's the host's ssh-dss fingerprint and here's its
ssh-rsa fingerprint".  This turns into something like
fp-md5=ssh-dss-60b725f10c9c85c70d97880dfe8191b3&fp-md5=ssh-rsa-3b5d5c3712955042212316173ccf37be,
which, syntactically, is providing conflicting values to a single
parameter.  That's whence the attempt to move the to the left side of
the equal sign in some way.

It's ugly, but you could base64-encode both: fp-bWQ1-c3NoLXJzYQ=....

Or you could ignore the issue, assuming that the future will never
define hash and cipher names which make the encoding ambiguous. :)

/~\ The ASCII				  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: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 16 Oct 2009 02:03:18 -0400

> which, syntactically, is providing conflicting values to a
> single parameter.  That's whence the attempt to move the
> to the left side of the equal sign in some way.

Yes, exactly.

> It's ugly, but you could base64-encode both:

A form of base64-encoding is an option if the goal is to fully preserve 
SSH algorithm names at the expense of human readability and 
manageability.

Something like base64-encoding would also permit any kind of private 
algorithm name to be expressed.

The major drawback is that human readability and manageability of SSH 
URIs would be drastically reduced this way.

But in the vast majority of cases, the algorithms used would be 
completely standard and predictable ones which could have very practical 
names.

How about this approach:

(1) The fingerprint parameter name is of the form 
fp-<hashAlg>-<hostKeyAlg>.

(2) A few shorthand parameter names are defined for commonly used 
algorithms, so the following commonly used combinations (and possibly 
more) can be easily expressed: fp-md5-rsa, fp-md5-dss, fp-sha1-rsa, 
fp-sha1-dss.

(2) If either <hashAlg> or <hostKeyAlg> is something that doesn't have 
one of these common names, it is prefixed with '+' instead of '-', and 
represented in a version of base64 that doesn't pick any unwelcome 
characters as the extra two in the alphabet.

Examples:

 fp+bWQ1-rsa
 fp-sha1+c3NoLXJzYQ
 fp+bWQ1+c3NoLXJzYQ

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Oct 2009 01:46:41 -0400

--On Thursday, October 15, 2009 04:22:35 PM -0400 der Mouse 
<[email-masked]> wrote:

> fp-md5=ssh-dss-60b725f10c9c85c70d97880dfe8191b3&fp-md5=ssh-rsa-3b5d5c3712
> 955042212316173ccf37be, which, syntactically, is providing conflicting
> values to a single parameter.  That's whence the attempt to move the to
> the left side of the equal sign in some way.

Unfortunately, that's insufficient.  Depending on the situation, one might 
wish to express that the named host may provide any of several keys, all 
using the same algorithm.  For example, one might provide a hostname which 
resolves to one of several distinct machines.

-- Jeff

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 16 Oct 2009 05:09:13 -0400

> Unfortunately, that's insufficient.  Depending on the
> situation, one might wish to express that the named
> host may provide any of several keys, all using the
> same algorithm.  For example, one might provide a
> hostname which resolves to one of several distinct
> machines.

I see.

Then perhaps something like this:

?fp1=md5:ssh-rsa:0a1b2c3d4e...
&fp2=md5:ssh-rsa:c9d721b241...
&fp3=md5:ssh-dss:1b951c9ff2...
&fp4=md5:ssh-dss:f21b1c9f92...

And again, some special character to allow for base64-encoded algorithm 
names.