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

Tony Arcieri <bascule@gmail.com> Sun, 04 October 2015 20:16 UTC

Return-Path: <bascule@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 BA7261A1B96 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 13:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 nwgtKOt-F3-8 for <tls@ietfa.amsl.com>; Sun, 4 Oct 2015 13:16:29 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 EACD31A1B8C for <tls@ietf.org>; Sun, 4 Oct 2015 13:16:28 -0700 (PDT)
Received: by iofh134 with SMTP id h134so166917644iof.0 for <tls@ietf.org>; Sun, 04 Oct 2015 13:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ocBoMqG5IMG0t/GVHyEZB6roDaV7aGUkYiEWOhc/sZ0=; b=K8uXB5cFu/nGTUpfDzfQacJYY1SDad9owpU7iLZpw6awQl2uRy44RoFiEqhq1Hh6qP IXYwXDbZlLnRSGH7+kdelj6q39arBK1jxiq48+GQctnf1l/ZTq6r0c28PFR3HjaLnSgf 9hFeS5rIGEHHz2MnYIAR4irccE/0hlEe+dU8UlfnTAeYUez/AHiI3RLn++v9/AMOndxl Qd637XWZ2OXBlQG2BgKnyF/FC9rFHlZS8Z50kIboeT/qOe3YRRl0Fv6kLu0H5wOVlGqR p/y00VKEu1H7j2wzirdoOyd2PHtBP8IU83FAzhsbP/ipky+4RNdzAxdL4s/rXDwwp4Vc EItA==
X-Received: by 10.107.130.220 with SMTP id m89mr25714724ioi.146.1443989788347; Sun, 04 Oct 2015 13:16:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.19.67 with HTTP; Sun, 4 Oct 2015 13:16:08 -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>
From: Tony Arcieri <bascule@gmail.com>
Date: Sun, 04 Oct 2015 13:16:08 -0700
Message-ID: <CAHOTMVLnKRV=KJE4t-ry1MxyrCEvNGZdjbzq9KH3AB9JR7ekUg@mail.gmail.com>
To: Jeffrey Walton <noloader@gmail.com>
Content-Type: multipart/alternative; boundary="001a113eee3c64d52505214d12af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ej6oXkAAdx2ZzvyBo5yi3fWuwPw>
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:16:30 -0000

On Sun, Oct 4, 2015 at 1: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.
>

No, you're just not following the conversation or understanding the
concepts.


> 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.


Doing compression safely/securely is an application-specific problem.

Using constant bitrate perceptual coding allows us to compress audio/video
streams in such a way that there is no compression side-channel, because
the data rate is kept constant per unit time.

If we were to try to use TLS compression instead, not only would it fail to
compress as well, but it would have a compression side-channel an attacker
could use to potentially recover a transcript of an encrypted conversation
(such attacks against against VBR audio compression).

TLS is the wrong layer at which to solve the problem of compression.

-- 
Tony Arcieri