Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-10.txt

From: [email-masked]
Date: Wed, 26 Mar 2008 10:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: The Transport Layer Security (TLS) Protocol Version 1.2
	Author(s)	: T. Dierks, E. Rescorla
	Filename	: draft-ietf-tls-rfc4346-bis-10.txt
	Pages		: 101
	Date		: 2008-3-26
	
This document specifies Version 1.2 of the Transport Layer Security
   (TLS) protocol. The TLS protocol provides communications security
   over the Internet. The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Thu, 27 Mar 2008 12:51:06 -0700

Some comments.....

7.4.1.1 Hello Request

-> HelloRequest is a simple notification that the client should begin
-> the negotiation process anew. In response, the client should a
                                                                ^send
-> ClientHello message when convenient.

7.4.2. Server Certificate (last sentence)

-> As cipher suites that specify new key exchange methods are specified
-> for the TLS Protocol, they will the imply certificate format and the
                                    ^^^ ^^^^^ swap
-> required encoded keying information.

7.4.3. Server Key Exchange Message

I think it would be a good idea to add dh_q to ServerDHParams as
suggested (by Bodo?).  There is now an RFC (5114) that defines DH
parameters with values for q (and appropriate generators).  Perhaps
there also needs to be an extension mechanism for this to allow
retrofitting it into older TLS versions?  An unfortunate problem with
RFC 5114 is that they didn't create any groups for DHE_* with more
than 112 bits of security, but I guess you can always generate your
own parameters.

Also since the ServerKeyExchange message is omitted for RSA, DH_DSS,
and DH_RSA, I think there should not be cases for them in the struct.
Someone could infer from the definition that they should send an
empty struct in those cases (even though it says not to).

7.4.4. Certificate Request

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

The last sentence:

-> Note: It is a fatal handshake_failure alert for an anonymous server
-> to request client authentication.

contradicts the statement near the bottom of page 4:

-> The peer's identity can be authenticated using asymmetric, or
-> public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This
-> authentication can be made optional, but is generally required for
-> at least one of the peers.
    ^^^^^^^^^^^^^^^^^^^^^^^^^

"At least one" implies that the client could be authenticated even if
the server is not.

7.4.7. Client Key Exchange Message

I think there is a problem with the version rollback check in the
RSA-encrypted premaster secret -- if the version is successfully
rolled back to TLS 1.0 or earlier, then the check is made optional.
Actually, I don't see the need for this check anyway since invalid
Finished messages will uncover any modification to the client hello.
But indeed if the version in the premaster secret is greater than the
supposed value from client hello, then there is definitely a problem.

Mike

---

From: <[email-masked]>
Date: Thu, 27 Mar 2008 22:24:57 +0200

Mike,

Given that TLS 1.2 is already approved, these comments come a 
bit late. The typos can be fixed during AUTH48, but adding
new functionality is not possible.

Couple of more detailed replies inline:

<snip>
> An unfortunate problem with RFC 5114 is that they didn't create any
> groups for DHE_* with more than 112 bits of security, but I guess
> you can always generate your own parameters.

BTW, RFC 3526 has several good groups -- which at least I'd recommend
over generating random group parameters -- and the larger ones there
should provide more than 112 bits of security. (They do have large
q's, though -- but they have g=2 which should speed up computations)

<snip>
> "At least one" implies that the client could be authenticated even 
> if the server is not.

The text on page 4 is of descriptive nature, and does not specify any
particular behavior for implementations. The actual requirements are
specified later, and although they add details that were missing from
the general description, they don't seem to contradict it.

> supposed value from client hello, then there is definitely a problem.

This is something we can't realistically fix for older versions of TLS,
since some SSLv3/TLS 1.0 implementations got this wrong. 

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Thu, 27 Mar 2008 13:59:38 -0700

> new functionality is not possible.

Yes, the IESG message arrived 10 minutes after I sent my review.
I have been so busy that I've had to put TLS on the back burner
for the past few months.  I'm hoping to update my server soon.

I still think it would be a good idea to pursue an extension to
specify the dh_q value in ServerDHParams.  Clearly this could
be its own document (or put into the successor to RFC 4366).  I
think it could be a really simple empty extension that tells the
server that the client knows about q, and the server responds if
it will put q into ServerDHParams.

Mike