I strongly support publishing this draft either in its present form or with 
any modification that does not impact the protocol's security analysis.

This the most time-sensitive and security-critical IETF draft with respect 
to impact on the Internet community that I have seen in 17 years of IETF 
participation.  As such, I strongly support the decision to start IETF last 
call early as permitted by RFC 2418 section 7.4.  I also encourage the IESG 
to move this document to the front of the queue for all support 
organizations (Secretariat, IANA, RFC editor) when processing occurs and to 
avoid holding a blocking DISCUSS after the telechat unless that blocking 
issue is more serious than the ongoing presence of this TLS security 
vulnerability on the Internet.


===
Three changes to draft-ietf-tls-renegotiation-01 I consider important (but 
not blocking):

* The header should explicitly state it Updates RFC 5246, 4346, 4366, 2246. 
This
  gets forward pointers in the RFC index to increase chances implementers 
of those
  specs will also find this one.  This is also necessary for RFC 5246 as 
this creates
  an exception to a MUST NOT.

* There is an error-of-fact in the introduction; this is incorrect:
"   If certificate-based client authentication is used, the server will
   believe that the initial traffic corresponds to the authenticated
   client identity."
This statement is true only for application protocols with a badly designed 
state transition from unauthenticated to authenticated state.  That is 
primarily limited to HTTPS and protocols based on HTTPS.  It is not true 
for most other IETF application protocols including SMTP, POP, IMAP, LDAP, 
NNTP, BEEP and XMPP (however, I suspect all of these are impacted by the 
TLS vulnerability in other ways).  Changing "is used" to "is used with 
HTTPS" would correct the error.

* Nomenclature: when discussing TLS_RENEGO_PROTECTION_REQUEST, the term 
"cipher suite value" needs to be used instead of "cipher suite", and the 
text needs to explicitly state that TLS_RENEGO_PROTECTION_REQUEST is not a 
cipher suite (it is not sufficient to say it can't be negotiated).  This is 
important for evaluating implementations against government standards that 
dictate which cipher suites an implementation may advertise.

Evaluation relative to draft-mrex-tls-secure-renegotiation-03:

Kudos to Martin Rex for producing such a good alternate proposal.  The 
introductory text up to and including section 4.1 is very good and would 
improve draft-ietf-tls-renegotiation.  While I would support a consensus to 
publish the mrex document as the solution, I presently prefer 
draft-ietf-tls-renegotiation-01 for four reasons:
1. Running code: multiple implementations and interop testing was performed 
on an
   earlier version of draft-ietf-tls-renegotiation.
2. Impact to core protocol handshake: The mrex proposal alters the 
handshake to include
   data that is not exchanged in-protocol.  If this impacts PKCS#11 
hardware tokens or
   other SSL accelerators (an issue mentioned by Dr Stephen Henson on the 
TLS list on
   Nov 26, 2009 19:24:55 +0000) that could severely impact deployment.  I 
do not know
   if that concern applies to the mrex proposal, but I know it does not 
apply to the
   draft-ietf-tls-renegotiation.  The point being the mrex proposal 
requires more analysis
   to verify impact.  As we're in a hurry, I prefer to easier to analyze 
proposal.
3. Extensibility.  In my experience one of the protocol design features 
most important to
   get right is extensibility.  SSL/TLS didn't really get that right until 
v1.2 (which is
   causing problems now).  As draft-ietf-tls-renegotiation uses the TLS 
extension
   facility more extensively, it will help future-proof more 
implementations.
4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some 
circumstances.
   That approach is untested in the field and I have concerns it will 
negatively impact
   middleboxes.  As draft-ietf-tls-renegotiation allows use of either the 
cipher suite
   value or the extension for C->S signaling, that mitigates the concern -- 
the field
   can choose the mechanism that works best.

My take on some controversial issues:

* There may not be a sufficient number of "extension intolerant" SSL/TLS 
servers in operation to justify the added complexity of 
TLS_RENEGO_PROTECTION_REQUEST.  However, I do not object to inclusion as 
it's possibly helpful for some alleged extension intolerant servers 
compliant with early drafts of SSLv3 and it helped move closer to WG 
consensus.

* I believe Bodo Moeller's proposal to exclude client's verify_data from 
ServerHello improves the protocol, but I do not find it a blocking or 
compelling issue.

* I find the present text in security considerations on identity change 
mid-stream acceptable from my perspective as an application developer. 
However, I do not care if that text is included or excluded from the 
approved version as it is ancillary to the important core purpose.

* Changing the handshake hash to include the previous verify_data after 
renegotiation: In the abstract, I find the "fail safe" nature of including 
verify_data in the hash a better design than having to explicitly check 
validity.  However, I find that less compelling than issues 1 & 2 above. 
Particularly given that TLS already requires skilled implementers to get 
tricky details correct in a fashion that can not be easily verified (e.g. 
PRNG).

* Non-extension signaling for ServerHello: I am strongly opposed to using 
any mechanism other than TLS extensions for signaling in the ServerHello. 
I found all such proposals (including overloading the version field) far 
too risky.  As the earlier mrex draft proposing such mechanisms was 
replaced by a revision which now uses the extension mechanism, I believe 
the matter is settled.

		- Chris