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

Adam Langley <> Wed, 27 November 2013 15:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 036D91AE076 for <>; Wed, 27 Nov 2013 07:26:16 -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 D4c5Cv4cTwtH for <>; Wed, 27 Nov 2013 07:26:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::22a]) by (Postfix) with ESMTP id F36A71AE0B3 for <>; Wed, 27 Nov 2013 07:25:54 -0800 (PST)
Received: by with SMTP id oy12so5367827veb.29 for <>; Wed, 27 Nov 2013 07:25:54 -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=lftnyMcVoQuPPPekpKUcGtqrNyjYUNLX8LD6GFqWPjs=; b=eD9bUbnmtSJBdtYBNEWp9G/b8Ie1ojjZC7rv6AAjarz0I8ZV06irTz6dOGEzV1fjfZ erKW3d/iQwLYRZqIbFuZoSsaTyecxWNiCC6M3rwHFOnDW7Jkm2FxD+sqVoj5+Ym6aJH+ ie9KDrC9nPSxaE2L0Zq/19+Damt7UYwBjx4tAXE+RpUHuPwxC7+lY717+RrqXkpFjf/8 08k3EeqOy8qFeNq7uaHbR07Afh7tNOTU1VigP0m+Ilyin0ndS9OJ53/YWSf68lZAPfHl jTBPhr6RqY19in8Nkdisvn/OW07PpYVUr6c+qGo3Z1zt9notH80x7lfY5Y5h3FLlotrE Cg6A==
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=lftnyMcVoQuPPPekpKUcGtqrNyjYUNLX8LD6GFqWPjs=; b=BdblzqS65gUKQsnOqYxSQX9GAOOAAzMwhQ/MRETw/h8FSFA/7A2oLBuZ0ooKf7c0Hj 0DBUzUNEYPy4QTvaP59IzHTdhwhZfJEGm1kuoTjwBPMf2wY9xMs5nkfRJh2GonFJO0EH ARmdvWuz1rmHZWmxgyruGKEhz6zwEmH+B3CxwdX7O2Ub+OVAIUxmIvJ+PBxRlhyAiN0O GMtMzF0iBk7rvlEg/xvdRtJfGwN/4eiGUhXP1BuKp6wO3SZ7YKVerVzNNdwu7vD+5itx zbin/UTremd5pA5Rv11kNTWlaHNbPahyE3hRu1pVm02hb11YQ0pMwVApVIcyt4i6qc4m IkOw==
X-Gm-Message-State: ALoCoQnCkCi4+Wkh7uXHI4QFalk2JFgeMtZx7e9Rd/jIQPTJyOm/yIt16maKMgaR/fTu4h2B/NRFwtFmJMuxtROGfHg8fVwXy/v+XYOO2sON2fUb4wNkhuycZJQ2I7F9EOwYZj4EMUeI9OMyGnQDA9XOCjoUHXQBn+GxV3iRIooGr3jfqJtcVjF1HkQ+O+LkcI66Xi5Nqsqf
X-Received: by with SMTP id xw8mr390313vec.41.1385565954078; Wed, 27 Nov 2013 07:25:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 27 Nov 2013 07:25:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Adam Langley <>
Date: Wed, 27 Nov 2013 10:25:31 -0500
Message-ID: <>
To: Trevor Perrin <>
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: Wed, 27 Nov 2013 15:26:16 -0000

On Tue, Nov 26, 2013 at 3:21 PM, Trevor Perrin <> wrote:
> There was an earlier thread about TLS-intolerant middleboxes and the
> problem they pose for TLS enhancements which require TLS Extensions
> (like CT, TACK, and OCSP "must-staple") [1].
> Are your observations actually good news for that case?  If many of
> those intolerant middleboxes that were being observed are actually
> *MITM* boxes with installed MITM roots, presumably browsers could
> detect when they are connecting to such a MITM middlebox, and relax
> their requirements around (CT, TACK, OCSP "must-staple", etc.)?

We already detect and relax requirements about public key pinning when
a MITM box is detected by a certificate that roots at a user-installed

The worry has generally always been around "firewall" like devices
that do DPI and "filter" certain TLS versions. They might still be a
problem but MITMs turned out to be so broken that we didn't get as far
as being able to test for them! The SCSV should let us do so.