(wearing IETF Security Area Director hat)
First of all, I want to say that it's clear that this was an unusual
IETF Last Call -- and this was expected, too. Usually a WG document
does not go to IETF Last Call until everyone in the WG is happy with
it, so most of the time, very little happens during the last call.
However, this document addresses an urgent security vulnerability, so
as discussed in the Hiroshima TLS WG meeting, it was decided to
solicit comments from the TLS WG members and the wider community
This means we've gotten quite a few emails. However, although the
volume of emails was large, I was a positively surprised how little
disagreement there was.
There was basically no disagreement about the functionality (what the
spec should do); only about how exactly the functionality should be
implemented. And even there, most people agreed on most of the big
issues, and the disagreement was mostly about details that, frankly
speaking, are not all that important (especially to the users of TLS).
Some have even dismissed many of the comments as "aesthetic".
I disagree with that -- the discussions were not that different from
ordinary discussions in any IETF WG. However, I think it's fair to say
that most comments were more about "it could/should be better" than
"it won't work". Also, despite the occasionally heated email
exchanges, I believe most people agree that getting this security
vulnerability fixed quickly is more important than the specific
details (as long as the details are not totally unreasonable).
Summarizing some open issues:
- We seem to have rough consensus that both clients and servers need
to be able, if they choose to do so, fully operate with legacy
(unpatched) systems, at least for a limited period of time (despite
the security implications). This implies the need for some form of
"signaling" in both directions, where a patched system can determine
if the other end supports the fixed renegotiation or not.
(The current draft supports this.)
- We seem to have rough consensus that the specification should
include some form of C->S signaling that can be used with
extension-intolerant servers and/or SSLv2 compatible client hellos.
(The current draft has the "magic cipher suite value" for this
- For S->C signaling, we seem to have rough consensus for a TLS
extension in ServerHello.
- Whether verify_data should be sent over-the-wire or not: current
text (send it over-the-wire) seems to have more support (at least 2/3
vs. 1/3). While the rough consensus is perhaps a bit rougher than
we'd normally hope to see, I believe most participants (of either
opinion) would prefer making a decision over continuing the discussion
until some indeterminate time. So we pick the one with more support.
- Whether to prohibit sending the extension (in initial ClientHello),
or require the magic cipher suite even if the extension is sent (in
initial ClientHello): The consensus is again a bit rougher than we'd
normally hope to see, but the current text (either is allowed) has
more support (about 2/3 vs. 1/3), so we keep it. And again, I believe
most participants prefer make some decision over continuing the
- There was some discussion on whether to add the magic cipher suite
to patched renegotiation ClientHellos (in addition to the extension),
too. I believe rough consensus is not to do this.
- The current draft doesn't clearly say what should be included in
legacy (insecure) renegotiation ClientHellos. I am not sure if we have
enough clear opinions to call consensus, but keeping it aligned with
the initial ClientHello (either MSCV or extension) seems to be one
simple approach (but I hope to see the actual text).
- Yngve Pettersen proposed explicitly saying that servers that
implement this draft must be extension-tolerant (not break if the
client sends extensions) and version-tolerant (not break if the client
proposes a higher version number than the server supports). It seems
these are not new requirements, so this would be an editorial
clarification (but being very clear doesn't hurt).
- Yngve also proposed adding requirements/recommendations about
fall-back/reconnection procedures (to extension-less handshake, or
earlier versions). I think the rough consensus is that the document
should not mandate or even recommend anything about such
fall-back/reconnection procedures (which are mostly not related to
- There was discussion about adding another C->S signaling method
using the proposed version: if proposed version >= 1.3, and the
negotiated version is <= 1.2, it means the client supports this draft
(what happens if negotiated version is >= 1.3 would be specified in
the TLS 1.3 spec). This would allow TLS >=1.3 clients to remove other
signaling (magic cipher suite/extension) from initial ClientHellos
(but requires extra code in the server). As Tom Petch (and others)
noted, if we want to do this, it has to be done now (and can't be done
when doing TLS 1.3). There was relatively little support for doing
this, and rough consensus seems to keep the spec as is in this regard.
- There were some proposals to make the ordering of extensions (in
either ClientHello, ServerHello, or both) significant somehow. The
rough consensus seems to keep the list unordered.
- There was a proposal to change the exact contents of the server's
extension. There wasn't much support for this, and rough consensus
seems to keep them as-is.
- There have been some concerns about the clarity of the
specification. I think there's some room for improvement here -- I
will work with the editor and WG chair to do something about this.
I've asked the document editor to update the draft as soon as
possible. The IESG will discuss this document this Thursday (December
17), and I hope we can have an approved specification before
I realize that not everyone will be happy with these decisions, but in
my judgment as Security Area Director, the choices are in line with
the rough community opinion, and are technically reasonable (many
other choices would have been reasonable, too). In particular, I
believe that continuing these discussions until some indeterminate
time in 2010 would not be in the best interest of the community (many
of whom have expressed that they prefer an OK solution this year,
instead of possibly-slightly-improved one next year).
Ietf mailing list