[Help-gnutls] Re: GnuTLS 1.6.2

[Niels Möller]

Simon Josefsson <simon at josefsson.org> writes:

> Are you sure that code is used for signing in the RSA key exchange
> ciphersuites, and not X.509 signing?  The RSA key exchange
> ciphersuites in TLS < 1.2 doesn't use RSA-PKCS#1 but sign a
> concatenation of the MD5 + SHA1 hash instead, see RFC 4346:

Looking deeper, it seems you are absolutely right. The Pike/Roxen code
doesn't use the standard sign method in the RSA class fr SSL, but uses
a special hack which does precisely what you describe. What a mess.
Sorry for the confusion.

Good to here that it is being cleaned up, at least to some degree, in
TLS.

> Initially I did follow the SHOULD and omitted the NULL, but I had
> interop problems with the only other TLS 1.2 implementation I'm aware
> of, so I changed GnuTLS.  The old code is still available in a
> #if-block, in case this changes again until the RFC is published.

If you care about the ASN.1 level, using the NULL may seem somewhat
silly and redundant. I tend to think about it as just a magic string
associated with the hash function. Then exactly which string is used
doesn't matter. What *does* matter is that everybody uses the same
string.

I would strongly recommend that the TLS folks stick to the magic
strings specified in RFC 3447, section 9.2. I think that's what most
IETF protocols do. A quick search turns up, e.g., RFC 4051 (Proposed
Standard), which explicitly writes out the magic string for rsa-md5,
matching RFC 3447, and then says that for the other hash algorithms,
only the object identifier is changed.

Introducing new magic strings in the TLS spec makes absolutely no
sense to me.

(The signature code in nettle never tries to take the pkcs#1-padding
apart. For signature verification, it constructs one padded value (a
bignum) by doing the secret RSA operation on the given signature, and
a second padded value from the hash of the locally computed hash of
the document being verified (in all protocols I've seen, the hash
algorithm to use is known from context, you never have to examine the
signature value to figure it out), and then it compares the padded
values as s bignums. I think this way of implementing it is more
robust, but it depends on everybody using the same magic value).

Regards,
/Niels