(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 partly overlapping. 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 purpose.) - 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 discussion. - 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 renegotiation anyway). - 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 Christmas. 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). Best regards, Pasi _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf