Re: [TLS] Certificate compression draft

Eric Rescorla <ekr@rtfm.com> Wed, 05 April 2017 17:46 UTC

Return-Path: <ekr@rtfm.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 940F3128DF6 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 E0i5vOE98ekv for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:46:19 -0700 (PDT)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 38057126C26 for <tls@ietf.org>; Wed, 5 Apr 2017 10:46:19 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id i124so4979404ybc.3 for <tls@ietf.org>; Wed, 05 Apr 2017 10:46:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/8Mt3M47/qTIYQblTWWTeB9RB3RcLJcnGmxDqxEppTk=; b=GTdL9Tc+VKxu3/kgre/Q8O3F9LkM+eUHOGVU4cfEehwXChE/i5+asAPsOjefwVIniS GuEMW4EhGfOd+PpFLzkcgQ5ErCkayveHhZhprceM9pwWG8Lom09HBi01/QH1vJQF4HYB saEPKxj+i8PdH3UnYLinwrr3cCDZaGYbo1JpOqM+M+UHypP6jg8rnPZH0uz0Vvg8Qh1J 7pP/FQG066tK0ELqKzwEO7Te5MJIbimRzaU5yMAgFbLARYBu0Z+Gd/BmoTDDbI0LiFsA MXc1hZInFlCMQI3M5urgYkdV6vPPsGt+zFHE0DeXT9fNdH6itCWiKBQJh0GjVH4YHXAO T7FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/8Mt3M47/qTIYQblTWWTeB9RB3RcLJcnGmxDqxEppTk=; b=WxLiFAyjwRjq5rQ/FlvCvsssobIIk4J2dVe4lMW8ADtvgrTJjsddPoiudce5MFzJh8 LHcQdp2l/lM+BqaSV2kQQsqxXjoLyhSqDWAAfIMXdr7pYV6MDYmXKVKjA82ljo6HLocy D561ynQhpP6Frf02JBXvdKuhjMG4asuqSVLl5LiVPDz83TjSOuqvY0rYt67WZ1PbgbDv dexQma2UWDQ6WsdoewrKzKBItl22kdkV/gxg1x1cljzrKyS2Qtuyf7eG3+EwzHYKVhfX sKYGmrXa0unSumcJ0zRcYtWNiUgWHBer0iO2IWsqeTAFF6dDOOJH5PNY9YBEfBYfjQxB LpXg==
X-Gm-Message-State: AFeK/H2RQAaNC8dpG2vXq2hnEreXESrugoyPbhV1KpEHU6Otg5OLr70DrmwUatlueoz7skyzhrB+ylDB00Ikfw==
X-Received: by 10.37.179.28 with SMTP id l28mr18654376ybj.107.1491414378406; Wed, 05 Apr 2017 10:46:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 10:45:38 -0700 (PDT)
In-Reply-To: <CAF8qwaBJj1vw6aLoNCrKq_sB5NXJnmRD2bvWj1MLZD1pTRBdyA@mail.gmail.com>
References: <1417765250.1980.1491370546230.JavaMail.open-xchange@webmail.cdac.in> <CAErg=HFM_QDXSQHir8+eViT9+H7t5G2_pLbFhGspzZ+vH6Q-Fg@mail.gmail.com> <CABcZeBMQ5wwkW2u7BToo+o86H9omL5wH7+595LXz+fjtYLa8NQ@mail.gmail.com> <b21286ab-02ae-745a-fcae-8e86d6f484e0@akamai.com> <CAF8qwaBJj1vw6aLoNCrKq_sB5NXJnmRD2bvWj1MLZD1pTRBdyA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 5 Apr 2017 10:45:38 -0700
Message-ID: <CABcZeBP73rQsaWsMTX+n76ZAZJWh2Hq152h44wDO6pgXw30j2A@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, Ryan Sleevi <ryan-ietftls@sleevi.com>, R Balaji <balaji@cdac.in>, Sankalp Bagaria <sankalp@cdac.in>, "Bagaria, Sankalp" <sankalp.nitt@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=f403045f29103cfb17054c6ef8ae
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/R0PuUqC-NUQkJAgXTZd6Wlssrt4>
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 17:46:22 -0000

On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin <davidben@chromium.org>
wrote:

> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
>
>> On 04/05/2017 09:21 AM, Eric Rescorla wrote:
>>
>> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi <ryan-ietftls@sleevi.com>
>> wrote:
>>
>> 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)
>>
>
> (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.
>

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