I think that Stefan sums up the state of play well (after some 1,000 posts to the TLS list with the number still rising steadily). The IETF Last Call was premature, capricious even, given the ongoing debates on the TLS list. Technically, either draft will do but the mrex draft is superior in what I regard as system issues, in the likelihood of being deployed in such a way that it works. Tom Petch ----- Original Message ----- From: "Stefan Santesson" <stefan@xxxxxxxxxxx> To: "David-Sarah Hopwood" <david-sarah@xxxxxxxxxxxxx>; <ietf@xxxxxxxx> Cc: <tls@xxxxxxxx> Sent: Tuesday, December 01, 2009 7:31 PM Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard > On 09-12-01 12:19 AM, "David-Sarah Hopwood" <david-sarah@xxxxxxxxxxxxx> > wrote: > > > The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG > >> (tls) to consider the following document: > >> > >> - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > >> <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@xxxxxxxx mailing lists by 2009-12-14. Exceptionally, > >> comments may be sent to iesg@xxxxxxxx instead. In either case, please > >> retain the beginning of the Subject line to allow automated sorting. > >> > >> The file can be obtained via > >> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt > > > > I believe the decision to take this draft to Last Call was premature, and > > that further discussion in the WG is necessary before deciding whether to > > adopt draft-ietf-tls-renegotiation or an alternative. > > I agree to this. > > I will support the current draft-ietf-tls-renegotiation-01 if that is choice > of direction in the end of this last call. > > However, the TLS working group has also been working hard to evaluate > whether an alternative solution could provide better integration with legacy > deployments and provide better security properties. > > This last call was initiated before the WG members had any real chance to > express their choice of direction. > > For the sake of completeness, the alternative approach was updated and > posted today and is available from: > http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-02 > > It is my opinion that this draft offers two noticeable advantages over > draft-ietf-tls-renegotiation-01 > > 1) By not sending verify data over the wire, this draft allows peers to > fail-safe as a result of implementation errors in cases where a > corresponding implementation error of draft-ietf-tls-renegotiation-01 leads > to a fail-unsafe situation. > > 2) It offers a solution where servers never have to parse data from TLS > extensions. This offers advantages when deploying the fix for legacy > implementations. > > > I would support if the choice of draft-mrex-tls-secure-renegotiation-02 as > the selected solution to the problem, or an update of > draft-ietf-tls-renegotiation-01 which incorporate the updated handshake > message hash calculation of draft-mrex-tls-secure-renegotiation-02 as an > alternative to sending verify data in the RI extensions. > > /Stefan > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf