[Gen-art] RE: Gen-ART review of draft-hollenbeck-epp-rfc3734bis-04.txt

Scott,

> I need to confirm Ted's reaction before doing anything with
> this review.

That's a fine response, as the review says:

> > Please wait for direction from your document shepherd
> > or AD before posting a new version of the draft.

With regards to timing:

> The last call period ended on 11 November and I've already
> updated the documents to reflect comments received as a result
> of the last call.

This is not a GenART IETF Last Call review.  Usually, GenART
tries to provide an IETF Last Call review, but that doesn't
appear to have happened for this draft.  The GenART reviewers
are human, and "stuff" happens ;-).

This GenART review is intended as input to the position that the
General Area Director will take on the IESG ballot for approval
of the draft, and FWIW, the General AD doesn't always agree 100%
with his reviewers ;-).  If knowing what that ballot position
will be matters, Ted should follow up directly with Brian to
understand Brian's view of these comments.

FWIW, I would hope that one of the Security ADs would point out
the existence of TLS 1.1, in addition to this input to the
General AD.  My understanding is that the primary purpose of
TLS 1.1 was to prevent some attacks on the CBC usage in TLS
1.0, and hence there's a preference for implementations to
move to TLS 1.1 as quickly as reasonably possible.

Thanks,
--David

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] 
> Sent: Friday, November 24, 2006 12:28 PM
> To: Black, David; gen-art@ietf.org
> Cc: hardie@qualcomm.com
> Subject: RE: Gen-ART review of draft-hollenbeck-epp-rfc3734bis-04.txt
> 
> I need to confirm Ted's reaction before doing anything with this
review.
> The last call period ended on 11 November and I've already updated the
> documents to reflect comments received as a result of the last call.
> 
> -Scott- 
> 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com] 
> > Sent: Friday, November 24, 2006 12:10 PM
> > To: gen-art@ietf.org; Hollenbeck, Scott
> > Cc: Black_David@emc.com; hardie@qualcomm.com
> > Subject: Gen-ART review of draft-hollenbeck-epp-rfc3734bis-04.txt
> > 
> > I have been selected as the General Area Review Team (Gen-ART)
> > reviewer for this draft (for background on Gen-ART, please see
> > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> > 
> > Please wait for direction from your document shepherd
> > or AD before posting a new version of the draft.
> > 
> > Document: draft-hollenbeck-epp-rfc3734bis-04.txt
> > Reviewer: David Black
> > Review Date: 24 November 2006
> > IESG Telechat date: 30 November 2006
> > 
> > Summary:
> > This drafts 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.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art