Sean Turner is the document shepherd and Stephen Farrell is our illustrious Area Director!
In a perfect world, only IETF standards-track protocols would be used to secure the Internet and older protocol versions would be replaced with new protocols as the IETF obsoleted the older version. Unfortunately, we don’t live in that world; there’s plenty of SSL3.0 (less so since I first wrote this) and TLS 1.0-1.2 deployed in the wild. The mechanism specified in this memo is a hack and the draft says so nonetheless it is a widely deployed hack; it specifies a standards track solution to avoid non-standard behavior to address a security vulnerability introduced by the non-standard behavior. The non-standard mechanism in question is the so-called SSL/TLS “fallback” dance (http://ietfmemes.tumblr.com/image/102388560279) that clients implement to work around interoperability problems with legacy servers that entails not using the standards-based TLS protocol version negotiation mechanisms alone but also intentionally reconnecting with a downgraded protocol if initial handshake attempts fail. Attackers can use this well-known behavior, for example to force clients to use CC (crap crypto) implemented in earlier versions. In the words of my co-chair: “The browser behavior is just plain broken and this draft tries to make it less broken.”
Review and Consensus
The draft was very actively reviewed in the WG (~450 msgs). It had two WGLCs: the first was the “normal” (this is my new normal: ~190 msgs during WGLC), the second was targeted at reviewing changes made during the 1st WGLC. I do not believe this draft requires outside review.
Obviously, how to fix this issue was hotly debated. The settled on mechanism modifies client and server behavior based on the client inclusion of the “fallback-scsv” cipher suite. You might be asking yourself why a cipher suite and not an extension. The short answer you might have heard was SSL3.0 doesn’t support extensions so the way to get this supported everywhere (even in the non-standards track SSL) is with a cipher suite and not an extension. But, SSL3.0 is in the process of being actively culled from the TLS herd so how’s that hold water, you might ask. Well, TLS server support for extensions is optional - the number of TLS extension intolerant servers is dwindling but we’re never sure it’ll go to zero. The extension vs cipher suite was a hot topic during the 1st WGLC, but in the spirt of rough consensus the advocate for the extension approach decided they could live without loving the cipher suite mechanism at the TLS WG session in Hawaii.
What to say about version skipping was another hotly debated topic, e.g., falling back from TLS 1.2 -> 1.0 because of some server configuration (or induced by an active attacker). In the end, the draft settled on not saying anything because it’s obvious that later versions are better than earlier version. Note that some continue believe this should be addressed by the draft, but it appears they are in the rough. I’ll note Bodo (one of the authors) nicely summarized where we ended up:
Because we’re dealing with the real world and there are middle boxes deployed, there was some discussion about what to do about the non-malicious variety, i.e., those that discard unsupported client hello versions. It’s a little unclear exactly what would be said about misbehaving middleboxes because they weaken TLS negotiation and potentially cause more failures.
Based on some measurements taken back in November 14.4% of TLS servers on the Internet now support the mechanism described in this draft.
Finally, my co-chair was originally shepherding this document but provided some suggested text so I took over as shepherd.
The shepherd confirmed with each of the authors that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. To be more specific: the authors knew of no IPR related to this draft and hence no IPR disclosures have been made.
Other Points of Minutiae
This documents updates every published version of TLS and DTLS because everybody ought to do this to prevent protocol downgrade attacks. There are no DOWNREFs. There is an informative reference to an individual draft, but it is appropriately an informative reference (also that draft will be considered for WG adoption probably in Jan ’15).
The IANA considerations section does list the squatted on cipher suite values and TLS alert codes in the IANA considerations section. We’re hoping that based on the widespread adoption that these can be assigned. I humbly apologies for squatting on these numbers on behalf of my WG draft authors, and I should have sought an early assignment for these numbers.