Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Watson Ladd <watsonbladd@gmail.com> Mon, 27 January 2014 00:24 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 3DA801A016C for <tls@ietfa.amsl.com>; Sun, 26 Jan 2014 16:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_12=0.6, 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 tjWjzpK8r7Dz for <tls@ietfa.amsl.com>; Sun, 26 Jan 2014 16:24:04 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4148A1A0169 for <tls@ietf.org>; Sun, 26 Jan 2014 16:24:03 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x13so4949997wgg.27 for <tls@ietf.org>; Sun, 26 Jan 2014 16:24:01 -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=gTBFC45TNRevlbu9o4nb/FSEFlq93uLyVH6CcgMKUiE=; b=SQw9p6Lo6hX7KKO6JK4RRpzqAppE8SVTXmbNHyBJHykKvgxyD99KD9RT8TPB54kvWR p9kX3G50+OIiOly17dV9gF7AmM4YPHK29EwRCVb2ne30pQMyFvTmzjtdjOnymh6GNGwA y1XhEe/tYMXNwczFr1AIfB+1nKEYuzxc6m0S5aNGy100ldOCTz2lUQtHOfvE7ZlDuez/ lIb6xaBhZzSF1JwLMMoLktX/E6pKkwqWgMf0ub0zDzK40j5FltfM79dKhULj5RwK2yrP THj2CIR1xBSkQbiADa5sOck5PaIAc24E02Mh+igP1i8fptRscmXdVdrZMGMKX/GtESyG fzqw==
MIME-Version: 1.0
X-Received: by 10.195.13.113 with SMTP id ex17mr18348790wjd.0.1390782241538; Sun, 26 Jan 2014 16:24:01 -0800 (PST)
Received: by 10.194.250.101 with HTTP; Sun, 26 Jan 2014 16:24:01 -0800 (PST)
In-Reply-To: <BLU0-SMTP1349A2413CE03D01E0FAA96B1A30@phx.gbl>
References: <CABcZeBP_-MUonYYsxgz2ZdokiEDVhx4mYq1a4BMayuGbbxb2Gg@mail.gmail.com> <BLU0-SMTP1738DF906BCBD666044DA2AB1A30@phx.gbl> <52E540F4.6090007@fifthhorseman.net> <BLU0-SMTP1349A2413CE03D01E0FAA96B1A30@phx.gbl>
Date: Sun, 26 Jan 2014 16:24:01 -0800
Message-ID: <CACsn0cmqmmxzehWJHxy6PzdqiC=WqnD_aySYqhhaVsQYXRF8=w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Yoav Nir <synp71@live.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
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, 27 Jan 2014 00:24:06 -0000

On Sun, Jan 26, 2014 at 3:32 PM, Yoav Nir <synp71@live.com> wrote:
> On 26/1/14 7:08 PM, Daniel Kahn Gillmor wrote:
>>
>>   4. An older firewall is dropping the TLS 1.2 connections, because they
>> fail some sanity check. (that all TLS records have 3.0 or 3.1 in the
>> record header)
>> Is this a "sanity check" or an "insanity check" ? :)
>
>
> When attacks are known, it's easy to program firewalls or IPS systems to
> detect them. the problem is unknown attacks. One countermeasure that is as
> old as firewalls is to make a sanity check of what a protocol should look
> like. This is somewhat beneficial. Most buffer overflow exploits and even
> SQL injections would not pass a sanity check. So firewall validations are
> written to common practice, not necessarily to RFC.

How exactly does that hurt this proposal? If the server is behind the
firewall and the SCVC is
recognized, someone screwed up big time: not our fault, they can
always disable the
SCVC check, and it lets them know something is broken. If it's the
client, then this is the calculation
server operators get to make: kick them off, vs. enable downgrade attacks.

The second part is that this behavior is highly suboptimal for
permitting protocol evolution. Part of this
is our fault: validating and parsing incoming data should be done with
as little complexity as possible, reducing
future bugs.
However, it raises a big problem for TLS 1.3: something like reducing
round trips might get blocked
spuriously, or maybe we run into problems with big extensions etc.
More clarity on what is being done here is required, or you need to
tell your customers
"this product can break the internet in ways unanticipated, and it is
our fault". F5 was kind enough to explain
why they broke the internet, and it was for a somewhat good cause.
I'ld like to see future issues like this get
resolved before five years of worry go by.

The third part is that exploits don't necessarily fail sanity checks:
Even if limited to ASCII bytes,
I can most likely find a gadget that does what I need to get inside
within any large codebase. Oddly enough,
I've never seen a CVE where "firewall XYZ prevents exploitation" is
mentioned. You would think firewall vendors
would trumpet these successes if they ever happened. Or think of all
the sendmail bugs exploitable by sending email
to the wrong people: no firewall could ever stop them.

>
> Sometimes this has unintended consequences. 12 years ago, many firewalls
> (including ours) would make a sanity check on TCP: we enforced the sequence
> SYN--SYNACK--ACK--data. Apple introduced some version of Mac OS (I think it
> was 9.2) that had a unique feaure: The first data from the client was sent
> in the third packet instead of following it. For the firewall this was a
> violation of TCP sanity. But as it turns out, this is not prohibited by the
> TCP specs. We fixed our firewall, but I guess this broke some things. I
> haven't seen this behavior again anywhere, and all versions of Mac OS
> following that did not do this*.
>
> So I wouldn't be surprised if there are some version-intolerant firewalls
> out there just as there are version intolerant servers.
>
> Yoav
> (*) Yes, I realize that this has probably more to do with moving to a BSD
> kernel than with traversing firewalls, but it is instructive that nobody
> repeated this experiment.
>
>
>
> _______________________________________________
> 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