Re: [TLS] ct_compliant cached info field
Eric Rescorla <ekr@rtfm.com> Fri, 22 February 2019 14:52 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 BED8F1200D7 for <tls@ietfa.amsl.com>; Fri, 22 Feb 2019 06:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 IML7519YAtE8 for <tls@ietfa.amsl.com>; Fri, 22 Feb 2019 06:52:05 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 81644130DD8 for <tls@ietf.org>; Fri, 22 Feb 2019 06:52:01 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id v7so1927660lfd.2 for <tls@ietf.org>; Fri, 22 Feb 2019 06:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=esrzi+fxUqWgD82yjqw4v9wPlZZ5CQJWwHE7+gbj8Eepx8TIl2fEfFPKmzf9Y+L8ow xEPaLr5SrYnGprFHoqfAfYUUHbYbqnbWc6c2UTBpc0ZdzoYdBPzBXWW2wcssN5VXdtkJ Q/j91dbUdi7yPytMCF1N6A/hFm5kjLzc5JydN8Z84fu6/zoc4hX+sUZmq2F4Iyz69lK3 WXe4uw0Dg+1MlUsgQqowVFwIVMyQrjYv9WJ6TkwmlPcMFTdrl7nKHIkR8bNv//14XGPR 8L0d0bv0e54W3d6h0EwKkZOTuTRR2BRcuzotlu1Pi3IFqGNXHCpH+fDB7HsmJ2cD786x P9/g==
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=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=PtZKWkV54vca2zkg2yGG17mT841IBCFbieaFwsxajpJDnq2qmHC7xajWzLPjgvhwX5 jI7PyUqFpJVN9966U/gP6DMCUNxlSoOiYD4/fOBV1bwogeJvAFF27UzGrtl3ztpvwpl0 NXsFQDDA6+nwbgv3RK5Ge2rEuzP387Giq7JmJK/vq+u5zrSbLX6/5GRGy8+QuSFCRrgA 2kQYy+6GQuhvV4BJyQrP9/BZGDSW7353S2ilfg0bnW0lh5m8pkhk8Trv+faH8kmf8gTM HVhMmYXufOExuWoIgV0QUbXNENNEsIBtlm24pIHiPbVRCL1/dN8kXJjXuxDK5ppUVWiD +wCQ==
X-Gm-Message-State: AHQUAuYY8wVzxz8gk1fF8eQDXkk89eTZMMjbccbcpfdhMemI+aOlwclY bDqY3CNQFO3+ILC7kB2AwopwFfzfkp6D+1kvb2kFKW0j
X-Google-Smtp-Source: AHgI3Ib/1DB8FPtUxnOp4aoU9Uj+JA+R94VZPcOaiCjLwm2Ludg/pQnU/UIfrYe8J3/ky4vxtw3RBFImFU+V0GQBxZE=
X-Received: by 2002:ac2:4191:: with SMTP id z17mr2063267lfh.78.1550847119565; Fri, 22 Feb 2019 06:51:59 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBNuQMW=e=DGU6atyBv7UqWvkb3JMKAjfhCd_uqdgELa8g@mail.gmail.com> <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com> <CABcZeBOeL4+Bmi7DfvxbkaJYSANqnBNjzHWgVYT69Bc51=gb4Q@mail.gmail.com> <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com>
In-Reply-To: <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 22 Feb 2019 06:51:20 -0800
Message-ID: <CABcZeBMpKjMbFhSw4_auDmTs+d3Bys4B=TpPzW8mCt-V_iecww@mail.gmail.com>
To: Rob Stradling <rob@sectigo.com>
Cc: Martin Thomson <mt@lowentropy.net>, Trans <trans@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a9bc5805827cbbe8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SVmqo_apC1vi883uufdEfYlwNJc>
Subject: Re: [TLS] ct_compliant cached info field
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: Fri, 22 Feb 2019 14:52:10 -0000
That works for me -Ekr On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <rob@sectigo.com> wrote: > EKR, Martin, > > Hi, and sorry for the long delay in replying. > > This originated in [1] and was added to 6962-bis in [2]. The motivation > was to provide a mechanism to permit a TLS server to avoid sending CT > artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client > already has or doesn't need, thereby reducing bytes on the wire for > constrained and high-volume environments. > > The approach envisaged by RFC7924 seems to be: "here's a list of TLS > message fingerprints I've received previously; please don't send these > exact messages to me again". This works for stand-alone messages that > contain one item, such as the server's Certificate message (which > contains 1 server certificate chain). > > However, in 6962-bis's case, SCTs and inclusion proofs are not > stand-alone items; instead, they correspond to particular certificates. > Each relevant TLS message will contain a TransItemList, which will > probably contain at least a set of several SCTs; and whilst each SCT is > static, the set (and the order within the set) is not. Therefore, the > approach of caching TLS messages by fingerprint didn't look like it > would work for us. > > We concluded that it would make more sense for the client to make a more > high-level statement: "here's a list of certificate fingerprints that > I've received previously and that I already regard as being CT-compliant". > > This isn't an essential part of 6962-bis. Other than Ben L's "Sounds > like a good idea" comment in [1], I don't recall anyone commenting on it > until EKR started this thread. > > I propose to remove this cached-info mechanism from 6962-bis, if nobody > objects. (It could of course be revisited in some future document, if > there's interest). > > > [1] https://trac.ietf.org/trac/trans/ticket/111 > > [2] https://github.com/google/certificate-transparency-rfcs/pull/186 > > On 31/12/2018 14:36, Eric Rescorla wrote: > > + trans > > > > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <mt@lowentropy.net > > <mailto:mt@lowentropy.net>> wrote: > > > > > > On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote: > > > Please take a look at > > > > > > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5 > > > > At a minimum, this would seem to update cached_info. > > > > There's not a lot of meat on this text. It seems to be saying that > > if you are providing transparency_info, then you can provide a > > certificate other than any of the certificates that the client > > believes to be CT compliant. Also, you don't provide "x509_sct_v2" > > or "precert_sct_v2" in transparency_info. > > > > How is the client then able to determine that this new certificate > > is CT compliant? Using "inclusion_proof_v2" and > > "signed_tree_head_v2" (or one or other)? If so, the text doesn't > > point in that direction. > > > > There's a lot of "why" missing in this document. Why would a client > > choose to indicate "ct_compliant"? Why is cached_info being > > extended in this way? > > > > I might guess that the reason here is that the draft aims to avoid > > including information that might change over time, which would > > render caches invalid. Isn't that motivation to recommend an SCT > > over an STH? > > > > Separately, why does this establish a new registry for signature > > schemes? It is obviously trying to keep TLS compatibility, based on > > the codepoints, but forking the registry is a great way to create > > problems. > > -- > Rob Stradling > Senior Research & Development Scientist > Email: rob@sectigo.com > >
- [TLS] ct_compliant cached info field Eric Rescorla
- Re: [TLS] ct_compliant cached info field Martin Thomson
- Re: [TLS] ct_compliant cached info field Eric Rescorla
- Re: [TLS] ct_compliant cached info field Rob Stradling
- Re: [TLS] ct_compliant cached info field Eric Rescorla
- Re: [TLS] ct_compliant cached info field Rob Stradling