Everyone here knows the drill:-) I reviewed http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-06 Other than the first two points below this is basically fine. Section 5 only allows SHA-1 to be used for certificates referenced by URLs. That seems wrong these days. I assume this was discussed in the WG, but still wonder about it. Perhaps a note as to why a hardcoded hash alg is considered ok here would be good? Section 6 also has a hardcoded SHA-1 hash for a client to indicate root CA information. Same comment/question as above. Section 8 allows a client to nominate an OCSP responder and provide extensions. Seems like this could provide a new covert channel between the client and OCSP responder, via the server. Not sure that's even worth noting though. Not security related but section 3 says that literal IPv4 & IPv6 addresses are not allowed as a HostName, what about in-addr.arpa? (Might be better to say MUST NOT there too rather than "not permitted")