Subject: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

From: Bodo Moeller <[email-masked]>
Date: Wed, 25 Sep 2013 22:35:11 +0200

---------- Forwarded message ----------
From: <[email-masked]>
Date: 2013/9/25
Subject: New Version Notification for
draft-bmoeller-tls-downgrade-scsv-00.txt
To: Bodo Moeller <[email-masked]>, Bodo Moeller <[email-masked]>

A new version of I-D, draft-bmoeller-tls-downgrade-scsv-00.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Filename:        draft-bmoeller-tls-downgrade-scsv
Revision:        00
Title:           TLS Signaling Cipher Suite Value (SCSV) for Preventing
Protocol Downgrade Attacks
Creation date:   2013-09-25
Group:           Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
Status:
http://datatracker.ietf.org/doc/draft-bmoeller-tls-downgrade-scsv
Htmlized:
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00

Abstract:
   This document defines a Signaling Cipher Suite Value (SCSV) that can
   be used to prevent protocol downgrades for Transport Layer Security
   (TLS).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 26 Sep 2013 07:50:12 +0200

Hi,

Please note that I have previously posted a draft describing an  
alternative approach which is client-side-only.

Document:  
<http://www.ietf.org/id/draft-pettersen-tls-version-rollback-removal-02.txt>
Tracker:  
<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>

This approach uses the Renego Indication extension as a proxy indication  
of whether or not the server is version and extension tolerant (according  
to my most recent numbers, this is 99.74% accurate among current renego  
patched servers), and if the client finds, after a version rollback, that  
it has connected to a renego patched server, it then reconnects using its  
highest supported version, and if that fails, reports a connection failure.

According to my most recent numbers (collected during a full scale beta  
test of the new TLS Prober a month ago, so I am not 100% sure the numbers  
are fully correct, as I am not sure the current version is stable) 80% of  
servers in my sample now support the Renego patch. Among these 0.261% of  
the servers are version and/or extension intolerant when sent TLS 1.x  
version range Client Hellos

Among the 20% of servers that were not patched 4.22% were version and/or  
extension intolerant (essentially all were extension intolerant, only .5%  
of these intolerant servers were only version intolerant; among the  
intolerant renego patched servers the corresponding number was 13% only  
version intolerant).

In total 1.05% of servers are version and/or extension intolerant in the  
TLS 1.0-TLS 1.2 range.

The benefit of my proposal is that:

  - it only needs to be deployed client-side.
  - it does not require changes to the protocol, only to how the client  
handle a specific situation.
  - once clients only accept renego patched server this method, *and* the  
version rollback functionality can be removed.

There will initially be the downside of handling the .26% servers that are  
version/extension intolerant, but those can be quickly patched. There is  
also the problem of version/extension intolerant intermediates in the  
network that have been observed by the Google Chrome team.

In relation to Bodo's proposal, I think my proposal have the added  
benefits that:

  - It does not require any server-side updates
  - All servers that would implement Bodo's proposal would already have  
implemented the renego patch, and _should_ already be version tolerant (as  
seen above, not all are, but 99.74% are). This also applies in relation to  
any server that implements whatever the solution for the  
padding/encrypt-mac issue will be. As such Bodo's proposal will only be  
relevant for version rollback attack scenarios, or buggy intermediates,  
both of which my proposal handle client-side as a fatal error.

Bodo's solution do have the benefit that the server will learn about the  
version rollback, although in a version rollback attack scenario involving  
a sufficiently compromised protocol version I am not sure that the server  
will receive the signal (if so, this would also affect the renego based  
variation, but a client can take additional steps if it does not receive  
the renego extension, e.g. remove secure indications/padlock for the page).

I'll also note that two other approaches (proposed by EKR and Adam  
Langley) for this have been discussed the past two years, using SCSVs, and  
these and mine were discussed at the IETF-84 TLS WG meeting.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Sep 2013 11:47:23 +0200

> Document: <http://www.ietf.org/id/draft-**pettersen-tls-version-**
> rollback-removal-02.txt<http://www.ietf.org/id/draft-pettersen-tls-version-rollback-removal-02.txt>
> >
> Tracker: <http://datatracker.ietf.org/**doc/draft-pettersen-tls-**
> version-rollback-removal/<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>
> >
>

> these and mine were discussed at the IETF-84 TLS WG meeting.

Thanks for your comments!

Obviously all of the above proposals are somehow related.  Actually, I
think that your ID and mine in fact complement each other in
that draft-pettersen-tls-version-rollback-removal-02 provides heuristics
for how to handle (and avoid) protocol rollbacks in the *current*
implementation landscape, whereas draft-bmoeller-tls-downgrade-scsv-00
specifies a simple mechanism that can be used to avoid security problems
from protocol rollbacks in a very *general* way.

Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
don't want to hijack entirely):

OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.

I'm not sure to what extent I agree to this claim (for example, we do allow
servers to abort with an insufficient_security alert if they don't agree
with any of the ciphersuites listed in ClientHello.cipher_suites), but in
any case please note that this is not actually what
draft-bmoeller-tls-downgrade-scsv-00 specifies.

Rather, the specification has very specific instructions for servers when
to abort the connection (certainly I'm all for encouraging
interoperability, but for a security protocol there clearly are limits to
this -- I'd rather not interoperate with man-in-the-middle-type attackers,
for example), and specifically leaves it to clients to request that
server-side behavior for a given handshake attempt or not.  The
specification includes recommendations that will ensure full security based
on the capabilities of the given client and server, but client
implementations are allowed to ignore these if there are appropriate
reasons.

(I think an essential difference to Eric's and Adam's earlier proposals is
that in my proposal, the client wouldn't enumerate its capabilities for the
purpose of server-side heuristics.  Instead, use is entirely directed by
the client, as needed by its protocol downgrade sequence.  In the ideal
case, with no client-side protocol downgrade taking place at all, nothing
happens.)

Bodo

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Sep 2013 13:34:50 +0200 (CEST)

> draft-bmoeller-tls-downgrade-scsv-00 specifies.

https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3

   This section specifies server behavior when receiving the
   TLS_DOWNGRADE_SCSV cipher suite from a client in
   ClientHello.cipher_suites.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      highest protocol version supported by the server is higher than
      the version indicated in ClientHello.client_version, the server
      MUST respond with a (fatal) protocol_version alert.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      ClientHello message does not include field
      client_hello_extension_list at all ([RFC3546], [RFC4366],
      [RFC5246]), the server MUST respond with a (fatal)
      protocol_version alert.

To me, this part of your document places two requirements on the _server_
to abort the handshake.  And the justification given for aborting the
handshake is *NOT* that the TLS connection characteristics proposed
in ClientHello is inacceptable to the servers' policy (which would be OK),
but that the TLS connection characteristics appear to be inconsistent
with the TLS connection charateristics alleged/assumed to be desired
by the client.

In a security protocol, it is a design failure to rely on a connection
peer to enforce one's own policy (the connection peer may be an adversary),
and it is necessary that each peer checks and enforces his own policy
himself.  But once it does that, there is no need (and less confusion)
if each peer takes care only of his own policy.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Sep 2013 16:29:09 +0200

> [...]
> to abort the handshake.

Yes. My point is that there's no server-side guesswork involved -- no
"flawed or unjustified" assumptions. This is entirely client-directed
behavior!

> peer to enforce one's own policy (the connection peer may be an adversary),

If the authenticated handshake for a client-side protocol downgrade goes
through and you're actually talking to an adversarial server, the same
adversary could have negotiated the downgraded protocol version immediately
via proper TLS version negotiation.  This entire specification is only
about scenarios in which the client *is* willing to use the downgraded
protocol if necessary and *is*, in particular, willing to rely on it at
least for authentication and integrity-check purposes.  In other words, you
are not relying on an arbitrary connection peer, but on an authenticated
server.

Bodo

---

From: [email-masked] (Martin Rex)
Date: Mon, 30 Sep 2013 19:16:57 +0200 (CEST)

> "flawed or unjustified" assumptions. This is entirely client-directed

To me, these two requirements amount to an unnecessary knee-jerk reaction,
while we are fully aware that most TLS version interop problems are
non-malicious, i.e. _not_ caused by an active attacker.

I really see harm in increasing the amount of TLS handshake failures
with new "abort" requirements of the TLS protocol itself.  Any new/additional
handshake failures ought to be left purely and entirely to the calling
applications and their security trade-offs / policies, which may or
may not involve the decision of an interactive user.  Our concern in
TLS WG ought to be reducing handshake failures, and getting rid of
the reconnect fallback entirely.

TLS version negotiation is royally broken (throughout the installed base),
and has been a well known fact since before TLSv1.1 (rfc4346) was
published in 2006.  And it doesn't look like time is helping to improve
the situation.  Actually, by shipping a defective RSA premaster client_version
check in Windows7/2008R2 the situation has become more challenging
today than it was in 2006.

Maybe you remember that there was a change to OpenSSL in order to
*improve* interoperability (=less failed TLS handshakes) in face
of this defective RSA premaster client_version check:

  http://www.ietf.org/mail-archive/web/tls/current/msg09417.html

  Relevant OpenSSL ChangeLog:

   Changes between 1.0.0h and 1.0.1  [14 Mar 2012]
  [...]
   *) Some servers which support TLS 1.0 can choke if we initially indicate
      support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
      encrypted premaster secret. As a workaround use the maximum pemitted
      client version in client hello, this should keep such servers happy
      and still work with previous versions of OpenSSL.
      [Steve Henson]

Another example for TLS version challenges are defective middle-boxes
(Bluecoat seems popular for internet access from company networks):
https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642

Yet another example would be the upgrade path for an installed server-farm,
where you would get yourself into trouble if the existing server-farm
causes clients to perform reconnect-fallbacks and trying to test
a new implementation of the kind you suggest would cause occasional
handshake failures for handshake where the first request went to an
old server, and the reconnect fallback to the updated server.
So for such a setup, this kind of feature would require a "flag day".

There is similar serious breakage in the TLS cipher suite documents that
describe AES in counter mode:
  http://tools.ietf.org/html/rfc5288#section-4
  http://tools.ietf.org/html/rfc6655#section-5

Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight-
forward, and the cipher suites (themselves) would exhibit the same
security properties.  But this breakage prohibits clients from even
proposing these cipher suites when they're doing a fallback, independent
of what is causing the fallback.

Consumers will typically (have to) limit the TLS version that their
client offers upfront to obtain robust behaviour.  And such a
configured limitation will typically be used for years (for as long
as the hardware is used and the software only upgraded).

To really improve the situation, new protocol features (including
TLS protocol versions >1.1) ought to be negotiated in a fashion that
increases the amount of successful TLS handshakes for the entire
installed base, and avoids the necessity for reconnect fallbacks--
something that the majority of programmtic TLS clients do not
even have.

-Martin