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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf