TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
draft-ietf-tls-downgrade-scsv-05

[Ballot comment]
Russ' Gen-ART observation needs to result in document a change. Hopefully that can be implemented as part of the approval process (or a new draft if otherwise required).

[Ballot comment]
This is the second SCSV value going into the registry.  I noted that the value proposed in Section 7 is not adjacent to the other SCSV value (0x00,0xFF TLS_EMPTY_RENEGOTIATION_INFO_SCSV), and in fact lies in the middle of a broad swath of unallocated code points. 

Would it be worthwhile to allocate a range of ciphersuite values to be used for these sorts of things (say 0x00,0xD0-0xFF), or at least make the code point assigned for this document adjacent to the other one so that if there are others, they can be managed in a range-like fashion?

[Ballot comment]
Thank you for working through Last Call comments on this one. I did have one niggle.

In this text:

6.  Security Considerations

  However, it is strongly recommended to send TLS_FALLBACK_SCSV when
  downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
  weaknesses that cannot be addressed by implementation workarounds
  like the remaining weaknesses in later (TLS) protocol versions.
 
I'm wondering whether "recommended" is intended as an RFC 2119 RECOMMENDED, but wondering more why someone wouldn't do this (why is it not required/REQUIRED?).

[Ballot comment]
Glad folks came to consensus on this even if it was tough.

The header of the document and the intro say that it updates RFCs 2246, 4346, 4347, 5246, and 6347, but the abstract only lists three of those.

The IANA considerations section is a little weird, since the actual allocations are listed in the part that is to be removed and then there is a sentence that claims the allocations are already done. Why not do the usual "This document registers the following values in XYZ registry ..." and keep the registrations themselves in there?

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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-downgrade-scsv-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

Upon approval of this document, IANA understands that there are two actions which it must complete.

First, in the TLS Cipher Suite subregistry of the Transport Layer Security (TLS) Parameters registry located at:

http://www.iana.org/assignments/tls-parameters/

a new TLS Cipher Suite will be registered as follows:

Value: 0x56,0x00
Description: TLS_FALLBACK_SCSV
DTLS-OK: Y
Reference: [ RFC-to-be ]

Second, in the TLS Alert subregistry of the Transport Layer Security (TLS) Parameters registry located at:

http://www.iana.org/assignments/tls-parameters/

a new TLS Alert will be registered as follows:

Value: 86
Description: inappropriate_fallback
DTLS-OK: Y
Reference: [ RFC-to-be ]

NOTE: Please update the URLs in the IANA Considerations section:

FROM:
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
                            #tls-parameters-4

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
                            #tls-parameters-6

TO:
http://www.iana.org/assignments/tls-parameters

This will ensure the URL will always work and point to the most current
version/extension. 

IANA understands that these two actions are the only ones required to be completed
upon approval of this document.

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
  Protocol Downgrade Attacks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a Signaling Cipher Suite Value (SCSV) that
  prevents protocol downgrade attacks on the Transport Layer Security
  (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ballot/


No IPR declarations have been submitted directly on this I-D.

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 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.