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