Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

Brian Smith <brian@briansmith.org> Fri, 16 January 2015 21:19 UTC

Return-Path: <brian@briansmith.org>
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 05D541B2C53 for <tls@ietfa.amsl.com>; Fri, 16 Jan 2015 13:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.321
X-Spam-Level:
X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MANGLED_BACK=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 joOMCEBegfno for <tls@ietfa.amsl.com>; Fri, 16 Jan 2015 13:19:07 -0800 (PST)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17C01B2C51 for <tls@ietf.org>; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id vb8so21125027obc.0 for <tls@ietf.org>; Fri, 16 Jan 2015 13:19:06 -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 :content-transfer-encoding; bh=W4HhZs+C0M8iSN8BW+VvChXOAThoESGB2oTR7C37c+8=; b=Ff5V0wTEOeB/db9XdaRa8Te2Sp1csF6eCiIKDKny6MjcXlBn/hdBw5VxlI/5dhHk0l DezWfqssrYjLeshKCP1VZYNWb3tc/pgjhQ1nwZuKpi8ACxKQyBJjtA1fPvMPqdZQlNf4 k6lzB8K2LbptB3TYPXh0/op5EtvaqKp5njydgg4SSCxeoZfPoIA13O5vHOMApHoNlTyw WEhC8ssSf9l50T+arkECeoBJWlDY6IuNNLKL5mzZyBbW39M2lYbM+wrPIDqC4dpiUjIO vM1gqLLvc0hp/MLFf+d2NPTvAi/4o2Q6+ea7oezP0EfD5kXmK6WHbwgJ8GIUgBCLBK4u dEwQ==
X-Gm-Message-State: ALoCoQkg+tlkfdGFHIYCKr5Rj7CV1CsU5fLjSlNzrgFUi9iZEJRfG8Gk0aNqFt1G7pNrno1uO59d
MIME-Version: 1.0
X-Received: by 10.60.155.195 with SMTP id vy3mr10906820oeb.62.1421443146306; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Fri, 16 Jan 2015 13:19:06 -0800 (PST)
In-Reply-To: <CAL9PXLyeE+Nh5hKf3zigDHe3UXpNrMr=Dn14WudsaKUwvzprTw@mail.gmail.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <20150116210327.61046788@pc> <CAL9PXLyeE+Nh5hKf3zigDHe3UXpNrMr=Dn14WudsaKUwvzprTw@mail.gmail.com>
Date: Fri, 16 Jan 2015 13:19:06 -0800
Message-ID: <CAFewVt6EOf7VVfuavqccsz_0CDjPXbsG=qWPZQ61=2pk4XVKmw@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/djr1Dho6BQw1Knqrs93LUMDQQ2o>
Cc: "tls@ietf.org" <tls@ietf.org>, ietf@ietf.org
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
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: Fri, 16 Jan 2015 21:19:08 -0000

Adam Langley <agl@google.com> wrote:
> On Fri, Jan 16, 2015 at 12:03 PM, Hanno Böck <hanno@hboeck.de> wrote:
>> Recently Mozilla has disabled the now so-called protocol dance, which
>> makes adding another workaround (SCSV) pretty much obsolete:
>
> Until they add TLS 1.3 support, when they'll need it again.

I don't think so, because we can change the way versions are
negotiated for TLS 1.3, so that the issue doesn't arise. In
particular, we can keep ClientHello.client_version as 0x0303 (TLS 1.2)
and negotiate TLS 1.3 with an extension.

Also, the rate of TLS 1.3 intolerance might be significantly lower
than projected. Ivan's numbers are based on a ClientHello with 0x0304
(TLS 1.3) as the record-layer version number. We know from past
experience working on NSS that 0x0301 (TLS 1.0) is a more compatible
record-layer version number. I think it was established that many
servers work fine when ClientHello.client_version = 0x0304 (TLS 1.3)
as long as the record-layer version number is 0x0301 (TLS 1.0) but
break when then record-layer vsion is 0x0304 (TLS 1.3). We'll need to
measure this in a more definitive way, but there's reason to be
optimistic.

Cheers,
Brian