Subject: [TLS] New TLS 1.2 draft submitted

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Feb 2006 11:41:28 -0800

I've just submitted a new draft for TLS 1.2 
(draft-ietf-tls-rfc4346-bis-00.txt).

This draft includes the following changes:

     - Merged in TLS Extensions and AES Cipher Suites from external
     documents.

     - Replacement of MD5/SHA-1 combination in the PRF

     - Replacement of MD5/SHA-1 combination in the digitally-signed
     element.

     - Allow the client to indicate which hash functions it supports.

I realize there is some controversy about the second and third
points, which we need to discuss at the meeting, but I wanted
to get something out and it seems to me that if we are going
to replace the MD5/SHA-1 combinations that it will look something
like this.

-Ekr

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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sun, 26 Feb 2006 15:42:26 +0300 (MSK)

Greetings!

> (draft-ietf-tls-rfc4346-bis-00.txt).

Sorry, where can I download the draft?

Thank you!

-- 
SY, Dmitry Belyavsky (ICQ UIN 11116575)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Feb 2006 05:40:50 -0800

> Sorry, where can I download the draft?

http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-ietf-tls-rfc4346-bis-00.txt

-Ekr

---

From: "Gregory S. Chudov" <[email-masked]>
Date: Mon, 27 Feb 2006 19:41:55 +0300

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

---

From: jimmy <[email-masked]>
Date: Tue, 28 Feb 2006 14:00:07 +0530

> (draft-ietf-tls-rfc4346-bis-00.txt).

This still has (in Section 6.2.1 Fragmentation, NOTE:) the sentence - 		

	Data of different TLS Record layer content types MAY be
        interleaved. Application data is generally of higher precedence
        for transmission than other content types and therefore handshake
        records may be held if application data is pending.

If the same language of tls1.0 is to be followed, (see 
http://www1.ietf.org/mail-archive/web/tls/current/msg00445.html), then 
shouldn't this be the other way round?

-jb