[Help-gnutls] Re: GnuTLS 1.6.2

[Simon Josefsson]

nisse at lysator.liu.se (Niels Möller) writes:

> 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.

Yes, I agree.

>> 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.

I agree, although I think there is likely some other specifications
that says the parameters field should be omitted, rather than to have
a NULL value in it.  So it may be too late to make everyone use the
same magic string.  The best one can do is to use the same string as
most modern implementations do.  Here I think the current TLS 1.2
draft is probably wrong.

> (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).

Yes, agreed.  GnuTLS actually throws the decrypted blob at libtasn1,
but when libgcrypt supports PKCS#1 I think the code should be
replaced.  Alternatively, all signing requests could be sent to an
external process which can support other approaches too, such as
PKCS#11 smartcards etc.

/Simon