Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

From: denis bider <[email-masked]>
Date: Tue, 10 Nov 2015 04:20:10 +0000

> The "ssh-" prefix specifies the encoding to use for keys and signatures.

The current RSA SHA-2 draft defines signature algorithm names separate from public key format. I believe this is important: it allows for seamless upgrade of existing RSA host and user keys to use the new signature methods. If we do not allow for this seamless upgrade, adoption of SHA-2 for host and user authentication will be delayed.

You assert that the "ssh-" prefix is necessary to convey a hint about the encoding. To me, this appears to be an arbitrary interpretation. I personally do not see this as relevant.

But if this was relevant, the names in the current draft still meet your criteria:

- The name of the public key format, which is the SSH-specific key format, continues to be "ssh-rsa". This indulges the idea that an "ssh-" prefix should be used if the format is SSH-specific.

- The signature algorithm names are "rsa-sha2-256" and "rsa-sha2-512". The signature encodings just contain the RSA signature blob, which is defined in RFC 3447. This is not SSH-specific.

Note that, besides a different name, the signature encoding is identical to this, defined in RFC 6187 for the key format "x509v3-rsa2048-sha256":
     string  "rsa2048-sha256"
     string  rsa_signature_blob
Notice how this does not have an "ssh-" prefix.

> And even if it were a small mistake, we should
> strive to keep naming consistent.

There has to be a reason for decisions beyond just consistency. Consistency must have a benefit, which it often does; but I do not see that benefit here.

What I see are disadvantages:

- We have to deal with a less practical, less readable name everywhere.
- The prefixed name would not disambiguate this algorithm from anything.
- The prefixed name would not even be consistent with RFC 6187.
- People frown on us for having deliberately chosen, for ourselves and for everyone, a less practical name.

The name we choose right now will be with us and our users for years to come. The non-prefixed choice is one I would very much prefer to see - and is the one that I think is more sensible.

Also:

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

----- Original Message -----
From: Niels "Möller" 
Sent: Monday, November 9, 2015 12:42
To: denis bider 
Cc: Peter Gutmann ; [email-masked] ; Jeffrey Hutzelman ; Mark D. Baushke ; [email-masked] ; [email-masked] ; [email-masked] ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider <[email-masked]> writes:

> The "ecdsa-sha2-..." algorithm names (RFC 5656) do not use the "ssh-" prefix.
>
> Neither do the new formats in RFC 6187, i.e. "x509v3-rsa2048-sha256"
> and "x509v3-ecdsa-sha2-...".
>
> In my opinion, the "ssh-" prefix is superfluous. The context of SSH is
> implied by where the names are used.

The "ssh-" prefix specifies the encoding to use for keys and signatures.
My understanding is that for ecdsa- and x509v3-, the encoding is
specified by appropiate other standards. While for ssh-rsa and ssh-dss,
the encoding is ssh-specific: It is specified in the ssh transport
protocol (RFC 4253), and include strings like "ssh-rsa" as part of the
encoding.

I belive the new rsa-sha2-256 algorithm name ought to also have an
"ssh-" prefix, because the format is equally ssh specific.

> I think the use of "ssh-" prefixes for all kinds of names was a
> (small) mistake in the original design.

I disagree. And even if it were a small mistake, we should strive to
keep naming consistent.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: denis bider <[email-masked]>
Date: Tue, 10 Nov 2015 05:20:06 +0000

> I view it sligtly differently. The "ssh-rsa" string inside
> the key encoding is not a name intended to be
> parsed (at least not when received over the wire),
> it's just required to be there.

We do sometimes use that string to identify the format, when the key is not presented to an application with out-of-band information.

When the key is read from an SSH public key file, for instance, this encoded string is crucial to knowing what kind of key it is.

I think it's a good idea for this string to be included in the public key format. It provides a common format that makes it easy to have consensus on calculating fingerprints, and it allows identification of key type when encountered outside of context.

(It further, theoretically, allows multiple public key formats to be used with the same negotiated host key algorithm. We haven't had a need for that yet, but it seems the SSHv2 designers went out of their way to avoid baking in place forced 1-to-1 mappings. The protocol has flexible hinges everywhere.)

Niels Möller <[email-masked]> , 11/10/2015 5:02 AM:
denis bider <[email-masked]> writes: 
 
> The current RSA SHA-2 draft defines signature algorithm names separate 
> from public key format. I believe this is important: it allows for 
> seamless upgrade of existing RSA host and user keys to use the new 
> signature methods. If we do not allow for this seamless upgrade, 
> adoption of SHA-2 for host and user authentication will be delayed. 
 
I fully agree this makes sense. 
 
> You assert that the "ssh-" prefix is necessary to convey a hint about 
> the encoding. To me, this appears to be an arbitrary interpretation. I 
> personally do not see this as relevant. 
 
My understanding of this design is that the prefix simply means 
"encoding is ssh-specific", and that is applicable also to the new 
signature algorithm. I'm sorry if I sounded too harsh; I think 
consistent naming is important, but it is still a minor detail. 
 
> - The name of the public key format, which is the SSH-specific key 
> format, continues to be "ssh-rsa". This indulges the idea that an 
> "ssh-" prefix should be used if the format is SSH-specific. 
 
I view it sligtly differently. The "ssh-rsa" string inside the key 
encoding is not a name intended to be parsed (at least not when received 
over the wire), it's just required to be there. Which *is* a bit of a 
peculiar design. The name *identifying* the algorithm and format is the 
name used in negotiating the algorithm, in keyexchange and user 
authentication, and it must be known prior to parsing an encoded key or 
signature. 
 
And then it happens that the different algorithms named "ssh-rsa" and 
"rsa-sha2-256" are specified to use the same encoding of public keys 
(for good reasons as you explain above). 
 
> - The signature algorithm names are "rsa-sha2-256" and "rsa-sha2-512". 
> The signature encodings just contain the RSA signature blob, which is 
> defined in RFC 3447. This is not SSH-specific. 
 
That is a relevant detail I had missed at first reading. So you use a 
standard format for the signature (and just prepend a fixed string, for 
consistency with other signature algorithms in ssh), but keep using the 
ssh-specific encoding for the keys. 
 
To sum up the naming issue: We seem to disagree, but I can live with 
either name. I'll do my best to refrain from writing more on that issue, 
but I'd be happy to hear other's opinions. 
 
Regards, 
/Niels

---

From: [email-masked] (Niels Möller)
Date: Tue, 10 Nov 2015 06:02:52 +0100

Regards,
/Niels