Re: [TLS] Certificate compression draft

Victor Vasiliev <> Wed, 22 March 2017 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD1CA1274D2 for <>; Wed, 22 Mar 2017 14:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 0DdbVZe68mYY for <>; Wed, 22 Mar 2017 14:34:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74B021292D3 for <>; Wed, 22 Mar 2017 14:34:56 -0700 (PDT)
Received: by with SMTP id p22so26519206qka.3 for <>; Wed, 22 Mar 2017 14:34:56 -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=W4pKvtP/hT6O3x4SHuwjF1n9sQ5OATl/np+80NzjOy8=; b=VnnZr00AscShyOToc7FQh8saV6jQmkdm/QRDmZQ2JYlyTlBkGkKsfw0U7ssIiMpFDK O6HO/RP2hxDkedSXLudpN2o3CFWKmPPj3SfgeifbrsEmMQwaF26hgrlelQo7miHNBBzP GMTfZzQ+0HHzXVMkWcyXWFi0OjAOa4x5qSYyQX8LNBy9CmBb01Z2rJjIMLbyqj/Pevsh F6jreOHUIY0Vb1GcPF9QpeTsaZ+6nQBJf50re0t1WJ8y858hz1MV5xsd7laiScYeUeEP rxwL1p6Q+XZ+NcC1GGKW26OeTikTzY0PxMmfryJxnht6LNmT0kykJBrnZ/gyNJwe+N2W NegA==
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=W4pKvtP/hT6O3x4SHuwjF1n9sQ5OATl/np+80NzjOy8=; b=GVu9OnMtZArt7UoL2MWMXvt407gin/uG7rn0ZR+x+ZCTul5F7hWDWUkjDCvoaxFb1R r5Zdp6OJXCVBcWTWzkW7q09syBZ8eKZ15AZxovv/UbU8uMHfZJMDmEoY+a6wHHlN52FZ 7hfMpgAlO7Eqtpypp0ptKJpztqrC/stgkiwzwqdoFdlvRafIVJZMF0VEMwa6PegnbXDJ k0QzULy3E92eorY5lBdMT6JxHjYAHFtw0CJEcQHsgvU663ViqhAol1rrWSmFV2HcbwNY F/VA3eZDn10KMd4X5WrkOkkBpkqJPox2ajEvK42g/GZtgXM+qofqQIB3etUOdxBmaKxk q0Jw==
X-Gm-Message-State: AFeK/H1JVszp3zPQh49VbmXMZ3juGiQcElVVzg6gVJU+5UsNdTENj5BSf/RG362lexzZgugRAXsHXQsiIuvtAAVE
X-Received: by with SMTP id t68mr40738016qkb.81.1490218495259; Wed, 22 Mar 2017 14:34:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Mar 2017 14:34:54 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Victor Vasiliev <>
Date: Wed, 22 Mar 2017 17:34:54 -0400
Message-ID: <>
To: Eric Rescorla <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=94eb2c0554e80c85af054b58880d
Archived-At: <>
Subject: Re: [TLS] Certificate compression draft
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: Wed, 22 Mar 2017 21:35:00 -0000

On Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla <> wrote:

> This proposal seems like a reasonable idea. One question I had is what the
> point of the "uncompressed length" field is:
>        struct {
>             uint24 uncompressed_length;
>             opaque compressed_certificate_message<1..2^24-1>;
>        } Certificate;
> I initially thought maybe it was a sanity check, but if so it's not a very
> good
> one. I see that in S 5 you encourage receivers to limit the compressed
> length, but having it expressed like this doesn't seem like that useful a
> security measure because the attacker gets to choose both the compressed
> data and the length. Is the idea just to let the receiver pre-allocate a
> buffer
> for decompression?

It's to some extent for all of the purposes you've mentioned, but in
general knowing
the size of decompression target makes writing code easier (since you only
to call inflate() once).

> The text says:
>    compressed_certificate_message  The compressed body of the
>       Certificate message, in the same format as the server would
>       normally express it.  The compression algorithm defines how the
>       bytes in the compressed_certificate_message are converted into the
>       Certificate message.
> I assume in this case "body" means "not including the header bytes"? I
> guess it's
> redundant, but it might be worthwhile being very precise

Indeed.  I'll see if I can make this more clear.

> Also:
>    The implementations MUST limit the size of the resulting decompressed
>    chain to the specified uncompressed length, and they MUST abort the
>    connection if the size exceeds that limit.  Implementations MAY
>    impose a lower limit on the chain size in addition to the 16777216
>    byte limit imposed by TLS framing, in which case they MUST apply the
>    same limit to the uncompressed chain before starting to decompress
>    it.
> Do you mean "upper" rather than "lower" for limit?

I meant "lower than 16M".  I've edited the editor's copy to make this
paragraph clearer.

  -- Victor.