IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Nits in current drafts



Ben Harris <bjh21%bjh21.me.uk@localhost> writes:

> In article <E1D33CS-00087a-00%medusa01.cs.auckland.ac.nz@localhost> you write:
> >The easiest way to resolve this I think is to require that signatures *only*
> >be in "ssh-xyz format", regardless of the certificate format used (i.e. don't
> >tie the signature format to the key format).
> 
> I think this is a bad idea for the following reasons:
> 
> It forces all RSA and DSA signatures to use a SHA-1 hash, which limits them
> to 80 (or maybe 69) bits of security, which is likely to be insufficient
> fairly soon, and is very likely to be less than the security offered by the
> MAC and cipher in use.

As long as we're signing an exchange hash computed with sha-1,
replacing the hashing that is part of the signature processing by
something stronger than sha-1 won't increase security, will it?

> It forces all RSA signatures to use RSASSA-PKCS1-v1_5/SHA-1, when the same
> keys might be used with other signature schemes and hashes.

Strictly speaking, it's possible to use the ssh-rsa *format* with
other encapsulation schemes and hashes. The format says how you put a
signature bignum into the ssh protocol, it doesn't say how that bignum
is computed or verified. There should be no problem to define a
signature algorithm "rsa-foo-sha512" and use the same format for the
generated signatures.

> It makes the use of libraries (or perhaps hardware) that encapsulate
> complete signature schemes unnecessarily difficult, and perhaps
> impossible

It's "difficult" rather than "impossible". If we ever want the
signature generated by your hardware to be verified by software, that
software must be able to decode the hardware's custom format
and get to the underlying bignum. You can do that at the sending side
(where the hardware is located), or at the receiving side (which needs
to verify the signature). And for interoperability, I think it makes a
lot of sense to do this conversion on the sender side, and have a
single format on the wire.

I think this has to be decided case by case when new certificate types
are added. But unless there are strong reasons to do differently for a
particular certificate type, I tend to agree with Peter. We don't need
more than one way to encode the bignum in an RSA (or DSA) signature.

(And for the current drafts, we just need to delete underspecified
certificate formats).

Regards,
/Niels



Home | Main Index | Thread Index | Old Index