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

Trevor Perrin <trevp@trevp.net> Tue, 26 November 2013 20:21 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4B61AE010 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mElVN8HKaUl7 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:21:11 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6C81ADF38 for <tls@ietf.org>; Tue, 26 Nov 2013 12:21:11 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so5779470wib.14 for <tls@ietf.org>; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FmzDEaAgOsD+nxAOMtPMkWBhIubs8vxcZ8yVKVludio=; b=kSF3q/4QJNekmdbOXsKOYCsIJVGelp7+OEeGMgZ0dwcvMFs1k9a5f4qcMe5mO6O6C3 26rfgGEiM1MXIOWHmsAph7PTuk65RGB5P/foKdvEsDIRPJi9ig3U+mo9FA9OAmXaIYkz THuLdsQ8lUbnhxwHT9DLWd/thsfHAohMLBK5TMyljMJZDtQZCmATH61JTNZ/I2YOHa6i uEh1Q5YG6tjIUYkfMfY7bF4n8Fa67FZV6aorrgh+Eix+bM3t++PzzZv2gDSbGWsUrvHV maQvhIL6kvIiWePMY0XuiLZoRE66vyamTK2rVtjU4t+t0kuK4BT93jrRfSTMx760QRA3 aKgw==
X-Gm-Message-State: ALoCoQluIrgKxH5fLq/QHFxkMoaak/+V/k6ny4170Gajn4awWfRQuDN11IW7FcwQcQa0RLd4RXBs
MIME-Version: 1.0
X-Received: by 10.180.7.136 with SMTP id j8mr19597941wia.17.1385497270622; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com> <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com>
Date: Tue, 26 Nov 2013 12:21:10 -0800
Message-ID: <CAGZ8ZG10rsysnNijZGRZAsh4h06235xWnFwUKOBAStOEYjnYCQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2013 20:21:13 -0000

On Tue, Nov 26, 2013 at 9:38 AM, Adam Langley <agl@google.com> wrote:
> On Mon, Nov 25, 2013 at 9:33 PM, Trevor Perrin <trevp@trevp.net> wrote:
>> Are these MITM products using special root certs installed in the
>> browser for MITM purposes?
>
> Yes.
>
>> If so, could the browser simply allow
>> SSLv3 fallback only when connecting to a cert under such an installed
>> root, while otherwise rejecting such a fallback?
>
> Yes, but I don't believe that would be viable on the Internet as a
> whole. There are certainly many HTTPS servers on the Internet that
> need fallback in order to function. We would like not to break them
> while stopping them dragging everyone's security down. So we still
> need some way to identify non-broken servers.

Sure, makes sense.

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.)?


Trevor

[1]
http://www.ietf.org/mail-archive/web/tls/current/msg09450.html
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html