Re: [TLS] potential attack on TLS cert compression

Victor Vasiliev <> Thu, 19 April 2018 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A182126D73 for <>; Thu, 19 Apr 2018 14:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Bqf3ieOD7kW for <>; Thu, 19 Apr 2018 14:40:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F32C12420B for <>; Thu, 19 Apr 2018 14:40:50 -0700 (PDT)
Received: by with SMTP id v2so6922191qkh.10 for <>; Thu, 19 Apr 2018 14:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/VxslnJSjzv+kElpS6s5Q8IMzTpajAeZaaZToF4MNBA=; b=o7aXLS+gAukkyjla/iP/Ev0+W+DFT11yONhp2ig3NZgpnlT/h+eWTSNB5Hvd7MsUif On9gbLd5Y8rNQPeDKJxA08B831QzImtEqbZze0pt1iFmYo5AHCFrJTRZWp1v20avWN3X ly6JtdkdtW2SywQw++/dhuhaynXys+LXu2CtVNt2ly83antTGW+EhEkNK7q1Vv8Utk30 g2e4I/0CZrnk7MWXT9UyzQq5XogayZAywvMksU0jwoKPpV4TEcw6Yh1A2i1qlN/EEYoI dgozl3kRfr6cTZMVR3VMW5rCpZIL1OcxTePr7QVaKC7EBxAwSzJNHNUgks+koBUarBvo 9tPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/VxslnJSjzv+kElpS6s5Q8IMzTpajAeZaaZToF4MNBA=; b=I+DwijFZ4gQ0oEqsEweRs35QhFTG836EVEP3ynAjgpscqxY95SjIncwXk/7VxSNKz6 aB/CePNNGKaKHMol8UbltV/zVU+3xd73ovdRIsHK1efwpWO6dRLvp8gk/lCKiwwSkBI3 zw9IJzz1ksPuP2P8dVanD/aR8MZlt1R1dVszyxLcf/joUI1CrbPQVN6uqGfZL9buAl+7 igwlDygUNlZfPZ4jUgXJp5CE++pH7BikH8I6pXNHxApfdNM0BLOI1l5O0QUb81Ai3/LM QAUt/DxrHLw7PSfBc4m25J+W0A2XjZ4l2stCJuxCv9lO/kjE32/GLjgZBItboqa0jxM6 NzMQ==
X-Gm-Message-State: ALQs6tDR3zPdmIdKQebO3TEeKeDqx3ShfLORnx6//wSZSTp9112luG0+ 0oWbr80Wl/I7nCrLkWLQUUwKUgQRyzH40mb3I6D+AUW6
X-Google-Smtp-Source: AB8JxZqeA3WWhHu/LEVnggkUFlkVIRSs8+5Db2RR0UWPoOCD3Bx5rMOuTl33+Vuxm2AfBPRclWv0NG32b1fHshZsJtE=
X-Received: by with SMTP id j80mr8356075qkh.23.1524174048999; Thu, 19 Apr 2018 14:40:48 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Apr 2018 14:40:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <20180322171000.GA23594@LK-Perkele-VII> <>
From: Victor Vasiliev <>
Date: Thu, 19 Apr 2018 14:40:48 -0700
Message-ID: <>
To: Thomas Pornin <>
Cc: Ilari Liusvaara <>, "" <>
Content-Type: multipart/alternative; boundary="001a1142980cc50856056a3a6caf"
Archived-At: <>
Subject: Re: [TLS] potential attack on TLS cert compression
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Apr 2018 21:40:52 -0000

Did we ever reach any agreement about what to do here?

For me, the threat model here seems fairly far-fetched and infeasible, in
the sense that the threat only exists in some very specific bugs in
multithreaded decompressor.

I'd be less reluctant to do this if it were not for the fact that all
solutions I've considered for this are quite annoying.  Putting the hash on
the wire means wasting bytes, and altering the transcript hash introduces a
lot of complexity into some implementations.

On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin <> wrote:
> Certificate compression would be challenging to implement, though.
> Usually, compression relies on at least a "window" over the decompressed
> data (32 kB for Zlib/Deflate). Some rudimentary forms of compression
> don't need that (e.g. run-length encoding) but usually offer poor
> compression ratios. A 32 kB window is a lot for the kind of architecture
> that BearSSL targets.

This is roughly my intuition -- you could parse certificate messages in a
streaming manner, but if you're on a sufficiently limited platform that
this is a worthwhile investment, you're probably not going to use
certificate compression anyways.