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

[Brian E Carpenter <[e-mail]>]

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
>>
>>[e-mail] 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:[e-mail]]	Sent: Friday, November 24, 2006 1:48 PM
>>>	To: Black, David; [e-mail]
>>>	Cc: [e-mail]
>>>	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:   [e-mail] [mailto:[e-mail]]
>>>	Sent:   Friday, November 24, 2006 12:55 PM Eastern Standard Time
>>>	To:     Hollenbeck, Scott; [e-mail]
>>>	Cc:     [e-mail]; [e-mail]
>>>	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:[e-mail]]
>>>	> Sent: Friday, November 24, 2006 12:28 PM
>>>	> To: Black, David; [e-mail]
>>>	> Cc: [e-mail]
>>>	> 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: [e-mail] [mailto:[e-mail]]
>>>	> > Sent: Friday, November 24, 2006 12:10 PM
>>>	> > To: [e-mail]; Hollenbeck, Scott
>>>	> > Cc: [e-mail]; [e-mail]
>>>	> > 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
>>>	> > [phone]             FAX: [phone]
>>>	> > [e-mail]        Mobile: [phone]
>>>	> > ----------------------------------------------------
>>>	
>>>	
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Gen-art mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/gen-art
> 
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art