Re: [TLS] Certificate compression draft

Ryan Sleevi <ryan-ietftls@sleevi.com> Wed, 05 April 2017 14:12 UTC

Return-Path: <ryan-ietftls@sleevi.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CCB124282 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 07:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.295
X-Spam-Level:
X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com
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 aMpMB5-cY-oZ for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 07:12:35 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB3C1250B8 for <tls@ietf.org>; Wed, 5 Apr 2017 07:12:35 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id A0E79600050D for <tls@ietf.org>; Wed, 5 Apr 2017 07:12:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=DMKC21QK2zSVVpk02Rll92/1MFE=; b= naSA4wGlIDwQLx4KQPPx0YhBGhiyoVTlnHdtD2IupPDEG8PC5gJglNUUkVD5+FHe i9zu5sd2OLi9tr8dL43GBBv+Dkh10ByVoPfpA/KW/xxLeb0ejflC935qCfL/0Mh/ rPz7lR0ldNR8cRJG8YUrKv5+QfxwbqIVDV8bxon/w0w=
Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 6A54F6000504 for <tls@ietf.org>; Wed, 5 Apr 2017 07:12:34 -0700 (PDT)
Received: by mail-lf0-f52.google.com with SMTP id h125so9415477lfe.0 for <tls@ietf.org>; Wed, 05 Apr 2017 07:12:34 -0700 (PDT)
X-Gm-Message-State: AFeK/H3UduTNdFhSplGEsrnWadMiVzsqnBCYw8TNJz3moPdr6DUoYxt27bZIiYfjScAqMUDkpdqwV1yC5qZyfQ==
X-Received: by 10.25.0.207 with SMTP id 198mr9851917lfa.134.1491401552575; Wed, 05 Apr 2017 07:12:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.193.197 with HTTP; Wed, 5 Apr 2017 07:12:31 -0700 (PDT)
In-Reply-To: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in>
References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Wed, 05 Apr 2017 10:12:31 -0400
X-Gmail-Original-Message-ID: <CAErg=HFM_QDXSQHir8+eViT9+H7t5G2_pLbFhGspzZ+vH6Q-Fg@mail.gmail.com>
Message-ID: <CAErg=HFM_QDXSQHir8+eViT9+H7t5G2_pLbFhGspzZ+vH6Q-Fg@mail.gmail.com>
To: Sankalp Bagaria <sankalp@cdac.in>
Cc: "tls@ietf.org" <tls@ietf.org>, R Balaji <balaji@cdac.in>, "Bagaria, Sankalp" <sankalp.nitt@gmail.com>
Content-Type: multipart/alternative; boundary="001a113c9f48c252d5054c6bfb6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OcTy0OoaBlT2y4Ce0n1F5GN-dSc>
Subject: Re: [TLS] Certificate compression draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Apr 2017 14:12:37 -0000

On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <sankalp@cdac.in> wrote:

> Hello,
>
> How is Certificate Compression advantageous over tls cached-info extension?
> Only case I can think of is - when the certificate is being sent for the
> first time,
> it can be compressed. Since the client doesn't have a copy of the
> certificate,
> cached-info can't be used. Are there more cases where compression is
> useful?
>

Does cached-info not represent a privacy info-leak by disclosing past
sessions prior to authenticating the new session? Versus compression, which
limits it to the session and thus reveals no new/additional information.
That was certainly true for TLS1.2

Is compression not a simpler implementation - given the 'two' hard problems
of computer science (caching, naming, off-by-one)? For example, you'd need
to maintain a per-host cache of certificate information to meaningfully
make use of it (... or else you end up with cross-origin state leakage, at
least in the context of a browser, which is a Bad Thing). You would either
need to read that information from stable storage prior to making the
connection (so that you can negotiate the cached info), or you'd need to do
a lazy-path where you index the cached entries and send those as available
to the server, while in parallel beginning to load those entries. If those
entries are corrupted, but used in the connection, the connection will
fail. If those entries are removed during the connection establishment, the
connection will fail.

In short, cached-info represents a much greater degree of complexity and
questionable privacy (both cross-origin and same origin - again, something
relevant for browsers, but perhaps not relevant for others). Let's keep it
simple :)