Hello,
On Sun, May 21, 2000 at 10:26:35PM +0200, Niels M�ller wrote:
> Sami Lehtinen notified me of a bug in LSH's implementation of ssh-dss
> signatures. As I would like to have my interpretation of the spec
> confirmed, and as I suspect that also openssh may have the same
> problem (as it manages to interoperate with LSH), I'm writing to the
> WG list.
>
> The transport draft, draft-ietf-secsh-transport-07.txt, defines an
> ssh-dss signature as
>
> uint32 length
> string "ssh-dss"
> string dss_signature_blob
The first field is omitted by OpenSSH as well as by SecureCRT
and from my experiments with other implementations of SSH2
it seems that ssh-2.1.0 and ssh-2.0.13 both omit everything but
dss_signature_blob
not even the size of the dss_signature_blob is included.
IMHO, the redundant field
uint32 length
seems inconsistent with the overall design of all other
parts of the SSH2 specification so I would strongly support
the change of the signature specification to
string "ssh-dss"
string dss_signature_blob
Moreover, from reading the drafts now again it seems to me that the
above mentioned (redundant) uint32 length is identical to the uint32
length field from the "string signature of H".
Similar to this is the definition for "ssh-dss" from the same
transport draft:
uint32 length
string "ssh-dss"
mpint p
mpint q
mpint g
mpint y
In all implementations that I could test (ssh-2.1.0, ssh-2.0.13,
lsh, SecureCRT, OpenSSH) the specified (redundant) length field is
_never_ sent across the wire. e.g., in SSH_MSG_KEXDH_REPLY length
field from the string
string K_S, the host key
is again identical to the length field from the "ssh-dss" definition.
> The problem is the first field, which LSH omits. The signature is used
> for instance inside the SSH_MSG_KEXDH_REPLY message,
>
> byte SSH_MSG_KEXDH_REPLY
> string server public host key and certificates (K_S)
> mpint f
> string signature of H
>
> In LSH, this message looks something like this:
>
> SSH_MSG_KEXDH_REPLY (byte)
> length of host key (uint32)
> host key data (byte array)
> length of f
> digits of f
> * length of signature (i.e. all below)
> 7 (length of "ssh-dss")
> "ssh-dss" (7 bytes)
> length of signature blob (usually 40, and always even)
> r digits (usually 20 bytes)
> s digits (usually 20 bytes, but always the same length as for r)
This is the same encoding OpenSSH generates and expects.
SecureCRT expects the same format and it seems consistent
with there overall design (there is never a explicit length
field, only 'string'-type data has length fileds).
And again: I would strongly favour the removal of the
redundant length fields from the drafts since:
1) They are not usefull at all. Why should n bytes of data
be encoded as:
uint32 n+4
uint32 n
n bytes data
2) There is no public implementation of the drafts that includes
the redundant length field so
3) Requiring the length field breaks all public implementations
of the drafts. This would hurt the acceptance of SSH2 much,
since it adds yet another layer of incompatibility.
> The extra length field is totally redundant here (and I believe it is
> equally redundant in all other places where an ssh-dss signature is
> used). I'm about to add it in LSH now, in order to comply with the
> draft, but I would also like the WG to give some consideration to
> removing the redundant length field in the definition of the ssh-dss
> signature.
As I said before, I see no reason why the length field is in the
drafts and I even think it refers to the length field from the
string encoding.
-markus
