Re: [TLS] New TLS 1.2 draft submitted

["Gregory S. Chudov" <[e-mail]>]

First comments:

1) This draft proposes a new enumerated type, HashType, which is not 
mentioned in IANA Considerations section, so it is unclear, how new hash 
types can be defined. Also, would be nice to allocate a value for gost.

7.4.1.4.7 Cert Hash Types

Proposed addition:
-----------------------------------------------------------------------
          enum{
-             md5(0), sha1(1), sha256(2), sha512(3), (255)
+             md5(0), sha1(1), sha256(2), sha512(3), gostR3411(4), (255)
          } HashType;
-----------------------------------------------------------------------


Proposed addition:
-----------------------------------------------------------------------
HashType  values are divided into three groups:

              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive 
are
                 reserved for IETF Standards Track protocols.

              2. Values from 64 decimal (0x40) through 223 decimal (0xDF) 
inclusive
                 are reserved for assignment for non-Standards Track 
methods.

              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
                 inclusive are reserved for private use.

           Additional information describing the role of IANA in the
           allocation of HashType code points is described
           in Section 11.
-----------------------------------------------------------------------

There are a lot of MD5 certificates still around. Are they now intentionaly 
forbidden by default?
-----------------------------------------------------------------------
   Clients SHOULD send this extension if they support any algorithm
   other than SHA-1. If this extension is not used, servers SHOULD
   assume that the client supports only SHA-1.
-----------------------------------------------------------------------


11. IANA Considerations

Chapter 7.4.4 became 7.4.5, but the references in IANA Considerations 
section
is not updated. By the way, rfc2246bis contains a typo here too - it 
references 7.4.3 instead of 7.4.4.

Proposed change:
-----------------------------------------------------------------------
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
+   Section 7.4.5 describes a TLS ClientCertificateType Registry to be
   maintained by the IANA, as defining a number of such code point
   identifiers. ClientCertificateType identifiers with values in the
   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
   Action. Values from the range 64-223 (decimal) inclusive are assigned
   via [RFC 2434] Specification Required.  Identifier values from
   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
   The registry will be initially populated with the values in this
-   document, Section 7.4.4.
+   document, Section 7.4.5.

+   Section 7.4.1.4.7 describes a TLS HashType Registry to be
+   maintained by the IANA, as defining a number of such code point
+   identifiers. HashType identifiers with values in the
+   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
+   Action. Values from the range 64-223 (decimal) inclusive are assigned
+   via [RFC 2434] Specification Required.  Identifier values from
+   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
+   The registry will be initially populated with the values in this
+   document, Section 7.4.4.
-----------------------------------------------------------------------


And some more invalid section numbers:

Table of Contents

-----------------------------------------------------------------------
    7.4.10.   Certificate verify                                          64
-   7.4.10.   Finished                                                    65

+   7.4.10.   Finished                                                    65
-----------------------------------------------------------------------

7.4.9. Finished

-----------------------------------------------------------------------
   The value handshake_messages includes all handshake messages starting
   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
+   may be different from handshake_messages in Section 7.4.10 because it
-----------------------------------------------------------------------

7.1. Change cipher spec protocol

-----------------------------------------------------------------------
   (See section 6.1.) The change cipher spec message is sent during the
   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
+   before the verifying finished message is sent (see section 7.4.11).
-----------------------------------------------------------------------

7.4.10. Certificate verify
7.4.10. Finished
------------------------------------------------------------------------
-7.4.10. Finished
+7.4.11. Finished
-----------------------------------------------------------------------

F.1.1. Authentication and key exchange

-----------------------------------------------------------------------
   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
+   Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished
   message, parties thus prove that they know the correct
   pre_master_secret.
-----------------------------------------------------------------------

F.1.1.2. RSA key exchange and authentication
-----------------------------------------------------------------------
-   the certificate verify message (see Section 7.4.8). The client signs
+  the certificate verify message (see Section 7.4.10). The client signs
-----------------------------------------------------------------------


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls