IETF Logo Mail Archive

Re: [TLS] Certificate compression draft

Eric Rescorla <ekr@rtfm.com> Wed, 05 April 2017 17:47 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 1A683129407 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 VXvkXM6kyoZa for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:47:12 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 03A05128DF6 for <tls@ietf.org>; Wed, 5 Apr 2017 10:47:11 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id i203so9607027ywc.3 for <tls@ietf.org>; Wed, 05 Apr 2017 10:47:10 -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=tCwlXkmZegbf84Xen7/eLTRptv0MEWA78JBNGFc8f5M=; b=dg8xHnbvj4r8hV1T7rh6Ja2fTLRFQJDj19T18rjuICsY7poRnuVy2gsPKXC/9NZXvl cJLxwMRCzf1P2IzdOfpK0Ew68tfSq31J34du3grZgiZmbiCUrEzQx+ZSs3wzjtYvg7Eb rCLairq2jjOV6o9JKb9nKSOMrTKodeJGY0ky/Xn3WlJa8XGVhfW2Oj04aICtXQSDXxpb YSx/eS2cezYnKJKGkQiGcLVvAiOuVR1Ecn6Bgaxw2dKrvefgGBAXPBb9I2l7dzEeYWsw POiqKjxiu5eIqBxyqJVSlqn4v7zFpmZf0OPROboRgBvoPwGS3nDeygsDPtQfNMewxiB5 KMeA==
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=tCwlXkmZegbf84Xen7/eLTRptv0MEWA78JBNGFc8f5M=; b=E9eA2rJ09XrmMoFJ8qLhiZUmeNKduw6VEsCRrq9rJ0dr9pvChCMsfxqHMNt1y2uqaQ /B+Uo41NbTjWacyFdKWBO8/3xLVhga64YBTQCxK1V1MUJXt2JHfuaZdeB2twbjqERc9C fyrUpdEbvY2EntwQbYYjiiqs/+yusCVRRIBd0y2KHl5XbpwNVF/9ycZ6SgexZ4aB7/3B BbwsWWENP2ylwVhGm2jPewO/CyxROT3rLp5Wlr8jpFOqqzgfilEujERFXVfDE29Dq6qk 5Ou6oCEgXWiJHy5xVt6wqU04IlN83EXujVjO2vTWezdsSlzf1QIaFSPI6cdmmxXqNcqg skZQ==
X-Gm-Message-State: AFeK/H1Rsn+4XyQai0vj5vW4NJeIrlqWC8bCJsLp+cDN1NT3ntE/BBEp5TF1zS9hR52uZWpl35AH3UMseodlDA==
X-Received: by 10.129.172.23 with SMTP id k23mr20278348ywh.337.1491414430179; Wed, 05 Apr 2017 10:47:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Wed, 5 Apr 2017 10:46:29 -0700 (PDT)
In-Reply-To: <CABcZeBP73rQsaWsMTX+n76ZAZJWh2Hq152h44wDO6pgXw30j2A@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> <CABcZeBP73rQsaWsMTX+n76ZAZJWh2Hq152h44wDO6pgXw30j2A@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 05 Apr 2017 10:46:29 -0700
Message-ID: <CABcZeBOQ+yca+74y6DA3sx+T9z9M_oBLDeVmhLs9GKdTT3bFUA@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="94eb2c1bae0053076b054c6efbc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WGxhUKZotL2VgwqYcKTL6jvCIg8>
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:47:15 -0000

On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla <ekr@rtfm.com> wrote:

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

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

-Ekr


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

v2.23.0 | Report a Bug | By Email