From nobody Wed Feb 1 06:03:05 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF764129460 for ; Wed, 1 Feb 2017 06:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 yCmyLyb0FeD4 for ; Wed, 1 Feb 2017 06:03:02 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9D12945A for ; Wed, 1 Feb 2017 06:03:02 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3584A496C3D; Wed, 1 Feb 2017 14:03:02 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1F266496C37; Wed, 1 Feb 2017 14:03:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485957782; bh=Fn0iOcQpEnpY5/DXkL8IK0t9nZTDjgHVI13uGyouL0A=; l=596; h=From:To:CC:Date:References:In-Reply-To:From; b=el0cJ/ynoeqOcFwhBPXYd05MaUUQi27RdOUckkibQjmf5B5BdeMA8CdFtvCZKrgab lPiUu0PAVFRbhqdzmutjIgLH6AtE5l7HpBxDQmN435rVMyoh9oIwXAD0Krk8uAMhGl Xfxgfk/Ih8czKjLhxrbJxG+C+beZvIQxZJZ5EnAg= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 04CDF98084; Wed, 1 Feb 2017 14:03:02 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Feb 2017 06:03:01 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 1 Feb 2017 09:03:01 -0500 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR Thread-Index: AQHSe/GW0YKLOLxGL067P4dSkvMytKFS7XNggAEdmgCAACPQgA== Date: Wed, 1 Feb 2017 14:03:00 +0000 Message-ID: <87964cd08db8405582b5cc7bce7b679d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , Ben Laurie , Paul Wouters Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:03:04 -0000 PiAxLiBDQXMgbWFrZSBtaXN0YWtlcyBidXQgYXJlbid0IG1hbGljaW91cy4NCj4gMi4gQ0FzIGFy ZSBtYWxpY2lvdXMgYnV0IGxvZ3MgYXJlIG5vdA0KPiAzLiBDQXMgYW5kIGxvZ3MgYXJlIGJvdGgg bWFsaWNpb3VzDQoNClRoZSBvcmlnaW5hbCBmb2N1cyB3YXMgbWFpbmx5IGFib3V0IGNhdGNoaW5n IHdyb25nIGNlcnRzLCB3aGljaCB3YXMgcmVhbGx5IGEgZm9jdXMgb24gQ0EgbWlzLWlzc3VhbmNl LiAgTG9ncyB3ZXJlIGludGVuZGVkIHRvIGJlIGEgY2hlY2sgb24gdGhhdCwgYW5kIG1vbml0b3Jz IGFuZCBhdWRpdG9ycyB3ZXJlIGxheWVycyBvbiB0b3AgdGhhdCB3b3VsZCBjYXRjaCBlcnJvbmVv dXMgbG9ncy4NCg0KSGF2ZSB5b3UgcmVhZCB0aGUgdGhyZWF0IG1vZGVsIGRvYz8gIEkgYXNzdW1l IHllcywgYnV0IGl0IG5ldmVyIGh1cnRzIHRvIGFzay4NCg0K From nobody Thu Feb 2 07:36:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBB1129468 for ; Thu, 2 Feb 2017 07:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Gk87Gm7Kr2mG for ; Thu, 2 Feb 2017 07:36:20 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 B705F1293EE for ; Thu, 2 Feb 2017 07:36:20 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id y143so6102884pfb.0 for ; Thu, 02 Feb 2017 07:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=yWHtXpkSaiG+pc1aO6EsdSv1/9bcSFOVyneN51donTI=; b=LUCGILJC7bfQwMNIHB9OEOGlra52xVtEAcqjptymG8hSKMHP7qMAMWeb3Sq1KUYXxe Y7DVv/Zjjs2XuC+ryalpZpSPHoziWM0U+qRRUmcIifc8n250gnTC0Pydgoo5lsNb7YtS qgpzWWfovZFHJRd1SAWiz1X3tZtsdwhXudURCvIDdGpujMXeUmhRapJWF6ZKCyFwG/hm ABNRXaiRt4oA7dyny7zfbNrGDaFbpKOifQW++CgXlvnsQQXtfEtnWr24Vu7xjcKQMY+y u7BoD8QbMCvyTb6v+ZhMW4EjSHs0q3ctTrRZWjkir2ElgexL0mAX+mcWNHaTHE/WvICV cxRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=yWHtXpkSaiG+pc1aO6EsdSv1/9bcSFOVyneN51donTI=; b=BBdzNiGIJuZ7ETXXM1Fo5uzBSMY2g/zINHyknqde8y6Fs7+zS7M2wFV5BSiSRyydrW 3SVVisu/luRk+WDeH6ncI9iKlWcVCCLctvYP0IZ9357XlsPkz01Kvnk41JB70U0A/MBW foh5zWH0SSlktQFnjOInbHWP+rmBoiZvf6U7xW75WFvTnWECPIYslZMbDwIGWmdlvuju OpAzZzBd0hSEFS4aPlRsiy+3nzTAJkSPCWvEgqkskogaesgBwfTnTxMOtm8W6kwmoIPY N/8iYZoA5YtyiT9qtSyFJfPw3pCxN9V6bgQ+0XIc9UFCK5aqG47SqJxxXquD9Y/aLQYc RlcQ== X-Gm-Message-State: AIkVDXIPcON3zTAaWYrr4y3+2FaPOUflEGNFySTKCHSQoouHwyx/DvlCOpK7ZTGVxDoosQ== X-Received: by 10.99.241.83 with SMTP id o19mr11326366pgk.195.1486049779950; Thu, 02 Feb 2017 07:36:19 -0800 (PST) Received: from Melindas-MacBook-Pro.local (209-112-217-13-radius.dynamic.acsalaska.net. [209.112.217.13]) by smtp.gmail.com with ESMTPSA id e127sm59412575pfh.89.2017.02.02.07.36.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 07:36:19 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Thu, 2 Feb 2017 06:36:17 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xkq7Dlse5W6NwCwjMqWK8j8PnX6pe0RUU" Archived-At: Subject: [Trans] Completed working group last call for the gossip document X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:36:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xkq7Dlse5W6NwCwjMqWK8j8PnX6pe0RUU Content-Type: multipart/mixed; boundary="bNvBWtWVRe3a8tvO8fVmv19eJmk0Le5pb"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: Completed working group last call for the gossip document --bNvBWtWVRe3a8tvO8fVmv19eJmk0Le5pb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: Working group last call for the gossip document (draft-ietf-trans-gossip) closed with relatively little comment. Linus expressed concern that there wasn't enough implementation experience to be confident in the correctness of the document, but there was general agreement that it would still be valuable to publish it as an experimental RFC, as a starting point for implementation and experimentation. So, we're sending the document along to the IESG for review and publication. Many thanks to Linus, DKG, and Tom for their work on the draft, and to reviewers for their comments. Melinda and Paul --bNvBWtWVRe3a8tvO8fVmv19eJmk0Le5pb-- --xkq7Dlse5W6NwCwjMqWK8j8PnX6pe0RUU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYk1HxAAoJELiGRpM6HoEu+HwP/jjJB+J2Ls1jRwWWZlobLK+o gxScV7b65yR/2SLf5atFBvkPJeXR3Y55txJnj88b5N/wH9ZwOv86Pg77w6Vo6ww7 4V8gE7cTrX4CkryFA6HUVdOqD5ByMC0pSlfMQ+CUxC/XiXLvel8bPwiNMAiN/YyC InvZQIdsP/iFkNujdsQEVpIEZfBNniqaa7f9DyetVxnhuknLMVzC2D5cO3HAvU8D BEWclOyJXfAQndgXbUBJChvh4D7E30jEsqvXV3GMQrx7TGh8icsSzo3MXur0HwWM anR3oo/00ogkqSv2WzwUuHQCW4N7dq3OICP7mI5zKX9xK5IU76YdU9TCFKOcbGYG fskcfR+A3/V6TW4+TlcYf5PfTS+30ke6Zi82xDkflepUcJ/4bqaeofUXxQYpSDwD E6lSEHMDK/KqfjOvU36YCCs17uv+4ej/I+BlUxQz2CzvShZsaX3sI5TAqdKuO+Kv XX5xMFRbE9pR9yQ1RULJZSoJkFMb5j+x52TURTQAUNv+i9QZf+JpANAPRN/F4ZvV mZFFgE+3aAgkclJz2uSEJ6wo/tkPif6UGGmaq/J/+k9fEf9f79DSXmMoqp/b83JD +mk/L8eoq5YsHuqqhilKYYl+reV+JnEcff5lH89Jb9fY/+NLL/v57IS93gMtnksS CQHrfqieDii+GO+4j01s =FVxM -----END PGP SIGNATURE----- --xkq7Dlse5W6NwCwjMqWK8j8PnX6pe0RUU-- From nobody Thu Feb 2 11:34:27 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2B12998A for ; Thu, 2 Feb 2017 11:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 gHQ8nYGlzKHM for ; Thu, 2 Feb 2017 11:34:21 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 BEC63129994 for ; Thu, 2 Feb 2017 11:34:20 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id o65so7897748ybo.2 for ; Thu, 02 Feb 2017 11:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y7brdvtJN4cLu3b0v38ThmYEd89YXCJQp/JO11C7whQ=; b=wKkYtg8buxQI6GKRQN1L9oyVKUlswZKfKVM9RbfOT9fuDVK0pZ9llIb2Gx+Ixh7hWT Vi9/SwYKhuMUYT+6ZBp/4kiiy7pUu+PDM6sIEbfQNPsuDazZrO3woOFIsegT9F6YwS4e fjUtvgJUHTu3cJqSotXzizd2oTMSOrMhK+Ec+ymLL5WyxDfsxNTpbcMz8rMgIB7jrpmP wBvFft+oUgfk297dyOn3NbvQuDB2RoEnGtk+Y6Tz8Lp+YHxU+fmAGyTdQyTzoqz8aqkI 74EeeHOSCyvXaM4jxSpLl0Hs+0cuI9pgYBSWTOCns8/jxvmsGfJlVj4ygU13dCF+CyB7 fdZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y7brdvtJN4cLu3b0v38ThmYEd89YXCJQp/JO11C7whQ=; b=mOxaPOsSfycR356GVCC+fgQyl9YrolwSpmiMOaZD1bNb5O4u3xFfRH21Xzs/Y5i8er UbP87Saq35psEmnuM1z+TfxKzcx4MsY9dGLSPHzmTTLG0GLQcZHdulaWXk0WrGM/bm07 XHmIlOVVsQQxDDzzU2gpPWEuw99nV9IuVDwcqcTN2oJIH+BQb4LkRBW/k+VjzyFZD5bT B4lQmkgYWnZBKeTIrapkBCO+dziQG/Ef+OV/L6jTJ92BozPsegew8hMIKr3fFx/VZacL 0oIAmuPutR5MUYIbzdFEMvbXnEvB95rwpT2WANCpo7kFvfX9XO03F6FyHVyFYC1VTd2Q 9Sxg== X-Gm-Message-State: AIkVDXKvqnHJxMBMCnx4vFi+yBFU14zo42xAaOCrUhbiTq6ML5RZiuWzTSIU35bEJG0jhuvzPzR8Ifs2Vk+CJQ== X-Received: by 10.37.224.77 with SMTP id x74mr3268498ybg.80.1486064059956; Thu, 02 Feb 2017 11:34:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 2 Feb 2017 11:33:39 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> From: Eric Rescorla Date: Thu, 2 Feb 2017 20:33:39 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c086b34686ff20547914054 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , Ben Laurie , Paul Wouters Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:34:25 -0000 --94eb2c086b34686ff20547914054 Content-Type: text/plain; charset=UTF-8 I thought it might be useful to elaborate on what I meant about threat model and technology for CT. As I mentioned, I think there are three primary threat models one might be concerned about: 1. CAs misissue but aren't malicious. 2. CAs are malicious or otherwise fail to log but logs are not 3. CAs and logs are both malicious In threat model #1, what is mostly required is merely that CAs submit certificates to logs. As long as every CA submits their certs to a common log than misissuance can be detected without any client side behavior at all. This is effectively CT as it is implemented for DV today and as Ben indicates, it has detected misissuance already. If CAs do not log (either maliciously or through mistake), then it is necessary for RPs to refuse to accept certificates which are not logged. However, as long as we believe that the logs behave correctly (specifically, they never sign an SCT that they don't then log) then all that is required is that a certificate contain SCTs from some set of logs and that RPs check that. This is roughly CT as Chrome proposes to implement as of end-of-2017. Note that the Merkle tree infrastructure is not needed here at all. The final case is the one where logs are also malicious and collude with a malicious CA to issue an SCT for a certificate but not to log it. In order to detect this, you need to ensure that RPs have the same view of the log structure as auditors do, because otherwise the CA can issue a certificate which will be acceptable to the RP but will never be audited [0]. The general notion for current CT is that there is some notion of getting global consensus on the state of the log and then the auditors and the RPs can know that they are checking the same thing. This is where the Merkle tree infrastructure comes in (though as I indicated previously, Richard and I do not believe it adequately addresses this case). Note that these are *all* detection use cases, but just detection under particular threat models. So, I think the question is: which threat model is this document intended to address? It seems to me that the charter pretty clearly comes down on #3, because it talks about "verifiable" logs and defines verifiable in a way that seems to include log misissuance. But perhaps I have misunderstood. -Ekr [0] This is just about avoiding TOCTOU bugs. On Wed, Feb 1, 2017 at 7:51 AM, Eric Rescorla wrote: > > On Tue, Jan 31, 2017 at 7:50 PM, Salz, Rich wrote: > >> > We don't have consensus. We're deadlocked and we're not getting >> > sufficient input from the working group to break the deadlock. >> >> Well, yeah, that's why you get paid the big bucks, right? :) >> >> > Paul and I can make a decision on the particular question that's a >> problem but >> > it probably means an appeal and further delay. >> >> That's the process. >> >> > Frankly, this working group was chartered under the assumption that the >> > goal was detection, not prevention. >> >> That's my perception as well. Is there anyone who thinks prevention was >> part of the scope? >> > > I think this is painting with a bit too broad a brush. One needs to talk > about > detection under a specific threat model, as I indicated previously. > Specifically, > there seem to be a number of potential threat models: > > 1. CAs make mistakes but aren't malicious. > 2. CAs are malicious but logs are not > 3. CAs and logs are both malicious > > What technological solution is adequate to detect misissuance depends on > which > of these three threat models you think applies. > > -Ekr > > --94eb2c086b34686ff20547914054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought it might be useful to elaborate on what I m= eant about
threat model and technology for CT. As I mentioned, I = think there
are three primary threat models one might be concerne= d about:

1. CAs misissue but aren't malicious.=
2. CAs are malicious or otherwise fail to log but logs are not
3. CAs and logs are both malicious


In threat model #1, what is mostly required is merely that CAs sub= mit
certificates to logs. As long as every CA submits their certs= to a
common log than misissuance can be detected without any cli= ent side
behavior at all. This is effectively CT as it is impleme= nted for DV
today and as Ben indicates, it has detected misissuan= ce already.

If CAs do not log (either maliciously = or through mistake), then it is
necessary for RPs to refuse to ac= cept certificates which are not
logged. However, as long as we be= lieve that the logs behave correctly
(specifically, they never si= gn an SCT that they don't then log) then
all that is required= is that a certificate contain SCTs from some set
of logs and tha= t RPs check that. This is roughly CT as Chrome
proposes to implem= ent as of end-of-2017.=C2=A0 Note that the Merkle tree
infrastruc= ture is not needed here at all.

The final case is = the one where logs are also malicious and collude
with a maliciou= s CA to issue an SCT for a certificate but not to log
it. In orde= r to detect this, you need to ensure that RPs have the same
view = of the log structure as auditors do, because otherwise the CA can
issue a certificate which will be acceptable to the RP but will never
be audited [0]. The general notion for current CT is that there is
some notion of getting global consensus on the state of the log and=
then the auditors and the RPs can know that they are checking th= e same
thing. This is where the Merkle tree infrastructure comes = in (though
as I indicated previously, Richard and I do not believ= e it adequately
addresses this case).

No= te that these are *all* detection use cases, but just detection
u= nder particular threat models.

So, I think the que= stion is: which threat model is this document
intended to address= ? It seems to me that the charter pretty clearly
comes down on #3= , because it talks about "verifiable" logs and defines
= verifiable in a way that seems to include log misissuance. But perhaps
I have misunderstood.

-Ekr


[0] This is just about avoiding TOCTOU bugs.







On Wed, Feb 1, 2017 at 7:51 AM, Eric Rescorla <ekr@rtfm.com> wr= ote:

On Tue, Jan 3= 1, 2017 at 7:50 PM, Salz, Rich <rsalz@akamai.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> We don't have consensus.=C2=A0= We're deadlocked and we're not getting
> sufficient input from the working group to break the deadlock.

Well, yeah, that's why you get paid the big bucks, right? :)

> Paul and I can make a decision on the particular question that's a= problem but
> it probably means an appeal and further delay.

That's the process.

> Frankly, this working group was chartered under the assumption that th= e
> goal was detection, not prevention.

That's my perception as well.=C2=A0 Is there anyone who thinks p= revention was part of the scope?

I think= this is painting with a bit too broad a brush. One needs to talk about
detection under a specific threat model, as I = indicated previously. Specifically,
there s= eem to be a number of potential threat models:

1. CAs make mistakes but aren'= t malicious.
2. CAs are malicious but logs = are not
3. CAs and logs are both malicious<= br>

Wh= at technological solution is adequate to detect misissuance depends on whic= h
of these three threat models you think ap= plies.

-Ekr


--94eb2c086b34686ff20547914054-- From nobody Thu Feb 2 11:34:45 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265E5129993 for ; Thu, 2 Feb 2017 11:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 UTBoqlhCbDxe for ; Thu, 2 Feb 2017 11:34:43 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 204C712999E for ; Thu, 2 Feb 2017 11:34:39 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so21563049ywc.2 for ; Thu, 02 Feb 2017 11:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SFuTU3Mz9xOJj6Wm29IC799F6kyJutzWErEi8A/pucg=; b=KrhfbUnVqMv84UlU5dGJJT+z6LRAl00YWbVnBCNGDzpFYmE7YsKloih+Ybq8QHBX60 MO+SyJ/QYmoe9H2Hd+tiwoqLDjr0pIq1l/SfgVNfFHJJ428nK+KlRekbiz7sWPt1QQ54 vyDSl5qexqvagINqxwvBe5Cj5DL13o7Y9uMEwYRhx7MO88vjYv2rlwTNg8tzc2zJuuQD 76avK30HJbMqXWRGzIdCPqmY3rtbQlsrauHvZJWSKJth6CaZe2JkO0zqlj4IyKF4yXeI cSQz0Vu4AqQj/bNBCG1CBz3qSBJKmR+w+vKboN1Ovp5u2GAtWert83a+7Rx6EN6pUKfi m4jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SFuTU3Mz9xOJj6Wm29IC799F6kyJutzWErEi8A/pucg=; b=E0mMLHzOQbBIQdD9V1BPpcpgW0KEZTN5y6Xc9riN7F6qpvArrqrmlDYci8j8Kj1ZRk LBzGCA3mYCl2/d7qfw2RYbyTAiXpD0Ew4/PwJYtt0Q/pnBmoTfCx4L6pOJvnps738/mA zCPtNCUV2N6pI9H2GaxS9a0E/k1MvoRZHT9Ynk8T8a/2KvGNvFYHsH6YEKschbhVY7mF DbQkonYVN6YZF9gfOijwt8G50EeV4e/06XmqkJsfoGyxtdd9iWHhIGyWJgsA2D7jtMiD 6kasZoBNtd+muq1E9yoLnNDjgCYTPlujHO7HImWJlyjJPBm5AhA0NflOPrEbOyHag8zZ BBrQ== X-Gm-Message-State: AIkVDXLbiqqjv10gwiQ1h2hTkUfT06Fu/RAcX787T9sjgKqIbQ/Z7Ts4CALhkxrX5GCohzoWMqV8Bg9pcIUguA== X-Received: by 10.129.137.129 with SMTP id z123mr7720593ywf.327.1486064078439; Thu, 02 Feb 2017 11:34:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 2 Feb 2017 11:33:57 -0800 (PST) In-Reply-To: <87964cd08db8405582b5cc7bce7b679d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> <87964cd08db8405582b5cc7bce7b679d@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Thu, 2 Feb 2017 20:33:57 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c06bf38827c4c054791414a Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , Ben Laurie , Paul Wouters Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:34:44 -0000 --94eb2c06bf38827c4c054791414a Content-Type: text/plain; charset=UTF-8 On Wed, Feb 1, 2017 at 3:03 PM, Salz, Rich wrote: > > 1. CAs make mistakes but aren't malicious. > > 2. CAs are malicious but logs are not > > 3. CAs and logs are both malicious > > The original focus was mainly about catching wrong certs, which was really > a focus on CA mis-issuance. Logs were intended to be a check on that, and > monitors and auditors were layers on top that would catch erroneous logs. > > Have you read the threat model doc? I assume yes, but it never hurts to > ask. > Yes, I have. I think it does a pretty good job of analyzing the various cases. -Ekr --94eb2c06bf38827c4c054791414a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 1, 2017 at 3:03 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 1. CAs = make mistakes but aren't malicious.
> 2. CAs are malicious but logs are not
> 3. CAs and logs are both malicious

The original focus was mainly about catching wrong certs, which was = really a focus on CA mis-issuance.=C2=A0 Logs were intended to be a check o= n that, and monitors and auditors were layers on top that would catch erron= eous logs.

Have you read the threat model doc?=C2=A0 I assume yes, but it never hurts = to ask.

Yes, I have. I think it does a = pretty good job of analyzing the various cases.

-E= kr
=C2=A0

--94eb2c06bf38827c4c054791414a-- From nobody Thu Feb 2 14:29:47 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D121295A8 for ; Thu, 2 Feb 2017 14:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 6DmZWY1wj1PX for ; Thu, 2 Feb 2017 14:29:46 -0800 (PST) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0518B129574 for ; Thu, 2 Feb 2017 14:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1486074585; bh=gMhf6qzrFCbrY0vh2LzG7zHmLcqcUhOGM6/bDf46v9o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=uAPS6pWnsNFcOCxDyPB4+6KVd1PgdZc5pQiNdv/njcJjW4C7FoenPlCjDCK5yPrvU R6OoAMHdH14dWH+PpCZcNgNtyBS9NI5ABjoSNsQ//fR2hDkBfK5DTEULdH1almH/50 fW9Y866Tbyxgq2D75yDKI36h+wEx1GtCLYrNDNmS3odx7/8w+8Kwocjitd7xHTxypH nJVkapx+zqUCQ6Grfs2TF4PzMxUwLtvxqowuD6jAciQq8Z3IdGuBWhH+KR9hxOqm1B 9ddGjAh5/KJdXJrNL0rOzgneyoQtZAz3flUhRM1VydCN9sVZ0auSEbYXxXS059KYRJ q6tqE+S2HtV4g== Date: Thu, 2 Feb 2017 14:29:44 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170202142944.bb864e58ac412bbd5c7cab87@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: Eric Rescorla , trans@ietf.org Subject: Re: [Trans] WGLC comments on draft-ietf-trans-6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:29:47 -0000 On Mon, 16 Jan 2017 17:23:27 -0500 Richard Barnes wrote: > Clearly in order to be efficient, multiple certs must chain back up > to the same STH; this is also a privacy requirement because otherwise > retrieving a given STH leaks which certificate you are verifying. > For similar privacy reasons, clients need to proactively download and > validate every STH they might encounter, to avoid making queries for > STHs (which leak browsing history). Hi Richard, As you point out, the privacy concern with fetching an STH's consistency proof can be addressed by requiring that multiple certificates "chain back" to any given STH. Why then is it necessary for clients to proactively download and validate every STH? Could clients not fetch consistency proofs on demand the first time they see an STH (and then cache the STH so they don't have to fetch the proof again)? If so, that would eliminate your concern with clients having to download 4MB a month. Regards, Andrew From nobody Thu Feb 2 20:32:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F5129B80 for ; Thu, 2 Feb 2017 20:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 Hwx9Mg6LZipP for ; Thu, 2 Feb 2017 20:32:40 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5196F129B7F for ; Thu, 2 Feb 2017 20:32:40 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id B8408A003A07 for ; Thu, 2 Feb 2017 20:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=HvHxOy+XOhOItN6wyH8TNRrMECo=; b= j3ZTRZv3RdJlubhAcStbJr9G8/qmQpTOVRAuipRAnuabGv1Rq/1Ms2oQlvcAcPnC m5oOQnff6r3cI9iBWWQ6al9aK9MuPFZvmVvFfqnOdXgQZlht/Kpmx0sAipmO4Fmz VOcQB3esm1GFvl699+h2iB3V7/+XWBr095eY1MVoqZA= Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 8550BA000B3C for ; Thu, 2 Feb 2017 20:32:39 -0800 (PST) Received: by mail-lf0-f53.google.com with SMTP id v186so4036566lfa.1 for ; Thu, 02 Feb 2017 20:32:39 -0800 (PST) X-Gm-Message-State: AIkVDXIiyidwE/yA5o+mTxqJX1Mb7JQMYmOSsooO5PSoZcSaAfPCW/7jh3WMiGXcnSVdwfzkGBCoNtTRQi/S2Q== X-Received: by 10.25.171.9 with SMTP id u9mr3687941lfe.151.1486096357714; Thu, 02 Feb 2017 20:32:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.154 with HTTP; Thu, 2 Feb 2017 20:32:37 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> From: Ryan Sleevi Date: Thu, 2 Feb 2017 20:32:37 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c1cc5e680f5ac054798c5b2 Archived-At: Cc: "trans@ietf.org" , Richard Barnes , "Salz, Rich" , Melinda Shore , Paul Wouters , Ben Laurie Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 04:32:41 -0000 --94eb2c1cc5e680f5ac054798c5b2 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla wrote: > If CAs do not log (either maliciously or through mistake), then it is > necessary for RPs to refuse to accept certificates which are not > logged. However, as long as we believe that the logs behave correctly > (specifically, they never sign an SCT that they don't then log) then > all that is required is that a certificate contain SCTs from some set > of logs and that RPs check that. This is roughly CT as Chrome > proposes to implement as of end-of-2017. Note that the Merkle tree > infrastructure is not needed here at all. > I believe you meant end-of-2016, but given that Chrome hasn't made the statement you're attributing, it's not fair to say "proposes to implement as of end-of-2017." > The final case is the one where logs are also malicious and collude > with a malicious CA to issue an SCT for a certificate but not to log > it. In order to detect this, you need to ensure that RPs have the same > view of the log structure as auditors do, because otherwise the CA can > issue a certificate which will be acceptable to the RP but will never > be audited [0]. The general notion for current CT is that there is > some notion of getting global consensus on the state of the log and > then the auditors and the RPs can know that they are checking the same > thing. This is where the Merkle tree infrastructure comes in (though > as I indicated previously, Richard and I do not believe it adequately > addresses this case). > It's unclear to me, from your remarks and Richard remarks earlier, whether you believe this goal is explicitly not achieved under the current proposals. It seems that you accept the current proposal actually does address this, but that you're unhappy with there being any window between issuance and global consensus. That is, there's agreement that the current model provides detection under a certain set of bounded constraints, but you want to reduce that. The rest of Richard's message seems to focus on whether the system is believed to be sufficiently scalable, but I don't know that there's consensus with Richard's assertion - that is, that CT is too inefficient to be deployed at scale. Indeed, much of the calculation seems to be based on an assumption of a design that tightens the detection window, rather than alternatives; the point being that the inefficiency Richard notes is itself an issue with Richard's proposal, not an intrinsic property. --94eb2c1cc5e680f5ac054798c5b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
If CAs do n= ot log (either maliciously or through mistake), then it is
ne= cessary for RPs to refuse to accept certificates which are not
lo= gged. However, as long as we believe that the logs behave correctly
(specifically, they never sign an SCT that they don't then log) then=
all that is required is that a certificate contain SCTs from som= e set
of logs and that RPs check that. This is roughly CT as Chro= me
proposes to implement as of end-of-2017.=C2=A0 Note that the M= erkle tree
infrastructure is not needed here at all.
<= /blockquote>

I believe you meant end-of-2016, but given = that Chrome hasn't made the statement you're attributing, it's = not fair to say "proposes to implement as of end-of-2017."
<= div>=C2=A0
The fi= nal case is the one where logs are also malicious and collude
wit= h a malicious CA to issue an SCT for a certificate but not to log
it. In order to detect this, you need to ensure that RPs have the same
view of the log structure as auditors do, because otherwise the CA c= an
issue a certificate which will be acceptable to the RP but wil= l never
be audited [0]. The general notion for current CT is that= there is
some notion of getting global consensus on the state of= the log and
then the auditors and the RPs can know that they are= checking the same
thing. This is where the Merkle tree infrastru= cture comes in (though
as I indicated previously, Richard and I d= o not believe it adequately
addresses this case).

It's unclear to me, from your remarks and = Richard remarks earlier, whether you believe this goal is explicitly not ac= hieved under the current proposals. It seems that you accept the current pr= oposal actually does address this, but that you're unhappy with there b= eing any window between issuance and global consensus. That is, there's= agreement that the current model provides detection under a certain set of= bounded constraints, but you want to reduce that.

The rest of Richard's message seems to focus on whether the system is = believed to be sufficiently scalable, but I don't know that there's= consensus with Richard's assertion - that is, that CT is too inefficie= nt to be deployed at scale. Indeed, much of the calculation seems to be bas= ed on an assumption of a design that tightens the detection window, rather = than alternatives; the point being that the inefficiency Richard notes is i= tself an issue with Richard's proposal, not an intrinsic property.
--94eb2c1cc5e680f5ac054798c5b2-- From nobody Fri Feb 3 05:49:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7498F129CEF for ; Fri, 3 Feb 2017 05:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 t8pjBkbuOYgS for ; Fri, 3 Feb 2017 05:49:48 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 64146129CFB for ; Fri, 3 Feb 2017 05:49:48 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id w194so6049477ybe.0 for ; Fri, 03 Feb 2017 05:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FW0OCKGifyfEsuQlywBAr5+hTyNlqEf0/qRcDhotNes=; b=j9VAwHWZMLucEGsSuCkD03mqdG1dmnCTU0ep8mHzOu1OykRgZOcYiGVBJmvYq2NOCG +hbnBk5NdCrsrxY3A9ADBI6O6tsB6Kq2DPcWoBptzg9UUgxm+tUqBOGIF+IpPPRFbXOU dWBPQO+Z36OuUifBWaEYXJqBfikJdw6HTlVPFAyNy2ueFRbg3tdq3X2PIgMP/ZqMiK9z jYBs7C0khzESuJmhHOTurGee02XiAr2Ww41NZnyaEVaA1IciFm4AmJTyjKUMs778ZWnA jykoydw47VCh6GSn9/F8R8BATMdL13IL+6aQduiDitZNAW3YBj+epRc+p17u00Rv/9yW wLDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FW0OCKGifyfEsuQlywBAr5+hTyNlqEf0/qRcDhotNes=; b=ebRzE14VWou7I3eBi1J8Jcqn7kfeS806nis6+v3vfrZZopzB8M4S00m8MhjPwmt6RX Ku8aBChX9KmO1ow/jG5dcdzyBnieZdi1uBohEwr3vAVDDRLc7drCxuStvLDhUob3Z/A5 aQdqMK+gdxHu5Z7bAO6Fchz1IhXzYMlEBD1RtAR65z/kpZGIo/gAiDtN+RpLqNbtMICc DKggoqJfpPj+XuzFRimBXc+NVK4nJKD1Dn3cf5VGsiA2yHU4u3XAUt5iQqaDuUh6fv/H bZ0rCvrPeLIh2RmPrTXcO24aC9JbAkuYRDlMfhE9FG7O8pUqjD00pI1IA3u8ZctHxFDC Mr3A== X-Gm-Message-State: AIkVDXKG2top/vlmZmox6jDX9hZqIuSmZYFttLha0LWIHoNCZA0qF5UW263vIUtgEG+e2fkr21ODEKguRWosSA== X-Received: by 10.37.124.195 with SMTP id x186mr5899553ybc.105.1486129787467; Fri, 03 Feb 2017 05:49:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 05:49:06 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> From: Eric Rescorla Date: Fri, 3 Feb 2017 05:49:06 -0800 Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=001a114bc39612d2c70547a08e6d Archived-At: Cc: "trans@ietf.org" , Richard Barnes , "Salz, Rich" , Melinda Shore , Paul Wouters , Ben Laurie Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:49:50 -0000 --001a114bc39612d2c70547a08e6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 2, 2017 at 8:32 PM, Ryan Sleevi wrote: > > > On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla wrote: > >> If CAs do not log (either maliciously or through mistake), then it is >> necessary for RPs to refuse to accept certificates which are not >> logged. However, as long as we believe that the logs behave correctly >> (specifically, they never sign an SCT that they don't then log) then >> all that is required is that a certificate contain SCTs from some set >> of logs and that RPs check that. This is roughly CT as Chrome >> proposes to implement as of end-of-2017. Note that the Merkle tree >> infrastructure is not needed here at all. >> > > I believe you meant end-of-2016, but given that Chrome hasn't made the > statement you're attributing, it's not fair to say "proposes to implement > as of end-of-2017." > I am referring to this statement: https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/78N3SMcqUGw/= ykIwHXuqAQAJ "This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome=E2=80=99s Cert= ificate Transparency policy in order to be trusted by Chrome. " As I understand that policy, certificates will be required to contain SCTs from some set of logs and Chrome will check that. I apologize if I have misrepresented the situation and I would appreciate any corrections or clarifications you may have. The final case is the one where logs are also malicious and collude >> with a malicious CA to issue an SCT for a certificate but not to log >> it. In order to detect this, you need to ensure that RPs have the same >> view of the log structure as auditors do, because otherwise the CA can >> issue a certificate which will be acceptable to the RP but will never >> be audited [0]. The general notion for current CT is that there is >> some notion of getting global consensus on the state of the log and >> then the auditors and the RPs can know that they are checking the same >> thing. This is where the Merkle tree infrastructure comes in (though >> as I indicated previously, Richard and I do not believe it adequately >> addresses this case). >> > > It's unclear to me, from your remarks and Richard remarks earlier, whethe= r > you believe this goal is explicitly not achieved under the current > proposals. It seems that you accept the current proposal actually does > address this, but that you're unhappy with there being any window between > issuance and global consensus. That is, there's agreement that the curren= t > model provides detection under a certain set of bounded constraints, but > you want to reduce that. > > The rest of Richard's message seems to focus on whether the system is > believed to be sufficiently scalable, but I don't know that there's > consensus with Richard's assertion - that is, that CT is too inefficient = to > be deployed at scale. Indeed, much of the calculation seems to be based o= n > an assumption of a design that tightens the detection window, rather than > alternatives; the point being that the inefficiency Richard notes is itse= lf > an issue with Richard's proposal, not an intrinsic property. > It might be better to debate this under the thread where Richard and I explicitly laid out our concerns or on the conference call which I understand the chairs to be arranging. The purpose of this parenthetical was merely to note those in the context of my understanding of the purpose of the various components of the system. With that said, I don't think that this is quite how I would state my concern. Even ignoring the question of detection window, it's not clear to us that there is a scalable story that actually provides public verifiability to clients. -Ekr --001a114bc39612d2c70547a08e6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 2, 2017 at 8:32 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
<= div dir=3D"ltr">

On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla <ekr@r= tfm.com> wrote:
If CAs do not log (either maliciously or thro= ugh mistake), then it is
necessary for RPs to refuse to accep= t certificates which are not
logged. However, as long as we belie= ve that the logs behave correctly
(specifically, they never sign = an SCT that they don't then log) then
all that is required is= that a certificate contain SCTs from some set
of logs and that R= Ps check that. This is roughly CT as Chrome
proposes to implement= as of end-of-2017.=C2=A0 Note that the Merkle tree
infrastructur= e is not needed here at all.

=
I believe you meant end-of-2016, but given that Chrome hasn't made= the statement you're attributing, it's not fair to say "propo= ses to implement as of end-of-2017."

I am referring to this statement:

"This = past week at the 39th meeting of the CA/Browser Forum, the Chrome=20 team announced plans that publicly trusted website certificates issued=20 in October 2017 or later will be expected to comply with Chrome=E2=80=99s= =20 Certificate Transparency policy in order to be trusted by Chrome. "

As I understand that policy, certificates will be re= quired to contain SCTs from some
set of logs and Chrome will chec= k that. I apologize if I have misrepresented the situation
and I = would appreciate any corrections or clarifications you may have.
=


The final case is the one where logs are a= lso malicious and collude
with a malicious CA to issue an SCT for= a certificate but not to log
it. In order to detect this, you ne= ed to ensure that RPs have the same
view of the log structure as = auditors do, because otherwise the CA can
issue a certificate whi= ch will be acceptable to the RP but will never
be audited [0]. Th= e general notion for current CT is that there is
some notion of g= etting global consensus on the state of the log and
then the audi= tors and the RPs can know that they are checking the same
thing. = This is where the Merkle tree infrastructure comes in (though
as = I indicated previously, Richard and I do not believe it adequately
addresses this case).

= It's unclear to me, from your remarks and Richard remarks earlier, whet= her you believe this goal is explicitly not achieved under the current prop= osals. It seems that you accept the current proposal actually does address = this, but that you're unhappy with there being any window between issua= nce and global consensus. That is, there's agreement that the current m= odel provides detection under a certain set of bounded constraints, but you= want to reduce that.

The rest of Richard's me= ssage seems to focus on whether the system is believed to be sufficiently s= calable, but I don't know that there's consensus with Richard's= assertion - that is, that CT is too inefficient to be deployed at scale. I= ndeed, much of the calculation seems to be based on an assumption of a desi= gn that tightens the detection window, rather than alternatives; the point = being that the inefficiency Richard notes is itself an issue with Richard&#= 39;s proposal, not an intrinsic property.

It might be better to debate this under the thread w= here Richard and I explicitly laid out our concerns
or on the= conference call which I understand the chairs to be arranging. The purpose= of this parenthetical
was merely to note those in the context of= my understanding of the purpose of the various components of
the= system.

With that said, I don't think that th= is is quite how I would state my concern. Even ignoring the question
<= div>of detection window, it's not clear to us that there is a scalable = story that actually provides public
verifiability to clients.

-Ekr



--001a114bc39612d2c70547a08e6d-- From return-hd6ixwbvxdfrj5jkmhwwarrnz6@temporary-address.scs.stanford.edu Fri Feb 10 15:12:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3831D1295D5; Fri, 10 Feb 2017 15:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 44VbmDnoyhRl; Fri, 10 Feb 2017 15:12:40 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C830F129401; Fri, 10 Feb 2017 15:12:37 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1ANCbnL007884; Fri, 10 Feb 2017 15:12:37 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1ANCb8i010273; Fri, 10 Feb 2017 15:12:37 -0800 (PST) From: David Mazieres To: trans@ietf.org, saag@ietf.org, ilc@ietf.org Date: Fri, 10 Feb 2017 15:12:37 -0800 Message-ID: <87poip3aje.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 15:45:40 -0800 Subject: [Trans] Internet-level Consensus - new list and possible BoF X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ilc@ietf.org List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:23:03 -0000 Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. Examples include: * The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. * The Stellar payment network, is used by remittance companies to trade currencies and send payments across the Internet. * UCSD's SPAM (Secure PAckage Manager) project relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency). * Stellar has an ongoing secure naming project that aims to allow domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected. We have just created a new IETF mailing mailing list to discuss such applications, the mechanisms that can meet their consensus needs, and a potential role of the IETF in devising a stable specification for an Internet-level consensus mechanism. The home page for the list is here: https://www.ietf.org/mailman/listinfo/ilc If there is interest in the topic, we would like to organize a BoF in Chicago. Please join the discussion on the list if you might be interested in participating. David From dm-list-ietf-ilc@scs.stanford.edu Fri Feb 10 15:33:31 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9E01295E8 for ; Fri, 10 Feb 2017 15:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QP6E9vNJ4SKY for ; Fri, 10 Feb 2017 15:33:28 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119491295EB for ; Fri, 10 Feb 2017 15:33:28 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1ANXRP5039873 for ; Fri, 10 Feb 2017 15:33:27 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1ANXRQF076380; Fri, 10 Feb 2017 15:33:27 -0800 (PST) From: dm-list-ietf-ilc@scs.stanford.edu To: trans@ietf.org Date: Fri, 10 Feb 2017 15:33:27 -0800 Message-ID: <877f4xaaew.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 15:45:40 -0800 Subject: [Trans] [Ilc] Internet-level Consensus - new list and possible BoF X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ilc@ietf.org List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:42:39 -0000 Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. Examples include: * The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. * The Stellar payment network, is used by remittance companies to trade currencies and send payments across the Internet. * UCSD's SPAM (Secure PAckage Manager) project relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency). * Stellar has an ongoing secure naming project that aims to allow domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected. We have just created a new IETF mailing mailing list to discuss such applications, the mechanisms that can meet their consensus needs, and a potential role of the IETF in devising a stable specification for an Internet-level consensus mechanism. The home page for the list is here: https://www.ietf.org/mailman/listinfo/ilc If there is interest in the topic, we would like to organize a BoF in Chicago. Please join the discussion on the list if you might be interested in participating. David From nobody Wed Feb 15 12:50:19 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A201297CD for ; Wed, 15 Feb 2017 12:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 6bHMpVxuZy0b for ; Wed, 15 Feb 2017 12:50:14 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 7C88D1297CE for ; Wed, 15 Feb 2017 12:50:14 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id y9so114589495uae.2 for ; Wed, 15 Feb 2017 12:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9DpmgXYPDj1VNuVFU7nEWJZwVtKime2usGY3v64UI+Q=; b=XGLJ6s4fm9DZRztSPVQsjo+4oMI1jlksYePPB1/WgEQxPuiLQ398fSiOEga0sPmTzm L7Nswo+c5ZoIjKwZUOMMXYkiWr9jvnfBukbpBPFd8870OFT5D2Mi6aVHM6BL/iNAhFVu 7zV2njVzSY/WE203UgeERU81mN85+78MNe3B4Qd6l99HXLwRRhWZL05hZP4vnS4ivc8V DMHKpfTcNzZl8dJ0+pEivyeeAkhfFKEA5v/SWr1Cr0V1AnTj9NSIecmw2AI7KFlCRIsU q/W+9bqxfbNyHQnePlbV/0edB/3jPk1aDtmXLON/svdNU4kxebTpXkJoovqKzHxai6D9 E4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9DpmgXYPDj1VNuVFU7nEWJZwVtKime2usGY3v64UI+Q=; b=tegnXJhGHrni3/VHh9m5lpC1M1/mDUIsCedi+cTZywuQhQ9Yk/2uu8/kvshQME4muL /SCPR/E6mfYzB8GwtX9ynL7UhfO2Ngyif1g+lnOjbPfTNz+ahG1vYfoaziwbuo03Em5e BXAyFL/zPSlZSccrhlyt+x3mPNXudoY3dPeDXnTMn1IsAxvsRG5GnuIhiZf80hmj34q0 6dbCSS+nNby+PLRWYOv4LoP0Wp84qteSGzGJQ2zSDGjepdQ2eAMuOaCj05aw3DHgxTNg kHkk9wjAhRupZZvaZJK6tG+EJzfFZQ9lE8AmEtTzBrUkJPYkRXR0cRryxDfmLnwxQCW3 KomQ== X-Gm-Message-State: AMke39nD8wU4/SogS6iXOpFHFBOZ9Rbu6tQF2N7rj8VqMmW/kouEXWuzyzMfZfUXJcFom1JZkL0jTU9GGtavvA== X-Received: by 10.176.2.113 with SMTP id 104mr1108770uas.155.1487191813105; Wed, 15 Feb 2017 12:50:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Wed, 15 Feb 2017 12:50:12 -0800 (PST) From: Richard Barnes Date: Wed, 15 Feb 2017 12:50:12 -0800 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary=001a113e4b92bc362b054897d33f Archived-At: Subject: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:50:18 -0000 --001a113e4b92bc362b054897d33f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear TRANS, We had a call between a group of us last week that was helpful in clarifying my thinking here. I wanted to follow up to the list with some more detailed thoughts. At base, in order to meet this group=E2=80=99s charter deliverables, what w= e want to be assured of is that the mechanisms in 6962-bis that are intended to enable public verifiability can actually do so in practice. That is, we need to establish that there is at least one plausible story for how some substantial fraction of the statements logs provide to clients end up getting audited. Part of the issue here is that we don=E2=80=99t have a full story anywhere = in the documents for how auditing works at scale, and there are a couple of incomplete models floating around that lead to different design requirements for the public verifiability parts of CT, i.e., the part that is now the Merkle tree. So let=E2=80=99s consider two straw-man models and= look at the differences they lead to. Call them =E2=80=9COption G=E2=80=9D and =E2= =80=9COption M=E2=80=9D :) In the below, we assume: - "STH" is a general term for an object that: 1. represents the state of a log at a given time 2. is signed by the log 3. can be verified to fit into a linear sequence with other STHs - Server cannot be relied upon to take action, so any CT information needs to come to the client from the CA Option G: Cache one STH / dynamic inclusion proofs 1. Auditor pulls STHs from logs at some frequency, validates consistency 2. Periodically, the client obtains from the auditor: a. The latest validated STH b. A proof of consistency from the last STH the client received 3. Client is configured to talk to a log proxy over DNS (for privacy) 4. Client gets SCT from server 5. Client audits by fetching inclusion proof to current STH from log proxy over DNS - [PRO] CA can issue immediately due to use of SCTs - [PRO] Client only has to keep latest SCT - [PRO] Compatible with existing CA practices w.r.t. SCTs - [CON] Client has to reveal browsing history to log proxy in queries - [CON] Audit failure from DNS failure indistinguishable from log malfeasance - [CON] Someone needs to operate a log proxy - [CON] Requirement for audit-time fetches effectively forces audits to be off-line w.r.t. certificate verification / TLS connection time Option M: Cache many STHs / static inclusion proofs 1. Auditor pulls STHs from logs at some frequency, validates consistency 2. Periodically, the client obtains from the auditor: a. A list of all STHs since the last one the client received b. Proofs of consistency along this chain 3. Client caches entire history of STHs that it has received (really just needs to store tree heads) 4. Client gets inclusion proof to an STH from server (either in the certificate or in a stapled OCSP response), verifies it 5. Client audits by verifying that the STH provided by the server is in the validated cache - [PRO] Client never makes queries that are dependent on browsing history - [PRO] Auditing can only fail if client state is stale (no live queries) - [PRO] No need for a log proxy - [PRO] If inclusion proof is provided at connection / validation time, then auditing can be done immediately for certificates that are old enough for their STHs to have propagated - [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert - [CON] Client needs to store entire history of STHs - [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / in addition to SCTs # Requirements for STHs / log structure Option G requires: - STHs can be issued relatively infrequently (say daily) - Inclusion proofs need to be log depth to any STH Option M requires: - STHs need to be issued relatively frequently (say ~5-10min) - Inclusion proofs need to be log depth only to the proximal STH Option G leads naturally to the current design, with a global Merkle tree. Option M leads to something like a Haber-Stornetta hash chain of batch Merkle trees. And conversely, each of these log structures is unfriendly to the other operational model. In general, whatever structure is assigned to the log in 6962-bis will encode assumptions about the operation of the overall system. So we need to discuss the overall system before we decide on the log structure. # What this means for 6962bis Whatever we specify in 6962bis will enable some models for auditing and make other models infeasible. It=E2=80=99s important that whichever models= 6962bis enables not have other features that make them infeasible to deploy. It seems to me that the two models above stake out roughly the two ends of the design space. I believe Option G is pretty much what Google is planning to deploy right now, though of course I might be mistaken about that. Personally, between the two, I find Option M much more appealing, largely because the failings of Option G seem much more intractable. Log proxies seem like a significant addition to the required infrastructure here, and the analysis required to separate mundane failures in queries to the log proxy from attacks on auditing seems likely to go awry. And I have a lot of difficulty imagining any mechanism for client queries that I would be comfortable with from a privacy point of view. Option M is not without problems. We=E2=80=99ll need to find some way to a= ddress the issuance delay problem, whether that entails some OCSP magic to bridge the gap or just getting the merge delays down to where the delay is acceptable to CAs. We=E2=80=99ll need to work out some migration question = about how But in any case, we need to get more alignment among the stakeholders here on what models for auditing are acceptable before we finalize the public verification mechanisms in 6962bis. Obviously, the countersignature-related parts of the document are not tied up in this discussion at all, so if someone wants to pull those out into a separate document, I would have no problem advancing that to PS straight away. =E2=80=94Richard --001a113e4b92bc362b054897d33f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TRANS,

We had a call between a group of us las= t week that was helpful in clarifying my thinking here.=C2=A0 I wanted to f= ollow up to the list with some more detailed thoughts.

At base, in o= rder to meet this group=E2=80=99s charter deliverables, what we want to be = assured of is that the mechanisms in 6962-bis that are intended to enable p= ublic verifiability can actually do so in practice.=C2=A0 That is, we need = to establish that there is at least one plausible story for how some substa= ntial fraction of the statements logs provide to clients end up getting aud= ited.

Part of the issue here is that we don=E2=80=99t have a full st= ory anywhere in the documents for how auditing works at scale, and there ar= e a couple of incomplete models floating around that lead to different desi= gn requirements for the public verifiability parts of CT, i.e., the part th= at is now the Merkle tree.=C2=A0 So let=E2=80=99s consider two straw-man mo= dels and look at the differences they lead to.=C2=A0 Call them =E2=80=9COpt= ion G=E2=80=9D and =E2=80=9COption M=E2=80=9D :)

In the below, we as= sume:

- "STH" is a general term for an object that:
=C2= =A0 1. represents the state of a log at a given time
=C2=A0 2. is signed= by the log
=C2=A0 3. can be verified to fit into a linear sequence with= other STHs
- Server cannot be relied upon to take action, so any CT inf= ormation needs to come to the client from the CA


Option G: Cache= one STH / dynamic inclusion proofs


1. Auditor pulls STHs from l= ogs at some frequency, validates consistency
2. Periodically, the client= obtains from the auditor:
=C2=A0 a. The latest validated STH
=C2=A0 = b. A proof of consistency from the last STH the client received
3. Clien= t is configured to talk to a log proxy over DNS (for privacy)
4. Client = gets SCT from server
5. Client audits by fetching inclusion proof to cur= rent STH from log proxy over DNS


- [PRO] CA can issue immediatel= y due to use of SCTs
- [PRO] Client only has to keep latest SCT
- [PR= O] Compatible with existing CA practices w.r.t. SCTs
- [CON] Client has = to reveal browsing history to log proxy in queries
- [CON] Audit failure= from DNS failure indistinguishable from log malfeasance
- [CON] Someone= needs to operate a log proxy
- [CON] Requirement for audit-time fetches= effectively forces audits to be off-line w.r.t. certificate verification /= TLS connection time


Option M: Cache many STHs / static inclusio= n proofs


1. Auditor pulls STHs from logs at some frequency, vali= dates consistency
2. Periodically, the client obtains from the auditor:<= br>=C2=A0 a. A list of all STHs since the last one the client received
= =C2=A0 b. Proofs of consistency along this chain
3. Client caches entire= history of STHs that it has received (really just needs to store tree head= s)
4. Client gets inclusion proof to an STH from server (either in the c= ertificate or in a stapled OCSP response), verifies it
5. Client audits = by verifying that the STH provided by the server is in the validated cache<= br>

- [PRO] Client never makes queries that are dependent on browsin= g history
- [PRO] Auditing can only fail if client state is stale (no li= ve queries)
- [PRO] No need for a log proxy
- [PRO] If inclusion proo= f is provided at connection / validation time, then auditing can be done im= mediately for certificates that are old enough for their STHs to have propa= gated
- [CON] CA needs to wait for inclusion proof if inclusion proof is= included in cert
- [CON] Client needs to store entire history of STHs- [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / in= addition to SCTs


# Requirements for STHs / log structure
Option G requires:

- STHs can be issued relatively infrequently (sa= y daily)
- Inclusion proofs need to be log depth to any STH

Optio= n M requires:

- STHs need to be issued relatively frequently (say ~5= -10min)
- Inclusion proofs need to be log depth only to the proximal STH=

Option G leads naturally to the current design, with a global Merkl= e tree.=C2=A0 Option M leads to something like a Haber-Stornetta hash chain= of batch Merkle trees.=C2=A0 And conversely, each of these log structures = is unfriendly to the other operational model.

In general, whatever s= tructure is assigned to the log in 6962-bis will encode assumptions about t= he operation of the overall system.=C2=A0 So we need to discuss the overall= system before we decide on the log structure.


# What this means= for 6962bis

Whatever we specify in 6962bis will enable some models = for auditing and make other models infeasible.=C2=A0 It=E2=80=99s important= that whichever models 6962bis enables not have other features that make th= em infeasible to deploy.

It seems to me that the two models above st= ake out roughly the two ends of the design space.=C2=A0 I believe Option G = is pretty much what Google is planning to deploy right now, though of cours= e I might be mistaken about that.=C2=A0

Personally, between the two= , I find Option M much more appealing, largely because the failings of Opti= on G seem much more intractable.=C2=A0 Log proxies seem like a significant = addition to the required infrastructure here, and the analysis required to = separate mundane failures in queries to the log proxy from attacks on audit= ing seems likely to go awry.=C2=A0=C2=A0 And I have a lot of difficulty ima= gining any mechanism for client queries that I would be comfortable with fr= om a privacy point of view.

Option M is not without problems.=C2=A0 = We=E2=80=99ll need to find some way to address the issuance delay problem, = whether that entails some OCSP magic to bridge the gap or just getting the = merge delays down to where the delay is acceptable to CAs.=C2=A0 We=E2=80= =99ll need to work out some migration question about how

But in any= case, we need to get more alignment among the stakeholders here on what mo= dels for auditing are acceptable before we finalize the public verification= mechanisms in 6962bis.

Obviously, the countersignature-related part= s of the document are not tied up in this discussion at all, so if someone = wants to pull those out into a separate document, I would have no problem a= dvancing that to PS straight away.

=E2=80=94Richard

--001a113e4b92bc362b054897d33f-- From nobody Wed Feb 15 14:35:55 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0236129880 for ; Wed, 15 Feb 2017 14:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=ritter.vg 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 35YcnZjQQBSw for ; Wed, 15 Feb 2017 14:35:52 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 BFAE21293EE for ; Wed, 15 Feb 2017 14:35:52 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id p22so480528qka.0 for ; Wed, 15 Feb 2017 14:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S3JPkwyRQDRX2FWPM5nMteZV0qpk2JLjE5cijOTiYms=; b=W4z7sRHDWzVKhovO5bidR5zEMK1gPR1AmXC70IoVP+VzAWEhBfU7t+Ze/sa/49bJoX HRDTD05QUCmZTtFGeSWDeE8LLcI51IEgpaeRPoQ1oclm852NtIhWPPjKC57IO1zvONA9 IEk/KiMjLZv+Wj1fJu1Jnn+zMqv6Q635jU8b8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S3JPkwyRQDRX2FWPM5nMteZV0qpk2JLjE5cijOTiYms=; b=COAEgg8TDBi5ch8i9FQMe+KZa1+aI2B/PmgrhTYCZVgYarh9amHdw0FMufyPcNDamY tE41LF0c9HXnfi4Nmq2/KOypL12pxn+71DhhwQwVscAxP4F6+xkFKsnFQ382RI3EyG6s 4zyg95+QMuBlbz5p9fHClBg2ZgGzuzelrNXhXxXKnuaK5p7wJli5TbVhvdNsbTuLw/SP nI2cjEVAln2ShjFkw1UHDb/clAOTREhsAUxvr9Uad4eZhlJ1S3/wsDu869Ju7bNJy+cH AIstie6vIb8lTUJ1R/mD8HyFneP8IYePc0obnr1ekKsEZedlpI9wP9XZSS+/QCFz2lCY c73g== X-Gm-Message-State: AMke39kfJah/J8iPC79MEN4ZUDb4s8CJ+ceR/8Yz8v03mja8AX1aWNxoIJ1vfTMZwu9Z1poTBwyUE635uxJBBQIq X-Received: by 10.55.113.129 with SMTP id m123mr38918156qkc.47.1487198151557; Wed, 15 Feb 2017 14:35:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.94.244 with HTTP; Wed, 15 Feb 2017 14:35:31 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Wed, 15 Feb 2017 16:35:31 -0600 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:35:54 -0000 On 15 February 2017 at 14:50, Richard Barnes wrote: > Dear TRANS, > > We had a call between a group of us last week that was helpful in clarify= ing > my thinking here. I wanted to follow up to the list with some more detai= led > thoughts. > > At base, in order to meet this group=E2=80=99s charter deliverables, what= we want to > be assured of is that the mechanisms in 6962-bis that are intended to ena= ble > public verifiability can actually do so in practice. That is, we need to > establish that there is at least one plausible story for how some > substantial fraction of the statements logs provide to clients end up > getting audited. > > Part of the issue here is that we don=E2=80=99t have a full story anywher= e in the > documents for how auditing works at scale, and there are a couple of > incomplete models floating around that lead to different design requireme= nts > for the public verifiability parts of CT, i.e., the part that is now the > Merkle tree. So let=E2=80=99s consider two straw-man models and look at = the > differences they lead to. Call them =E2=80=9COption G=E2=80=9D and =E2= =80=9COption M=E2=80=9D :) > > In the below, we assume: > > - "STH" is a general term for an object that: > 1. represents the state of a log at a given time > 2. is signed by the log > 3. can be verified to fit into a linear sequence with other STHs > - Server cannot be relied upon to take action, so any CT information need= s > to come to the client from the CA > > > Option G: Cache one STH / dynamic inclusion proofs > > > 1. Auditor pulls STHs from logs at some frequency, validates consistency > 2. Periodically, the client obtains from the auditor: > a. The latest validated STH > b. A proof of consistency from the last STH the client received > 3. Client is configured to talk to a log proxy over DNS (for privacy) > 4. Client gets SCT from server > 5. Client audits by fetching inclusion proof to current STH from log prox= y > over DNS > > > - [PRO] CA can issue immediately due to use of SCTs > - [PRO] Client only has to keep latest SCT > - [PRO] Compatible with existing CA practices w.r.t. SCTs > - [CON] Client has to reveal browsing history to log proxy in queries > - [CON] Audit failure from DNS failure indistinguishable from log > malfeasance > - [CON] Someone needs to operate a log proxy > - [CON] Requirement for audit-time fetches effectively forces audits to b= e > off-line w.r.t. certificate verification / TLS connection time > > > Option M: Cache many STHs / static inclusion proofs > > > 1. Auditor pulls STHs from logs at some frequency, validates consistency > 2. Periodically, the client obtains from the auditor: > a. A list of all STHs since the last one the client received > b. Proofs of consistency along this chain > 3. Client caches entire history of STHs that it has received (really just > needs to store tree heads) > 4. Client gets inclusion proof to an STH from server (either in the > certificate or in a stapled OCSP response), verifies it > 5. Client audits by verifying that the STH provided by the server is in t= he > validated cache > > > - [PRO] Client never makes queries that are dependent on browsing history > - [PRO] Auditing can only fail if client state is stale (no live queries) > - [PRO] No need for a log proxy > - [PRO] If inclusion proof is provided at connection / validation time, t= hen > auditing can be done immediately for certificates that are old enough for > their STHs to have propagated > - [CON] CA needs to wait for inclusion proof if inclusion proof is includ= ed > in cert > - [CON] Client needs to store entire history of STHs > - [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / in > addition to SCTs Neither option specifies what the client does when it finds some data suspicious or how it shared said data with an auditor. I'm not sure you can leave this unspecified while trying to decide the rest of things. For example, in Option G do you report SCTs you can't resolve inclusion proofs for after N tries? In Option M what do you do about STHs you don't have in your verified cache? I'm also unclear if the log proxy is also an auditor (it seems like it implies it is, but that doesn't seem right.) That Option M problem is an additional con I think: [CON] Client must cache or otherwise handle the situation when the inclusion proof is to a STH is doesn't know about. This could be either an attack or just a newly issued certificate. This devolves to the case of off-line verification in G. -tom From nobody Wed Feb 15 15:38:13 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE53129BCB for ; Wed, 15 Feb 2017 15:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 0Xz1CaeQ7zaq for ; Wed, 15 Feb 2017 15:38:09 -0800 (PST) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BA1129B9E for ; Wed, 15 Feb 2017 15:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1487201889; bh=imCCKfZDYKRnfXwkRSXVwlbNnTTHu28yECQASFB+qHk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=swWgb2d+IzTolGKU6WAjqiqwvBmGL5KBlMC6TaOENxqP0IfJPTmr/MJgYeafOWrHF FwUI9mTKV/u2FshSwJFgcEGCfsqpL6Kv5wN9ivOozI1d/O7AJRDWnv8ttX0fbzIK39 Nabg8E5q1XG4VV3AbjBLuQCufRv/5KEpY/m0VIHdUetdC6w8BEMk1iiauHrP/V7Uzf 5OarHVquRtJ2r2lMogp77mnbO9Knm0QpvUBjJ+CJxH18SoFoG1U0t0NRmzBxS1ahuR HzVrVXBAXhEQci/WlwWnfGZJGWRR5yYkhGlByoTYMzruh3Nlv1zgCa0sabhiFCA+QC NavUsi55Azi1Q== Date: Wed, 15 Feb 2017 15:38:08 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170215153808.1d276ae3c7a6a9be3c6b95b3@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:38:11 -0000 On Wed, 15 Feb 2017 12:50:12 -0800 Richard Barnes wrote: > > [...] > > Option M: Cache many STHs / static inclusion proofs > > [...] > > - [PRO] If inclusion proof is provided at connection / validation > time, then auditing can be done immediately for certificates that are > old enough for their STHs to have propagated Since a client cannot distinguish between a rogue STH and a legitimate STH that it doesn't know about yet, it has no choice but to accept the connection if it doesn't know about an STH and audit it later. Therefore, option M is no better than option G in this regard: both provide post-hoc detection rather than prevention. You can't call this a "pro" for option M while simultaneously calling it a "con" for Option G. > [...] > > Option M leads to something like a Haber-Stornetta hash chain > of batch Merkle trees. Why? The only justification provided so far is that a client would need to download 4MB of data a month, which is a "pretty big chunk of data."[1] This is a rather extraordinary claim. Can you explain your reasoning why 4MB a month is too much? Even if 4MB/month is deemed excessive, there are other options which avoid reliance on SCTs, but can be implemented on top of 6962bis' current design without requiring clients to download 4MB a month. Let's call them Options A1 and A2. Option A1: Fetch consistency proofs on demand 1. Client gets an STH and an inclusion proof to the STH from server, verifies the proof, and adds STH to a cache if not already present. 2. In the background, client audits unverified STHs in the cache by requesting a consistency proof between the unverified STH and some other verified STH. - [PRO] No need to audit SCTs. - [PRO] Although client makes queries (consistency proofs) that are triggered by browsing, the queries do not reveal browsing history because many certificates use inclusion proofs to the same STH. - [PRO] No need for a log proxy. - [PRO] Client only needs to fetch consistency proofs for STHs it actually sees. - [PRO] Client only needs to store STHs it actually sees. - [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert. - [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in addition to SCTs. I asked you on-list two weeks ago why this wouldn't work[2], but you have not replied. Option A2: Publicly-logged STH batches 1. Auditor pulls STHs from logs at some frequency, validates consistency. 2. Periodically, auditor logs batches of STHs to CT logs. 3. Periodically, the client obtains from the auditor: a. Batches of STHs since the last one the client received b. Inclusion proofs for each STH batch up to the log's latest STH c. Consistency proof between the last STH received by the client and the latest STH 4. The client verifies all proofs received from auditor, but assumes that the STHs in the batches are legitimate. 5. Client caches entire history of STHs that it has received (really just needs to store tree heads). 6. Client gets inclusion proof to an STH from server (either in the certificate or in a stapled OCSP response), verifies it. 7. Client audits by verifying that the STH provided by the server is in the cache. 8. An ecosystem of auditors monitors logs for STH batches and audits all contained STHs by requesting consistency proofs. This saves the client from having to verify every single STH itself. - [PRO] No need to audit SCTs. - [PRO] Client never makes queries in response to browsing. - [PRO] No need for a log proxy. - [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert. - [CON] Client needs to store entire history of STHs. - [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in addition to SCTs. Option A2 is very similar to Option M, but avoids the need for clients to do their own STH auditing (except for STHs related to the STH batches). If you're happy with Option M you should be happy with Option A2, even when implemented on top of the current Merkle Tree design. I agree with many of your concerns about SCT auditing, but considering that Options A1 and A2 can be implemented on top of 6962bis (plus Option M if 4MB/month can be tolerated), I don't see why these concerns should hold up publication. Regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368 [2] https://mailarchive.ietf.org/arch/msg/trans/sA7ZrHIsuqWvIkF0B4I8dv8nKsY From nobody Wed Feb 15 16:01:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31052129C02 for ; Wed, 15 Feb 2017 16:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 9xVmTlfaHoiT for ; Wed, 15 Feb 2017 16:01:20 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 82D2D129BFE for ; Wed, 15 Feb 2017 16:01:20 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id 96so1252406uaq.3 for ; Wed, 15 Feb 2017 16:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BKBb0gEOGwGB7e1nq3PNuq5AzIFggSrwf0puBlaBYRU=; b=EWKmSpoHXNeHiDGyC+RJHpCgGhW+MrpKI90yT6lIWW/Ocv9l6F2N85nmNqJbFjFWWq QvUT/TptAu3tH8fpIEjVxvZgExgNFvA0O+HOWzj4G3muuSxNTChfUxpwUDHNtGqrEApv gl679NGlxWscBo5HcutYUiGcU5HBahA04Qs9X221olT73bBXqlYHWlhN++g18l/2c8HO YojrrSKDD1WeQ2douy3FTzlA1BoYNKZdBgYYR2a49elEUv1Q6uihPeNecO4WKNlJLi0L 2elsszUzFXQaXruGEJtJ6kTrKlFTwyIvtMQ/gBhmwIN0yJNmcyfUXYPfHsXTWyPK473J Fuig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BKBb0gEOGwGB7e1nq3PNuq5AzIFggSrwf0puBlaBYRU=; b=FaB4VU1WQOUsUZ6pAJRMN10OpxqQdu8dc8GH2pGTtSqgIVrVSjsewLPeL/GCZCuW25 PnJ6540Uc+gQuN08+fWTfTXXmRljYRV6EO3LGpQO3TMjLGPU//HrJAcxxfshn/NLsNR6 gQm9/7d3j0FH+OKvqUNuzPhSs39vSVZMBAPo5L8eCubR739eop0zcxa6iDNE5pWNQv4e xtQxma/88jVAE+4c1FEYPOZZKE+NdBurfzOzNppyewiAUNeXJLGsW8+XuL6DodUzqbrp INxqUc4y1AnRtC5qoYN/LHhpQTBHbxRGD0lZ19OgzF3zQRRb9+2ui60aolaNhUC5jMC4 l6Kg== X-Gm-Message-State: AMke39nl1WrkdQBY1zoiruem0/+kdfTvVQbsO4iA81p1lDWQQ2lcf2xiKK7mN1zSMFhRnkvJfs3BX2bJnPwXIQ== X-Received: by 10.159.36.73 with SMTP id 67mr20684497uaq.124.1487203279323; Wed, 15 Feb 2017 16:01:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Wed, 15 Feb 2017 16:01:18 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Wed, 15 Feb 2017 16:01:18 -0800 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=001a113e1c9c2ccc5b05489a7f42 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:01:22 -0000 --001a113e1c9c2ccc5b05489a7f42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 2:35 PM, Tom Ritter wrote: > On 15 February 2017 at 14:50, Richard Barnes wrote: > > Dear TRANS, > > > > We had a call between a group of us last week that was helpful in > clarifying > > my thinking here. I wanted to follow up to the list with some more > detailed > > thoughts. > > > > At base, in order to meet this group=E2=80=99s charter deliverables, wh= at we > want to > > be assured of is that the mechanisms in 6962-bis that are intended to > enable > > public verifiability can actually do so in practice. That is, we need = to > > establish that there is at least one plausible story for how some > > substantial fraction of the statements logs provide to clients end up > > getting audited. > > > > Part of the issue here is that we don=E2=80=99t have a full story anywh= ere in the > > documents for how auditing works at scale, and there are a couple of > > incomplete models floating around that lead to different design > requirements > > for the public verifiability parts of CT, i.e., the part that is now th= e > > Merkle tree. So let=E2=80=99s consider two straw-man models and look a= t the > > differences they lead to. Call them =E2=80=9COption G=E2=80=9D and =E2= =80=9COption M=E2=80=9D :) > > > > In the below, we assume: > > > > - "STH" is a general term for an object that: > > 1. represents the state of a log at a given time > > 2. is signed by the log > > 3. can be verified to fit into a linear sequence with other STHs > > - Server cannot be relied upon to take action, so any CT information > needs > > to come to the client from the CA > > > > > > Option G: Cache one STH / dynamic inclusion proofs > > > > > > 1. Auditor pulls STHs from logs at some frequency, validates consistenc= y > > 2. Periodically, the client obtains from the auditor: > > a. The latest validated STH > > b. A proof of consistency from the last STH the client received > > 3. Client is configured to talk to a log proxy over DNS (for privacy) > > 4. Client gets SCT from server > > 5. Client audits by fetching inclusion proof to current STH from log > proxy > > over DNS > > > > > > - [PRO] CA can issue immediately due to use of SCTs > > - [PRO] Client only has to keep latest SCT > > - [PRO] Compatible with existing CA practices w.r.t. SCTs > > - [CON] Client has to reveal browsing history to log proxy in queries > > - [CON] Audit failure from DNS failure indistinguishable from log > > malfeasance > > - [CON] Someone needs to operate a log proxy > > - [CON] Requirement for audit-time fetches effectively forces audits to > be > > off-line w.r.t. certificate verification / TLS connection time > > > > > > Option M: Cache many STHs / static inclusion proofs > > > > > > 1. Auditor pulls STHs from logs at some frequency, validates consistenc= y > > 2. Periodically, the client obtains from the auditor: > > a. A list of all STHs since the last one the client received > > b. Proofs of consistency along this chain > > 3. Client caches entire history of STHs that it has received (really ju= st > > needs to store tree heads) > > 4. Client gets inclusion proof to an STH from server (either in the > > certificate or in a stapled OCSP response), verifies it > > 5. Client audits by verifying that the STH provided by the server is in > the > > validated cache > > > > > > - [PRO] Client never makes queries that are dependent on browsing histo= ry > > - [PRO] Auditing can only fail if client state is stale (no live querie= s) > > - [PRO] No need for a log proxy > > - [PRO] If inclusion proof is provided at connection / validation time, > then > > auditing can be done immediately for certificates that are old enough f= or > > their STHs to have propagated > > - [CON] CA needs to wait for inclusion proof if inclusion proof is > included > > in cert > > - [CON] Client needs to store entire history of STHs > > - [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / = in > > addition to SCTs > > > Neither option specifies what the client does when it finds some data > suspicious or how it shared said data with an auditor. I'm not sure > you can leave this unspecified while trying to decide the rest of > things. For example, in Option G do you report SCTs you can't resolve > inclusion proofs for after N tries? In Option M what do you do about > STHs you don't have in your verified cache? I'm also unclear if the > log proxy is also an auditor (it seems like it implies it is, but that > doesn't seem right.) > I agree that this is important, but I don't really see a connection to log structure. In either case, at this stage, the client has in hand the data it needs to claim a violation; the only question is how it get reported. > That Option M problem is an additional con I think: > [CON] Client must cache or otherwise handle the situation when the > inclusion proof is to a STH is doesn't know about. This could be > either an attack or just a newly issued certificate. This devolves to > the case of off-line verification in G. > It's true that if you get a proof to an STH you don't have, then you have to cache it and see if you get one in a reasonable amount of time. I didn't count this as a CON for M because it's the same as G -- the point of the PRO there was that M can do immediate validation in many cases, but G never can. --Richard > -tom > --001a113e1c9c2ccc5b05489a7f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 15, 2017 at 2:35 PM, Tom Ritter <tom@ritter.vg> = wrote:
On 15 February 2017 at 14:50, Richard Barnes <rlb@ipv.sx> wro= te:
> Dear TRANS,
>
> We had a call between a group of us last week that was helpful in clar= ifying
> my thinking here.=C2=A0 I wanted to follow up to the list with some mo= re detailed
> thoughts.
>
> At base, in order to meet this group=E2=80=99s charter deliverables, w= hat we want to
> be assured of is that the mechanisms in 6962-bis that are intended to = enable
> public verifiability can actually do so in practice.=C2=A0 That is, we= need to
> establish that there is at least one plausible story for how some
> substantial fraction of the statements logs provide to clients end up<= br> > getting audited.
>
> Part of the issue here is that we don=E2=80=99t have a full story anyw= here in the
> documents for how auditing works at scale, and there are a couple of > incomplete models floating around that lead to different design requir= ements
> for the public verifiability parts of CT, i.e., the part that is now t= he
> Merkle tree.=C2=A0 So let=E2=80=99s consider two straw-man models and = look at the
> differences they lead to.=C2=A0 Call them =E2=80=9COption G=E2=80=9D a= nd =E2=80=9COption M=E2=80=9D :)
>
> In the below, we assume:
>
> - "STH" is a general term for an object that:
>=C2=A0 =C2=A01. represents the state of a log at a given time
>=C2=A0 =C2=A02. is signed by the log
>=C2=A0 =C2=A03. can be verified to fit into a linear sequence with othe= r STHs
> - Server cannot be relied upon to take action, so any CT information n= eeds
> to come to the client from the CA
>
>
> Option G: Cache one STH / dynamic inclusion proofs
>
>
> 1. Auditor pulls STHs from logs at some frequency, validates consisten= cy
> 2. Periodically, the client obtains from the auditor:
>=C2=A0 =C2=A0a. The latest validated STH
>=C2=A0 =C2=A0b. A proof of consistency from the last STH the client rec= eived
> 3. Client is configured to talk to a log proxy over DNS (for privacy)<= br> > 4. Client gets SCT from server
> 5. Client audits by fetching inclusion proof to current STH from log p= roxy
> over DNS
>
>
> - [PRO] CA can issue immediately due to use of SCTs
> - [PRO] Client only has to keep latest SCT
> - [PRO] Compatible with existing CA practices w.r.t. SCTs
> - [CON] Client has to reveal browsing history to log proxy in queries<= br> > - [CON] Audit failure from DNS failure indistinguishable from log
> malfeasance
> - [CON] Someone needs to operate a log proxy
> - [CON] Requirement for audit-time fetches effectively forces audits t= o be
> off-line w.r.t. certificate verification / TLS connection time
>
>
> Option M: Cache many STHs / static inclusion proofs
>
>
> 1. Auditor pulls STHs from logs at some frequency, validates consisten= cy
> 2. Periodically, the client obtains from the auditor:
>=C2=A0 =C2=A0a. A list of all STHs since the last one the client receiv= ed
>=C2=A0 =C2=A0b. Proofs of consistency along this chain
> 3. Client caches entire history of STHs that it has received (really j= ust
> needs to store tree heads)
> 4. Client gets inclusion proof to an STH from server (either in the > certificate or in a stapled OCSP response), verifies it
> 5. Client audits by verifying that the STH provided by the server is i= n the
> validated cache
>
>
> - [PRO] Client never makes queries that are dependent on browsing hist= ory
> - [PRO] Auditing can only fail if client state is stale (no live queri= es)
> - [PRO] No need for a log proxy
> - [PRO] If inclusion proof is provided at connection / validation time= , then
> auditing can be done immediately for certificates that are old enough = for
> their STHs to have propagated
> - [CON] CA needs to wait for inclusion proof if inclusion proof is inc= luded
> in cert
> - [CON] Client needs to store entire history of STHs
> - [CON] Requires CAs to upgrade to fetch inclusion proofs instead of /= in
> addition to SCTs


Neither option specifies what the client does when it finds som= e data
suspicious or how it shared said data with an auditor. I'm not sure
you can leave this unspecified while trying to decide the rest of
things. For example, in Option G do you report SCTs you can't resolve inclusion proofs for after N tries? In Option M what do you do about
STHs you don't have in your verified cache? I'm also unclear if the=
log proxy is also an auditor (it seems like it implies it is, but that
doesn't seem right.)

I agree that t= his is important, but I don't really see a connection to log structure.= =C2=A0 In either case, at this stage, the client has in hand the data it ne= eds to claim a violation; the only question is how it get reported.
=C2=A0
That Option M problem is an additional con I think:
[CON] Client must cache or otherwise handle the situation when the
inclusion proof is to a STH is doesn't know about. This could be
either an attack or just a newly issued certificate. This devolves to
the case of off-line verification in G.

It's true that if you get a proof to an STH you don't have, then y= ou have to cache it and see if you get one in a reasonable amount of time.= =C2=A0 I didn't count this as a CON for M because it's the same as = G -- the point of the PRO there was that M can do immediate validation in m= any cases, but G never can.=C2=A0
=C2=A0
--Ric= hard



-tom

--001a113e1c9c2ccc5b05489a7f42-- From nobody Wed Feb 15 16:33:48 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DE129550 for ; Wed, 15 Feb 2017 16:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 WBl4T0h6-JWP for ; Wed, 15 Feb 2017 16:33:42 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 58E6A12953F for ; Wed, 15 Feb 2017 16:33:42 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id r136so1590092vke.1 for ; Wed, 15 Feb 2017 16:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vNqqR8D3pZ8ipwFM9PaOWG4JcPCVNZ9ZH2xVaWw12dg=; b=XqqscMDFhD4X+4J7+mdkNe8px+JL0xA/P9xs8dxbnDKJ9+7e+/rFRMB/nvlbPmj8sd A7hHu9pjEf6LbqRr20vEF/l9p1/vJhZcyoJR6NiT2+uKVWJFGaQwb2LVK9hKCTcZMwtQ u5H0+ZkQ4ja1SLvY+oOcWgiYRQmMKEqZWpkL+ffRo0FQ8MSLLvBHslFebY9qrvuszrnA mRBBTMi3/8yNVxJH7AU5dWt1DSS6sFMzXi4kwRwVyY7iOUgJih89lawZRsZz/zeUlRwV g0ML5XW6818QQZnqub2RggzibcB8nDq4n2Mc9Z2XH+rE+4VeODDmTf332joRDPwVAnr2 XYOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vNqqR8D3pZ8ipwFM9PaOWG4JcPCVNZ9ZH2xVaWw12dg=; b=bAjF0xaCQQzhiqOkmC+yzIADT5QqzhlXCxaoc8WcTenX/J4zx1MYZFnzYG1CxYRf1Y v+uVaUO9G0zscl7YVn86raJsl+WvxRlxEF+yzCNvDCF9anAvxKnJNjBVeNp8xOFw1QTl MyAXbi6th24AFAG0NYS67UuS1O27rL71F1Jes7OLrPp0+yg5BE07zN7lvaXI7Cj2j2Bh l0eQQbkyXGgYeDbsEvf6YwZ8c1uTLDNHZGLT3qoyuKUgkg6+aGoGAxPx4FFr1apZEQe6 YvoHAEijKnzmh+SOq4ThWv2yELL6btsmuZax/QrWLfX1Q2Xg8sJCd8rC/GDU4XVj+yao bgiQ== X-Gm-Message-State: AMke39nMUIXN8EczhWY8NCLkzOMZAmaqZNgVsAbI/u0vmvgK+LEbSbUpOzj4PV8gj52WDIK+evc8jExntNRuQg== X-Received: by 10.31.192.204 with SMTP id q195mr18682912vkf.155.1487205221126; Wed, 15 Feb 2017 16:33:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Wed, 15 Feb 2017 16:33:40 -0800 (PST) In-Reply-To: <20170215153808.1d276ae3c7a6a9be3c6b95b3@andrewayer.name> References: <20170215153808.1d276ae3c7a6a9be3c6b95b3@andrewayer.name> From: Richard Barnes Date: Wed, 15 Feb 2017 16:33:40 -0800 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=001a114388ccea3ee405489af255 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:33:46 -0000 --001a114388ccea3ee405489af255 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 3:38 PM, Andrew Ayer wrote: > On Wed, 15 Feb 2017 12:50:12 -0800 > Richard Barnes wrote: > > > > [...] > > > > Option M: Cache many STHs / static inclusion proofs > > > > [...] > > > > - [PRO] If inclusion proof is provided at connection / validation > > time, then auditing can be done immediately for certificates that are > > old enough for their STHs to have propagated > > Since a client cannot distinguish between a rogue STH and a legitimate > STH that it doesn't know about yet, it has no choice but to accept the > connection if it doesn't know about an STH and audit it later. Therefore, > option M is no better than option G in this regard: both provide post-hoc > detection rather than prevention. You can't call this a "pro" for option > M while simultaneously calling it a "con" for Option G. > > > [...] > > > > Option M leads to something like a Haber-Stornetta hash chain > > of batch Merkle trees. > > Why? The only justification provided so far is that a client would > need to download 4MB of data a month, which is a "pretty big chunk of > data."[1] This is a rather extraordinary claim. Can you explain your > reasoning why 4MB a month is too much? > To be a bit glib -- the folks who manage syncing state out to Firefox balked when I mentioned it to them. Basically, that amount might not sound scary from the client side, but if you're thinking about syncing that data out to 100s of millions of clients, that's an extra few 100MBps of capacity you have to provision, and it's only kinda cacheable. > Even if 4MB/month is deemed excessive, there are other options which > avoid reliance on SCTs, but can be implemented on top of 6962bis' > current design without requiring clients to download 4MB a month. > Let's call them Options A1 and A2. > To be clear, I did not mean to imply that these were the only options. On the contrary, I would like to have some discussion about the options here so we can understand what requirements we should be holding 6962bis to. Can you explain why being implemented on top of the current system is a requirement? I can see why it's desireable, e.g., to avoid further delay. But in general, I would be inclined to change the spec to the web's needs rather than the other way around. > Option A1: Fetch consistency proofs on demand > > 1. Client gets an STH and an inclusion proof to the STH from server, > verifies the proof, and adds STH to a cache if not already present. > > 2. In the background, client audits unverified STHs in the cache > by requesting a consistency proof between the unverified STH and some > other verified STH. > > - [PRO] No need to audit SCTs. > - [PRO] Although client makes queries (consistency proofs) that are > triggered by > browsing, the queries do not reveal browsing history because many > certificates > use inclusion proofs to the same STH. > - [PRO] No need for a log proxy. > - [PRO] Client only needs to fetch consistency proofs for STHs it actually > sees. > - [PRO] Client only needs to store STHs it actually sees. > - [CON] CA needs to wait for inclusion proof if inclusion proof is > included in cert. > - [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in > addition to SCTs. > > I asked you on-list two weeks ago why this wouldn't work[2], but you > have not replied. > Sorry, that's my fault. Trying to be more responsible on this thread :) I think this is better than option G, but there are still a couple of concerns. The one that's most critical to me is that you're relying on the structure of STHs for a privacy property -- if there are too few new certs under an STH, then your consistency query reveals your browsing history. That seems like a very fragile assumption to be making, especially given that we have no STH discipline / schedule in the current system. And making logs explicitly trusted for this privacy property seems counter to the idea that logs are not to be trusted. > > Option A2: Publicly-logged STH batches > > 1. Auditor pulls STHs from logs at some frequency, validates consistency. > > 2. Periodically, auditor logs batches of STHs to CT logs. > > 3. Periodically, the client obtains from the auditor: > a. Batches of STHs since the last one the client received > b. Inclusion proofs for each STH batch up to the log's latest STH > c. Consistency proof between the last STH received by the client and the > latest STH > > 4. The client verifies all proofs received from auditor, but assumes > that the STHs in the batches are legitimate. > > 5. Client caches entire history of STHs that it has received (really > just needs to store tree heads). > > 6. Client gets inclusion proof to an STH from server (either in the > certificate or in a stapled OCSP response), verifies it. > > 7. Client audits by verifying that the STH provided by the server is in > the cache. > > 8. An ecosystem of auditors monitors logs for STH batches and audits > all contained STHs by requesting consistency proofs. This saves the > client from having to verify every single STH itself. > > - [PRO] No need to audit SCTs. > - [PRO] Client never makes queries in response to browsing. > - [PRO] No need for a log proxy. > - [CON] CA needs to wait for inclusion proof if inclusion proof is > included in cert. > - [CON] Client needs to store entire history of STHs. > - [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in > addition to SCTs. > > Option A2 is very similar to Option M, but avoids the need for clients > to do their own STH auditing (except for STHs related to the STH > batches). If you're happy with Option M you should be happy with Option > A2, even when implemented on top of the current Merkle Tree design. > What you lose in this design relative to both G and M is the clients direct assurance that the STHs it's relying on are a valid sequence, as opposed to something the auditor made up. That is, the assurance here is like if you took G or M and removed the part where the auditor sends down the consistency proofs. That's not the biggest tragedy in the world, but if that's the best we can do, we'll need to be clear about this constraint in the document ("Most clients will need to delegate consistency checking to an auditor, which means that they will be at risk of the auditor lying to them in the following ways..."). But given that there are options on the table that get us to a stranger guarantee at the cost of a spec change and some adaptation by the small number of logs that exist, I'm not sure why we should settle here. > I agree with many of your concerns about SCT auditing, but considering > that Options A1 and A2 can be implemented on top of 6962bis (plus Option > M if 4MB/month can be tolerated), I don't see why these concerns should > hold up publication. > As I've noted above, A1 and A2 aren't really meeting my requirements. (Maybe we should go through a requirements exercise here?) "It's in the document" is a reason to persist in standardizing a design, much less implementing it. If we want to keep the current design, let's get consensus that there's a plausible auditing story for it. Otherwise, let's pick another one. --Richard > > Regards, > Andrew > > [1] https://mailarchive.ietf.org/arch/msg/trans/gO_ > DFW3v9FmBCOek_hifZ6KL368 > > [2] https://mailarchive.ietf.org/arch/msg/trans/ > sA7ZrHIsuqWvIkF0B4I8dv8nKsY > --001a114388ccea3ee405489af255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 15, 2017 at 3:38 PM, Andrew Ayer <agwa@andrewayer.name<= /a>> wrote:
= On Wed, 15 Feb 2017 12:50:12 -0800
Richard Barnes <rlb@ipv.sx> wrote:
>
> [...]
>
> Option M: Cache many STHs / static inclusion proofs
>
> [...]
>
> - [PRO] If inclusion proof is provided at connection / validation
> time, then auditing can be done immediately for certificates that are<= br> > old enough for their STHs to have propagated

Since a client cannot distinguish between a rogue STH and a legitima= te
STH that it doesn't know about yet, it has no choice but to accept the<= br> connection if it doesn't know about an STH and audit it later.=C2=A0 Th= erefore,
option M is no better than option G in this regard: both provide post-hoc detection rather than prevention.=C2=A0 You can't call this a "pro= " for option
M while simultaneously calling it a "con" for Option G.

> [...]
>
> Option M leads to something like a Haber-Stornetta hash chain
> of batch Merkle trees.

Why?=C2=A0 The only justification provided so far is that a client w= ould
need to download 4MB of data a month, which is a "pretty big chunk of<= br> data."[1]=C2=A0 This is a rather extraordinary claim.=C2=A0 Can you ex= plain your
reasoning why 4MB a month is too much?

= To be a bit glib -- the folks who manage syncing state out to Firefox balke= d when I mentioned it to them.

Basically, that amount mig= ht not sound scary from the client side, but if you're thinking about s= yncing that data out to 100s of millions of clients, that's an extra fe= w 100MBps of capacity you have to provision, and it's only kinda cachea= ble.

=C2=A0
Even if 4MB/month is deemed excessive, there are other options which
avoid reliance on SCTs, but can be implemented on top of 6962bis'
current design without requiring clients to download 4MB a month.
Let's call them Options A1 and A2.

= To be clear, I did not mean to imply that these were the only options.=C2= =A0 On the contrary, I would like to have some discussion about the options= here so we can understand what requirements we should be holding 6962bis t= o.

Can you explain why being implemented on top of the cu= rrent system is a requirement?=C2=A0 I can see why it's desireable, e.g= ., to avoid further delay.=C2=A0 But in general, I would be inclined to cha= nge the spec to the web's needs rather than the other way around.

=C2=A0
Option A1: Fetch consistency proofs on demand

1. Client gets an STH and an inclusion proof to the STH from server,
verifies the proof, and adds STH to a cache if not already present.

2. In the background, client audits unverified STHs in the cache
by requesting a consistency proof between the unverified STH and some
other verified STH.

- [PRO] No need to audit SCTs.
- [PRO] Although client makes queries (consistency proofs) that are trigger= ed by
=C2=A0 browsing, the queries do not reveal browsing history because many ce= rtificates
=C2=A0 use inclusion proofs to the same STH.
- [PRO] No need for a log proxy.
- [PRO] Client only needs to fetch consistency proofs for STHs it actually = sees.
- [PRO] Client only needs to store STHs it actually sees.
- [CON] CA needs to wait for inclusion proof if inclusion proof is included= in cert.
- [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in ad= dition to SCTs.

I asked you on-list two weeks ago why this wouldn't work[2], but you have not replied.

Sorry, that's my = fault.=C2=A0 Trying to be more responsible on this thread :)

<= div>I think this is better than option G, but there are still a couple of c= oncerns.=C2=A0 The one that's most critical to me is that you're re= lying on the structure of STHs for a privacy property -- if there are too f= ew new certs under an STH, then your consistency query reveals your browsin= g history.=C2=A0 That seems like a very fragile assumption to be making, es= pecially given that we have no STH discipline / schedule in the current sys= tem.=C2=A0 And making logs explicitly trusted for this privacy property see= ms counter to the idea that logs are not to be trusted.

= =C2=A0

Option A2: Publicly-logged STH batches

1. Auditor pulls STHs from logs at some frequency, validates consistency.
2. Periodically, auditor logs batches of STHs to CT logs.

3. Periodically, the client obtains from the auditor:
=C2=A0 a. Batches of STHs since the last one the client received
=C2=A0 b. Inclusion proofs for each STH batch up to the log's latest ST= H
=C2=A0 c. Consistency proof between the last STH received by the client and= the latest STH

4. The client verifies all proofs received from auditor, but assumes
that the STHs in the batches are legitimate.

5. Client caches entire history of STHs that it has received (really
just needs to store tree heads).

6. Client gets inclusion proof to an STH from server (either in the
certificate or in a stapled OCSP response), verifies it.

7. Client audits by verifying that the STH provided by the server is in
the cache.

8. An ecosystem of auditors monitors logs for STH batches and audits
all contained STHs by requesting consistency proofs. This saves the
client from having to verify every single STH itself.

- [PRO] No need to audit SCTs.
- [PRO] Client never makes queries in response to browsing.
- [PRO] No need for a log proxy.
- [CON] CA needs to wait for inclusion proof if inclusion proof is included= in cert.
- [CON] Client needs to store entire history of STHs.
- [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in ad= dition to SCTs.

Option A2 is very similar to Option M, but avoids the need for clients
to do their own STH auditing (except for STHs related to the STH
batches). If you're happy with Option M you should be happy with Option=
A2, even when implemented on top of the current Merkle Tree design.

What you lose in this design relative to both = G and M is the clients direct assurance that the STHs it's relying on a= re a valid sequence, as opposed to something the auditor made up.=C2=A0 Tha= t is, the assurance here is like if you took G or M and removed the part wh= ere the auditor sends down the consistency proofs.

=
That's not the biggest tragedy in the world, but if that's the= best we can do, we'll need to be clear about this constraint in the do= cument ("Most clients will need to delegate consistency checking to an= auditor, which means that they will be at risk of the auditor lying to the= m in the following ways...").=C2=A0 But given that there are options o= n the table that get us to a stranger guarantee at the cost of a spec chang= e and some adaptation by the small number of logs that exist, I'm not s= ure why we should settle here.

=C2=A0
I agree with many of your concerns about SCT auditing, but considering
that Options A1 and A2 can be implemented on top of 6962bis (plus Option M if 4MB/month can be tolerated), I don't see why these concerns should=
hold up publication.

As I've noted = above, A1 and A2 aren't really meeting my requirements.=C2=A0 (Maybe we= should go through a requirements exercise here?)

"I= t's in the document" is a reason to persist in standardizing a des= ign, much less implementing it.=C2=A0 If we want to keep the current design= , let's get consensus that there's a plausible auditing story for i= t.=C2=A0 Otherwise, let's pick another one.

--Richard=



=C2=A0

Regards,
Andrew

[1] https://mailarchive.ietf.= org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368

[2] https://mailarchive.ietf.= org/arch/msg/trans/sA7ZrHIsuqWvIkF0B4I8dv8nKsY

--001a114388ccea3ee405489af255-- From nobody Wed Feb 15 17:19:14 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2C12946E for ; Wed, 15 Feb 2017 17:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 apX-7BRXwMaN for ; Wed, 15 Feb 2017 17:19:10 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C53129461 for ; Wed, 15 Feb 2017 17:19:10 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id C57B620051C23 for ; Wed, 15 Feb 2017 17:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=qtd4g9ERs+6Us5EBqq8e5EkXMIs=; b= TUkK0TSAZKmyBUCCwyExNCeurrM+/6/OHkzBs3mYzWptujxfubl+1bUUjqMtuq7i iqiQ37ijjDM5E6/5d8+9/Q9OA6cvERF8q/0Is0yw3MFSw4EwK5ZcPla/VapABhZQ T7tazMMRNilHSJ5QZ+0LzxW1fisImrqFpsZHLDd7JM8= Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 98A2520051C22 for ; Wed, 15 Feb 2017 17:19:09 -0800 (PST) Received: by mail-lf0-f43.google.com with SMTP id v186so1363899lfa.1 for ; Wed, 15 Feb 2017 17:19:09 -0800 (PST) X-Gm-Message-State: AMke39lVCmOcTkXO87BOatDpXUrHS4jbI6vbPcqzJMuxfEWIV77jUTRCzemS1l5CxA9kWGATBXm/Ut2cf1tJYQ== X-Received: by 10.25.156.144 with SMTP id f138mr13504954lfe.80.1487207947775; Wed, 15 Feb 2017 17:19:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.154 with HTTP; Wed, 15 Feb 2017 17:19:07 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Wed, 15 Feb 2017 17:19:07 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11410e7c6f395105489b955f Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:19:13 -0000 --001a11410e7c6f395105489b955f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes wrote: > At base, in order to meet this group=E2=80=99s charter deliverables, what= we want > to be assured of is that the mechanisms in 6962-bis that are intended to > enable public verifiability can actually do so in practice. That is, we > need to establish that there is at least one plausible story for how some > substantial fraction of the statements logs provide to clients end up > getting audited. > If I may, it seems like you're stating two (different) goals as equivalent; the subtlety here at least deserves calling out. For recap, the charter is https://datatracker.ietf.org/wg/trans/charter/ , with the work item being "Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to HTTP over TLS." The subtlety here I'm calling out is that you're implicitly treating "clients" to mean "common Web browsers". While I certainly agree that's an important use case to consider (and certainly one we at Google have been considering), your interpretation is much more narrower than what's chartered, and your concerns much more specific to individual products (on particular platforms), rather than to either the general case of "Web browsers" or even "TLS clients". The danger in this approach is that it bleeds dangerously close to specifying implementation policy, when the current draft provides infrastructure to support a variety of policies for a variety of consumers and clients. Notable here is that you can have CT clients that may decide to 'hard-fail' - whether browser or otherwise - and so some of the 'pragmatic' cons you highlight aren't exactly relevant to the chartered objective, or refer to implementation details and product decisions rather than generalized problems. I think perhaps if we can agree on the scope and its relevance to the charter - which you're highlighting as the key concern - we can better work through these issues. For example, if you imagine a command-line TLS client (such as wget or curl), neither Option M nor Option G, as you've defined them, may be suitable. Does that mean it's necessarily to fundamentally alter how 6962-bis works? Maybe, maybe not. Does that mean it's necessary for such a "guidance document" to consider wget and curl's needs as equivalent to the presumed consumers of Option M or Option G? Maybe, maybe not. --001a11410e7c6f395105489b955f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes <= rlb@ipv.sx> w= rote:
At base, in order to meet this group=E2=80=99s charter deliverables, what = we want to be assured of is that the mechanisms in 6962-bis that are intend= ed to enable public verifiability can actually do so in practice.=C2=A0 Tha= t is, we need to establish that there is at least one plausible story for h= ow some substantial fraction of the statements logs provide to clients end = up getting audited.

If I may, it = seems like you're stating two (different) goals as equivalent; the subt= lety here at least deserves calling out. For recap, the charter is=C2=A0https://datatracker= .ietf.org/wg/trans/charter/ , with the work item being "Publish an= update to RFC 6962 as a standards-track mechanism to apply verifiable logs= to HTTP over TLS."

The subtlety here I'm= calling out is that you're implicitly treating "clients" to = mean "common Web browsers". While I certainly agree that's an= important use case to consider (and certainly one we at Google have been c= onsidering), your interpretation is much more narrower than what's char= tered, and your concerns much more specific to individual products (on part= icular platforms), rather than to either the general case of "Web brow= sers" or even "TLS clients".

The da= nger in this approach is that it bleeds dangerously close to specifying imp= lementation policy, when the current draft provides infrastructure to suppo= rt a variety of policies for a variety of consumers and clients. Notable he= re is that you can have CT clients that may decide to 'hard-fail' -= whether browser or otherwise - and so some of the 'pragmatic' cons= you highlight aren't exactly relevant to the chartered objective, or r= efer to implementation details and product decisions rather than generalize= d problems.

I think perhaps if we can agree on the= scope and its relevance to the charter - which you're highlighting as = the key concern - we can better work through these issues. For example, if = you imagine a command-line TLS client (such as wget or curl), neither Optio= n M nor Option G, as you've defined them, may be suitable. Does that me= an it's necessarily to fundamentally alter how 6962-bis works? Maybe, m= aybe not. Does that mean it's necessary for such a "guidance docum= ent" to consider wget and curl's needs as equivalent to the presum= ed consumers of Option M or Option G? Maybe, maybe not.
--001a11410e7c6f395105489b955f-- From nobody Thu Feb 16 11:38:05 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5021295EE for ; Thu, 16 Feb 2017 11:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 YL-WuXoujrkH for ; Thu, 16 Feb 2017 11:38:02 -0800 (PST) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C885D1294C3 for ; Thu, 16 Feb 2017 11:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1487273882; bh=rM/7Rl302DlO7G09c7X61SvJC0Da+t5odmA6s1MtxD8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=n6gA0UWc9IPHYiJ2TWN5OziT5XLfsik3FS553ID968TKQ+Oe0h7XhkFhqzhRIPmPZ dN0/UCNxpeGm86UxYucAMgkUUCXeZ92HLP3Zxm4Uku3819Mqz64oS+z3I/lDg6Jv9/ 9mPR+0Li9+pTMOgbPEHOzyRsAqsJfWE+24+B3dxPB1plbw1B+x47+hDEhwPiFYvnaU H3ZQRV8ExUIpmmoGiC52hzBYrv78SrZFFWCX5OsKYyg8a4mxIk7z2E7gtmyBH4DOkI EUyjgwYE4LKC53iKkx4hzP6J5c2NYdhoRLlugKTKc+QNzqAK6sMASTvOOg9FJfkY76 clTPt3Dqtb43g== Date: Thu, 16 Feb 2017 11:38:01 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170216113801.359d3eb906dc4c9e141f9073@andrewayer.name> In-Reply-To: References: <20170215153808.1d276ae3c7a6a9be3c6b95b3@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:38:04 -0000 On Wed, 15 Feb 2017 16:33:40 -0800 Richard Barnes wrote: > [...] > > > > > > [...] > > > > > > Option M leads to something like a Haber-Stornetta hash chain > > > of batch Merkle trees. > > > > Why? The only justification provided so far is that a client would > > need to download 4MB of data a month, which is a "pretty big chunk > > of data."[1] This is a rather extraordinary claim. Can you > > explain your reasoning why 4MB a month is too much? > > > > To be a bit glib -- the folks who manage syncing state out to Firefox > balked when I mentioned it to them. > > Basically, that amount might not sound scary from the client side, > but if you're thinking about syncing that data out to 100s of > millions of clients, that's an extra few 100MBps of capacity you have > to provision, and it's only kinda cacheable. Ah, it's a server-side constraint. Thanks for clarifying. Would an effective caching strategy make this implementable by Mozilla? What if every STH and its consistency proof to the previous STH was a separate resource? That's trivially cacheable, and HTTP/2 makes it cheap for the client to request lots of resources at once. > > Even if 4MB/month is deemed excessive, there are other options which > > avoid reliance on SCTs, but can be implemented on top of 6962bis' > > current design without requiring clients to download 4MB a month. > > Let's call them Options A1 and A2. > > > > To be clear, I did not mean to imply that these were the only > options. On the contrary, I would like to have some discussion about > the options here so we can understand what requirements we should be > holding 6962bis to. > > Can you explain why being implemented on top of the current system is > a requirement? I can see why it's desireable, e.g., to avoid further > delay. But in general, I would be inclined to change the spec to the > web's needs rather than the other way around. Does the desirability of a new design outweigh the desirability of moving forward with the current one? Tradeoffs always have to be made, or one could spend forever in quest of the perfect solution. Consider: 1. The delay would likely be significant. RFC6962bis would need major changes. The gossip and threat analysis documents would need revision. This would hold up other work. 2. We'd forgo much of the running code and implementation experience from RFC6962. 3. There's no guarantee that a Haber-Stornetta chain is the right solution - what if we uncover unforeseen problems in a year? > > Option A1: Fetch consistency proofs on demand > > > > 1. Client gets an STH and an inclusion proof to the STH from server, > > verifies the proof, and adds STH to a cache if not already present. > > > > 2. In the background, client audits unverified STHs in the cache > > by requesting a consistency proof between the unverified STH and > > some other verified STH. > > > > - [PRO] No need to audit SCTs. > > - [PRO] Although client makes queries (consistency proofs) that are > > triggered by > > browsing, the queries do not reveal browsing history because many > > certificates > > use inclusion proofs to the same STH. > > - [PRO] No need for a log proxy. > > - [PRO] Client only needs to fetch consistency proofs for STHs it > > actually sees. > > - [PRO] Client only needs to store STHs it actually sees. > > - [CON] CA needs to wait for inclusion proof if inclusion proof is > > included in cert. > > - [CON] Requires CA to upgrade to fetch inclusion proofs instead > > of / in addition to SCTs. > > > > I asked you on-list two weeks ago why this wouldn't work[2], but you > > have not replied. > > > > Sorry, that's my fault. Trying to be more responsible on this > thread :) > > I think this is better than option G, but there are still a couple of > concerns. The one that's most critical to me is that you're relying > on the structure of STHs for a privacy property -- if there are too > few new certs under an STH, then your consistency query reveals your > browsing history. That seems like a very fragile assumption to be > making, especially given that we have no STH discipline / schedule in > the current system. And making logs explicitly trusted for this > privacy property seems counter to the idea that logs are not to be > trusted. 6962bis could require a minimum number of log entries between STHs, much like it requires a minimum amount of time. Monitors could detect it if logs violated this requirement. However, one could stuff the log with certificates that it knows will never be used on the public Internet, so you're right that this option has privacy problems which makes it inferior to options M and A2. > > Option A2: Publicly-logged STH batches > > > > 1. Auditor pulls STHs from logs at some frequency, validates > > consistency. > > > > 2. Periodically, auditor logs batches of STHs to CT logs. > > > > 3. Periodically, the client obtains from the auditor: > > a. Batches of STHs since the last one the client received > > b. Inclusion proofs for each STH batch up to the log's latest STH > > c. Consistency proof between the last STH received by the client > > and the latest STH > > > > 4. The client verifies all proofs received from auditor, but assumes > > that the STHs in the batches are legitimate. > > > > 5. Client caches entire history of STHs that it has received (really > > just needs to store tree heads). > > > > 6. Client gets inclusion proof to an STH from server (either in the > > certificate or in a stapled OCSP response), verifies it. > > > > 7. Client audits by verifying that the STH provided by the server > > is in the cache. > > > > 8. An ecosystem of auditors monitors logs for STH batches and audits > > all contained STHs by requesting consistency proofs. This saves the > > client from having to verify every single STH itself. > > > > - [PRO] No need to audit SCTs. > > - [PRO] Client never makes queries in response to browsing. > > - [PRO] No need for a log proxy. > > - [CON] CA needs to wait for inclusion proof if inclusion proof is > > included in cert. > > - [CON] Client needs to store entire history of STHs. > > - [CON] Requires CA to upgrade to fetch inclusion proofs instead > > of / in addition to SCTs. > > > > Option A2 is very similar to Option M, but avoids the need for > > clients to do their own STH auditing (except for STHs related to > > the STH batches). If you're happy with Option M you should be happy > > with Option A2, even when implemented on top of the current Merkle > > Tree design. > > > > What you lose in this design relative to both G and M is the clients > direct assurance that the STHs it's relying on are a valid sequence, > as opposed to something the auditor made up. That is, the assurance > here is like if you took G or M and removed the part where the > auditor sends down the consistency proofs. Not quite, because in option A2, the client has assurance that every STH it relies upon has been published for the world to see. If a log misbehaves and signs an inconsistent STH, and the auditor passes that STH through to the client, someone is certain to notice and detect the log's misbehavior. > That's not the biggest tragedy in the world, but if that's the best > we can do, we'll need to be clear about this constraint in the > document ("Most clients will need to delegate consistency checking to > an auditor, which means that they will be at risk of the auditor > lying to them in the following ways..."). It's true that clients have to assume that someone else does the auditing faithfully, but since the STHs are logged for anyone to audit, this is a very safe assumption. > But given that there are > options on the table that get us to a stranger guarantee at the cost > of a spec change and some adaptation by the small number of logs that > exist, I'm not sure why we should settle here. > > > I agree with many of your concerns about SCT auditing, but > > considering that Options A1 and A2 can be implemented on top of > > 6962bis (plus Option M if 4MB/month can be tolerated), I don't see > > why these concerns should hold up publication. > > > > As I've noted above, A1 and A2 aren't really meeting my requirements. > (Maybe we should go through a requirements exercise here?) I would like to convince you that A2 meets your requirements. I contend that its auditing guarantees are as strong as M's. In particular, having proof that the STHs are publicly-logged is just as good as the client auditing them itself. If you disagree, I'm curious why. Regards, Andrew From nobody Thu Feb 16 12:02:34 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550851296E9 for ; Thu, 16 Feb 2017 12:02:32 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OjnH4aKtiSxx for ; Thu, 16 Feb 2017 12:02:30 -0800 (PST) Received: from dfw-mailout20.raytheon.com (dfw-mailout20.raytheon.com [199.46.199.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72726129A5F for ; Thu, 16 Feb 2017 12:02:11 -0800 (PST) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by dfw-mailout20.ext.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1GK29Ia004985 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 20:02:09 GMT Received: from 008-smtp-out.ray.com ([23.103.8.213]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1GK28nM018955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Feb 2017 20:02:09 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB021.008f.mgd2.msft.net (23.103.8.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.16; Thu, 16 Feb 2017 20:02:07 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.0860.012; Thu, 16 Feb 2017 20:02:07 +0000 From: Steve KENT To: Ryan Sleevi , Richard Barnes Thread-Topic: [Trans] The importance of understanding auditing Thread-Index: AQHSh80kfExfXtOnuUCmL0vHQ+8Ec6Fq1buAgAE0jKA= Date: Thu, 16 Feb 2017 20:02:07 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.8.133] Content-Type: multipart/alternative; boundary="_000_f4d0dcfb88a04b9b9c074d321cfc8b53CY1PR0601MB023008fmgd2m_" MIME-Version: 1.0 X-CC: ryan-ietf@sleevi.com, rlb@ipv.sx, trans@ietf.org X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-16_14:, , signatures=0 X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-16_14:, , signatures=0 X-DMZ-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702160188 X-DMZ-Spam-Reason: mlx Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:02:32 -0000 --_000_f4d0dcfb88a04b9b9c074d321cfc8b53CY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ryan, I agree that the charter for TRANS refers to TLS client in general, but the= WG has long focused primarily (if not exclusively) on browsers as the TLS = clients of interest for CT. For example, the gossip document talks extensiv= ely in terms of browsers and HTTPS clients, not generic TLS clients. The th= reat model also talks in terms of browsers as clients of TLS servers, and h= as done so for a very long time. For browsers we have a model of how trust = anchor stores are managed and thus how info about logs could be promulgated= (even though these mechanisms are not IETF standards.) For generic TLS cli= ents I don't believe there are similar models, which would suggest gaps in = the architecture. Steve ________________________________ From: Trans on behalf of Ryan Sleevi Sent: Wednesday, February 15, 2017 8:19:07 PM To: Richard Barnes Cc: trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes > wrote: At base, in order to meet this group's charter deliverables, what we want t= o be assured of is that the mechanisms in 6962-bis that are intended to ena= ble public verifiability can actually do so in practice. That is, we need = to establish that there is at least one plausible story for how some substa= ntial fraction of the statements logs provide to clients end up getting aud= ited. If I may, it seems like you're stating two (different) goals as equivalent;= the subtlety here at least deserves calling out. For recap, the charter is= https://datatracker.ietf.org/wg/trans/charter/ , with the work item being = "Publish an update to RFC 6962 as a standards-track mechanism to apply veri= fiable logs to HTTP over TLS." The subtlety here I'm calling out is that you're implicitly treating "clien= ts" to mean "common Web browsers". While I certainly agree that's an import= ant use case to consider (and certainly one we at Google have been consider= ing), your interpretation is much more narrower than what's chartered, and = your concerns much more specific to individual products (on particular plat= forms), rather than to either the general case of "Web browsers" or even "T= LS clients". The danger in this approach is that it bleeds dangerously close to specifyi= ng implementation policy, when the current draft provides infrastructure to= support a variety of policies for a variety of consumers and clients. Nota= ble here is that you can have CT clients that may decide to 'hard-fail' - w= hether browser or otherwise - and so some of the 'pragmatic' cons you highl= ight aren't exactly relevant to the chartered objective, or refer to implem= entation details and product decisions rather than generalized problems. I think perhaps if we can agree on the scope and its relevance to the chart= er - which you're highlighting as the key concern - we can better work thro= ugh these issues. For example, if you imagine a command-line TLS client (su= ch as wget or curl), neither Option M nor Option G, as you've defined them,= may be suitable. Does that mean it's necessarily to fundamentally alter ho= w 6962-bis works? Maybe, maybe not. Does that mean it's necessary for such = a "guidance document" to consider wget and curl's needs as equivalent to th= e presumed consumers of Option M or Option G? Maybe, maybe not. --_000_f4d0dcfb88a04b9b9c074d321cfc8b53CY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ryan,


I agree that the charter for TRANS refers to TLS client in general, but = the WG has long focused primarily (if not exclusively) on browsers as the T= LS clients of interest for CT. For example, the gossip document talks exten= sively in terms of browsers and HTTPS clients, not generic TLS clients. The threat model also talks in ter= ms of browsers as clients of TLS servers, and has done so for a very long t= ime. For browsers we have a model of how trust anchor stores are managed an= d thus how info about logs could be promulgated (even though these mechanisms are not IETF standards.) For = generic TLS clients I don't believe there are similar models, which would s= uggest gaps in the architecture.


Steve


From: Trans <trans-bounc= es@ietf.org> on behalf of Ryan Sleevi <ryan-ietf@sleevi.com>
Sent: Wednesday, February 15, 2017 8:19:07 PM
To: Richard Barnes
Cc: trans@ietf.org
Subject: Re: [Trans] The importance of understanding auditing
 


On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes= <rlb@ipv.sx> wrote:
At base, in order to meet this group’s charter deliv= erables, what we want to be assured of is that the mechanisms in 6962-bis t= hat are intended to enable public verifiability can actually do so in pract= ice.  That is, we need to establish that there is at least one plausible story for how some substantial fraction of= the statements logs provide to clients end up getting audited.

If I may, it seems like you're stating two (different) goals as equiva= lent; the subtlety here at least deserves calling out. For recap, the chart= er is https= ://datatracker.ietf.org/wg/trans/charter/ , with the work item being "Publish an update to RFC 6962 as a standa= rds-track mechanism to apply verifiable logs to HTTP over TLS."

The subtlety here I'm calling out is that you're implicitly treating &= quot;clients" to mean "common Web browsers". While I certain= ly agree that's an important use case to consider (and certainly one we at = Google have been considering), your interpretation is much more narrower than what's chartered, and your concerns much more spec= ific to individual products (on particular platforms), rather than to eithe= r the general case of "Web browsers" or even "TLS clients&qu= ot;.

The danger in this approach is that it bleeds dangerously close to spe= cifying implementation policy, when the current draft provides infrastructu= re to support a variety of policies for a variety of consumers and clients.= Notable here is that you can have CT clients that may decide to 'hard-fail' - whether browser or otherwise -= and so some of the 'pragmatic' cons you highlight aren't exactly relevant = to the chartered objective, or refer to implementation details and product = decisions rather than generalized problems.

I think perhaps if we can agree on the scope and its relevance to the = charter - which you're highlighting as the key concern - we can better work= through these issues. For example, if you imagine a command-line TLS clien= t (such as wget or curl), neither Option M nor Option G, as you've defined them, may be suitable. Does that = mean it's necessarily to fundamentally alter how 6962-bis works? Maybe, may= be not. Does that mean it's necessary for such a "guidance document&qu= ot; to consider wget and curl's needs as equivalent to the presumed consumers of Option M or Option G? Maybe, maybe not.
--_000_f4d0dcfb88a04b9b9c074d321cfc8b53CY1PR0601MB023008fmgd2m_-- From nobody Thu Feb 16 12:41:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF1129698 for ; Thu, 16 Feb 2017 12:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 WjhnKuHicQpg for ; Thu, 16 Feb 2017 12:41:49 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EE5129689 for ; Thu, 16 Feb 2017 12:41:49 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id A45636000507 for ; Thu, 16 Feb 2017 12:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=At7AmFk92BnLxnKVSK3ou4DFoRw=; b= twmQtnrBkNNlIOCl3nrAeq3QJZyPptFRIq6ErUS7KfD69mnEIolCRoz9qtzuw/xd CnSQ//RIe+OZCuPR1uQxbiG91IZf+YpKqv8g/RCI4tmu97JdKrmoOQvbZ5Ul6Vq3 gcKb61k3jtYirYJVYDZ+Dsag3M9IqV1jvveO3YhT+AA= Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 7283E6000503 for ; Thu, 16 Feb 2017 12:41:48 -0800 (PST) Received: by mail-lf0-f52.google.com with SMTP id x1so13890121lff.0 for ; Thu, 16 Feb 2017 12:41:48 -0800 (PST) X-Gm-Message-State: AMke39l+v/D+5ojqAlgjLkSYuP8Aa2TjLpxAR1k4DU4KYyBs0TiGgBm00nD4zOgdWPG5arUfX2nCY2dlOfEfFg== X-Received: by 10.46.20.93 with SMTP id 29mr1106475lju.10.1487277706563; Thu, 16 Feb 2017 12:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.154 with HTTP; Thu, 16 Feb 2017 12:41:45 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 16 Feb 2017 12:41:45 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Steve KENT Content-Type: multipart/alternative; boundary=f403045fb5d461ddc30548abd3ff Archived-At: Cc: Ryan Sleevi , Richard Barnes , "trans@ietf.org" Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:41:50 -0000 --f403045fb5d461ddc30548abd3ff Content-Type: text/plain; charset=UTF-8 On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT wrote: > Ryan, > > > I agree that the charter for TRANS refers to TLS client in general, but > the WG has long focused primarily (if not exclusively) on browsers as the > TLS clients of interest for CT. For example, the gossip document talks > extensively in terms of browsers and HTTPS clients, not generic TLS > clients. The threat model also talks in terms of browsers as clients of TLS > servers, and has done so for a very long time. For browsers we have a model > of how trust anchor stores are managed and thus how info about logs could > be promulgated (even though these mechanisms are not IETF standards.) For > generic TLS clients I don't believe there are similar models, which would > suggest gaps in the architecture. > Thanks for clarifying Steve. I highlight this concern/divergence because I think it's important to understand whether the disagreements are architectural or political. I think the good comparison here is OCSP, OCSP Stapling, and client policy. For a number of TLS clients (including S2S scenarios or automated tooling), OCSP (with hardfail) is a totally viable scenario. However, we know browsers have raised a variety of concerns with OCSP's deployment in that model, which is where OCSP Stapling serves as a useful bridge for that. However, even with OCSP Stapling, we cannot suggest that it's addressed the revocation threat model unless and until OCSP stapling is mandatory for connections - otherwise, we're back to the same problem. OCSP Stapling being mandatory for connections is more a question of policy than of technology. Similarly, I think it's important to understand where our disagreements exist on technology and whether the perspectives of concerns are things that are true and generic, or if they are specific to certain deployment and trust scenarios. For example, it's quite trivial and easy to imagine a CT deployment scenario in which the client directly communicated with an Auditor/Monitor who could fulfill all the roles necessary for the assurances here - at a certain cost of client privacy (in their communications with the Auditor/Monitor). Richard's discussion highlights things in terms of "pros" and "cons", but evaluating whether something is a pro, con, or neutral implies with it a specific set of requirements and objectives, and I believe those requirements and objectives may differ between potential clients - those both active in TRANS and those absent. That's why I wanted to get a better clarification here about the particular objective set as the WG sees it (vs as Google, Mozilla, or other implementors may see it), and then better articulate the requirements. As an example, imagine a proposal which proposed that for clients, after some period of time, an OCSP response MUST be stapled and the OCSP response MUST include an inclusion proof to an STH within some delta of the OCSP responses' validity period. That is a solution which is effectively coupled to policy - such as whether OCSP responses must be stapled - and to implementation - such as whether OCSP stapled responses should be preferred. --f403045fb5d461ddc30548abd3ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <steve.kent@raytheo= n.com> wrote:

Ryan,


I agree that the charter for TRANS refers to TLS client in general, but = the WG has long focused primarily (if not exclusively) on browsers as the T= LS clients of interest for CT. For example, the gossip document talks exten= sively in terms of browsers and HTTPS clients, not generic TLS clients. The threat model also talks in ter= ms of browsers as clients of TLS servers, and has done so for a very long t= ime. For browsers we have a model of how trust anchor stores are managed an= d thus how info about logs could be promulgated (even though these mechanisms are not IETF standards.) For = generic TLS clients I don't believe there are similar models, which wou= ld suggest gaps in the architecture.

Thanks for= clarifying Steve.

I highlight this concern/divergence b= ecause I think it's important to understand whether the disagreements a= re architectural or political. I think the good comparison here is OCSP, OC= SP Stapling, and client policy. For a number of TLS clients (including S2S = scenarios or automated tooling), OCSP (with hardfail) is a totally viable s= cenario. However, we know browsers have raised a variety of concerns with O= CSP's deployment in that model, which is where OCSP Stapling serves as = a useful bridge for that. However, even with OCSP Stapling, we cannot sugge= st that it's addressed the revocation threat model unless and until OCS= P stapling is mandatory for connections - otherwise, we're back to the = same problem. OCSP Stapling being mandatory for connections is more a quest= ion of policy than of technology.

Similarly, I thi= nk it's important to understand where our disagreements exist on techno= logy and whether the perspectives of concerns are things that are true and = generic, or if they are specific to certain deployment and trust scenarios.= For example, it's quite trivial and easy to imagine a CT deployment sc= enario in which the client directly communicated with an Auditor/Monitor wh= o could fulfill all the roles necessary for the assurances here - at a cert= ain cost of client privacy (in their communications with the Auditor/Monito= r).

Richard's discussion highlights things in = terms of "pros" and "cons", but evaluating whether some= thing is a pro, con, or neutral implies with it a specific set of requireme= nts and objectives, and I believe those requirements and objectives may dif= fer between potential clients - those both active in TRANS and those absent= . That's why I wanted to get a better clarification here about the part= icular objective set as the WG sees it (vs as Google, Mozilla, or other imp= lementors may see it), and then better articulate the requirements.

As an example, imagine a proposal which proposed that for= clients, after some period of time, an OCSP response MUST be stapled and t= he OCSP response MUST include an inclusion proof to an STH within some delt= a of the OCSP responses' validity period. That is a solution which is e= ffectively coupled to policy - such as whether OCSP responses must be stapl= ed - and to implementation - such as whether OCSP stapled responses should = be preferred.
--f403045fb5d461ddc30548abd3ff-- From nobody Thu Feb 16 12:43:19 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D280B12969F for ; Thu, 16 Feb 2017 12:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Veo7VTe5eytS for ; Thu, 16 Feb 2017 12:43:10 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 79A1A1296A6 for ; Thu, 16 Feb 2017 12:43:10 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id g67so4736828itb.1 for ; Thu, 16 Feb 2017 12:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=upBR329oNYnXJSlQO2iDH9EhZRlHoW8CNorFbbVwtQ4=; b=Wcwrcujdgj8EjTA6NS/kfvKcOkAsxetob28R99akMYq+FX4g4vq1GnhWlJG3lHDrKP B59WwcdD+Y7hp0kt4C5ogkVz/SdSWKpZ20DBcErCGF7M40grZM6KRlrR2BeFSb/XetQS afjbUQN/mG44s+lyVqaEI/ELxXJ9mucSQriH4jQpI4Pa+5ki/k+yoDPo+AOqC2yehMhS UmILFRhVAAh7finLXoarW5meOMXNvxy+dcP56C4ZK4nu1Zg7/3Q6ZZY3tFaprjJwG1++ Z+8B5m27TQZGDezc9DVZLXsfBoyuNnlnhdu4k01D6SKiIZ9fnbHyAgf9RD4FV5ny+IVR NUYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=upBR329oNYnXJSlQO2iDH9EhZRlHoW8CNorFbbVwtQ4=; b=tFPKxwQNxqEcsZTSFkwToVmH/t9J/SwJeJxaR0KzisTp1mmv+FpB5CdjZJjRlh+CiC yur/7gAVTXeWAgVed/sn9y4KyqsdFuUYMCyMLwRxElX4OWkHYXeVtsgToYN8EmqfzfP7 zVbbgYbHxZUHIoxhVtb/H4/TOtMdTeHEypn+TpQKQCXCGcWZOk1T78mIzCAoYA+FahpH 8ySP0+1HlGNDiC8RFHmKeRFTFiZsVHmRN/Wt31bxTK0ij0mHpWiN1UnLj0Ur8Xlh2n2t hGr5GSCWbaOHdgw4v4h//cuN5ewFBlncxtRidT5B4LKvFRGT17bQo+S38gLbxqqEqNYY S7hw== X-Gm-Message-State: AMke39miApF9p/dM1mj2yW4y+Nv+luSP0WrbW9KL/Enyr0yHuFi0GgPh0XwEs2XrtDyKASkO+PRXgxc9hKccu03c X-Received: by 10.107.7.78 with SMTP id 75mr4809628ioh.165.1487277789321; Thu, 16 Feb 2017 12:43:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Thu, 16 Feb 2017 12:42:38 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Thu, 16 Feb 2017 20:42:38 +0000 Message-ID: To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Content-Type: multipart/alternative; boundary=001a113f98d250f9370548abd873 Archived-At: Subject: [Trans] Fwd: [ct-policy] CT Policy Days Location X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:43:18 -0000 --001a113f98d250f9370548abd873 Content-Type: text/plain; charset=UTF-8 Cross-post from the Chromium ct-policy list. tl;dr: - There are free spaces if any of you would like to attend in-person. - You can attend remotely via https://hangouts.google. com/hangouts/_/google.com/ctpolicydays (if you can only use PSTN and would like to dial in, let me know). ---------- Forwarded message ---------- From: 'Ryan Hurst' via Certificate Transparency Policy < ct-policy@chromium.org> Date: Thu, Feb 16, 2017 at 2:56 AM Subject: [ct-policy] CT Policy Days Location All, I am looking forward to seeing you all next week at Google, we will be located in Google Tech Corners II on the Third Floor in Quinn Mallory. I will have people in the lobby to help get you to the right location. The address is: Google, Inc. Tech Corners 2 807 11th Ave Sunnyvale, CA 94089 We have the room from 8am - 5pm (PST) but the event will not start until 9am. Agenda wise, I received some feedback for ideas on working group sessions from others but otherwise it seems the agenda has the right structure. State of the Union and Warming Up Time Start Stop Slot Description Discussion Leader / Notes 0:15 9:00 9:15 Check-in, badging, get situated in room All 0:30 9:00 9:30 Breakfast - Continental All 0:05 9:30 9:35 Welcome and Logistics Ryan Hurst 0:45 9:35 10:20 1 Presentation: Operating CT Logs at Scale CT Team 0:45 10:20 11:05 2 Presentation: CT Standardization Roadmap CT Team 0:15 11:05 11:20 Break All 0:45 11:20 12:05 3 Presentation: Current Chrome Policy Chrome Team 1:00 12:05 13:05 Lunch All 0:45 13:05 13:50 4 Discussion: Concerns with Current Policy Ryan Hurst 0:30 13:50 14:20 Pick Break-Out Sessions Ryan Hurst 0:45 14:20 15:05 5.1 Break-Out Sessions - 1 TBD* 0:30 15:05 15:35 Coffee/Beverage Service Break All 0:45 15:35 16:20 5.2 Break-Out Sessions - 1 Presentations TBD 0:45 16:20 17:05 6.1 Break-Out Sessions - 2 TBD* 0:45 17:05 17:50 6.2 Break-Out Sessions - 2 Presentations All 15 17:50 Adjourn for the Day All 2:40 17:50 20:30 Casual Dinner - @ - On your own or informal group All Break Out Sessions and Next Steps Start Stop Slot Description Discussion Leader / Notes 9:00 9:15 Check-in, badging, get situated in room All 9:00 9:45 Breakfast - Continental All 9:45 10:15 Kick-Off and Check-point Ryan Hurst 10:15 10:45 7.1 Break-Out Sessions - 3 TBD* 10:45 11:30 Break All 11:30 12:30 7.2 Break-Out Sessions - 3 Presentations TBD* 12:30 13:30 Lunch All 13:30 14:15 8.1 Break-Out Sessions - 4 TBD* 14:15 15:15 Break All 15:15 16:00 8.2 Break-Out Sessions - 4 Presentations TBD* 16:00 16:30 Coffee/Beverage Service Break All 16:30 17:30 9 Next Steps Summary Ryan Hurst 17:30 Adjourn All 17:30 20:00 Casual Dinner - @ - On your own or informal group All For the remote attendees we will have a Google Video Chat here: https://hangouts.google.com/hangouts/_/google.com/ctpolicydays There is still more room so don't be shy if you want to attend, just let me know. Ryan -- You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group. To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org. To post to this group, send email to ct-policy@chromium.org. To view this discussion on the web visit https://groups.google.com/a/ chromium.org/d/msgid/ct-policy/CAKexNNMGtROWamVuM%3DWtvz8HACcSOTNLuXiZKnQZD_ LNSqWwyQ%40mail.gmail.com . --001a113f98d250f9370548abd873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cross-post from the Chromium ct-policy list.
tl;dr:
- There are free spaces if any of you would like to atte= nd in-person.
- You can attend remotely via=C2=A0https://hangouts.google.com/hangouts/_/go= ogle.com/ctpolicydays=C2=A0=C2=A0(if you can only use PSTN and wou= ld like to dial in, let me know).

-----= ----- Forwarded message ----------
From: &= #39;Ryan Hurst' via Certificate Transparency Policy <ct-policy@chromium.org= >
Date: Thu, Feb 16, 2017 at 2:56 AM
Subject: [ct-policy] C= T Policy Days Location

All,

I am= looking forward to seeing you all next week at Google, we will be located = in Google Tech Corners II on the Third Floor in Quinn Mallory. =C2=A0

I will have people in th= e lobby to help get you to the right location.

The address is: =C2=A0

Google, Inc.

Tech Corners 2

807 11th Ave

Su= nnyvale, CA 94089

We have the room from 8am - 5pm (PST) but the event will not start= until 9am.

Agenda wise, I received=C2= =A0some feedback for ideas on working group sessions from others but otherw= ise it seems the agenda has the right structure.

State of the Union and Warming Up

= = = =

Coffee/Beverage Service Break

<= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

15:35

Time

Start

Stop

Slot=

Description

Discus= sion Leader / Notes

0:15

9:00

9:= 15


Check-in, badgi= ng, get situated in room

All

0:30

9:00

<= /td>

9:30

<= br>

Breakfast - Continental

All

0:05

9:30=

9:35


Welcome and Logistics

Ryan Hurst

0:45

9:35

10:20

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;te= xt-align:right">1

Presentation: Operating CT= Logs at Scale

CT Team

0:45

=

10:20

11:0= 5

2

<= /td>

Presentation: CT Standardization Roadmap

CT Team

= 0:15

11:05=

11:20


Brea= k

All

0:45

11:20

12:05

3

Presentation: Current Chrome Policy

Chrome Team<= /span>

1:00

<= /td>

12:05

13:05


Lunch

All=

0:45

=

13:05

13:50

4

Discus= sion: Concerns with Current Policy

Ryan Hurst

0:30

13:50

14:20


Pick Break-Out Sessions

Rya= n Hurst

0:45

14:20

15:05

5.1

Break-Out Sessions - 1

TBD*

0:30

15:05

=

15:35


All

0:45

16:20

5.2

=

= Break-Out = Sessions - 1 Presentations

TBD

0:45

16:20

17:05

6.1

Break-Out Sessions -= 2

TBD*

0:45

17:05

17:50

6.2

Break-Out Sessions - 2 Presentations

All

15

17:50



Adjourn for the Day

All

= 2:40

17:50=

20:30


Casual Dinner - @ - On your own or informal group<= /p>

All



Break= Out Sessions and Next Steps

Start=

<= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

Disc= ussion Leader / Notes

=

15:15

=

16:30

=

Stop

Slot

Description

9:00

9:15


Check-in, badging, get situated in room

All

9:00

9:45


Breakfast - Continental

All

9:45

10:1= 5


Kick-Off and Che= ck-point

Ryan Hurst

10:15

10:45

7.1

Break-Out Sessions - 3

T= BD*

10:45=

11:30


Brea= k

All

11:30

12:30<= /span>

7.2

Break-Out Sessions - 3 Presentations

=

12:30

13:30


Lun= ch

All

13:30

14:15<= /span>

8.1

Break-Out Sessions - 4

TBD*<= /p>

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;te= xt-align:right">14:15


Break

=

15:15

16:00

8.2

Break-Out Sessions - 4 Presentations

TBD*<= /p>

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;te= xt-align:right">16:00


Coffee/Beverage = Service Break

All

16:30

17:30

9=

Next Steps Summary

Ryan Hurs= t

17:30



Adjourn

All

17:30

20:00<= /p>


Casual Dinner - @ - On your own or informal group=

All


For the remote attendees we will have a Google= Video Chat here:=C2=A0https://hangouts.google.com/h= angouts/_/google.com/ctpolicydays=C2=A0

There is still more = room so don't be shy if you want to attend, just let me know.

Ryan



<= /span>

--
You received this message because you are subscribed to the Google Groups &= quot;Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-policy@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct= -policy/CAKexNNMGtROWamVuM%3DWtvz8HACcSOTNLuXiZKnQZD_LNSqWwy= Q%40mail.gmail.com.

--001a113f98d250f9370548abd873-- From nobody Fri Feb 17 09:19:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49212959A for ; Fri, 17 Feb 2017 09:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL=0.141, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 QhCryz1yzS8b for ; Fri, 17 Feb 2017 09:19:21 -0800 (PST) Received: from dfw-mailout10.raytheon.com (dfw-mailout10.raytheon.com [199.46.199.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54BDB129562 for ; Fri, 17 Feb 2017 09:19:21 -0800 (PST) Received: from tx-mailout10.rtnmail.ray.com (tx-mailout10.rtnmail.ray.com [138.126.127.234]) by dfw-mailout10.ext.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1HHJIN7048629 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Feb 2017 17:19:18 GMT Received: from 008-smtp-out.ray.com ([23.103.8.213]) by tx-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id v1HHJHga007877 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 17 Feb 2017 17:19:18 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB021.008f.mgd2.msft.net (23.103.8.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.16; Fri, 17 Feb 2017 17:19:16 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.0860.012; Fri, 17 Feb 2017 17:19:16 +0000 From: Steve KENT To: Ryan Sleevi Thread-Topic: [Trans] The importance of understanding auditing Thread-Index: AQHSh80kfExfXtOnuUCmL0vHQ+8Ec6Fq1buAgAE0jKCAABBKgIABVate Date: Fri, 17 Feb 2017 17:19:16 +0000 Message-ID: <6521151207624ec3bc74a2e88992b872@CY1PR0601MB023.008f.mgd2.msft.net> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.8.4] Content-Type: multipart/alternative; boundary="_000_6521151207624ec3bc74a2e88992b872CY1PR0601MB023008fmgd2m_" MIME-Version: 1.0 X-CC: ryan-ietf@sleevi.com, rlb@ipv.sx, trans@ietf.org X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-17_14:, , signatures=0 X-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-17_14:, , signatures=0 X-DMZ-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702170159 X-DMZ-Spam-Reason: mlx Archived-At: Cc: Richard Barnes , "trans@ietf.org" Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 17:19:23 -0000 --_000_6521151207624ec3bc74a2e88992b872CY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ryan, Thanks for the thoughtful reply and further explanation of your concerns. I= agree that what constitutes a pro or con is very much a function of the pe= rceived use context, which is why IETF WGs often (but not always) develop a= set of requirements before pursuing the design of solutions. Unfortunately= , that was not the case for TRANS. The charter asserts that verifiable logs= are the solution for the problem of mis-issuance in the context of HTTP ov= er TLS, but mis-issuance is not defined in the charter or in 6962-bis (alth= ough the threat doc does define the term). If we adopt the very general context of any use of HTTP/TLS then it's harde= r to establish firm requirements based on uniform assumptions, because of t= he wide range of scenarios that are encompassed. Your discussion of OCSP st= apling illustrates the problem, I believe. I support Richard's assumption t= hat browser use of CT is a useful scope for the current doc. Also, as I not= ed, that context has been the focus of WG discussions since the beginning, = as reflected in the two other active WG docs. Steve ________________________________ From: Trans on behalf of Ryan Sleevi Sent: Thursday, February 16, 2017 3:41:45 PM To: Steve KENT Cc: Ryan Sleevi; Richard Barnes; trans@ietf.org Subject: Re: [Trans] The importance of understanding auditing On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT > wrote: Ryan, I agree that the charter for TRANS refers to TLS client in general, but the= WG has long focused primarily (if not exclusively) on browsers as the TLS = clients of interest for CT. For example, the gossip document talks extensiv= ely in terms of browsers and HTTPS clients, not generic TLS clients. The th= reat model also talks in terms of browsers as clients of TLS servers, and h= as done so for a very long time. For browsers we have a model of how trust = anchor stores are managed and thus how info about logs could be promulgated= (even though these mechanisms are not IETF standards.) For generic TLS cli= ents I don't believe there are similar models, which would suggest gaps in = the architecture. Thanks for clarifying Steve. I highlight this concern/divergence because I think it's important to under= stand whether the disagreements are architectural or political. I think the= good comparison here is OCSP, OCSP Stapling, and client policy. For a numb= er of TLS clients (including S2S scenarios or automated tooling), OCSP (wit= h hardfail) is a totally viable scenario. However, we know browsers have ra= ised a variety of concerns with OCSP's deployment in that model, which is w= here OCSP Stapling serves as a useful bridge for that. However, even with O= CSP Stapling, we cannot suggest that it's addressed the revocation threat m= odel unless and until OCSP stapling is mandatory for connections - otherwis= e, we're back to the same problem. OCSP Stapling being mandatory for connec= tions is more a question of policy than of technology. Similarly, I think it's important to understand where our disagreements exi= st on technology and whether the perspectives of concerns are things that a= re true and generic, or if they are specific to certain deployment and trus= t scenarios. For example, it's quite trivial and easy to imagine a CT deplo= yment scenario in which the client directly communicated with an Auditor/Mo= nitor who could fulfill all the roles necessary for the assurances here - a= t a certain cost of client privacy (in their communications with the Audito= r/Monitor). Richard's discussion highlights things in terms of "pros" and "cons", but e= valuating whether something is a pro, con, or neutral implies with it a spe= cific set of requirements and objectives, and I believe those requirements = and objectives may differ between potential clients - those both active in = TRANS and those absent. That's why I wanted to get a better clarification h= ere about the particular objective set as the WG sees it (vs as Google, Moz= illa, or other implementors may see it), and then better articulate the req= uirements. As an example, imagine a proposal which proposed that for clients, after so= me period of time, an OCSP response MUST be stapled and the OCSP response M= UST include an inclusion proof to an STH within some delta of the OCSP resp= onses' validity period. That is a solution which is effectively coupled to = policy - such as whether OCSP responses must be stapled - and to implementa= tion - such as whether OCSP stapled responses should be preferred. --_000_6521151207624ec3bc74a2e88992b872CY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ryan,


Thanks for the thoughtful reply and further explanation of your concerns= . I agree that what constitutes a pro or con is very much a function of the= perceived use context, which is why IETF WGs often (but not always) develo= p a set of requirements before pursuing the design of solutions. Unfortunately, that was not the case for TRANS. T= he charter asserts that verifiable logs are the solution for the problem of= mis-issuance in the context of HTTP over TLS, but mis-issuance is not defi= ned in the charter or in 6962-bis (although the threat doc does define the term).


If we adopt the very general context of any use of HTTP/TLS then it's ha= rder to establish firm requirements based on uniform assumptions, because o= f the wide range of scenarios that are encompassed. Your discussion of OCSP= stapling illustrates the problem, I believe. I support Richard's assumption that browser use of CT is a usef= ul scope for the current doc. Also, as I noted, that context has been the f= ocus of WG discussions since the beginning, as reflected in the two other a= ctive WG docs.


Steve

From: Trans <trans-bounc= es@ietf.org> on behalf of Ryan Sleevi <ryan-ietf@sleevi.com>
Sent: Thursday, February 16, 2017 3:41:45 PM
To: Steve KENT
Cc: Ryan Sleevi; Richard Barnes; trans@ietf.org
Subject: Re: [Trans] The importance of understanding auditing
 


On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <steve.kent= @raytheon.com> wrote:

Ryan,


I agree that the charter for TRANS refers to TLS client in general, but = the WG has long focused primarily (if not exclusively) on browsers as the T= LS clients of interest for CT. For example, the gossip document talks exten= sively in terms of browsers and HTTPS clients, not generic TLS clients. The threat model also talks in ter= ms of browsers as clients of TLS servers, and has done so for a very long t= ime. For browsers we have a model of how trust anchor stores are managed an= d thus how info about logs could be promulgated (even though these mechanisms are not IETF standards.) For = generic TLS clients I don't believe there are similar models, which would s= uggest gaps in the architecture.

Thanks for clarifying Steve.

I highlight this concern/divergence because I think it's important to = understand whether the disagreements are architectural or political. I thin= k the good comparison here is OCSP, OCSP Stapling, and client policy. For a= number of TLS clients (including S2S scenarios or automated tooling), OCSP (with hardfail) is a totally via= ble scenario. However, we know browsers have raised a variety of concerns w= ith OCSP's deployment in that model, which is where OCSP Stapling serves as= a useful bridge for that. However, even with OCSP Stapling, we cannot suggest that it's addressed the revocat= ion threat model unless and until OCSP stapling is mandatory for connection= s - otherwise, we're back to the same problem. OCSP Stapling being mandator= y for connections is more a question of policy than of technology.

Similarly, I think it's important to understand where our disagreement= s exist on technology and whether the perspectives of concerns are things t= hat are true and generic, or if they are specific to certain deployment and= trust scenarios. For example, it's quite trivial and easy to imagine a CT deployment scenario in which the cl= ient directly communicated with an Auditor/Monitor who could fulfill all th= e roles necessary for the assurances here - at a certain cost of client pri= vacy (in their communications with the Auditor/Monitor).

Richard's discussion highlights things in terms of "pros" an= d "cons", but evaluating whether something is a pro, con, or neut= ral implies with it a specific set of requirements and objectives, and I be= lieve those requirements and objectives may differ between potential clients - those both active in TRANS and those absent. That's wh= y I wanted to get a better clarification here about the particular objectiv= e set as the WG sees it (vs as Google, Mozilla, or other implementors may s= ee it), and then better articulate the requirements.

As an example, imagine a proposal which proposed that for clients, aft= er some period of time, an OCSP response MUST be stapled and the OCSP respo= nse MUST include an inclusion proof to an STH within some delta of the OCSP= responses' validity period. That is a solution which is effectively coupled to policy - such as whether OCS= P responses must be stapled - and to implementation - such as whether OCSP = stapled responses should be preferred.
--_000_6521151207624ec3bc74a2e88992b872CY1PR0601MB023008fmgd2m_-- From nobody Tue Feb 21 05:33:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5250E129BB1 for ; Tue, 21 Feb 2017 05:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aBn17YqnEbvt for ; Tue, 21 Feb 2017 05:33:16 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 17F47129BB6 for ; Tue, 21 Feb 2017 05:33:15 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id z61so81936551wrc.1 for ; Tue, 21 Feb 2017 05:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VZiHp40HUwC9/yNKI9/aZtHuvA0SJbhWZlR19GWnTZI=; b=HikU71rNq5rRXXco8j9LL74hgKeQmVAYeJpJw74zm8IFr6BcXVkod1TPdwuChnAnw9 VN/kuJmmkn0S26GFcQ84bUJ6YtH+z09EVgHb1DZ6cogjUP8eNk1xdhOmFkxmwPuqFRW8 ovnoL2MV9o++znWS46RjGmHyETerBrhSVLhJdHGxA7y6QOqpYcESVvUkKcQxx/PvzOLD 0cnRdUhNobmw0rFwJ7e3x8fiH4j8V9rKVnL3R/3isqmqx30DgAdGa9X2ykfSRsK9T7H0 PqWIeXvx8qjTcxWLyUyRIQZ2aqAnzT8bTT307hBJCA5uCRfcIR1A0D2JpFAEsj9a/rcN 3vPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VZiHp40HUwC9/yNKI9/aZtHuvA0SJbhWZlR19GWnTZI=; b=JOtqaffdtYQBL9Ba5Gc0XaS8k2WMz4IjETpu4wp8WLZfdaURaFHThN4QfLUwdXmwRp 5YNVQWb61wi4LJ+fkDV/8dMVaiUuNyEDF3zNp+D3PJ5mjCBHMsqApwN4GKrrUOXteAxk I6hP4s0DCqj9kxEeBub2W4BMhmb2UbpdGO4GZ1CjRhNe+0/xKHNTc8zXB+lRAvHN9VZT eVScSOZQdQE6MELFRjrHHAfD8QIqjIuCbVZ6QNGTfsBghmDhFiBcoI2K9vzNmQYl9lBu HCYcG3/3joVItTZi34QRx+xYAqPa+zx7VTeHK9YqentUoQw5V8quaPmql6UxbQAVK/ey manQ== X-Gm-Message-State: AMke39lCVZnxuPVFzwI63XTRDoOO4nywo31pZ99/5xRFeCaWNU8ZWOc1k1Eobh24hW99v+bce8J1Ly9T9AWBJA== X-Received: by 10.223.138.9 with SMTP id w9mr19625442wrw.50.1487683993507; Tue, 21 Feb 2017 05:33:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.153.2 with HTTP; Tue, 21 Feb 2017 05:33:12 -0800 (PST) In-Reply-To: References: From: Deb Cooley Date: Tue, 21 Feb 2017 08:33:12 -0500 Message-ID: To: Eran Messeri Content-Type: multipart/alternative; boundary=f403045e447cf8a43305490a6b8c Archived-At: Cc: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] Fwd: [ct-policy] CT Policy Days Location X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 13:33:17 -0000 --f403045e447cf8a43305490a6b8c Content-Type: text/plain; charset=UTF-8 Can you post the PSTN information? TY, Deb Cooley On Thu, Feb 16, 2017 at 3:42 PM, Eran Messeri wrote: > Cross-post from the Chromium ct-policy list. > tl;dr: > - There are free spaces if any of you would like to attend in-person. > - You can attend remotely via https://hangouts.google.co > m/hangouts/_/google.com/ctpolicydays > (if you > can only use PSTN and would like to dial in, let me know). > > ---------- Forwarded message ---------- > From: 'Ryan Hurst' via Certificate Transparency Policy < > ct-policy@chromium.org> > Date: Thu, Feb 16, 2017 at 2:56 AM > Subject: [ct-policy] CT Policy Days Location > > All, > > I am looking forward to seeing you all next week at Google, we will be > located in Google Tech Corners II on the Third Floor in Quinn Mallory. > > I will have people in the lobby to help get you to the right location. > > The address is: > > Google, Inc. > > Tech Corners 2 > > 807 11th Ave > > Sunnyvale, CA 94089 > > We have the room from 8am - 5pm (PST) but the event will not start until > 9am. > > Agenda wise, I received some feedback for ideas on working group sessions > from others but otherwise it seems the agenda has the right structure. > > State of the Union and Warming Up > > Time > > Start > > Stop > > Slot > > Description > > Discussion Leader / Notes > > 0:15 > > 9:00 > > 9:15 > > Check-in, badging, get situated in room > > All > > 0:30 > > 9:00 > > 9:30 > > Breakfast - Continental > > All > > 0:05 > > 9:30 > > 9:35 > > Welcome and Logistics > > Ryan Hurst > > 0:45 > > 9:35 > > 10:20 > > 1 > > Presentation: Operating CT Logs at Scale > > CT Team > > 0:45 > > 10:20 > > 11:05 > > 2 > > Presentation: CT Standardization Roadmap > > CT Team > > 0:15 > > 11:05 > > 11:20 > > Break > > All > > 0:45 > > 11:20 > > 12:05 > > 3 > > Presentation: Current Chrome Policy > > Chrome Team > > 1:00 > > 12:05 > > 13:05 > > Lunch > > All > > 0:45 > > 13:05 > > 13:50 > > 4 > > Discussion: Concerns with Current Policy > > Ryan Hurst > > 0:30 > > 13:50 > > 14:20 > > Pick Break-Out Sessions > > Ryan Hurst > > 0:45 > > 14:20 > > 15:05 > > 5.1 > > Break-Out Sessions - 1 > > TBD* > > 0:30 > > 15:05 > > 15:35 > > Coffee/Beverage Service Break > > All > > 0:45 > > 15:35 > > 16:20 > > 5.2 > > Break-Out Sessions - 1 Presentations > > TBD > > 0:45 > > 16:20 > > 17:05 > > 6.1 > > Break-Out Sessions - 2 > > TBD* > > 0:45 > > 17:05 > > 17:50 > > 6.2 > > Break-Out Sessions - 2 Presentations > > All > > 15 > > 17:50 > > > Adjourn for the Day > > All > > 2:40 > > 17:50 > > 20:30 > > Casual Dinner - @ - On your own or informal group > > All > > > > Break Out Sessions and Next Steps > > Start > > Stop > > Slot > > Description > > Discussion Leader / Notes > > 9:00 > > 9:15 > > Check-in, badging, get situated in room > > All > > 9:00 > > 9:45 > > Breakfast - Continental > > All > > 9:45 > > 10:15 > > Kick-Off and Check-point > > Ryan Hurst > > 10:15 > > 10:45 > > 7.1 > > Break-Out Sessions - 3 > > TBD* > > 10:45 > > 11:30 > > Break > > All > > 11:30 > > 12:30 > > 7.2 > > Break-Out Sessions - 3 Presentations > > TBD* > > 12:30 > > 13:30 > > Lunch > > All > > 13:30 > > 14:15 > > 8.1 > > Break-Out Sessions - 4 > > TBD* > > 14:15 > > 15:15 > > Break > > All > > 15:15 > > 16:00 > > 8.2 > > Break-Out Sessions - 4 Presentations > > TBD* > > 16:00 > > 16:30 > > Coffee/Beverage Service Break > > All > > 16:30 > > 17:30 > > 9 > > Next Steps Summary > > Ryan Hurst > > 17:30 > > > Adjourn > > All > > 17:30 > > 20:00 > > Casual Dinner - @ - On your own or informal group > > All > > > For the remote attendees we will have a Google Video Chat here: > https://hangouts.google.com/hangouts/_/google.com/ctpolicydays > > > There is still more room so don't be shy if you want to attend, just let > me know. > > Ryan > > > > -- > You received this message because you are subscribed to the Google Groups > "Certificate Transparency Policy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ct-policy+unsubscribe@chromium.org. > To post to this group, send email to ct-policy@chromium.org. > To view this discussion on the web visit https://groups.google.com/a/ch > romium.org/d/msgid/ct-policy/CAKexNNMGtROWamVuM%3DWtvz8HACc > SOTNLuXiZKnQZD_LNSqWwyQ%40mail.gmail.com > > . > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --f403045e447cf8a43305490a6b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you post the PSTN information?=C2=A0


=
TY,
Deb Cooley


On Thu, Feb 16, 2017 = at 3:42 PM, Eran Messeri <eranm@google.com> wrote:
Cross-post from the Chromium = ct-policy list.
tl;dr:
- There are free spaces if any o= f you would like to attend in-person.
- You can attend remotely v= ia=C2=A0https://hangouts.googl= e.com/hangouts/_/google.com/ctpolicydays=C2=A0=C2=A0(if you c= an only use PSTN and would like to dial in, let me know).

---------- Forwarded message ----------
From: 'Ryan Hurst' via Certificate Transparency Po= licy <ct-policy@chromium.org>
Date: Thu, Feb 16,= 2017 at 2:56 AM
Subject: [ct-policy] CT Policy Days Location

All,

I am looking forward to seeing you al= l next week at Google, we will be located in Google Tech Corners II on the = Third Floor in Quinn Mallory. =C2=A0

I will have people in the lobby to help get you to the ri= ght location.

The address is: =C2= =A0

Google, Inc.

Tech Corners 2

807 11th Ave

Sunnyvale, CA 94089

We have the room from 8a= m - 5pm (PST) but the event will not start until 9am.

Agenda wise, I received=C2=A0some feedback for ideas on wor= king group sessions from others but otherwise it seems the agenda has the r= ight structure.

State of the Union and War= ming Up

=

1

= = =

Discussion: Concerns with Current Policy

<= /td><= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

16:20

Time

Start

Stop

Slot

Descript= ion

Discussion Leader / Notes

0:15

9:00

<= span style=3D"font-size:12pt;font-family:arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap">9:15


Check-in, badging, get situated in room

A= ll

0:30

9:00

9:30


Breakfast - Continental

All

0:05

9:30

9:35

<= /td>

Welcome and Logistics<= /p>

Ryan Hurst

= 0:45

9:35<= /p>

10:20

Presentation: Operating CT Logs at Scale

CT Team

0:45

10:20

11:05

2

Presentat= ion: CT Standardization Roadmap

CT Team

= 0:15

11:05

11:20


<= /td>

Break

All

= 0:45

11:20

12:05

Presentation: Current Chrome P= olicy

Chrome Team

1:00

13:05


Lunch

All

0:45

13:50

4

Ryan Hurst

0:30=

13:50

=

14:20


=

= Pick Break= -Out Sessions

Ryan Hurst

0:45

14:20

15= :05

5.1

Break-Out Sessions - 1

TBD*

0:30

15:05

15:35


Coffee/Beverage Service = Break

All

0:45

15:35<= /span>

16:20

<= /td>

5.2

Break-Out Sessions - 1 Presentations

TBD

0:45

6.1

Break-Out Sessions - 2

TBD*

0:45

17:05

17:50

6.2

Break-Out Sess= ions - 2 Presentations

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12pt;font-family:arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap">All

15

17:50



Adjourn for the Day

<= /td>

All

2:40=

17:50

20:30


Casual Dinner - @ - On your= own or informal group

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12pt;font-family:arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap">All

=



=

Break Out Sessions and Next Steps

= <= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

Lunch

<= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

17:30

=

Start

Stop

Slot

=

Discussion Leader / Notes

= 9:00

9:15<= /span>


Check-in, badging,= get situated in room

All

9:00

9:45


Breakfast - Continental

All

9:45

10:15


Kick-Off and Check-point

Ryan Hurst

<= /td>

10:15

10:45

7.1

Brea= k-Out Sessions - 3

TBD*

10:45

11:30


Break

All

11:30

12:30

7.2

Break-Out Sessions = - 3 Presentations

TBD*

12:30

13:30


All

13:30

14:15

8.1

Break-Out Sessions = - 4

TBD*

14:15

15:15<= /span>


Break

All

15:15

=

16:00

8.2<= /span>

Break-Out Sessions - 4 Presentatio= ns

TBD*

16:00

16:30<= /span>


Coffee/Beverage Service Break

All

16:30

17:30

9

Next Steps Su= mmary

Ryan Hurst


<= /td>

Adjourn

All

17:30

20:00


=

Casual Dinner - @ - On= your own or informal group

All


For the remote atte= ndees we will have a Google Video Chat here:=C2=A0https:/= /hangouts.google.com/hangouts/_/google.com/ctpolicydays=C2=A0=

There is still more room so don't be shy if you want to attend, = just let me know.

Ryan


--
You received this message because you are subscribed to the Google Groups &= quot;Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-policy@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct= -policy/CAKexNNMGtROWamVuM%3DWtvz8HACcSOTNLuXiZKnQZD_LNSqWwyQ%40mail.gmail.com.


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans


--f403045e447cf8a43305490a6b8c-- From nobody Tue Feb 21 06:06:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B244E129BA3 for ; Tue, 21 Feb 2017 06:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cMjVKX9mVAkK for ; Tue, 21 Feb 2017 06:06:39 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 CEFF8129BC9 for ; Tue, 21 Feb 2017 06:06:38 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id y135so50973310itc.1 for ; Tue, 21 Feb 2017 06:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZGFget3TnJJq3QPhkdVyC+jl5lYn8I3MantAyEk88Yo=; b=fTIqrJ9bZ3bCqALbwoTKIRFqtlReuoxT8UnkDf1poCotK2nvsJcUE6t7mumk7lb1jn YVEdChpmggf96N0umj7gAnUQ1IvsUiAVoGDRi5zbdow4DoyxtlU7Jay6/RhPN3kBmy/1 Be96vZ+L708gUzKWoxKvjzMFJOUMCKMJsCChsduOP2VSSuTlLY7THzzPA3nk4KMwKGma zNAMSn/g+jHDdbnQn9Nn/m36MZNGG9DoYL56++q5utcT4Mu1fqUVdPfzOBKya05BQSsX gC3hs0kxxEzOnGNrRYEQoGbqoMbxq99xDrXve8ZEtIT0R29d09kL9t+tBMNlbHJnndma 2Vig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZGFget3TnJJq3QPhkdVyC+jl5lYn8I3MantAyEk88Yo=; b=e4OGzwz3sMlMwncH4563DTTFLksCc88fCBbO807SPra1R2iqKPaS4HmQppU4r8rjLK Bit0+9mddqM7qcySDWxzGH+7LLHqTpSGrq8JChoW7R6iePYk1eA35Am2TQL4YDkVnsXu rlIyp9jfgtyW9EmQgvcbYiNFmHzxXeoLbTyc+akY4HhzStUvAXyMtz0z2ZUzorFrIMF2 Q6mmOE5uI+/4S9kkEmQM6NwTWPu1HR3PDsqkcdXQCLCotL1A+aT5T87fLPgBjoq0w7Cl 3ecTqDaYq4hnIIVvD6HfRuX5vFVVKOkKn7Y6Iz+xF165kDMZFSKqQ+mHX4yAewfeFYcb u/bA== X-Gm-Message-State: AMke39nDguuNSuMG5Ijef9W14K464sI2zOM3dd68l/1C7XF0ZjZE1lZjMt8A5HMPtQv+STnO9QMKCfcU842ohb4c X-Received: by 10.107.7.78 with SMTP id 75mr24047959ioh.165.1487685997795; Tue, 21 Feb 2017 06:06:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Tue, 21 Feb 2017 06:06:07 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Tue, 21 Feb 2017 06:06:07 -0800 Message-ID: To: Deb Cooley Content-Type: multipart/alternative; boundary=001a113f98d26fe38605490ae3a5 Archived-At: Cc: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] Fwd: [ct-policy] CT Policy Days Location X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:06:40 -0000 --001a113f98d26fe38605490ae3a5 Content-Type: text/plain; charset=UTF-8 Hi, I'll have to dial individual participants up. If you'd like to participate via PSTN, please reply privately with your phone number and I'll connect you around 9:30 AM PST. Eran On Tue, Feb 21, 2017 at 5:33 AM, Deb Cooley wrote: > Can you post the PSTN information? > > > TY, > Deb Cooley > > > On Thu, Feb 16, 2017 at 3:42 PM, Eran Messeri wrote: > >> Cross-post from the Chromium ct-policy list. >> tl;dr: >> - There are free spaces if any of you would like to attend in-person. >> - You can attend remotely via https://hangouts.google.co >> m/hangouts/_/google.com/ctpolicydays >> (if you >> can only use PSTN and would like to dial in, let me know). >> >> ---------- Forwarded message ---------- >> From: 'Ryan Hurst' via Certificate Transparency Policy < >> ct-policy@chromium.org> >> Date: Thu, Feb 16, 2017 at 2:56 AM >> Subject: [ct-policy] CT Policy Days Location >> >> All, >> >> I am looking forward to seeing you all next week at Google, we will be >> located in Google Tech Corners II on the Third Floor in Quinn Mallory. >> >> I will have people in the lobby to help get you to the right location. >> >> The address is: >> >> Google, Inc. >> >> Tech Corners 2 >> >> 807 11th Ave >> >> Sunnyvale, CA 94089 >> >> We have the room from 8am - 5pm (PST) but the event will not start until >> 9am. >> >> Agenda wise, I received some feedback for ideas on working group sessions >> from others but otherwise it seems the agenda has the right structure. >> >> State of the Union and Warming Up >> >> Time >> >> Start >> >> Stop >> >> Slot >> >> Description >> >> Discussion Leader / Notes >> >> 0:15 >> >> 9:00 >> >> 9:15 >> >> Check-in, badging, get situated in room >> >> All >> >> 0:30 >> >> 9:00 >> >> 9:30 >> >> Breakfast - Continental >> >> All >> >> 0:05 >> >> 9:30 >> >> 9:35 >> >> Welcome and Logistics >> >> Ryan Hurst >> >> 0:45 >> >> 9:35 >> >> 10:20 >> >> 1 >> >> Presentation: Operating CT Logs at Scale >> >> CT Team >> >> 0:45 >> >> 10:20 >> >> 11:05 >> >> 2 >> >> Presentation: CT Standardization Roadmap >> >> CT Team >> >> 0:15 >> >> 11:05 >> >> 11:20 >> >> Break >> >> All >> >> 0:45 >> >> 11:20 >> >> 12:05 >> >> 3 >> >> Presentation: Current Chrome Policy >> >> Chrome Team >> >> 1:00 >> >> 12:05 >> >> 13:05 >> >> Lunch >> >> All >> >> 0:45 >> >> 13:05 >> >> 13:50 >> >> 4 >> >> Discussion: Concerns with Current Policy >> >> Ryan Hurst >> >> 0:30 >> >> 13:50 >> >> 14:20 >> >> Pick Break-Out Sessions >> >> Ryan Hurst >> >> 0:45 >> >> 14:20 >> >> 15:05 >> >> 5.1 >> >> Break-Out Sessions - 1 >> >> TBD* >> >> 0:30 >> >> 15:05 >> >> 15:35 >> >> Coffee/Beverage Service Break >> >> All >> >> 0:45 >> >> 15:35 >> >> 16:20 >> >> 5.2 >> >> Break-Out Sessions - 1 Presentations >> >> TBD >> >> 0:45 >> >> 16:20 >> >> 17:05 >> >> 6.1 >> >> Break-Out Sessions - 2 >> >> TBD* >> >> 0:45 >> >> 17:05 >> >> 17:50 >> >> 6.2 >> >> Break-Out Sessions - 2 Presentations >> >> All >> >> 15 >> >> 17:50 >> >> >> Adjourn for the Day >> >> All >> >> 2:40 >> >> 17:50 >> >> 20:30 >> >> Casual Dinner - @ - On your own or informal group >> >> All >> >> >> >> Break Out Sessions and Next Steps >> >> Start >> >> Stop >> >> Slot >> >> Description >> >> Discussion Leader / Notes >> >> 9:00 >> >> 9:15 >> >> Check-in, badging, get situated in room >> >> All >> >> 9:00 >> >> 9:45 >> >> Breakfast - Continental >> >> All >> >> 9:45 >> >> 10:15 >> >> Kick-Off and Check-point >> >> Ryan Hurst >> >> 10:15 >> >> 10:45 >> >> 7.1 >> >> Break-Out Sessions - 3 >> >> TBD* >> >> 10:45 >> >> 11:30 >> >> Break >> >> All >> >> 11:30 >> >> 12:30 >> >> 7.2 >> >> Break-Out Sessions - 3 Presentations >> >> TBD* >> >> 12:30 >> >> 13:30 >> >> Lunch >> >> All >> >> 13:30 >> >> 14:15 >> >> 8.1 >> >> Break-Out Sessions - 4 >> >> TBD* >> >> 14:15 >> >> 15:15 >> >> Break >> >> All >> >> 15:15 >> >> 16:00 >> >> 8.2 >> >> Break-Out Sessions - 4 Presentations >> >> TBD* >> >> 16:00 >> >> 16:30 >> >> Coffee/Beverage Service Break >> >> All >> >> 16:30 >> >> 17:30 >> >> 9 >> >> Next Steps Summary >> >> Ryan Hurst >> >> 17:30 >> >> >> Adjourn >> >> All >> >> 17:30 >> >> 20:00 >> >> Casual Dinner - @ - On your own or informal group >> >> All >> >> >> For the remote attendees we will have a Google Video Chat here: >> https://hangouts.google.com/hangouts/_/google.com/ctpolicydays >> >> >> There is still more room so don't be shy if you want to attend, just let >> me know. >> >> Ryan >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Certificate Transparency Policy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ct-policy+unsubscribe@chromium.org. >> To post to this group, send email to ct-policy@chromium.org. >> To view this discussion on the web visit https://groups.google.com/a/ch >> romium.org/d/msgid/ct-policy/CAKexNNMGtROWamVuM%3DWtvz8HACcS >> OTNLuXiZKnQZD_LNSqWwyQ%40mail.gmail.com >> >> . >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --001a113f98d26fe38605490ae3a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'll have to dial individual pa= rticipants up.
If you'd like to participate via PSTN, please = reply privately with your phone number and I'll connect you around 9:30= AM PST.

Eran

On Tue, Feb 21, 2017 at 5:33 AM, Deb Coole= y <debcooley1@gmail.com> wrote:
Can you post the PSTN information?=C2=A0

TY,
Deb Cooley

<= /div>

On Thu, Feb 16, 2017 at 3:42 PM, Eran Messeri = <eranm@google.com<= /a>> wrote:
Cross-post from the Chromium ct-polic= y list.
tl;dr:
- There are free spaces if any of you wo= uld like to attend in-person.
- You can attend remotely via=C2=A0= https://hangouts.google.com/hangouts/_/google.com/ctpolicydays=C2=A0=C2=A0(if you can only = use PSTN and would like to dial in, let me know).

---------- Forwarded message ----------
From: 'Ryan Hurst' via Certificate Transparency Policy= <ct-policy@chromium.org>
Date: Thu, Feb 16, 2017 at= 2:56 AM
Subject: [ct-policy] CT Policy Days Location

All,

I am looking forward to seeing you all next w= eek at Google, we will be located in Google Tech Corners II on the Third Fl= oor in Quinn Mallory. =C2=A0

I will have people in the lobby to help get you to the right loca= tion.

The address is: =C2=A0

Google, Inc.

Tech Corners 2

<= p>807 11th Ave

Sunnyvale, CA 94089

<= div>

We have the room from 8am - 5pm = (PST) but the event will not start until 9am.

Agenda wise, I received=C2=A0some feedback for ideas on working gro= up sessions from others but otherwise it seems the agenda has the right str= ucture.

State of the Union and Warming Up<= /span>

=

= Time

Start

Stop

Slot

Description

Discussion Leader / Notes

0:15

9:00

9:15


Check-in, badging, get situated in room

All=

=

0:30

9:00

9:30


Breakfast - Continental

All

0:05

9:30

9:35


Welcome and Logistics

=

Rya= n Hurst

0:45

9:35

=

10:20

1

CT Team

0:45

10:20

11:05

2

Presentation: CT St= andardization Roadmap

CT Team

0:15

11:05

11:20


Break

All

0:45

11:20

12:05

3=

Presentation: Current Chrome Policy

Chrome Team

1:00

12:05

13:05


L= unch

All

0:45

13:05

13:50

4

Discussion: Concerns with Current Policy

Ryan Hur= st

0:30

13:50

14:20


Pick Break-Out Sess= ions

Ryan Hurst

0:45

14:20

= 15:05

5.1

Break-Out Sessions - 1

TBD*

<= /td>

0:30

15:05

15:35


Coffee/Beverage Service Break

All

0:4= 5

15:35<= /p>

16:20

5.2

Break-Out Sessions - 1 Presentations

TBD

0:45

16:20

17:05=

6.1

= Break-Out Sessions - 2

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12pt;font-family:arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap">TBD*

0:45

17:05

17:50

6.2

Break-Out Sessions - = 2 Presentations

All

15

17:50



Adjourn for the Day

All

2:40

17:50

20:30


Casual Dinner - @ - On your own or i= nformal group

All

=

Break Out Sessions and Next Steps

<= td style=3D"border-width:0.75pt;border-style:solid;border-color:rgb(0,0,0);= vertical-align:bottom;padding:2pt">

9:00

All

12:30


Casual Dinner - @ - On your o= wn or informal group


For the remote attendees w= e will have a Google Video Chat here:=C2=A0https://hangou= ts.google.com/hangouts/_/google.com/ctpolicydays=C2=A0

= There is still more room so don't be shy if you want to attend, just le= t me know.

Ryan


=


<= /div><= font color=3D"#888888">

--
You received this message because you are subscribed to the Google Groups &= quot;Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-policy@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct= -policy/CAKexNNMGtROWamVuM%3DWtvz8HACcSOTNLuXiZKnQZD_LNSqWwyQ%40m= ail.gmail.com.


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans



--001a113f98d26fe38605490ae3a5-- From nobody Tue Feb 21 09:42:51 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15587129485 for ; Tue, 21 Feb 2017 09:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3JKKspxoQytM for ; Tue, 21 Feb 2017 09:42:49 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 D757D12943D for ; Tue, 21 Feb 2017 09:42:48 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id h10so112673962ith.1 for ; Tue, 21 Feb 2017 09:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LjoFIXT/kIKLNGWRP7TCQT2qNoZGC31n/XEbVjkegYg=; b=JkFVHBxW6ES19lg0+QMFOd3Dej8M/mwE8KtqwiCQlmZOYZ+72oIUF3BpctLX9hZ+Zu vvH4laC2u/3kpx2ifrbvAvJlbwrz2RKzIMCc5OY6pKNCXLGjO4SX8mwPqjCIA/J8haAJ sKZzfRXHuVsV5CkKa9KfLa34lHLOU/0cKTObuBonSoHTSpzPj/31DmNxuOz319+UseeM Cxe8KdrdP312mydArZlomX73dj4ThkI06cADX3wBhV+/GFtiiSjVM5geaFWMJrIElwtq CbSNGWgJ2wSslxbprMVuwNTikuMJrUsfKE5FFvAWg2a1rK6MNdczbX909NvSdkzA81M6 wnTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LjoFIXT/kIKLNGWRP7TCQT2qNoZGC31n/XEbVjkegYg=; b=KHdn6676XGTpRfT2ksdl0F2QcGz1VTYVgace6rDEhl1EtVBRnGmUHBghP71VvthTcq JiX2OI6xiUfF+D0YE1c8gWxgIRYK0meOlWyqq8ZM9Mv6+o6knpWeFrmNiGd6uVj03HU4 9j94j2xYBf4R3M4EV4Q0D0DfSixtW+tjXGAaElNoMCvaMW+FqRiQ2Sb/2t6EGEZuU55s DnhvV48fQcq+Hf811FDg/FEJxYxA3bdOpRAWyOjllMohcttXeL5Up8ZzQ97xHtLm6jfq bCxwzNNixJj2trze44FoYe4xTbqmbZIEZ0ZIn/PmU8D/m8ynCcbONXgdmrR0/tskcQdE CN7g== X-Gm-Message-State: AMke39khwcfdD7yWTg/JMxbgECMSifolsX7TL8Rr3Pl5EGetKE797xcn56tx4Zbb9zAShYuz0zIq/aFqRGL9DNfA X-Received: by 10.36.93.213 with SMTP id w204mr31276518ita.60.1487698965660; Tue, 21 Feb 2017 09:42:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Tue, 21 Feb 2017 09:42:15 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Tue, 21 Feb 2017 09:42:15 -0800 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113a629661fd8e05490de8fb Archived-At: Subject: [Trans] Fwd: CT policy days remote participation link X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:42:50 -0000 --001a113a629661fd8e05490de8fb Content-Type: text/plain; charset=UTF-8 FYI. ---------- Forwarded message ---------- From: Eran Messeri Date: Tue, Feb 21, 2017 at 9:39 AM Subject: CT policy days remote participation link To: "ct-policy@chromium.org" For those participating remotely, please join via: https://hangouts.google.com/hangouts/_/google.com/ctpolicy-days Regards, Eran --001a113a629661fd8e05490de8fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI.

---------- Forward= ed message ----------
From: Eran Messeri <eranm@chromi= um.org>
Date: Tue, Feb 21, 2017 at 9:39 AM
Subject: CT = policy days remote participation link
To: "ct-policy@chromium.org" <ct-policy@chromium.org>


For those participating remotely, please join via:

Regards,
Eran

--001a113a629661fd8e05490de8fb-- From nobody Thu Feb 23 11:18:51 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E7C1296C8 for ; Thu, 23 Feb 2017 11:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0dEzlevRukeD for ; Thu, 23 Feb 2017 11:18:48 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 8E6331296A6 for ; Thu, 23 Feb 2017 11:18:48 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id b129so186825pgc.2 for ; Thu, 23 Feb 2017 11:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=NZ+X9rv/EQR89VPGVSwQ5UMTyVCgvQkqTF7soQdPyHM=; b=BTPkaUHEarqiHyvk+XAaXm8rWjE8KaFINUuql7jikfoRuzMHA6m8T5TBT8F2OtnR1g mPpAGQKFwkn68yCgqgbVXXp/hZwf6mgSAPV+Jpk/AGJCGuriiAHVQxO0V5+ChajrG7/z JHYWO/4cDkKHSk2v8lqxFfrkiCUeGXqn8jU6d9+Pk1aRxkm3Ep+7PVhTgooXMzbznwUG zpw4PfIXwRuFH/fPpd4b/YdxNapZVOBo/Gn110GExIzW+HJNzlekufOnGlD0VEnC99Ea M2zLhWx0h1U92oklyCtFWv2rt8i4qSWfSHVwvztF9x55aZUMty5EtAaDwulBo/GasnLt G2/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NZ+X9rv/EQR89VPGVSwQ5UMTyVCgvQkqTF7soQdPyHM=; b=o7UaZF6JFh9JyJz6fN+54KN1O0SItfNcY0JEh2o8bqXaLGuXaQmEwKUne4L+m2fAf8 dUXFlKjlInrYt82aBtvJjhsB54eBr7JHEFZGN2YMYF4KLWJkKY0pVU6JcgM4sK5M2NV3 lHrGIUg8eCOTlUHucbzwClr8in9yqb6iKKKGk7at7aBvzorf1UF0iFbiq7OjJQKCJ/G1 YlaagDRGR7Ti7AptGzWh4sxfu1DYIfxsmLPXkJjbLVx5/1ZuC8zDY94n3rdrGxDkQUSm yKjVGNjHYX/YGfFgtFnq+bQgKfoHSLIlJq7XhJmTx91GUysx6ewF/69+fvwA1XD3XMgm QGEw== X-Gm-Message-State: AMke39lJVz1zTZ6gykvM41Zl+74jUB9oFMVAdascNK6xKMzTxFyI2BYxv0q3GYJSpWPsSg== X-Received: by 10.98.87.142 with SMTP id i14mr47831754pfj.85.1487877527492; Thu, 23 Feb 2017 11:18:47 -0800 (PST) Received: from Melindas-MacBook-Pro.local (209-112-145-158-radius.dynamic.acsalaska.net. [209.112.145.158]) by smtp.gmail.com with ESMTPSA id e2sm11216381pga.61.2017.02.23.11.18.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 11:18:46 -0800 (PST) To: trans@ietf.org References: From: Melinda Shore Message-ID: Date: Thu, 23 Feb 2017 10:18:42 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nddN1Pg3rWfODwLLSqiWkF0FoSP5cvnxh" Archived-At: Subject: Re: [Trans] The importance of understanding auditing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:18:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nddN1Pg3rWfODwLLSqiWkF0FoSP5cvnxh Content-Type: multipart/mixed; boundary="6BrT5cmtQ0O3OBSsTlk5pJltM5AsRMOMd"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: Subject: Re: [Trans] The importance of understanding auditing References: In-Reply-To: --6BrT5cmtQ0O3OBSsTlk5pJltM5AsRMOMd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: The discussion seems to have settled out, and this is a check to see where we stand. First, in general it sounds like there's a need for a client behavior document regardless, and we'll take the mechanics of that to a separate discussion. Second, Richard proposed two auditing models (one STH and dynamic inclusion proofs, and many STHs and static inclusion proofs), which in turn led to a discussion of what sort of TLS client we're targeting, in the first place. That we're covering browsers seems uncontroversial but there's not agreement on clients beyond that (for example, command-line or batching tools like curl and wget). I think this is where I need to point out that our current deliverables specify HTTP over TLS but not browsers, even though our documents tend to focus on browsers, and the charter discusses the possibility of addressing other, non-HTTP applications. I think it would be probably be useful to have another call. Would people involved in this discussion be up for a call next week? Melinda --6BrT5cmtQ0O3OBSsTlk5pJltM5AsRMOMd-- --nddN1Pg3rWfODwLLSqiWkF0FoSP5cvnxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYrzWTAAoJELiGRpM6HoEu8p4P/3ejNBHrKmYrP13YKXzILaSs +ScAR7dBQNSUzZFsYcqKFN6rfd2sLmSZTPHfLSpZ31HcnrR+yi8QyQhXke6nWIb1 WLR3kVDwbHsBdGpKVeAhjgA30YkwF3KwZlpf6/odKrU1GmCseHkuLtnGyBgckVYi DdNHgXC3tY2k8q2DnMRN2P0YVjrHD0CJV/bsCMqLuruOZWgjGwDvGTeZYYgACR8e yVXGhMbjnyZRtE+wtt84OiHoRWzeMDh3yBKTI94FYERvz+5eM7scc/jEpjgvQQov LcaEnFg7NBi7fRUbI9GUlIk2nqxhiD1CWz9YtIzmpDlHLIUHlSEqux46CSYdzAdB lhxGx8dVvf6THlc/c7GFV66pi6xVTkG+61KHmazBYOUQDATbLn1LpXPjzF5ySbkR 6cBo/roi2j8LAlSfx+nki4Bwj1NUgVFWI1ZxEOindeUHxMncFnCmiyeUJHZArh/l Q5xoV6e4XeKQR5BvbgJbkUi0x4ISuI/xcg08Aecswk89LV5g5nzMGpLAsQVtXoYQ fn+ILYCca7By4mZcLJ9hGR109abUEQGCBiZolHtzVhMMOUnFFGxDijMtena6+FO3 UZ55zij7lIFOAFvysK9Wn+5BHc1/j2SOwWeg8v/cXZ8xD6RL/j+COi+OrRHpxnaL kYszpMrgVJVJjUzN+/W/ =g1LG -----END PGP SIGNATURE----- --nddN1Pg3rWfODwLLSqiWkF0FoSP5cvnxh-- From nobody Thu Feb 23 11:32:28 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7113512A1F4 for ; Thu, 23 Feb 2017 11:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 pKtukw84EiwC for ; Thu, 23 Feb 2017 11:32:24 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 2195B12A135 for ; Thu, 23 Feb 2017 11:32:24 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id d9so6191546itc.0 for ; Thu, 23 Feb 2017 11:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ogUhut4Act2d4IKYoBx9cp3toAaODQEhPmnhrafhL2M=; b=OGb7VeamNFs955KkzLZ1Y6QUaJQz4s+Zk+v81u3H38vLkPz4vSiq9W+9zw/zcA8lIX hYNyNqIju/XQqBqoyeKKCADpAe0K4ngimmuhz/uLuzFoGXWfg3iRldtzSThzATpAj87F mTY+eV5pt6eli/mVIaViE5JboHQmc6eOnO1MNIho9E8INDwJbMO9IOm+ub+SuI+yFUHN /ZvvW+wfXMyK6vU+gozUXKItHES6myQGtJPy9dHfIu03MrGMpGkr0R3SJwBk9NmyV+Ac m6Qx4SQYdURpDL/4IaUEBzDAimgFFPJn9mzehY4+rG00ESMrjurXe3n0D+sNqeumZVeg irpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ogUhut4Act2d4IKYoBx9cp3toAaODQEhPmnhrafhL2M=; b=VgPqTUoiOcflgE3/xbzEPoJc2TEQvXzzpWcVj+v9gSTTgQwQNHWB2LLL6RLaewkBTU I75OV611nrALCSNwFefq05pGuIGdrI5LolIASXe+WBcpfNV95td4LfTRpM2SBY+vK0zd G27PEmbjwvvEbkWFRZgsPlK0/kMEnrUcBgOdXzooVSCiN0Hk3w+XwrDjq9v3Vj4O1h/9 Jfif3u73b2zKnJNdxQ4UJLk2irdGyQXLMvMJ46PSiOda3l+5wfjuqvsM3fUAGRQubFk+ 8HcHVUWkGcJpyjudIIsptmruyBSxPIOgb+XyF3cJQHa09CaUXKg38TjA66T/NCOBv9Jg Rb2A== X-Gm-Message-State: AMke39nVirSTouvZIz4Y9QHAb2rbFAOf1bCxxaMKYWkOXaKmA1WItN5GHmGa7QDg/LI5jYgdNDRbZhdRwXYT1SVG X-Received: by 10.107.7.78 with SMTP id 75mr35667282ioh.165.1487878342900; Thu, 23 Feb 2017 11:32:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Thu, 23 Feb 2017 11:31:52 -0800 (PST) From: Eran Messeri Date: Thu, 23 Feb 2017 11:31:52 -0800 Message-ID: To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Content-Type: multipart/alternative; boundary=001a113f98d2196c62054937ac89 Archived-At: Subject: [Trans] Public verification of log behaviour - obtaining proofs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:32:26 -0000 --001a113f98d2196c62054937ac89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99d like to overview a few options for clients to obtain inclusion = proofs of log entries (each comprising of the corresponding SCT=E2=80=99s timestam= p + certificate) in a privacy-preserving manner. The naive approach, of contacting the CT log itself (or a proxy), discloses to the operator of the service the certificates each client (as defined by IP) observed. Option 1: DNS-based protocol [1]. Clients perform two types of queries, under this protocol: * Getting the index of an entry. * Getting an inclusion proof for entry with the given index. This protocol preserves the client=E2=80=99s privacy by using the client=E2= =80=99s recursive resolver to proxy the request (rather than directly connecting to a service) - full privacy analysis is at [2]. An upside of this protocol is that responses to queries generated under this protocol are constant and can be cached infinitely - an entry=E2=80=99= s index will never change, as well as the inclusion proof from a particular index for a particular tree size. This is the approach the CT team and Chrome team at Google are working on implementing - currently DNS queries are authoritatively resolved by a DNS front-end of the CT log mirror operated by Google. The intent is to measure success rates and validate correct operation under most scenarios, then standardize the protocol. Option 2: SSL Proxy for log traffic. Clients connect to a proxy that will relay the TCP connection to the log (much like SOCKS5), but perform an SSL handshake with the log. Since the connection is coming from the proxy, the log will not learn which clients observed which certificate. As the connection is encrypted, the proxy will not learn which clients observed which certificates. One downside of the protocol is that responses are not cacheable by the log / proxy (at least not with a naive implementation). It should be noted that clients only need to fetch an inclusion proof once per observed certificate, not once per connection, and that information can be cached on the client. The other downside, and the reason we didn=E2=80=99t implement this approac= h at Google, is that collusion between the proxy operator and the log operator could easily correlate requests to the proxy with requests to the log and de-cloak clients. Note the underlying assumption of clients having up-to-date Signed Tree Heads, provided to them by the UA vendor. While the original design called for clients obtaining STHs themselves, having UA vendors push down STHs improves the scalability aspect and does not change the threat model (since clients already trust the UA vendor). If anything, it serves to guarantee all clients have the same view of the tree, making it harder for the log to present split views. I=E2=80=99ll post separately about dealing with the result of an inclusion = proof check. Eran [1] https://github.com/google/certificate-transparency-rfcs/blob/master/dns/dra= ft-ct-over-dns.md [2] https://www.ietf.org/mail-archive/web/trans/current/msg02617.html --001a113f98d2196c62054937ac89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99d like to overview a few options for client= s to obtain inclusion proofs of log entries (each comprising of the corresp= onding SCT=E2=80=99s timestamp + certificate) in a privacy-preserving manne= r.

The naive approach, of contacting the CT log it= self (or a proxy), discloses to the operator of the service the certificate= s each client (as defined by IP) observed.

Option = 1: DNS-based protocol [1].
Clients perform two types of queries, = under this protocol:
* Getting the index of an entry.
*= Getting an inclusion proof for entry with the given index.

<= /div>
This protocol preserves the client=E2=80=99s privacy by using the= client=E2=80=99s recursive resolver to proxy the request (rather than dire= ctly connecting to a service) - full privacy analysis is at [2].
=
An upside of this protocol is that responses to queries gene= rated under this protocol are constant and can be cached infinitely - an en= try=E2=80=99s index will never change, as well as the inclusion proof from = a particular index for a particular tree size.

Thi= s is the approach the CT team and Chrome team at Google are working on impl= ementing - currently DNS queries are authoritatively resolved by a DNS fron= t-end of the CT log mirror operated by Google. The intent is to measure suc= cess rates and validate correct operation under most scenarios, then standa= rdize the protocol.

Option 2: SSL Proxy for log tr= affic.
Clients connect to a proxy that will relay the TCP connect= ion to the log (much like SOCKS5), but perform an SSL handshake with the lo= g. Since the connection is coming from the proxy, the log will not learn wh= ich clients observed which certificate. As the connection is encrypted, the= proxy will not learn which clients observed which certificates.
=
One downside of the protocol is that responses are not cache= able by the log / proxy (at least not with a naive implementation). It shou= ld be noted that clients only need to fetch an inclusion proof once per obs= erved certificate, not once per connection, and that information can be cac= hed on the client.

The other downside, and the rea= son we didn=E2=80=99t implement this approach at Google, is that collusion = between the proxy operator and the log operator could easily correlate requ= ests to the proxy with requests to the log and de-cloak clients.
=
Note the underlying assumption of clients having up-to-date = Signed Tree Heads, provided to them by the UA vendor. While the original de= sign called for clients obtaining STHs themselves, having UA vendors push d= own STHs improves the scalability aspect and does not change the threat mod= el (since clients already trust the UA vendor). If anything, it serves to g= uarantee all clients have the same view of the tree, making it harder for t= he log to present split views.

I=E2=80=99ll post s= eparately about dealing with the result of an inclusion proof check.
<= div>
Eran


--001a113f98d2196c62054937ac89-- From nobody Thu Feb 23 11:45:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9122312A2AC for ; Thu, 23 Feb 2017 11:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cwfxS6ChH_vH for ; Thu, 23 Feb 2017 11:45:01 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 38918129A8F for ; Thu, 23 Feb 2017 11:45:01 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id h10so178068224ith.1 for ; Thu, 23 Feb 2017 11:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qPjpo7uiNalVUCNKJpYCadgoIMfoju7GSf9+IFpJie8=; b=ND1JaByeujqIaUe3BCicSnIVrIVO+DFCyJDHByUgXgdfUrw71VczOK4x9PD3wMLrt8 BI5Mk9q9PfacIrc3XibgKiLChSB9wQ/G4293WqXw5NZXrXk+zs1RbYYdHdNoAKpE19Sc BfeG7l5u7D2OAfVRquWKVbUqzvJmRli/ljKGAVA4qQb0Wda00QkuSUuuH/XjZULdyakv UQQR9OI3MijjUNNFXtMeSlGuo6EasFol0D9YE9IIxDxaog6PWCaKIfVTQ6DjM4CfEfiV 6V9b96jjdfxjwANwuXzPHapeiYPmngOYg5XJ5NYRAW9g9Jl52vh8jePH42L7TrHsLUdq FH/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:from:date:message-id:subject:to; bh=qPjpo7uiNalVUCNKJpYCadgoIMfoju7GSf9+IFpJie8=; b=EHJW0LAoQUZE7Xygj3Z6tBw3JhPwQrqkLBizohuFJxwqFx1KZYcTbBVMw/EuI6x3m6 Zwx3yxyK57CmvBjf+eB7afpigmP3BYG9K7ra5Za92ePrG1Jl+kbCjoH5sgbXTefVAPzr 9QxCYGYVbL3f8sO7l+h0WU4uTIIdKgU8JO2SVMk22OLGHc1z57LFAeUsndgtGpRY9E6P E79TBwnoi6pBTTh1HdEshARkUnzS1wpHM3L1LFvRumaB4q2xzxHO/wRq1y2TbxIkEHnu j4XGRhcbafUz0qR9k8TD2c3fkwNz9rRsj+PaPcneobjp8VPmAX4e7JI+JfTmDwAOgfEg 2wVQ== X-Gm-Message-State: AMke39nO1tEK4dZUlndKY0+kyWBD44Q0xHF9Ib1wGGb2kO/mYE82NiBVekowo4Q6dYsCSI4QE8glx3LTT/n3dngq X-Received: by 10.36.116.71 with SMTP id o68mr4587009itc.60.1487879100179; Thu, 23 Feb 2017 11:45:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Thu, 23 Feb 2017 11:44:29 -0800 (PST) From: Eran Messeri Date: Thu, 23 Feb 2017 11:44:29 -0800 Message-ID: To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Content-Type: multipart/alternative; boundary=001a114aad2c3c6e68054937d965 Archived-At: Subject: [Trans] Reporting evidence of potential log misbehaviour X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:45:04 -0000 --001a114aad2c3c6e68054937d965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To complement my other post about methods for obtaining inclusion proofs, I've listed some thoughts about coping with failure to obtain an inclusion proof. Note that this is not a concrete work plan, and does not represent conclusions reached with the broader CT & Chrome teams. Feedback is most welcome. Under the assumption of the current deployment of 6962, in particular: - Clients get SCTs (without inclusion proofs). - Clients periodically receive STHs from a the UA vendor (which acts as a trusted auditor). The problem is: How can log misbehaviour, observed by some clients, can be published to other parties? More concretely, how can clients, in possession of a suspicious log promise, make other parties aware of this promise? Particularly, SCTs that could not be audited successfully (=E2=80=9Csuspici= ous=E2=80=9D SCTs). Assumptions: * The client trusts the UA software vendor (which is already the case). * Same incident response model as for misbehaving CAs: Clients can only disclose evidence, but not take local action, and rely on the managers of the root store program for remediation. Approaches for solution: (1) Disclose =E2=80=9Csuspicious=E2=80=9D SCTs to the UA vendor. (2) Disclose =E2=80=9Csuspicious=E2=80=9D SCTs to the website owner (or a c= hosen collection service). (3) Privacy-preserving proof of log misbehaviour. (1) Is the most trivial action for a client to take, but has to be balanced against privacy implications (of disclosing part of the browsing history). For example, a client could only disclose SCTs from a certain log for which it failed to get an inclusion proof, while at the same time being able to obtain inclusion proofs for other SCTs from the same log. The heuristics for determining when to disclose SCTs to the trusted auditor, or when to suggest so to the user, should be based on real-world data of success rates for obtaining inclusion proofs, which is the motivation behind deployment of the DNS-based protocol. Option (2), of reporting SCTs to the originating website or a collection service nominated by the website has better privacy properties, as information about observed certificates + SCTs is only reported to the site from which it originated. This method is specified in the Gossip document. It does require website participation, but does not require websites to make security decisions (as observed SCTs can be passed along to monitoring services). A third option is a privacy-preserving proof of log misbehaviour - there's academic work in the area which I hope to be able to share soon, but can be implemented on top of RFC6962 (and would be simpler to implement on top of 6962-bis). In this option, there would be a proof, signed by the log, that it cannot fulfil a commitment to incorporate an SCT. One variant would not disclose the SCT at all, and another one would disclose the timestamp from the SCT, allowing black-listing of bad entries. Note, that all of these options would work if clients receive embedded inclusion proofs + STHs. Reporting back to the UA vendor implies trust in the UA vendor to take action. To add transparency to the system and prevent the option of a UA vendor denying having received potential evidence of log misbehaviour, all such evidence (as well as the view of logs the UA vendor sends to its users) can be logged in a verifiable data structure. The problem of global consensus on the state of CT logs (i.e. among UA vendors, for example), is a much broader one that may be tackled by the =E2=80=9CInternet-level Consensus=E2=80=9D list. Eran --001a114aad2c3c6e68054937d965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To complement my other post about methods for obtaini= ng inclusion proofs, I've listed some thoughts about coping with failur= e to obtain an inclusion proof. Note that this is not a concrete work plan,= and does not represent conclusions reached with the broader CT & Chrom= e teams.
Feedback is most welcome.

Under= the assumption of the current deployment of 6962, in particular:
- Clients get SCTs (without inclusion proofs).
- Clients periodi= cally receive STHs from a the UA vendor (which acts as a trusted auditor).<= /div>

The problem is:
How can log misbehaviour= , observed by some clients, can be published to other parties? More concret= ely, how can clients, in possession of a suspicious log promise, make other= parties aware of this promise? Particularly, SCTs that could not be audite= d successfully (=E2=80=9Csuspicious=E2=80=9D SCTs).

Assumptions:
* The client trusts the UA software vendor (which = is already the case).
* Same incident response model as for misbe= having CAs: Clients can only disclose evidence, but not take local action, = and rely on the managers of the root store program for remediation.

Approaches for solution:
(1) Disclose =E2=80=9C= suspicious=E2=80=9D SCTs to the UA vendor.
(2) Disclose =E2=80=9C= suspicious=E2=80=9D SCTs to the website owner (or a chosen collection servi= ce).
(3) Privacy-preserving proof of log misbehaviour.
=
(1) Is the most trivial action for a client to take, but has= to be balanced against privacy implications (of disclosing part of the bro= wsing history). For example, a client could only disclose SCTs from a certa= in log for which it failed to get an inclusion proof, while at the same tim= e being able to obtain inclusion proofs for other SCTs from the same log. T= he heuristics for determining when to disclose SCTs to the trusted auditor,= or when to suggest so to the user, should be based on real-world data of s= uccess rates for obtaining inclusion proofs, which is the motivation behind= deployment of the DNS-based protocol.

Option (2),= of reporting SCTs to the originating website or a collection service nomin= ated by the website has better privacy properties, as information about obs= erved certificates + SCTs is only reported to the site from which it origin= ated. This method is specified in the Gossip document. It does require webs= ite participation, but does not require websites to make security decisions= (as observed SCTs can be passed along to monitoring services).
<= br>
A third option is a privacy-preserving proof of log misbehavi= our - there's academic work in the area which I hope to be able to shar= e soon, but can be implemented on top of RFC6962 (and would be simpler to i= mplement on top of 6962-bis). In this option, there would be a proof, signe= d by the log, that it cannot fulfil a commitment to incorporate an SCT. One= variant would not disclose the SCT at all, and another one would disclose = the timestamp from the SCT, allowing black-listing of bad entries.

Note, that all of these options would work if clients rece= ive embedded inclusion proofs + STHs.

Reporting ba= ck to the UA vendor implies trust in the UA vendor to take action. To add t= ransparency to the system and prevent the option of a UA vendor denying hav= ing received potential evidence of log misbehaviour, all such evidence (as = well as the view of logs the UA vendor sends to its users) can be logged in= a verifiable data structure.

The problem of globa= l consensus on the state of CT logs (i.e. among UA vendors, for example), i= s a much broader one that may be tackled by the =E2=80=9CInternet-level Con= sensus=E2=80=9D list.

Eran
--001a114aad2c3c6e68054937d965-- From nobody Fri Feb 24 11:22:29 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942681294DC for ; Fri, 24 Feb 2017 11:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 gwJkl9BlvPZW for ; Fri, 24 Feb 2017 11:22:25 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 034041294D4 for ; Fri, 24 Feb 2017 11:22:24 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id 89so19225757wrr.3 for ; Fri, 24 Feb 2017 11:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jEEtcxJGhLU7gyTYWeKyT8hfTm2g7rMGTL29qEnS86A=; b=ediCMGZ/wKClZVnmUtceVve7icCatlPzW2FkqltmpeFyDJp3pNuKA/opJUgHEFDuhM 5KkWvDZIYfhJsf733puOeDQe16kf0oTDT4IWXhdiygI95e3StzroSPnQpmJyhvpmppKA kFGVmc6upPY92QxIZvd/lGLVKXe+83K9k6I5Ec2kDLWRCCsBPHhvcSb8+H9FiMbrJzzD /Ej2tsGgpJ+OyJc4W2rUaJY03tbrniK4nzlmrHfy1LL+e/rESQ+yTYvDI2DyXMpA32Nt tXNV3xd4RxeH91cYkSqbBAOpAaQssfRs/p1LLnCOF+w7LqMKZkZazdjC3BNsAAc2d0cb HbbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jEEtcxJGhLU7gyTYWeKyT8hfTm2g7rMGTL29qEnS86A=; b=j+p67LMKoztKysuM1q719uSYjqCuo7MR4zVaH0PpfyHZWUecwFH5BcbIDcyShXDKLB ZoLOC343zRyPezcb6touAiaqNsYfPuk8aSuWYxgvWdsTaglWznne9WdgTcdIdvpkNlUt GZRJMmGoG+wIBOLt1MeSU88Klm2TW7pLm1z3ItN5ILlWAjyLYWNcawEnj9aNAJyZwVFi 7/hNCvNAnsRDZL2GJ3aoyF+o4ygcUlFc6lFZ92SsGvPJLDey0S+MmQOUyjrMZNlAVrl9 Sr92MuMxSMgBMQ/Q06L82mOF5b0g937yVi7PAcbNUfwV/2+VpSoakTQ0o68+C/OalTgf lKVw== X-Gm-Message-State: AMke39mHmAwcYRl4hwqPDKRsdrdL39i49RqX1sqqa91/P12RFdhe93Xq7YiRM/ocxKiQFsIHE750tCfzwmLD1hnJ X-Received: by 10.223.134.52 with SMTP id 49mr3934856wrv.50.1487964143348; Fri, 24 Feb 2017 11:22:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.158.15 with HTTP; Fri, 24 Feb 2017 11:21:52 -0800 (PST) In-Reply-To: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Eran Messeri Date: Fri, 24 Feb 2017 11:21:52 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1146c03c34361305494ba632 Archived-At: Cc: "trans@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:22:27 -0000 --001a1146c03c34361305494ba632 Content-Type: text/plain; charset=UTF-8 Following up on this thread, after a few discussions about it in online & offline forums: - It is necessary to have the "Redaction reason" entry in the log to commit the log to the redaction of a particular entry and avoid allowing the log to present redacted/unredacted view at will. - A few have echoed Phillip's sentiment that once an entry is suppressed then the suppression reason can't be effectively audited for correctness. - There was a strong push-back against this mechanism on the basis that it weakens the basic properties we get from the Merkle tree right now. Potential problems: What if the "Redaction reason" entry itself was redacted? - A suggestion by Peter Bowen was to simply not serve the redacted entry: The only API method by which a suppressed entry can be obtain is 'get-entries', it's possible to return an error when the range specified includes a suppressed entry. That suffers from the same drawback of the log being able to selectively presenting redacted/unredacted view. - An approach many see as superior is to reduce the chances of having entries with undesirable content in the log by restricting the certificates that may be logged (e.g. forbidding certificates with embedded images). Eran On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker wrote: > Lets break this down. > > In what way is suppression of a previously enrolled certificate different > to not enrolling the certificate at all? > > The only ones I can see is that it means that 1) the CA is off the hook, > they fulfilled their duties and 2) the fact that suppression has occurred > is visible. > > > CT relies on there being some feedback mechanism to detect unenrolled > certs, the same would apply to suppressed certs. > > So let us imagine that a government coerces a CA to issue a bogus cert and > then coerces a notary to suppress it. What next? > > Well first off anyone who has a copy of that cert taken from the > repository before the suppression is going to hard look at it. So the > chance of people being aware of the suppression and working out the reason > for it is essentially 99%. > > > A person formerly very senior in NSA told me that the governing paradigm > post Snowden was 'NOBUS': Nobody but us. Sure they might want to perform > this type of attack if they think they can get away with it but they won't > do things that are liable to get caught. > > > > > On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie wrote: > >> On 16 November 2016 at 11:39, Paul Wouters wrote: >> > On Wed, 16 Nov 2016, Ben Laurie wrote: >> > >> > (no hats on) >> > >> >> On 16 November 2016 at 03:46, Paul Wouters wrote: >> >>> >> >>> How can I as log consumer detect the difference between the log >> removing >> >>> illegal content and the log being compelled by a government to hide a >> >>> rogue >> >>> certificate? >> >> >> >> >> >> Court orders are court orders. That issue is not in the log's domain. >> > >> > >> > It was an example. the core isuse is, how can a consumer determine the >> > log censored itself with a valid reason, versus an attack, compromise, >> > having been compelled, or for financial gain or any other invalid >> reason? >> > >> > Using a hash of a removed cert won't allow anyone to verify the reason >> > for removal. And clearly the content cannot remain their either. It's >> > a catch22. >> >> This is why the redaction reason entry exists, so that there _is_ >> something to reason about. If you (a consumer) are unconvinced by the >> reason, well, there are public fora where you can voice your concerns. >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a1146c03c34361305494ba632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up on this thread, after a few discussions about= it in online & offline forums:
- It is necessary to have the "= ;Redaction reason" entry in the log to commit the log to the redaction= of a particular entry and avoid allowing the log to present redacted/unred= acted view at will.
- A few have echoed Phillip's sentim= ent that once an entry is suppressed then the suppression reason can't = be effectively audited for correctness.
- There was a strong push= -back against this mechanism on the basis that it weakens the basic propert= ies we get from the Merkle tree right now. Potential problems: What if the = "Redaction reason" entry itself was redacted?
- A sugge= stion by Peter Bowen was to simply not serve the redacted entry: The only A= PI method by which a suppressed entry can be obtain is 'get-entries'= ;, it's possible to return an error when the range specified includes a= suppressed entry. That suffers from the same drawback of the log being abl= e to selectively presenting redacted/unredacted view.
- An = approach many see as superior is to reduce the chances of having entries wi= th undesirable content in the log by restricting the certificates that may = be logged (e.g. forbidding certificates with embedded images).
Eran

On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker <ietf= @hallambaker.com> wrote:
Lets = break this down.

In what = way is suppression of a previously enrolled certificate different to not en= rolling the certificate at all?

The only ones I can see is that it means that 1) the CA is off the h= ook, they fulfilled their duties and 2) the fact that suppression has occur= red is visible.


CT relies on there = being some feedback mechanism to detect unenrolled certs, the same would ap= ply to suppressed certs.

= So let us imagine that a government coerces a CA to issue a bogus cert and = then coerces a notary to suppress it. What next?

Well first off anyone who has a copy of that cert t= aken from the repository before the suppression is going to hard look at it= . So the chance of people being aware of the suppression and working out th= e reason for it is essentially 99%.


A person formerly very senior in NSA told me that the governing paradigm p= ost Snowden was 'NOBUS': Nobody but us. Sure they might want to per= form this type of attack if they think they can get away with it but they w= on't do things that are liable to get caught.




On Wed, Nov 16, 2016 = at 6:48 AM, Ben Laurie <benl@google.com> wrote:
On 16 November 2016 at 11:39, Paul Wouters <paul@nohats.ca> wr= ote:
> On Wed, 16 Nov 2016, Ben Laurie wrote:
>
> (no hats on)
>
>> On 16 November 2016 at 03:46, Paul Wouters <paul@nohats.ca> wrote:
>>>
>>> How can I as log consumer detect the difference between the lo= g removing
>>> illegal content and the log being compelled by a government to= hide a
>>> rogue
>>> certificate?
>>
>>
>> Court orders are court orders. That issue is not in the log's = domain.
>
>
> It was an example. the core isuse is, how can a consumer determine the=
> log censored itself with a valid reason, versus an attack, compromise,=
> having been compelled, or for financial gain or any other invalid reas= on?
>
> Using a hash of a removed cert won't allow anyone to verify the re= ason
> for removal. And clearly the content cannot remain their either. It= 9;s
> a catch22.

This is why the redaction reason entry exists, so that there _is_ something to reason about. If you (a consumer) are unconvinced by the
reason, well, there are public fora where you can voice your concerns.


_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans


--001a1146c03c34361305494ba632-- From nobody Fri Feb 24 12:00:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988C1129508 for ; Fri, 24 Feb 2017 12:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C6A3JfqlFS6o for ; Fri, 24 Feb 2017 12:00:02 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 101181294EE for ; Fri, 24 Feb 2017 12:00:02 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id k4so21154100otc.0 for ; Fri, 24 Feb 2017 12:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vu06i5WxdCZ3+cY2+L9dA7IsNC/A+Nwwb68cwknSI0w=; b=Vt6mZ0Si9KZQbcFiNQXal6KAUioxwHnEsfR7Kk3LPtLDAGETyBgHfNpAGUyM2Fhe0w RlkeEKwum31KP+nV5LqszyhDcIBfHv4Kxzee5+1/Vb8hYBIZTna3NS5Ibnq2cIYke7Ps pUx37qMTjJZFpPjhZqUdpEdU8F4ntwT5Z9Ihmf+lgp2xCtwD45Ep47DMT+VeOBNyOWf5 CoVUrY7gIfHm3AL1PLVHGArUFA9447LY+QXASdDncdRtPWd/QvQrZw8dVo7DfKvlKyDc dkNGV/TyzcHEVJUrkQAsCOaqrXN1sDq39Ls6+Ldy1sUIze9ruWnwERmowGG5kpuZttS1 InnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vu06i5WxdCZ3+cY2+L9dA7IsNC/A+Nwwb68cwknSI0w=; b=FCnrkiDNXWE8+Ee8G+ve4uunVmxB8JZDu0VmHSZqgFsnNASQg+YnZ+2+EssOQ18PjQ oY7VjS7Jabm83Flht72hsaCwkI46AGRvrfGTDsPkquhQXZI8tm8a+OioN0eKzoIBaDcZ oCenY2uebAgVxoTZBwCVcozmMFcRtwiKOXfBzOqClAwv+wwOZuCNrIs39mouUDKTzcYw FNS0NHY8pFphdp+Un2pAuDfhLElgCN8kei5FUikCrPI0JobnrsTV75sZlMpLwAuVGjsi WEGmBc48drFAbOy601LT4zNOrTOv0m8qqhgHetZwbYqrwugOJvHWggNTam4Vb/hP6SgQ Vwxg== X-Gm-Message-State: AMke39nhiqh8MVdVlnzcWVATj32jXjCN/ZwYIWaFrwK9lXgEKmlIIgmoCzyxQJQK0+x4uMVLFEETRcGeTEYreA== X-Received: by 10.157.25.14 with SMTP id j14mr2096564ota.178.1487966401370; Fri, 24 Feb 2017 12:00:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.228 with HTTP; Fri, 24 Feb 2017 12:00:00 -0800 (PST) In-Reply-To: References: <4E665C5B-BC28-428E-9BFB-626D3364E05B@nohats.ca> From: Peter Bowen Date: Fri, 24 Feb 2017 12:00:00 -0800 Message-ID: To: Eran Messeri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Laurie , Paul Wouters , Phillip Hallam-Baker , "trans@ietf.org" Subject: Re: [Trans] How to redact an entry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:00:05 -0000 On Fri, Feb 24, 2017 at 11:21 AM, Eran Messeri wrote: > Following up on this thread, after a few discussions about it in online & > offline forums: > - It is necessary to have the "Redaction reason" entry in the log to commit > the log to the redaction of a particular entry and avoid allowing the log to > present redacted/unredacted view at will. > - A few have echoed Phillip's sentiment that once an entry is suppressed > then the suppression reason can't be effectively audited for correctness. > - There was a strong push-back against this mechanism on the basis that it > weakens the basic properties we get from the Merkle tree right now. > Potential problems: What if the "Redaction reason" entry itself was > redacted? > - A suggestion by Peter Bowen was to simply not serve the redacted entry: > The only API method by which a suppressed entry can be obtain is > 'get-entries', it's possible to return an error when the range specified > includes a suppressed entry. That suffers from the same drawback of the log > being able to selectively presenting redacted/unredacted view. Another option would be to return something other than "leaf_input" and "extra_data" in the object. For example the log could return the hash of the MerkleTreeLeaf that was there along with a reference to the leaf that has the redaction reason entry. > - An approach many see as superior is to reduce the chances of having > entries with undesirable content in the log by restricting the certificates > that may be logged (e.g. forbidding certificates with embedded images). > > Eran > > On Wed, Nov 16, 2016 at 6:20 AM, Phillip Hallam-Baker > wrote: >> >> Lets break this down. >> >> In what way is suppression of a previously enrolled certificate different >> to not enrolling the certificate at all? >> >> The only ones I can see is that it means that 1) the CA is off the hook, >> they fulfilled their duties and 2) the fact that suppression has occurred is >> visible. >> >> >> CT relies on there being some feedback mechanism to detect unenrolled >> certs, the same would apply to suppressed certs. >> >> So let us imagine that a government coerces a CA to issue a bogus cert and >> then coerces a notary to suppress it. What next? >> >> Well first off anyone who has a copy of that cert taken from the >> repository before the suppression is going to hard look at it. So the chance >> of people being aware of the suppression and working out the reason for it >> is essentially 99%. >> >> >> A person formerly very senior in NSA told me that the governing paradigm >> post Snowden was 'NOBUS': Nobody but us. Sure they might want to perform >> this type of attack if they think they can get away with it but they won't >> do things that are liable to get caught. >> >> >> >> >> On Wed, Nov 16, 2016 at 6:48 AM, Ben Laurie wrote: >>> >>> On 16 November 2016 at 11:39, Paul Wouters wrote: >>> > On Wed, 16 Nov 2016, Ben Laurie wrote: >>> > >>> > (no hats on) >>> > >>> >> On 16 November 2016 at 03:46, Paul Wouters wrote: >>> >>> >>> >>> How can I as log consumer detect the difference between the log >>> >>> removing >>> >>> illegal content and the log being compelled by a government to hide a >>> >>> rogue >>> >>> certificate? >>> >> >>> >> >>> >> Court orders are court orders. That issue is not in the log's domain. >>> > >>> > >>> > It was an example. the core isuse is, how can a consumer determine the >>> > log censored itself with a valid reason, versus an attack, compromise, >>> > having been compelled, or for financial gain or any other invalid >>> > reason? >>> > >>> > Using a hash of a removed cert won't allow anyone to verify the reason >>> > for removal. And clearly the content cannot remain their either. It's >>> > a catch22. >>> >>> This is why the redaction reason entry exists, so that there _is_ >>> something to reason about. If you (a consumer) are unconvinced by the >>> reason, well, there are public fora where you can voice your concerns. >> >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans >

Start

Stop

Slot

Descrip= tion

Discussion Leader / Notes

9:00

9:15


Check-in, badging, get situ= ated in room

All

9:45


Breakfast - Continental

9:45

10:15

<= br>

Kick-Off and Check-point

Ryan Hurst

10:15

10:45

7.1

Break-Out Sessi= ons - 3

TBD*

10:45

11= :30


Break

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:12pt;font-family:arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap">All

11:30

12:30

7.2

Break-Out Sessions - 3 Pres= entations

TBD*

13:30


Lunch

=

= All

13:30

14:15

8.1

Break-Out Sessions - 4

TBD*

14:= 15

15:15<= /p>


Break

All

15:15

16:00

= 8.2=

Break-Out Sessions - 4 Presentations

TBD*

16= :00

16:30<= /p>


Coffee/Beverage Service Break

All

16:30

17:30

9

Next Steps Summary

Ryan Hurst

17:30


Adjourn

All

17:30

20:00


All