Last Call Review of draft-ietf-tls-rfc4366-bis-
review-ietf-tls-rfc4366-bis-secdir-lc-farrell-2009-11-02-00

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