Re: [TLS] An SCSV to stop TLS fallback.

Brian Smith <> Fri, 06 December 2013 22:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 282131AE15A for <>; Fri, 6 Dec 2013 14:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9auPBKhJR9jv for <>; Fri, 6 Dec 2013 14:22:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0CB801AE146 for <>; Fri, 6 Dec 2013 14:22:33 -0800 (PST)
Received: by with SMTP id w7so1026751qeb.22 for <>; Fri, 06 Dec 2013 14:22:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bd18v8sRlm2VSbz9Gq5OYPOJbfnWs0Zs5WazX11h+1A=; b=FAdNFplWgJKHdgqiktU9tOEAprIZ7OoS1OjS7NE6dNCpDi1XVyOfwXp5AW8ut5CFSz SieSBfFY+8UhsbGw0qHHoArOar56WtW15qXX16A1+moXPaIPlw/r7lDidozjL7gAG85g pWCEJ342E6zxCvJ/Z85I7aenf/jNMg71Sl/YapMzrrZdXjkdRskaLfA4w73Y2MloGw6j rAk0Hcv2ZmqlFDJZnudJDw5bjnjVdesk7DG3Wga40ja1qqIoMN9rqDYQosRZVJ/eFj5+ zbgR2y69fP/C7EQtGCwrgGko4mgFMKGmjaSEoC5Rw9fRlRHfsEF/9v8I6H8bPP7IFsEC XV+Q==
X-Gm-Message-State: ALoCoQnIM3KUGn4cxmVA2h/aYw4D+hKOS4aBY8H1se0PPb34jLRhAtN5gMz9a+wwiZ+ssJqaVgzj
MIME-Version: 1.0
X-Received: by with SMTP id m9mr10813570qaf.23.1386368549979; Fri, 06 Dec 2013 14:22:29 -0800 (PST)
Received: by with HTTP; Fri, 6 Dec 2013 14:22:29 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
Date: Fri, 6 Dec 2013 14:22:29 -0800
Message-ID: <>
From: Brian Smith <>
To: Adam Langley <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-Mailman-Version: 2.1.15
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: Fri, 06 Dec 2013 22:22:36 -0000

On Wed, Nov 27, 2013 at 7:28 AM, Adam Langley <> wrote:
> On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <> wrote:
>> these fallback connections add a lot of
>> latency. If we attempt a fallback connection in response to a
>> connection reset, and we receive an inappropriate_fallback alert, then
>> we'd have to make yet *another* connection without the fallback.
> I didn't have that in mind. In the code as I currently have it
> written, an inappropriate_fallback doesn't trigger an "upgrade".
> Rather the original error code that triggered the downgrade is
> remembered and returned.
> So the connection might go: TLS 1.2, connection reset; fallback to TLS
> 1.1, inappropriate_fallback; fail the connection with a connection
> reset error.
> We don't retry HTTP connections, after all.

Sorry for the delay.

Firefox does retry for connection resets. In fact, our TLS intolerance
mechanism is implemented by converting the error that causes us to
suspect TLS intolerance into a connection reset error code, and then
returning that connection reset error to our HTTP stack. In the case
of a RST in the middle of a GET request when pipelining is enabled,
Firefox will even resend the GET request on the assumption that it is
idempotent. Firefox has done things this way for a very long time,
presumably to help users get the results they want when they are on
flaky networks.

Anyway, it seems bad get a positive "yes, you can reach me and I will
respond" response from the server and then stop trying to communicate
with it. It is better to find some way to get the HTTP response that
the user is waiting for, if we can find one.

This is why I think it is better to try backporting TLS-1.2-only
cipher suites to TLS 1.1 and TLS 1.0, and then have clients send all
the same extensions in TLS 1.0 and TLS 1.1 that they would send in TLS
1.2, plus an indication of the max version supported in an extension
or an SCSV, and then let the server "upgrade" the connection to TLS
1.2 by using TLS 1.2 features while still indicating in its

Granted, there is significant compatibility risk in doing this,
because some intermediary may choke somehow.  It will require
widespread experimentation to see how well it works. I am happy to
change Firefox to support this experiment if we can find partners
running servers on the internet that are also willing to experiment
with it.

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)