Re: [TLS] ct_compliant cached info field

Rob Stradling <rob@sectigo.com> Mon, 25 February 2019 11:46 UTC

Return-Path: <rob@sectigo.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 9F17D1200B3; Mon, 25 Feb 2019 03:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.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 uM28D5vpM0Ba; Mon, 25 Feb 2019 03:46:06 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810085.outbound.protection.outlook.com [40.107.81.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B1312F295; Mon, 25 Feb 2019 03:46:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3NXJgYh27jB3nGh5Si6tq5Qu3fQkteCyWDvJdsn1PSE=; b=httSwaLQH9JZg04wOslflPPWE/IoQYVDbAzkVCl93K2PtN2xZNWNaLDlGTgJCVqyZ0QF0aHB2g2ClZ/ZSq5FGbYJ9zVE0JkJvZma7QJHpYJIBzU4AlbYNr2p3Pj39g4wVXIHFSFYPBq1rzFpCF7mRZ8NoSgeAobCzyYzOUQFBUM=
Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB3355.namprd17.prod.outlook.com (20.176.127.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 11:46:04 +0000
Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 11:46:04 +0000
From: Rob Stradling <rob@sectigo.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Martin Thomson <mt@lowentropy.net>, Trans <trans@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ct_compliant cached info field
Thread-Index: AQHUng4AiTlMjhjKyU+rxTv7bjD+jKWYYcaAgACOqgCAU0y3AIAAAuEAgASDJ4A=
Date: Mon, 25 Feb 2019 11:46:03 +0000
Message-ID: <6bf40eed-54f1-c04c-6e60-8bf67503036a@sectigo.com>
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> <CABcZeBMpKjMbFhSw4_auDmTs+d3Bys4B=TpPzW8mCt-V_iecww@mail.gmail.com>
In-Reply-To: <CABcZeBMpKjMbFhSw4_auDmTs+d3Bys4B=TpPzW8mCt-V_iecww@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0451.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::31) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4bd16097-ff7f-4f48-62e1-08d69b16d205
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB3355;
x-ms-traffictypediagnostic: DM6PR17MB3355:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM6PR17MB335569BBEB02797AF429C196AA7A0@DM6PR17MB3355.namprd17.prod.outlook.com>
x-forefront-prvs: 095972DF2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39850400004)(366004)(396003)(376002)(189003)(199004)(81166006)(2616005)(54906003)(8676002)(476003)(256004)(6116002)(14444005)(71190400001)(71200400001)(93886005)(6246003)(186003)(6916009)(305945005)(316002)(25786009)(229853002)(7736002)(97736004)(11346002)(4326008)(86362001)(5660300002)(486006)(81156014)(46003)(386003)(53546011)(31686004)(6506007)(68736007)(6512007)(6306002)(478600001)(53936002)(14454004)(6486002)(76176011)(99286004)(52116002)(105586002)(106356001)(8936002)(36756003)(966005)(2906002)(446003)(102836004)(31696002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3355; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIzMzU1OzIzOlYvbHZ3SmdvTnRUOVoxamsrMENXWEdhYkNp?= =?utf-8?B?a1c0RmlSNUJjVU8rVFY4a3Rid2Z2VmJWVW1rM0tzN2lZM3dPSlBBbHJxWU1R?= =?utf-8?B?SklZQ0lpRmNvbDZ5VmUweEM1TkR5b2dQT1pXcnIvamdwZmRNdk5zV1dVR056?= =?utf-8?B?NTFGSXpzd2pqSmIrcnB0cTRNVDdvaFNtWVlMT09ZNStrU0lNVFVBdnhiVXl3?= =?utf-8?B?MU5NSThjbjNlbTZQVktBNXNoUFROdHNZZktGOHppZDdIYTlUbUlseXo4ejkv?= =?utf-8?B?YitNWGlyT3ZCQ2VrYWtRNTlrbnQxeEMxL29uVGpPNUhKUW1RS3dvOW9BMStX?= =?utf-8?B?VXo3U0gwK0ViZUU4Q3VHMU1SSWFKandCTmhtMitEcVpxNkVFQm5wYXpZcCsx?= =?utf-8?B?bXFZdWJIVXlTZ1UrWjYwalh4RVRMNmhvSFExU3hyTWpLaFFtMnRSQStrRWxF?= =?utf-8?B?ZFArOHlaMXpHU3dIbm9MZmpFcmQzak54SCtZMVE3TkoxOE84T0lwaEFPSWdI?= =?utf-8?B?NzNFOGtoWDdKODd1eElyd2lpcjMvbFNkdHh2S05aVUFpM2pJQUtmOVRxUExK?= =?utf-8?B?WkYvclVrMGxpRGV4R1ZwQlc0TWxnV3FLbXhFUVo4dWxFczlNMVJ4UWNTRmRZ?= =?utf-8?B?R3pkYXJsenI2eVM4Q1RxNEVWa1g3UzlUaWxMbXJuZTgyejJxMmZyUjdrSkVp?= =?utf-8?B?RzZzdlEvTlBZN2Y4WDQ0aU9RWC8rVEtaTUZWSFhQa1NwbWQyeEYvUEhwRmZJ?= =?utf-8?B?UHlZRnZEQnh0bG9VVjU0QUZqWG9KbUdMcXlwVTlLM3Q2VCtEVGRpN2ZEa01r?= =?utf-8?B?b1lGRnlTWDdKZDgraUdkMldGVzVhS1dNS2xRRDRFZ25memw4Z1ZSRi9NQlB4?= =?utf-8?B?YlMrbHRnc2g0SXF4RmxjNkU4aWppSjBlb2VwL3VxU281eDNxdk9zeU02UzNN?= =?utf-8?B?NTRrbVBRaC8ycyttc043K0hxS1VZMUgzZXh3MmJjUmFzYVl2cWJwRUdFeWVK?= =?utf-8?B?M1BwRjBaTm83b1lSdWRCMTU2OFdQTWx0MDhrcG9QQkt1TWJyVzRzK3E0TmRG?= =?utf-8?B?bzJLMFplYnlHaW42R0hISlkwRmp3L1djeHJ5TUxQc25RaGZ4Qnk0OGVRV09U?= =?utf-8?B?WUgyTGZMZCttWFRRNTIzTjMrS2cvdWJid0FSVkRuTlVmaEtSRFRLWkJhNklh?= =?utf-8?B?WTltdTFoMWlJNnZyVXRJeFNwM3NwV1ZSZkdxZGxGb0ZUTGk1TWcwNFRoV3lq?= =?utf-8?B?WDBNY2t5UE8xRUlXOWFmeWo5NDBMWmpMTlJ2ei82ZWUyMUU2M0drWXgyZUo5?= =?utf-8?B?OUNOZjh1NFNobThSbkdzdjhWTTFyOEFmc0tEUjAwMFV2WGdrdUV4dktSUWFh?= =?utf-8?B?aStUM0NqbUorOEU4b25xemh3dEZvbzRWTFgvSGQ0OUdraCtMOE1yZnBualBH?= =?utf-8?B?WVhCTUpZdEFBTnJ2U29OcUZKY05GTlVaU3Nna2RJMWc0RGR4d2FKNThQcStm?= =?utf-8?B?OUZhWXlLMmxNaWovaWt0WEg5TWhTUGdqRHNKVjdLemwrOWpsRG5paU03U2dU?= =?utf-8?B?alNBYS9HV08vaXg0YmhlMVhPT0Z2VTZWR3hPamZ6Y3BKN1hkdWVpSm0vdzZP?= =?utf-8?B?elhNOWtJY2xab1NrMlF4MFZIWng4bFZGcE1YbnVCbmJ2WVBJbGd4NDh2MWZD?= =?utf-8?B?bVRJNEY3dUg0RkFERmhkS3cwQ0FxcklTVExXdnRBNHpZMWRCZVFWSHFZR3pa?= =?utf-8?Q?1uQDMTTHB9UlKtLcdYtBwe0cFNWSP4Zp3qaag=3D?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tU3gJ8tFy/KfjPPD3iimrgifF7YqxA+VQ/hyPQLAWSMxMuG5jrsLajDVYaorn3Jdsyiht4aZaCudN3SgTulKEYT1j3NOoLWeWrKydM9p3sTt3il+rj7m3pVLoTajEafuNnyp3jcZhRJ7X5tg433HIy4i7xdd5IpyDdpf5j8tK3HTooLMYET3fVYYaQ2O5ufZ7/bSpumCbThCgIWdACd/4+kP8z6Z6N9T/xmBbxlmse48RKy7PjAfCqr1d4q2g06hDk7O3mYDH0DGu3w2any4CBzVI1nUNbWrSzj8dqM2hWo5/D8kYR2FeLdcf6ZG7aBQac1mNclfxu0CP+K44W8VXTI8v6dMIsgFa9YELSIppCQToBsGZZPa3S5jAvCsfXpiNu6Sb2YdCZpa+fLtHeReuaCrOIZnTaodHkKY+F7E4B0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <665BF445716C274299E47C4D3C87F282@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bd16097-ff7f-4f48-62e1-08d69b16d205
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 11:46:01.8056 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3355
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZoV3tjQjuZUNScsS5D4J00lN0mY>
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: Mon, 25 Feb 2019 11:46:10 -0000

Thanks EKR.

Done, in https://github.com/google/certificate-transparency-rfcs/pull/307

On 22/02/2019 14:51, Eric Rescorla wrote:
> That works for me
> 
> -Ekr
> 
> 
> On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <rob@sectigo.com 
> <mailto: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>
>      > <mailto: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 <mailto:rob@sectigo.com>
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: rob@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.