Subject: Re: [TLS] TLS Digest, Vol 155, Issue 13

From: Sankalp Bagaria <[email-masked]>
Date: Wed, 7 Jun 2017 13:56:56 +0530

>
>
> Message: 3
> Date: Tue, 6 Jun 2017 16:23:24 +0200
> From: Hanno B?ck <[email-masked]>
> To: [email-masked]
> Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
> Message-ID: <20170606162324.4aee493b@pc1>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, 6 Jun 2017 09:20:03 +0200
> Sean Turner <[email-masked]> wrote:
>
> > I appears that we?ve got enough consensus/interest to adopt
> > draft-ghedini-tls-certificate-compression-00 based on the WG session
> > in Chicago and this thread:
>
> Hi,
>
> one aspects brought up in that thread was that there is already RFC
> 7924, which allows certificate caching. There's also AIA, which allows
> a client to fetch intermediate certificates, however as far as I can
> see there's no way for a server to decide whether a client supports AIA.
>
> All of these technologies seem to try to tackle the same problem:
> reduce the burden of transmitting certificates.
>
> I wonder if there should be more a big picture discussion here. If
> clients have a good way of caching certificates - would that mean
> transmitting them is so rare that compressing becomes unnecessary?
>
> Also regarding 7924: I tried to find out what server and client software
> supports that. I didn't find anything. One could see that as an
> indication that it's not a big deal after all. If people are concerned
> about the data wasted by transmitting certificates, I wonder if it
> wouldn't be a more important issue to implement the already existing
> tech that's available instead of inventing new tech.
>
>
> --
> Hanno B?ck
> https://hboeck.de/
>

Dear Hanno,

This issue was raised by me also on April 5, 2017. I got the following
reply.

Regards,
Sankalp Bagaria.

On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <[email-masked]> 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 certificateinformation 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 :)