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

Watson Ladd <watsonbladd@gmail.com> Mon, 25 November 2013 23:49 UTC

Return-Path: <watsonbladd@gmail.com>
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 2FB621AE0B7 for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Jf8e_Ark7dim for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:49:33 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8521ADF92 for <tls@ietf.org>; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hm4so4412278wib.0 for <tls@ietf.org>; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r+YjU15cweXZJUs29pe1rqRT0TTsWH3IEsk9pbCyw+c=; b=tffKznoLBqJ+vySyUFp2rwL25WENAvgDKmcnDPurlVURPWF+7QxfdfKViYk3DmkxxP XnFxrN2x76pyMw9K6CbbNnq5ItP6ztoPRLZ7H2QwkMmm8Baj85mcaWWB+QMRTSqelkZC KcgHJZujOFwxLkH6z/M8pQnWo91uWvbjmzl2DwbXQw8+mvGm1bZx3CApBbVDAtNw0M6F i3LKsle2jVxNKh5pRkHxREoc3hCw6oxM+21WfX1tykcnDAOTKsKXpuythmXLpMxez8/6 uRbTAhpgf/1pnyOaSpxxoAFAi93ZVBmIKdirT6KLoAwVqfjXRweD528eqLTgXWrByErF 0nDQ==
MIME-Version: 1.0
X-Received: by 10.180.89.68 with SMTP id bm4mr11255842wib.0.1385423372662; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
Date: Mon, 25 Nov 2013 15:49:32 -0800
Message-ID: <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=UTF-8
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: Mon, 25 Nov 2013 23:49:35 -0000

On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com> wrote:

>
> Thus I'd like to propose the design of an SCSV with which we can move forward:
>
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.
I enthusiastically support this extension: it will solve a bug as old
as SSL without breaking
anything it seems. Why the hell wasn't this done sooner?
>
> This will not break MITMs because they will not process the SCSV. Any
> vendors that try to support the SCSV while having bugs that need
> fallback will find out when things stop working. But that, thankfully,
> will be their problem based on the Universal Rule of Users: the last
> thing that updated is to blame.
>
> Of course, this doesn't mean that firewalls won't turn out to be a
> problem but, at the moment, we can't even figure that out because of
> the the broken MITMs. We can't protect MITMed users, but it would be
> nice if they didn't ruin it for everyone else.
If firewalls block port 53, it's not the browser's problem. If
firewalls block 80, it's not the browser's problem. Why should
TLS 1.2 be any different?
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin