Oops - I missed the fact that this was intended for Draft Standard as opposed to recycling at Proposed Standard (mea culpa). What Ted suggests makes fine sense given the desire to advance this draft to DS.
Sorry/Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Monday, November 27, 2006 2:58 AM > To: Ted Hardie > Cc: [email protected]; [EMAIL PROTECTED]; Black, David > Subject: Re: [Gen-art] RE: Gen-ART review > ofdraft-hollenbeck-epp-rfc3734bis-04.txt > > Yes, I agree with Ted. A non-normative note seems the only > way to handle this that doesn't create endless interlock. > > Brian > > Ted Hardie wrote: > > We can certainly raise the issue with the Security ADs, but my take on it is > > that we can go forward with this at DS with TLS 1.0 references and implementation > > reports. I think we can and probably should add language which notes that > > updated versions of TLS now exist and that new or updated implementations > > should consider those, given that they allow backwards compatibility. > > > > I would not want to halt advancement of the document now to shift this to > > 1.1; that seems to create the worst kind of lockstep, since it means that > > the stability is never guaranteed. I would far prefer to see this re-cycle > > at draft some time in the future once the use of TLS 1.1 in this context justifies > > that change. > > > > Ted > > At 11:32 AM +0100 11/26/06, Brian E Carpenter wrote: > > > >>Yes, if it's a change in the spec, that would need implementation > >>reports specifically calling out TLS 1.1. I have difficulty > >>seeing how to handle it as a normative requirement at DS > >>without that. > >> > >> Brian > >> > >>[EMAIL PROTECTED] wrote: > >> > >>>Scott, > >>>That sounds fine - my recommendation is not to disallow the > >>>implementations that did TLS 1.0 according to 3734, but rather > >>>require new implementations that follow 3734bis to support > >>>TLS 1.1 in addition to TLS 1.0 (and prefer TLS 1.1 when there's > >>>a choice). This is definitely a topic on which Ted's input > >>>is important. > >>>Thanks, > >>>--David > >>> > >>> > >>>________________________________ > >>> > >>> From: Hollenbeck, Scott > [mailto:[EMAIL PROTECTED] Sent: Friday, November > 24, 2006 1:48 PM > >>> To: Black, David; [email protected] > >>> Cc: [EMAIL PROTECTED] > >>> Subject: RE: Gen-ART review of > >>>draft-hollenbeck-epp-rfc3734bis-04.txt > >>> > >>> > >>> > >>> David, > >>> > >>> I understand GenArt reviews. I was an IESG member myself not > >>>too long ago. > >>> > >>> I'm also well aware of TLS 1.1. The problem I have is that > >>>changing the reference now adds a new requirement to > implementations > >>>that didn't exist when 3734 was first approved. That's > what I want to > >>>talk to Ted about. > >>> > >>> -Scott- > >>> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>> Sent: Friday, November 24, 2006 12:55 PM Eastern Standard Time > >>> To: Hollenbeck, Scott; [email protected] > >>> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > >>> Subject: 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:[EMAIL PROTECTED] > >>> > Sent: Friday, November 24, 2006 12:28 PM > >>> > To: Black, David; [email protected] > >>> > Cc: [EMAIL PROTECTED] > >>> > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>> > > Sent: Friday, November 24, 2006 12:10 PM > >>> > > To: [email protected]; Hollenbeck, Scott > >>> > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > >>> > > 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 > >>> > > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > >>> > > ---------------------------------------------------- > >>> > >>> > >>> > >>> > >>> > >>> > >>>----------------------------------------------------------- > ------------- > >>> > >>>_______________________________________________ > >>>Gen-art mailing list > >>>[email protected] > >>>https://www1.ietf.org/mailman/listinfo/gen-art > > > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
