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

[<Pasi.Eronen at nokia.com>]

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

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.

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

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
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls