Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Dec 2009 19:31:04 +0100

On 09-12-01 12:19 AM, "David-Sarah Hopwood" <[email-masked]>
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
>> [email-masked] mailing lists by 2009-12-14. Exceptionally,
>> comments may be sent to [email-masked] 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