I disagree that the last call is premature. I realize that not everyone
is happy with all aspects of the current document but a clear majority
of people on the TLS list have voiced their support for it. I do not
see any consensus that the existing approach is flawed, nor do I see
evidence of an emerging consensus on an alternative approach.
This document fixes a serious security hole in TLS and so it is
important to finish it in a timely manner. While a minority of the WG
may feel that it this draft isn't exactly the way it would like, it does
address the relevant security issue. I don't feel that waiting several
more weeks to see if consensus forms around some other approach is
likely to be useful.
(Speaking as TLS Working Group Co-Chair)
Behalf Of Yoav Nir
Sent: Tuesday, December 01, 2009 2:06 AM
Cc: tls(_at_)ietf(_dot_)org Group
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation
(Transport LayerSecurity (TLS) Renegotiation Indication
Extension) to Proposed Standard
On Nov 30, 2009, at 5:37 PM, 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
<draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
final comments on this action. Please send substantive comments to
the ietf(_at_)ietf(_dot_)org mailing lists by 2009-12-14.
may be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please
the beginning of the Subject line to allow automated sorting.
I oppose publishing the current draft.
There are two unresolved issues still being discussed on the
TLS mailing list:
1. non-extension signaling for older versions (SSLv3 and
maybe TLS 1.0) 2. explicit vs implicit addition of old
verify_data to the PRF (also known as fail-unsafe vs fail-safe)
I think the WG is converging, and that a couple of more weeks
of discussion may lead to consensus.
I agree with David-Sarah Hopwood that a last call (WG or
IETF) is still premature.
Ietf mailing list
Ietf mailing list