Summary
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:
http://www.ietf.org/mail-archive/web/tls/current/msg14848.html
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.
Intellectual Property
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.