Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt
David Benjamin <davidben@chromium.org> Tue, 26 March 2019 21:19 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 CA77112006D for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 14:19:08 -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 YZKZYn1ctdZZ for <tls@ietfa.amsl.com>; Tue, 26 Mar 2019 14:19:06 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 C706F120020 for <tls@ietf.org>; Tue, 26 Mar 2019 14:19:05 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id k14so16484679qtb.0 for <tls@ietf.org>; Tue, 26 Mar 2019 14:19:05 -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=BTUJx+aKOpfscZTWsXi4ANZW2pycen4av/aSXlNWHak=; b=aAZQljUDYTPNmIL3ceiXHEtllidrtaUfHzUyxxYoogL7z2zc/7MJj+LoqCh1oqFQZX dyj1gnoZjft/pz7ksOHG4fkTbzUq0fJBT0X0IREqHV/wZGnN2RSQ9V0ng7Mb/wgvnJED 5o2vBPVmerGqspEeEtUt85lpc1+qiyMPhj9ao=
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=BTUJx+aKOpfscZTWsXi4ANZW2pycen4av/aSXlNWHak=; b=P4DyNcYJMTn5VZMX6QHlzYgH0qhQ8GXJsD4QMgfzXr9CKVWUIVr+P24Vd7yqaa0Wu8 WJN7GcNOQE+xaOAXbLregaXTKFapB0ZG3rrisSyUpvdNCoj2y/8skMFvTjGMQurqKCOQ 7AnqV9DSgfLmKCG/oj1Rg+j2ka4g/1EcSjdlWgPHNL/9zbxDVD10tr1Pycb7j33LeJ6o d/CAflFcVUCi4Shf5hCHV9nDrEO52BwRuzaTGXLfF3q4DSdZXA3vKKQ3xASHV/7rxkVr 2Bwl/6DeRyvC1uKFWAF0/jTkzzL0BbIDoM5hyCwThjs/nGdavzH+M8j9kjNiPfuxrRMv S6Ew==
X-Gm-Message-State: APjAAAVEwyOxfHVvr1oklz+/m/MQHY6TnQAt1WZYq/nyzqIGRlU+gsak p8Sh0Z9cp5hJj88ygJzMaHW8Sxz70ysmrUK3DIlVHtbLFig9
X-Google-Smtp-Source: APXvYqyS0kG7YNbdNJXrudpQq3po0bUVqoVdR9AFvNrEVv6/RxP9imWOZir02ToLlnM2muHHChTGgUcgfGo31K+uk3g=
X-Received: by 2002:ac8:7513:: with SMTP id u19mr28702260qtq.202.1553635144619; Tue, 26 Mar 2019 14:19:04 -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> <CAF8qwaCUVy-V7G4J6SPiSzg8oRurAK6VmtdCy242RuVPL3AGKw@mail.gmail.com> <1F8D6DC4-813D-47D3-810E-6F18662E67A1@akamai.com>
In-Reply-To: <1F8D6DC4-813D-47D3-810E-6F18662E67A1@akamai.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 26 Mar 2019 22:18:48 +0100
Message-ID: <CAF8qwaA1gsUGphrv3f2v3JM70jouzqjVsjS5cbJTHTi=4PaWcQ@mail.gmail.com>
To: "Sniffen, Brian" <bsniffen@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e853a1058505ded1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KYZACz1HhhWaukHCAe9kWaBZUJc>
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 21:19:09 -0000
On Tue, Mar 26, 2019 at 6:21 PM Sniffen, Brian <bsniffen@akamai.com> wrote: > 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. > > > Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they? > Perhaps I am misreading https://github.com/google/brotli/releases , but > *even if* the Brotli maintainers are careful, I expect many less careful > entities to version their compression schemes internally, without updating > the codepoint. > I'm not personally familiar with Brotli's history, but looking through that link, no I don't believe they changed the standard dictionary. The standard dictionary is fixed in RFC 7932 <https://tools.ietf.org/html/rfc7932#appendix-A>. So is the rest of the decoding algorithm <https://tools.ietf.org/html/rfc7932#section-10>. Looking through the commits, 1.0.5 <https://github.com/google/brotli/compare/v1.0.4...v1.0.5> is just talking about a tool to extract the dictionary from the RFC <https://github.com/google/brotli/commit/a4581c158ecad55360aa54f09a08bcc1790c560b> . 1.0.3 <https://github.com/google/brotli/compare/v1.0.2...v1.0.3> appears to be talking about adding a separate variant <https://github.com/google/brotli/commit/35e69fc7cf9421ab04ffc9d52cb36d07fa12984a> which is not what the code point in the spec refers to. The spec says codepoint brotli(2) corresponds to the algorithm defined RFC 7932. If you use another algorithm, even a related one, it is not brotli(2). Maybe it's large_window_brotli(123) or brotli(2) plus a separate large_window(456) extension, but that will be reflected in the transcript. Even without an RFC, not making wire-incompatible changes to a serialization format is a rather fundamental requirement. Your decoding needs to match, or you have not implemented the same thing and will not interop. The spec can go call that out I suppose, but this is usually considered redundant. Compression is just a serialization format that attempts to use fewer bytes for hopefully likely inputs (and thus more bytes for other, hopefully unlikely, inputs). Maybe it is family of formats parameterized by a dictionary, but then someone needs to pick an instantiation. Individual instantiations are still serialization formats, with the usual expected rules. Different instantiations will not interop or the dictionary didn't do anything. > 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. > > > No, the time of the transaction is a silent input. I’m worried about > extremely persistent adversaries, including those who can update some of > the involved software in apparently-innocent ways. > (Some aspects of time actually are part of the transcript by way of the random values used for freshness.) If your adversary can change your software, I don't think this is the part you need to worry about. :-P But, yeah, if you make wire-incompatible changes to your implementation over time and introduce ambiguity, the transcript may not work as intended. It will also presumably fail to interop. This equally true for code points and length prefixes as compression formats. David > -Brian > > 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 > >
- [TLS] I-D Action: draft-ietf-tls-certificate-comp… internet-drafts
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Alessandro Ghedini
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Sean Turner
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Alessandro Ghedini
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Sniffen, Brian
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… David Benjamin
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Sniffen, Brian
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… David Benjamin
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… John Mattsson
- Re: [TLS] I-D Action: draft-ietf-tls-certificate-… Victor Vasiliev