Document: draft-hollenbeck-epp-rfc3734bis-04.txt
Reviewer: David Black
Review Date: 24 November 2006
IESG Telechat date: 30 November 2006

Summary:
This draft is on the right track, but has open issues,
described in the review.

Comments:
This is a small update to the existing RFC 3734.  The one
open issue is the need to deal with the fact that TLS has
been updated since RFC 3734 was published; this is almost
a nit, but it does require attention.

The TLS requirement is "must use", not just "must implement"
- that requirement is already present in RFC 3734, and is
justified by EPP having a weak "password in the clear"
mechanism as the only means of authentication.

TLS has evolved since RFC 3734 was published.  This 3734bis
draft references RFC 2246, which specifies TLS 1.0.  TLS 1.1
has now been specified by RFC 4346, and that RFC needs to be
referenced. In addition, the version usage requirements for
TLS 1.0 vs. TLS 1.1 need to be specified.

I would say that one of TLS 1.0 or TLS 1.1 MUST be used, TLS
1.1 SHOULD be used, and TLS 1.1 implementations MUST
correctly negotiate use of TLS 1.0 when that is necessary
(this negotiation is already specified in RFC 4346).  The
result should be that implementations developed in accordance
with RFC 3734 are allowed to use TLS 1.0 for backwards
compatibility and that all servers MUST use TLS 1.0 when a
client does not support TLS 1.1, as indicated in the TLS
Client Hello message.

While not absolutely necessary, it would help implementers
to also say that these TLS requirements prohibit use of SSL 2
and SSL 3, and they specifically prohibit use of the SSL 2
ciphersuites and the SSL 2 Client Hello message that are
specified in Appendix E of RFC 4346.  This is worth calling
out because SSL 2 has significant security weaknesses by
comparison to SSL 3 and TLS - removing SSL 2 support entirely
is among the best ways to ensure that it is not used.