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

[Mike <mike-list at pobox.com>]

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

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls