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

"Yngve N. Pettersen" <> Thu, 26 September 2013 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C477711E8159 for <>; Wed, 25 Sep 2013 22:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 38Jj6X7Upmop for <>; Wed, 25 Sep 2013 22:50:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D762D11E8153 for <>; Wed, 25 Sep 2013 22:50:24 -0700 (PDT)
Received: from ([]:52846 helo=killashandra.invalid.invalid) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1VP4T0-0002DS-Nu for; Thu, 26 Sep 2013 07:50:22 +0200
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
References: <> <>
Date: Thu, 26 Sep 2013 07:50:12 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <>
Message-ID: <op.w3z7tycm3dfyax@killashandra.invalid.invalid>
In-Reply-To: <>
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2013 05:50:30 -0000


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


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.

On Wed, 25 Sep 2013 22:35:11 +0200, Bodo Moeller <> wrote:

> ---------- Forwarded message ----------
> From: <>
> Date: 2013/9/25
> Subject: New Version Notification for
> draft-bmoeller-tls-downgrade-scsv-00.txt
> To: Bodo Moeller <>om>, Bodo Moeller <>
> 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:
> Status:
> Htmlized:
> 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
> The IETF Secretariat

Yngve N. Pettersen

Using Opera's mail client: