Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Wed, 26 March 2014 22:21 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 85BA21A03DC for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 15:21:51 -0700 (PDT)
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 zmA8y9LePDPM for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 15:21:49 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 87E871A03DB for <tls@ietf.org>; Wed, 26 Mar 2014 15:21:49 -0700 (PDT)
Received: by mail-yk0-f177.google.com with SMTP id q200so1437543ykb.36 for <tls@ietf.org>; Wed, 26 Mar 2014 15:21:47 -0700 (PDT)
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=yag/opBLYZNg05GhPkLCf5T0vVQZ9HyXuK3+FsQGTh4=; b=kgyPd9oUu7fBDXC3z3ffNcd0yE2AsrXBOnENEfc2fFSC96F2DTw1lgOSoqorM9Ig3q kkbfncTbqXaHgxk2JY01PfelmCOC2a478GuCSv3TIqRCnxzm/9CN1fKQjKDESasg4DtV eqpqHxjbHW2DZxIXah30+GsXDY11nljfePDq3crOyE2lThu24PX+9IpWoDCuTXyja+xj p7bAwWoQoBx6ZA9odks8xApY6xOwus4q4L5hhenAI96ur6oS0UMVf3kA+4uMOmyVfWyH a5CBkpLkw2NbYnf091joMCpS7GH+MSOGQvDKizpNpJ9pYdq8eul7Ut43XxVI0zivzmDE DfGg==
MIME-Version: 1.0
X-Received: by 10.236.134.71 with SMTP id r47mr39676196yhi.83.1395872507913; Wed, 26 Mar 2014 15:21:47 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Wed, 26 Mar 2014 15:21:47 -0700 (PDT)
In-Reply-To: <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp>
References: <2E8232FA-CFDF-42AA-A405-0B080EFE0135@rhul.ac.uk> <20140326220200.6A9781AC7D@ld9781.wdf.sap.corp>
Date: Wed, 26 Mar 2014 18:21:47 -0400
Message-ID: <CACsn0cmBN9F1f416tFvWa4LPTCGwdLrP82qHuYDpPUhmVjyJNw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iHJ5U99ZAk9g6JrS1knsye9yq_0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirmation of Consensus on Removing Compression from TLS 1.3
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: Wed, 26 Mar 2014 22:21:51 -0000

On Wed, Mar 26, 2014 at 6:02 PM, Martin Rex <mrex@sap.com> wrote:
> Paterson, Kenny wrote:
>>
>> Really? I assume you know about CRIME??
>
> Yes, I do.  Similar to BEAST, it is *NOT* an attack.
> It is a pretty boring demonstration of the principle of operation
> of querying an encryption oracle (BEAST) or compression oracle (CRIME).
>
> None of the alleged "fixes" against BEAST and CRIME addresses the
> real vulnerability.  Even with compression disabled and TLSv1.1+ or
> AEAD cipher suites, the vulnerability is WIDE OPEN.  The attackers
> code could, rather than performing a demonstration of a boring
> principle, submit any attacker-desired nefarious request to the
> server, the Browser will blissfully insert the authentication-credentials
> into that nefarious request, and the server will blissfully execute
> the request.  No matter what fancy stuff the TLS WG puts into TLSv1.3,
> the attack will continue to work as long as the browser keeps doing
> the stupid stuff: volutarily and blissfully inserting authentication
> credentials into requests that the browser performs on the attackers
> behalf.

This is called a CSRF, and has been known for a long time. The
solution is to use capability-like URLs, with unguessable content.

BEAST goes further: it exposes to the adversary credentials, rather
than letting the adversary use some of them through controllable
means. Sometimes you need to take advantage of this browser behavior:
OAuth I believe relies on being able to make cross-site requests with
the user credentials, as does single-sign-on.

Furthermore, BEAST also affects VPNs built on TLS, where you don't
have an option but to pass possibly adversarially influenced traffic.

Sincerely,
Watson Ladd
>
>
> -Martin
>
> _______________________________________________
> 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