Re: [TLS] TLS 1.3 - Support for compression to be removed

Watson Ladd <watsonbladd@gmail.com> Sun, 04 October 2015 20:10 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 985541A1B29 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 13:10:52 -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 Lqx8zaD2rvno for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 13:10:51 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BA11A1B2B for <tls@ietf.org>; Sun, 4 Oct 2015 13:10:50 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so89228766wic.1 for <tls@ietf.org>; Sun, 04 Oct 2015 13:10:49 -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:content-transfer-encoding; bh=53pkuYWow8+x6mYjg0z9I5k4JDVL+r24yJpcgvXdJC4=; b=tz0keRqLO3f7f0KgJDBzoMM0i4XslUDM0QeX1fcFneDmEvYscK+OXGHnd7cGpldi42 yrUfhQ6mWV4V0rjb6Q+UlDWkvQOnTQiEtmPbVbw9JvetW+HFc9TBylI3JJoJMa9BrVAg mKbPg4BuGFiEw6WfPXgvDYgeNWAenActXNyZG2nK/mvwuVhlYdhrI5sq+KVcqhmZXxXt 67YBeDCzLl82HNZ/kEUBrTKfo9EDHEe+N6stoA/oJjQQ1ciB8v6p0OSOcbeRbKypfqYI 1pvregSZKmpY1HaivtglDYeeSBK07UX30G4AhbXxOnUec4/4/GAKnPozhG6oFIC9m+rT uXqg==
MIME-Version: 1.0
X-Received: by 10.180.198.142 with SMTP id jc14mr8370408wic.32.1443989449196; Sun, 04 Oct 2015 13:10:49 -0700 (PDT)
Received: by 10.28.51.145 with HTTP; Sun, 4 Oct 2015 13:10:48 -0700 (PDT)
In-Reply-To: <CAH8yC8=Yze=ByftxFUkSy8y2e7q0EijkxGtYjWOe7fEO66iODw@mail.gmail.com>
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <201510041450.24540.davemgarrett@gmail.com> <CAHOTMV+G6CRgX0YPQ-HmG06rd6ttOaoXKF+HwacTiEGwJ+_vkg@mail.gmail.com> <201510041527.04800.davemgarrett@gmail.com> <CAH8yC8=Yze=ByftxFUkSy8y2e7q0EijkxGtYjWOe7fEO66iODw@mail.gmail.com>
Date: Sun, 04 Oct 2015 16:10:48 -0400
Message-ID: <CACsn0cmH5Nco_AGXE3ec_GapCryZZPrXGVFh6YhLtcFnams__g@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: noloader@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FGprBmBZXK3_h7ArP7lTJfzDA9I>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 04 Oct 2015 20:10:52 -0000

On Sun, Oct 4, 2015 at 4:01 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>>> Typically compression is used to lower the overall size of data, working on
>>> a wide class of inputs. In the perceptual coding case the class of inputs
>>> is constrained, and the goal is to keep the data rate constant, not
>>> optimally small.
>>
>> Yep. You could do this in bursts with different caps each time to get it to work with bursty things like HTTP & other general data transfer protocols. Without a really good modern compression algorithm, though, it isn't that appealing. Once these caveats and tweaks start getting added to the simple concept, it starts treading into the territory that is better handled by the application protocol that actually *knows what it's sending*. This seems to be the logical wall we keep hitting, which is why TLS doesn't seem like the place to do this.
>>
> I think two concepts are blending into one.... You appear to be
> arguing for efficiency, and I'm more concerned with safely/securely.
>
> I'm fairly certain the internet community at large would benefit from
> "compression done safely/securely", even if its not the most
> efficient. If the application layer wants to provide a more efficient
> implementations, then that's fine too.
>
> I think this I where things now stand (if I am surveying correctly):
> (1) TLS WG did not fix the problem (bad); (2) users don't have a
> choice (bad); (3) applications will have to provide their own
> compression when desired, which will likely increase overall risk for
> users (bad). For (3) keep in mind browsers are not the only user
> agents or consumers of web services.
>
> All-in-all, I think its a win for NSA, GCHQ and other miscreants; and
> an overall loss for user.

As we've tried to explain to you, TLS is a channel encryption
abstraction, and does not know which parts of the stream of bytes it
is being asked to send are controlled by who. Absent this information,
there is no way to know what can be compressed how. By contrast
applications know this information, and can design the compression
scheme accordingly. How does this increase risk over TLS providing an
inappropriate scheme which isn't secure?

>
> Jeff
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.