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(_at_)aaa-sec(_dot_)com>
To: "David-Sarah Hopwood" <david-sarah(_at_)jacaranda(_dot_)org>;
<ietf(_at_)ietf(_dot_)org>
Cc: <tls(_at_)ietf(_dot_)org>
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(_at_)jacaranda(_dot_)org>
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(_at_)ietf(_dot_)org mailing lists by 2009-12-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf