Subject: Re: [TLS] Certificate compression draft

From: Sankalp Bagaria <[email-masked]>
Date: Wed, 5 Apr 2017 11:05:46 +0530 (IST)

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?

Another point that need to be seen is that the time required to compress/
decompress is not more than the savings got in transmitting a compressed
certificate (smaller in size than complete certificate).

Thanks and Regards,
Sankalp Bagaria.

On Mon, Mar 6, 2017 at 2:58 PM, Victor Vasiliev < [email-masked]
<mailto:[email-masked]> > wrote:

>  Certificate   compression  has been discussed on this list briefly before,
> and
> there was some interest in at least considering a  draft  for it.  The  draft
> now
> exists (co-authored by Alessandro and myself), and it can be found at:
>
>  https://datatracker.ietf.org/doc/draft-ghedini-tls-
> <https://datatracker.ietf.org/doc/draft-ghedini-tls->
>  certificate - compression /
>   [ GitHub repo:  https://github.com/ghedo/tls-certificate-compression
> <https://github.com/ghedo/tls-certificate-compression>  ]
>
> The proposed scheme allows a client and a server to negotiate a  compression
> algorithm for the server  certificate  message.  The scheme is purely opt-in
> on
> both sides.  The current version of the  draft  defines zlib and Brotli
>  compression , both of which are well-specified formats with an existing
> deployment experience.
>
> There are multiple motivations to compress certificates.  The first one is
> that
> the smaller they are, the faster they arrive (both due to the transfer
> time and
> a decreased chance of packet loss).
>
> The second, and more interesting one, is that having small certificates is
> important for QUIC in order to achieve 1-RTT handshakes while limiting the
> opportunities for amplification attacks.  Currently,  TLS  1.3 over TCP
> without
> client auth looks like this:
>
>   Round trip 1: client sends SYN, server sends SYN ACK
>     Here, the server provides its own random value which client will
>     have to echo in the future.
>   Round trip 2: client sends ACK, ClientHello, server sends
> ServerHello...Finished
>     Here, ACK confirms to server that the client can receive packets and
> is not
>     just spoofing its source address.  Server can send the entire
> ServerHello to
>     Finished flight.
>
> In QUIC, we are trying to merge those two rounds into one.  The problem,
> however, is that the ClientHello is one packet, and ServerHello...Finished
> can
> span multiple packets, meaning that this could be used as an amplification
> attack vector since the client's address is not yet authenticated at this
> point.
> In order to address this, the server has to limit the number of packets it
> sends
> during the first flight (i.e. ServerHello...Finished flight).  Since
> certificates make up the majority of data in that flight, making them
> smaller
> can push them under the limit and save a round-trip.
>
> Cheers,
>   Victor.
-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 5 Apr 2017 10:12:31 -0400

On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <[email-masked]> wrote:

> Only case I can think of is - when the certificate is being sent for the
> first time,

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 :)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Apr 2017 07:21:47 -0700

> That was certainly true for TLS1.2

This will also be true in TLS 1.3, even with encrypted certificates because
(hopefully) they
will be a lot smaller. Though you could of course pad out to the same size
:)

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 11:14:26 -0500

On 04/05/2017 09:21 AM, Eric Rescorla wrote:
>
>
> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hello,
>          
>         Only case I can think of is - when the certificate is being
>         sent for the first time,

The authors presented work noting that reducing the certificate size
when the client is first talking to a server can be useful to keep the
server's first flight into a certain number of packets, useful to avoid
hitting congestion control backoff and/or a cap on (reply size / request
size) to avoid DDOS amplification attacks, as for QUIC.

>     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
>
>
> This will also be true in TLS 1.3, even with encrypted certificates
> because (hopefully) they
> will be a lot smaller. Though you could of course pad out to the same
> size :)
>

The elephant in the room being that an attacker watching the network can
replay the observed ClientHello but using its own KeyShare and read the
resulting encrypted certificate reply.  (h/t davidben)

-Ben

---

From: David Benjamin <[email-masked]>
Date: Wed, 05 Apr 2017 17:15:50 +0000

> resulting encrypted certificate reply.  (h/t davidben)

(Supposing that the server is a traditional server that accepts multiple
requests and does not select the certificate based on external factors in
the transport or elsewhere, which means you're selecting by things not
covered by TLS's transcript.)

Also, while one could compressed pad up to uncompressed length and make
compression useless, hiding whether your certificate was compressed is not
a plausible goal. More plausible is hiding which certificate was selected.

Without compression, your certificates still have different lengths, so you
would need to pad up to max(certificate_message(cert) for cert in certs)
anyway, where certs is all identities your particular server wishes to make
indistinguishable. Maybe chunk up to a boundary beyond that if you want.

With compression, you pad up to max(compress(certificate_message(cert) for
cert in certs). Maybe chunk up to a boundary beyond that if you want.
(Packet boundary for the QUIC use case?) This means you're now bound by
your worst cert rather than your selected cert, but one could still expect
a size win.

This is, of course, all assuming your server setup is somehow such that the
above pachyderm doesn't apply.

David

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Apr 2017 10:45:38 -0700

On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin <[email-masked]>
wrote:

> Without compression, your certificates still have different lengths, so
> you would need to pad up to max(certificate_message(cert) for cert in
> certs) anyway, where certs is all identities your particular server wishes
> to make indistinguishable. Maybe chunk up to a boundary beyond that if you
> want.
>
> With compression, you pad up to max(compress(certificate_message(cert)
> for cert in certs). Maybe chunk up to a boundary beyond that if you want.
> This is, of course, all assuming your server setup is somehow such that
> the above pachyderm doesn't apply.
>

Sorry, yes, I should have mentioned this, especially as I just made the
same point to someone
else the other day.

I think there are two threat models here:

1. Active attacker
2. Passive attacker.

As you indicate the active attacker can elicit the server's certificate by
replaying CH
with his own KeyShare (this is part of what makes SNI encryption so hard).

For a passive attacker, as David suggests, you can hide which cert was
selected
by padding up to the largest cert (whether the cert was compressed or not).
That
may or may not be valuable depending on the scenario [for instance in
WebRTC].
As you say, I don't think you can hide the cache hit even from a passive
attacker
because then you would need to pad up to an unreasonable amount.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Apr 2017 10:46:29 -0700

> with his own KeyShare (this is part of what makes SNI encryption so hard).

Or of course, if we had an SNI encryption mechanism that tied to KeyShare.

-Ekr

> by padding up to the largest cert (whether the cert was compressed or
> not). That

---

From: Sankalp Bagaria <[email-masked]>
Date: Thu, 6 Apr 2017 15:09:16 +0530 (IST)

Hello,

I see your point regarding privacy and complexity arising in cache-info. Should
we use compression then instead of cache-info every time ? When should
we use cache-info and when should we use compression ?

Thanks and Regards,
Sankalp Bagaria.

>     cached-info can't be used. Are there more cases where compression is

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