Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt

David Benjamin <davidben@chromium.org> Tue, 26 March 2019 16:56 UTC

Return-Path: <davidben@google.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 B2B78120611 for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 09:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Vv8fw-mo83sj for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 09:56:27 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 8887F120372 for <tls@ietf.org>; Tue, 26 Mar 2019 09:56:27 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id p20so15401527qtc.9 for <tls@ietf.org>; Tue, 26 Mar 2019 09:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ViJ+h+3opXyAcRmivS/R2zib7jqR34wLjlgDIsZU7Ag=; b=hGMq/9k00oecKSiYYj0rj2pEoQPigluRqQAmsp1ysj6gDlsLFow/1OTwxepKfqLoqp 80B8CF2Q+eLitYudyCkhPUJw9CicstpLxlkLS2Nx6dhKxqKMjliAciJ3FXCcZWzAQyks mtXGe9jjdzxbH5UFVdrCaTBxOVb0vdlMTLpGw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ViJ+h+3opXyAcRmivS/R2zib7jqR34wLjlgDIsZU7Ag=; b=XwnbuPa/HBDX6CJASy/3PA8JRxUQiGqT0HwqM5pEA86SDcLscuxpf8h/aTtN67UPTe keH4vLRd6OpHW4KETAH/x2Y7SsezU1TWszbubIJhym+4UlqK5CBZkebHrVO50jcHdO8f pznGNOcYJ1MDtFBpamX/s9YzNaoq2ep5LrddiaFix/75C9V4mEEXQp8JrWViql6xrq6s pKa9Xeb+zmE53YYQbi0Qg5IoMu4c6XXpKxclb6alU7itfr3CQYMogwsfv4jROAPYFvDQ 0BEf9JDGnPiKQCtCmZfgVeaHxDJC2YlJgvFXNkYV2LNVR4PVKDV9hsZPIieXo0vYm//u hOmg==
X-Gm-Message-State: APjAAAVj5tt9Jdq7vCRKYIUWkIGfGTYCeai7K8/GsML+VS5AmR3Wmz85 U/xlGFrOIS6qUFqgPN2vIqDQNE6M7QOFgUkdDLL6
X-Google-Smtp-Source: APXvYqyC4vz2RN7uwU0rySfVdn6HaGKjSmxxayhZbmMgdqW2jwvAQ44mnJjHyd/dxisiBHo6R9o7dbnig0gsYqgfMuo=
X-Received: by 2002:a0c:b590:: with SMTP id g16mr26170342qve.146.1553619386478; Tue, 26 Mar 2019 09:56:26 -0700 (PDT)
MIME-Version: 1.0
References: <153856977342.9010.10521757586695280@ietfa.amsl.com> <20181003123643.GA5454@mandy.flat11.house> <EC87E55E-A342-40D7-9E09-DB790B04BB9F@sn3rd.com> <20181004170124.GA13528@mandy.flat11.house> <63200ECA-5F92-44A1-970D-E96F90B89EE9@akamai.com>
In-Reply-To: <63200ECA-5F92-44A1-970D-E96F90B89EE9@akamai.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 26 Mar 2019 17:56:09 +0100
Message-ID: <CAF8qwaCUVy-V7G4J6SPiSzg8oRurAK6VmtdCy242RuVPL3AGKw@mail.gmail.com>
To: "Sniffen, Brian" <bsniffen@akamai.com>
Cc: Alessandro Ghedini <alessandro@ghedini.me>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a629cd058502330c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8HXJEq-N4dpRYrNhpXNa6OCvqtg>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 26 Mar 2019 16:56:31 -0000

On Tue, Mar 26, 2019 at 5:07 PM Sniffen, Brian <bsniffen@akamai.com>; wrote:

> >> WG - I’d like to echo Alessandro request for reviews.   If this
> outstanding WG item is not resolved before IETF103 we will discuss the
> outstanding issue there, and barring any other major issues we are planning
> to WGLC the draft after IETF103.
> >>
> >> One question: There was some discussion earlier about dictionaries.
> Are dictionaries being used in the current deployments?
> >
> > No, neither Chrome nor Cloudflare are using dictionaries. Something I
> forgot
> > to mention in my previous email is that the numbers are for plain brotli
> > compression, so without dictionary.
>
> Just to check: is this still true for the excellent numbers we saw today?
> Surely it’s only the text-like parts of the certificate that are
> compressed.  As EKR mentioned, presumably a bunch of the savings is from
> compressing the Subject of one cert against the Issuer of another.  Perhaps
> there’s some ASN.1 framing too?
>
> If the Brotli dictionary were there, I’d expect to see compression of
> “Massachusetts” and “Czechia.”  But versioning of that dictionary seems
> dangerous for the same reasons we talked about the hash table lookups being
> dangerous.  Is there a space for a requirement that the decompression
> function contain no information flow from the algorithm, so that all bits
> in the output were present somewhere in the compressed input?
>

Brotli has a dictionary built into the algorithm. I believe that is indeed
being used, as it's a part of Brotli. I think the earlier email was saying
no external certificate-specific dictionary used.

I don't think "no information flow from the algorithm" is particularly
well-defined. The output of course takes information flow from the
algorithm as the algorithm is being run. One could replace Brotli's
dictionary from an array lookups to a series of ifs, etc., without changing
the function.

The transcript encoding must be injective, but we inherently have that
requirement: the receiver needs to decompress it! The transcript includes
all inputs to the receiver, notably the compression algorithm code point.
Were Brotli's static dictionary changed, it would no longer be Brotli. It
would perhaps be Brotli2 and would want a separate codepoint. To that end,
I think the discussion on hash table lookups similarly forgot this
decompressibility requirement. Let's define my_fancy_algorithm to be:

func compress(input) {
   if input == some_particular_cert {
      return "0x00"
  }
  return "0x01" + input
}

This is silly, but still fine because the codepoint for my_fancy_algorithm
is in the transcript. It would even be fine if my_fancy_algorithm relied on
a separately-negotiated dictionary extension. The sender inherently must
unambiguously communicate the dictionary name. That ends up in the
transcript. (This is the same logic behind other uses of the handshake
transcript. Blindly stuffing the handshake bytes into the transcript lets
us align functional and security requirements.)

David