Hello.  I have implemented TLS 1.2 in GnuTLS following
draft-ietf-tls-rfc4346-bis-02.txt.  I was able to connect successfully
to https://www.mikestoolbox.net:4433/ (thanks Mike!) so I believe my
implementation is ready enough that I can write down some of my
thoughts on the draft.

1.  It would have reduced implementation time if there were a list of
protocol syntax changes.  For example, it took me some debugging to
understand that CertificateRequest was modified from (RFC 4346):

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

into

       struct {
           ClientCertificateType certificate_types<1..2^8-1>;
           HashType certificate_hash<1..2^8-1>;
           DistinguishedName certificate_authorities<0..2^16-1>;
       } CertificateRequest;

In general I recommend to add new fields to the end of a structure
instead of in the middle of it.  It makes version-aware parsers
cleaner.

2.  The modification to change RSA signing was to change:

   In RSA signing, a 36-byte structure of two hashes (one SHA and one
   MD5) is signed (encrypted with the private key).  It is encoded with
   PKCS #1 block type 1, as described in [PKCS1A].

into:

   In RSA signing, the output of the chosen hash function is encoded as
   a PKCS #1 DigestInfo and then signed using block type 01 as described
   in Section 8.1 as described in [PKCS1A].

This could be improved with some helpful discussion to guide
implementers.  PKCS1A is under-specified and even incorrect here.  Is
there a reason we don't reference PKCS1B here?

DigestInfo mis-handling was the cause of the recent bugs that affected
OpenSSL, Mozilla NSS, GnuTLS and several proprietary TLS libraries for
X.509 signature validations.  It would be unfortunate if TLS 1.2
introduce the same problem into TLS itself.

The problems with PKCS1A are:

1) It uses BER encoding, when PKCS1B correctly changed this to DER.

2) It doesn't specify whether the parameters field should be NULL or
omitted for non-MD2/MD4/MD5 algorithms.

I don't think there is any controversy around 1).  DER should be used.

Whether to use a DigestInfo.AlgorithmIdentifier.parameters field that
is NULL or omitted seems somewhat problematic.  PKCS1A says regarding
MD2/MD4/MD5:

             For these object identifiers, the parameters field of the
             digestAlgorithm value should be NULL.

It doesn't say anything about other hashes.  PKCS1B says:

   The parameters field associated with id-sha1, id-sha256, id-sha384,
   and id-sha512 should be omitted, but if present, shall have a value
   of type NULL.

However the example in PKCS1B uses NULL:

      SHA-1:   (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.

Further, appendix H of PKCS1B contains additional discussions:

   *  The requirement that the parameters in an AlgorithmIdentifier
      value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was
      changed to a recommendation that the parameters be omitted (while
      still allowing the parameters to be NULL). This is to align with
      the definitions originally promulgated by NIST. Implementations
      MUST accept AlgorithmIdentifier values both without parameters and
      with NULL parameters.

I note that Mike's server required a NULL here.  I initially didn't
send one, my ASN.1 library computed a DER encoding with an omitted
parameters field.  For reference, that DER code is:

  SHA-1: 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 || H

Mike's server didn't accept this.

This will leads to interoperability problems with TLS 1.2 unless the
specification is more explicit about the problem.

I suggest adding after this paragraph:

   In RSA signing, the output of the chosen hash function is encoded as
   a PKCS #1 DigestInfo and then signed using block type 01 as described
   in Section 8.1 as described in [PKCS1A].

This new paragraph:

   As discussed in [PKCS1B], the DigestInfo MUST be DER encoded and
   for digest algorithms without parameters (which include SHA-1) the
   DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted
   but implementations MUST accept both without parameters and with
   NULL parameters.

Other text instead would be fine, but I strongly believe that this
problem should be mentioned explicitly because we have seen that it
has serious failure modes (false positives in RSA signature
verification).

For the record, I wouldn't have any problem with saying that the
parameters field MUST be omitted -- the fewer choices the better.
However, that would be a taking things a bit further than PKCS1B.

Thanks,
Simon

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls