Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[[e-mail] (Martin Rex)]

Salz, Rich wrote:
> 
>> Permitting the server to continue the TLS handshake with
>> ServerHello.server_version = (ClientHello.client_version +1)
> 
> Brian pointed out that this seems to not work.

Technically, my proposed and extremely simple improvement works *PERFECTLY*
in his example.  But Brian and I might be talking past each other.


I'm not saying that the early adopters of the downgrade-scsv proposal
must change.  But I also do not want to see a knee-jerk reaction, that
can easily lead to a complete interop failure rubber-stamped for
standards track, when it could be easily improved by allowing servers
an alternative response that bears a significantly lower risk of
causing harm in the form of complete interop failure, when shipped
as server patch into an installed base of unknown usage scenarios.



The semantics of the FALLBACK_SCSV (i.e. the presence of the cipher suite
in ClientHello) specified in the current proposal could be described as

"Client signals to Server that it supports a TLS protocol version
 that is higher than what is currently conveyed in ClientHello.client_version".

The semantics of the fatal inappropriate_fallback(86) alert from the
server of the current proposal could be described as

"Server signals to Client that it also supports a TLS protocol version
 that is higher than what the server received in ClientHello.client_version".


Improving the current downgrade-scsv proposal, by giving the server the
choice to alternatively continue the TLS handshake successfully, using
ServerHello.server_version = (ClientHello.client_version+1) will convey
back to the client the same information as the "inappropriate_fallback(86)"
fatal alert--but give the client significantly *MORE* options to
perform a successful TLS handshake with that server.

The server's willigness to continue the handshake, selected from among
the TLS protocol options actually offered in ClientHello, is *NOT* an
obligation for the client to continue that handshake and to send
application data over the resulting session.  If the TLS client believes
that it could do better, it may take chances and retry a new connection
immediately.  But with the alternative of a successful continuation of
the handshake, interop is still a viable option to the client, and not
all conceivable protocol downgrades will actually impair the security.


Clients, in particular Web Browsers, are notorious about breaking
connections frequently and during all connection states (after connect
after TLS handshake start or during data transfer).  This may be users
doing navigation on partially loaded pages that contain myriads of embedded
seperate objects, or this may be active scripting composing colorful
UIs from myriads of small UI elements.

Servers, on the other hand, are normally patient and well-behaved, but
may appear unresponsive under high load or flaky network connectivity.

 
I firmly believe that most of the causes for TLS protocol downgrades
will continue to be non-malicious rather than active attacks.  And
in many cases, the proposed improvement of the server successfully
continuing with ServerHello.server_version=(ClientHello.client_version + 1)
will provide a comparable level of security to what would happen had
the client had proposed a higher protocol version in ClientHello.
So this improvement can also save network round-trips on non-malicious
downgrades.


Looking at the downgrade dance of Firefox 34, it does

  1.  record={3,1}   client_version={3,3}  + extensions
  2.  record={3,1}   client_version={3,2}  + extensions
  3.  record={3,1}   client_version={3,1}  + extensions
  <error page>

So Firefox seems to have abandoned not only SSLv3, but also
extension-less ClientHellos.

It seems that the only "problem" that is left here, is an unfortunate
requirement in AEAD cipher suite RFCs (such as AES-GCM, rfc5288):

https://tools.ietf.org/html/rfc5288#section-4

   4.  TLS Versions

   These cipher suites make use of the authenticated encryption with
   additional data defined in TLS 1.2 [RFC5246].  They MUST NOT be
   negotiated in older versions of TLS.
*                                         Clients MUST NOT offer these
*   cipher suites if they do not offer TLS 1.2 or later.
                                                         Servers that
   select an earlier version of TLS MUST NOT select one of these cipher
   suites.  Because TLS has no way for the client to indicate that it
   supports TLS 1.2 but not earlier, a non-compliant server might
   potentially negotiate TLS 1.1 or earlier and select one of the cipher
   suites in this document.  Clients MUST check the TLS version and
   generate a fatal "illegal_parameter" alert if they detect an
   incorrect version.


Considering that TLS version intolerance had been well-known when the
AEAD cipher suite documents where published, the above (*) requirement
should have better been something like the following from the beginning:

   When a Client offers any of these cipher suites, it implies that
   the client supports and is willing to use protocol version TLS 1.2
   or later.  This implication will take precedence over any protocol
   version in ClientHello.client_version that is lower than TLS 1.2,
   and might have been used by the client purely for better interoperability
   with old or defective TLS servers that are intolerant to newer TLS
   protocol versions in ClientHello.client_version.


Then browsers would not have had to worry as much about their downgrade
dance, there would be a strong argument for programmatic clients (those
that do not contain any app-level downgrade dance heuristics)
to adopt TLSv1.2 + AEAD cipher suites.


How about assigning a small number (<=4) of alternative TLS cipher suite IDs
to existing AEAD TLS cipher suites than will carry the above implication?

Candidate cipher suites for assignment of an alias cipher suite ID:

     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xC0,0x27};
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xC0,0x28};


-Martin