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

Adam Langley <> Tue, 26 November 2013 17:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24B551ADF71 for <>; Tue, 26 Nov 2013 09:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YoNsLtwoQcot for <>; Tue, 26 Nov 2013 09:33:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c02::22d]) by (Postfix) with ESMTP id ED92C1ADDDA for <>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
Received: by with SMTP id p14so4071023vbm.18 for <>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=V3u5ew3Be0pWcVzs0Hg5EZUJDmHwukFAtlu0XZXbTZi5o2lsAh/gYKB6Z/H52l6mAU wkpaaYXhRp7BQG219VCZYDefOYruEDXG/TdIW81LBZEvvOqkii4s1F1fYuqyCNBXw30l iQCkqjVZPAApjsuf4u5SfryIh6u4RKH7LhtfcBG3UM8BfSAg2laCl8NlnnnLtH++iv86 YrF2nS02H7zZOB8cOOIU3gRt87bEkN1pwEr8nTW3vXzLoTePRkvu0XA8ujs3UoKz/gbe W74EI3rmIPt9c1FFKlj74hAy0l4xA3YMCOCaLrFVt5w7y7P53KyLsCP8dPCLLW9o8GiZ jFdA==
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:from:date :message-id:subject:to:cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=C6it6GGn0fVPN5DFpV8xrZAEuCPofHYyNRWfUw2T9+kalyKVtfjqH1bGu3IbIbe/Zm Ya8EksgxAbsxI0zmZ7W0p9DOJY1HXHcceuhkjW0R4uucBFa5EEzVJyLgFeu5Ow92H9HQ DB2WY2qmdjwPtywJ6UxnCpNEkA857TCW2sjFz9WiRX2Vy1aPjoDhpFnJ8G+z3gWESpYl ZfdHyd56NoXMhFEbczuDdsRaawsAc/x/uEOvdU3MXO0f05POGPPqUa7Z1rnBRuHEiNW7 Rv9bmL68gTsGDxW0tBb/+SJ7NJbUBbEh2QLFsYjDOI1XycEoP7RcsGn4vHmHalfszNil zUoA==
X-Gm-Message-State: ALoCoQkRMtFlS1xRjSJvyQQrtOYC/nNHs3JSJl++IlwUSZXpVRwuybcd6Q9sRf4nUGekrOxRx+BwKUPThHFEXQ+kSMimfelsDEt0OGvIoG4rSH9vT5UuvIzHz5jxX1V2c71vbfq27U7CestWjo43KNLalmMZzvvMRFgiiBPY/1+Zby07fbz5DCEirtcRddWcuRhIMj92RpUf
X-Received: by with SMTP id xk9mr27061903vdc.8.1385487187652; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Nov 2013 09:32:47 -0800 (PST)
In-Reply-To: <op.w64s0vig3dfyax@killashandra.invalid.invalid>
References: <> <op.w64s0vig3dfyax@killashandra.invalid.invalid>
From: Adam Langley <>
Date: Tue, 26 Nov 2013 12:32:47 -0500
Message-ID: <>
To: "Yngve N. Pettersen" <>
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: Tue, 26 Nov 2013 17:33:09 -0000

On Mon, Nov 25, 2013 at 7:59 PM, Yngve N. Pettersen <> wrote:
>  - Are these implementations functioning as proxies or just inspecting the
> encrypted protocol data, without decrypting?

I think that the problems so far have been with full MITM proxies.

>  - Does *any* of these implementations support the Renego patch? If they
> don't, then my suggestion for using the Renego extension support as a proxy
> for version tolerance might still work.

Unfortunately I've no idea. There seem to be more variants of some of
these products than pips in a pomegranate.

>  - Do you know that none of them will not break due to an SCSV? If they are
> breaking due to expectations of what is supposed to be in the handshake,
> some of them they could very well break due to unexpected ciphersuites, as
> well. (while the Renego SCSV seem to have worked well, I don't think it can
> be relied on as a reliable indication as it is only used for SSL v3-only
> hellos, because there are servers that does not tolerate the Renego
> extension in combination with the Renego SCSV.

It is possible that there could be compat issues with an SCSV but, as
far as I know, it's the least likely to have problems.

> A pessimistic guess is that, as per Murhpy's Law, there will be both broken
> Renego patched implementations, and implementations that react to the
> proposed SCSV. As far as the SCSVs are concerned, how do you propose to
> handle those cases?

Tiny amounts of breakage are acceptable if there are some edge cases.
I don't know yet whether the breakage will be tiny and, as ever, it'll
be a bunch of work to find out. But it seems to be the best way

You report that 0.3% of sites are expected to fail if we use renego as
an anti-fallback signal. That is not a heart warming number and I'd
like to try to break less, if at all possible.