[email protected]
[Top] [All Lists]

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Secur

Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
From: Stefan Santesson
Date: Tue, 01 Dec 2009 19:31:04 +0100
On 09-12-01 12:19 AM, "David-Sarah Hopwood" <[email protected]>

> 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 protected] mailing lists by 2009-12-14. Exceptionally,
>> comments may be sent to [email protected] 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:

It is my opinion that this draft offers two noticeable advantages over

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

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.


Ietf mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>