From nobody Tue Jan 10 02:26:27 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C421293DC; Tue, 10 Jan 2017 02:26:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148404398279.19743.8420299342084697330.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 02:26:22 -0800 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-gossip-04.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:26:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency of the IETF. Title : Gossiping in CT Authors : Linus Nordberg Daniel Kahn Gillmor Tom Ritter Filename : draft-ietf-trans-gossip-04.txt Pages : 57 Date : 2017-01-10 Abstract: The logs in Certificate Transparency are untrusted in the sense that the users of the system don't have to trust that they behave correctly since the behavior of a log can be verified to be correct. This document tries to solve the problem with logs presenting a "split view" of their operations. It describes three gossiping mechanisms for Certificate Transparency: SCT Feedback, STH Pollination and Trusted Auditor Relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-gossip-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-gossip-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 10 08:46:11 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 D22B5129D25 for ; Tue, 10 Jan 2017 08:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 aV8VvAwogC-P for ; Tue, 10 Jan 2017 08:46:07 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 64955129704 for ; Tue, 10 Jan 2017 08:46:07 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id k184so168744065wme.1 for ; Tue, 10 Jan 2017 08:46:07 -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=Hjz8eYE4NX8rH8moYCd9UOoKYfciqQZZ0LS5yPxIB0Q=; b=qPKO4LIKv31CMYnCVT8kEiJa9AQIfhsVihe09xx81vtfGUS8ULaM70QS/SOzq2iuPK vw0dn9ErUfM4UCs3aGf3LCmS+B4BzIoicxG3s/eMgFoizCnuGY0PIKrNXEzOunGASHfz 2lEpSGTQflV1gJ0t+g82maXhVWNARPg8+PmHvIyoCcGtMzbrj3psF2jmqsHEs2ARe7xL 9bLdmf5y/gjBoChrCsBw/wP4ll0UVWAiEJ8Yus2AbjVkSgWFuasRd5m6rOOVfXjbWrZs LOwvqWS1t05z0Def2wykS8mlbf70jwm+IQY+a3LJj3REPmYHLxQib2edhhgWlyAoCoDY WMEQ== 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=Hjz8eYE4NX8rH8moYCd9UOoKYfciqQZZ0LS5yPxIB0Q=; b=I0BQWa4gLP0DEL7FuKtwHc3YAaitVHWEGjhHvy0xygj1Cn9P7efQLKYW36SfH1yxvQ 6ObDEv3iCP2CHDtiVNNXcI9U1F0N+aFmFtitHWxwe+67vyMGD9M7wnHPcNWnF44MlRI7 zMWnI4rVIGDAWCUAPmH6qL2M4/H68KfJfYRc/pIkryL0tAX3PngEwD9wrd/E+nv6sRQx hykAtJsIl4rEROs/FJLWsrZXOn+qVU+m2JEEwEMavUvIRNSbggPRJHsQ2Sdke4wjGCzY z7Gvn9sXHgsj8YEnBwgY8pF6LFuNOr/k2ej9QH3rJuKDQydKthqIjN99xqx6BWi7Q1Bx xTUQ== X-Gm-Message-State: AIkVDXIgfsiF6F+UojvxB+UHYwD/oN58So5n03eqKbaL2uVcO19wIEf2CLUTLa15NLCUJoGmU4fkBbY/J7Q8bsRH X-Received: by 10.223.168.87 with SMTP id l81mr2562739wrc.194.1484066765625; Tue, 10 Jan 2017 08:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.207.72 with HTTP; Tue, 10 Jan 2017 08:45:35 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Tue, 10 Jan 2017 16:45:35 +0000 Message-ID: To: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Content-Type: multipart/alternative; boundary=f403045d57d06388f40545c0388b Archived-At: Subject: [Trans] Fwd: Intent to Implement: Expect-CT header 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, 10 Jan 2017 16:46:10 -0000 --f403045d57d06388f40545c0388b Content-Type: text/plain; charset=UTF-8 FYI, Chrome's intent-to-implement of the Expect-CT header. Discussion is going on in the following blink-dev thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tgn5R-58iek ---------- Forwarded message ---------- From: Emily Stark Date: Fri, Jan 6, 2017 at 8:34 PM Subject: Intent to Implement: Expect-CT header To: blink-dev *(Note: net-dev@ on bcc)* Contact emails estark@chromium.org Spec https://datatracker.ietf.org/doc/draft-stark-expect-ct/ Summary A new HTTP header that allows websites to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on their connections. By turning on Expect-CT, sites can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs. Motivation Certificate Transparency (CT) is a system that allows TLS certificates to be audited and monitored in public logs. Chrome is in the process of adopting Certificate Transparency fully, which will allow site owners to discover misissued certificates in CT logs and take action (such as revocation). However, it will be quite a while before Chrome can require CT for all certificates, meaning that site owners cannot yet get the full security benefits of CT. Expect-CT allows security-conscious site owners to opt in to CT enforcement well before CT is fully required for all certificates. (A common question is "What about Chrome's plan to require CT in October 2017? Won't Expect-CT be useless then?" In October 2017, we plan to require CT for all *new* certs, which does not protect site owners from previously issued bad certificates, or from a bad CA that issues a backdated cert, which has been known to happen.) Also note that we've had an experimental report-only version of Expect-CT on canary/dev/beta for some time now, for a limited set of sites that are on a baked-in hardcoded list. This Intent introduces an HTTP header for Expect-CT (allowing any site to opt in to the feature without being on the hardcoded list) and an enforcement mode (allowing sites to specify that they want connections to be closed, not merely reported, if they are not CT-compliant). Interoperability and Compatibility Risk *Interop*: The main interoperability risk of this feature is that it is up to the browser to decide details of CT enforcement, e.g. how many SCTs are required and from what CT logs. Thus, a certificate that satisfies the CT policy of one browser may not satisfy the CT policy of another. However, this is an interop risk of CT in general, and not specific to Expect-CT; multiple browsers are in the process of implementing CT fully and working closely together to develop CT policies that are harmonious. *Compatibility*: There is no compat risk for existing web content, since Expect-CT is an opt-in feature. Much like other opt-in security features such as HSTS and HPKP, Expect-CT presents an opportunity for a footgun, in that a site might turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a certificate that is not CT compliant, resulting in the site becoming inaccessible in Chrome until the Expect-CT configuration expires. We are minimizing this risk by supporting a reporting mode, in which a site owner will receive reports if their site becomes inaccessible due to Expect-CT. Ongoing technical constraints No Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes OWP launch tracking bug https://crbug.com/679012 Link to entry on the feature dashboard https://www.chromestatus.com/feature/5677171733430272 Requesting approval to ship? No -- You received this message because you are subscribed to the Google Groups "net-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org. To post to this group, send email to net-dev@chromium.org. To view this discussion on the web visit https://groups.google.com/a/ chromium.org/d/msgid/net-dev/CAPP_2SaT_Kq5vh26o% 3DD04TB5HOjZ3BFAMb1rX3zdffhKYtc-3w%40mail.gmail.com . --f403045d57d06388f40545c0388b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, Chrome's intent-to-implement of the Expect-CT hea= der.

Discussion is going on in the following blink-dev t= hread:

---------- Forwarded message ----------
From: Emily Stark <estark@chromium.org>
Date: Fri, Jan 6, 2017 at 8:= 34 PM
Subject: Intent to Implement: Expect-CT header
To: blink-dev &l= t;blink-dev@chromium.org><= br>

(Note: n= et-dev@ on bcc)


Contact emails

estark@chro= mium.org


Spec

https://datatracker.ietf.org/doc/draft-stark-expe= ct-ct/


Summary

A new HTTP header that allo= ws websites to instruct user agents to expect valid Signed Certificate Time= stamps (SCTs) to be served on their connections. By turning on Expect-CT, s= ites can discover misconfigurations in their Certificate Transparency deplo= yments and ensure that misissued certificates accepted by UAs are discovera= ble in Certificate Transparency logs.


Mot= ivation

Certificate Transparency=C2=A0(CT) is a system that allows TLS certi= ficates to be audited and monitored in public logs. Chrome is in the proces= s of adopting Certificate Transparency fully, which will allow site owners = to discover misissued certificates in CT logs and take action (such as revo= cation). However, it will be quite a while before Chrome can require CT for= all certificates, meaning that site owners cannot yet get the full securit= y benefits of CT. Expect-CT allows security-conscious site owners to opt in= to CT enforcement well before CT is fully required for all certificates.


(A common ques= tion is "What about Chrome's plan<= /a> to require CT in October 2017? Won't Expect-CT be useless then?&quo= t; In October 2017, we plan to require CT for all *new* certs, which does n= ot protect site owners from previously issued bad certificates, or from a b= ad CA that issues a backdated cert, which has been known to happen.)


Also note that we&#= 39;ve had an experimental report-only version of Expect-CT on canary/dev/be= ta for some time now, for a limited set of sites that are on a baked-in har= dcoded list. This Intent introduces an HTTP header for Expect-CT (allowing = any site to opt in to the feature without being on the hardcoded list) and = an enforcement mode (allowing sites to specify that they want connections t= o be closed, not merely reported, if they are not CT-compliant).


Interoperability= and Compatibility Risk

Interop: The main interoperability risk of this feature is that it is up to the = browser to decide details of CT enforcement, e.g. how many SCTs are require= d and from what CT logs. Thus, a certificate that satisfies the CT policy o= f one browser may not satisfy the CT policy of another. However, this is an= interop risk of CT in general, and not specific to Expect-CT; multiple bro= wsers are in the process of implementing CT fully and working closely toget= her to develop CT policies that are harmonious.


Compatibility: There is no compat risk for existing web content, since Expect-CT is an = opt-in feature. Much like other opt-in security features such as HSTS and H= PKP, Expect-CT presents an opportunity for a footgun, in that a site might = turn on Expect-CT, but due to misconfiguration or misunderstanding, serve a= certificate that is not CT compliant, resulting in the site becoming inacc= essible in Chrome until the Expect-CT configuration expires. We are minimiz= ing this risk by supporting a reporting mode, in which a site owner will re= ceive reports if their site becomes inaccessible due to Expect-CT.


Ongoing technical co= nstraints

No

<= br>

Will this featu= re be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS,= Android, and Android WebView)?

Yes


OWP launch tracking bug

https://crbug.com/679012


Link to entry on the = feature dashboard

https://www.chromestatus.co= m/feature/5677171733430272


Requesting approval to ship?

No=

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

--f403045d57d06388f40545c0388b-- From nobody Tue Jan 10 16:23:35 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 85E98129886 for ; Tue, 10 Jan 2017 16:23:33 -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 9fgFthNVSGXx for ; Tue, 10 Jan 2017 16:23:32 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 30D3D129889 for ; Tue, 10 Jan 2017 16:23:32 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y143so34278688pfb.0 for ; Tue, 10 Jan 2017 16:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version; bh=1NMf9qb6Czu1E0rH1kHgXpr3zzzemaZ5OuNLkME2x8w=; b=dm14cj5jnaZA5ey8mKKBsd18jFchSBC8oFhcD24OxUM441/J9A1lwIGPmN4JNR18SW U0WsMxVigZ/tTf1Qb5xJI4m+KBFUv0g2Ldw66yrQbDFj/ynco5CNAYrwfvbSzfn+F3Ph VOZDn+h+hWpusRiu9gqXCyBFFdLFQn3W+f3QyP2fk+ZyY6iqoZ1Hq+Aspwxh0N8mHOrl oKQpIU0YFPfb9DOtghaqvpjnGFB9z5si4KIeM2dK6ZzhAE75Wqzxva0FIaei3jWt7sSw tkTGFtn4PI7vshi+k06jfMvFs2Xy6TqNP9F3YbWW6I/mne7fC/9IQ/woliEdV0ktsH0d Q5hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=1NMf9qb6Czu1E0rH1kHgXpr3zzzemaZ5OuNLkME2x8w=; b=KGruGcLS9gr91RM23R5y0q4zYjdzROUduZi2xjyWZRTdt/MGDbwEnoS+avVKtQPKfb VIC185ltXNsVrPvtz0+rlIAUH6jKLMWYMrJ6q4zXwcKqBfuc/Fqx9H6FwvqjreGqfNXi sfalEWVSJT4uT/rK+00JAD34rao7rrKNUyuIQPeouesPTds2WdQNAixznLkzCrVk1GtB wWSKB/ihgZo1WAVBloEajQVuXM7Rjx5K1uIIlkyNLjfO4yeHLKSE66DdgP1bW+FFW9gv ZnfcREaBe+ErSDvaQ/eE93SDY/kfzEA4osdkFoWiB0kojxXYZDxP6NkjVwgk4+keautF m9cA== X-Gm-Message-State: AIkVDXLM0pQ6IX+En3jzj8L6V4Jj6KbYwc2RbcPmL5h+O1/ZOSwwgdYRac0R25UZ5PfdYw== X-Received: by 10.98.94.129 with SMTP id s123mr6815440pfb.37.1484094211675; Tue, 10 Jan 2017 16:23:31 -0800 (PST) Received: from Melindas-MacBook-Pro.local (209-112-217-149-radius.dynamic.acsalaska.net. [209.112.217.149]) by smtp.googlemail.com with ESMTPSA id p5sm8434348pgk.23.2017.01.10.16.23.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 16:23:30 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> Date: Tue, 10 Jan 2017 15:23:28 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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="EiQL4O0nHxGkXFqRW7NB2usPHiv7F70v6" Archived-At: Cc: Paul Wouters , Linus Nordberg Subject: [Trans] Call for adoption, draft-ietf-trans-gossip 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, 11 Jan 2017 00:23:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EiQL4O0nHxGkXFqRW7NB2usPHiv7F70v6 Content-Type: multipart/mixed; boundary="MulwWq4Eu0Fuce5KodNQOIihBUj3JhuR1"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Cc: Paul Wouters , Linus Nordberg Message-ID: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> Subject: Call for adoption, draft-ietf-trans-gossip --MulwWq4Eu0Fuce5KodNQOIihBUj3JhuR1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: Happy new year! This is a call for adoption of a deliverable on the use of gossip protocols to detect inconsistencies in CT logs. The draft in question has been updated and is available here: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ Please give the document a read and let us know if you think it's suitable for adoption as a trans working group item, and if you've got some initial thoughts on the identification of three mechanisms for specification this would be a good time to share them. This call for adoption closes on Tuesday, 24 January 2017. Many thanks, Melinda & Paul --MulwWq4Eu0Fuce5KodNQOIihBUj3JhuR1-- --EiQL4O0nHxGkXFqRW7NB2usPHiv7F70v6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdXsBAAoJELiGRpM6HoEuG70P/iRykBKr6KWH937HRCqJRkky lvGdv9S0cLoukzL8x3+ZmedTaYGJbz3uGbLMEEO67sn9e+92LFQRSgytvjbS4x06 3iCoe67FunXrWBBEvW3d8v821aD2I/V6svqcksjRre7UtQI0t7nzXogR1D6koNL/ JoTDjfnkEsExVb88R1N1BKP4CxImDNVH+pWm5hhwAoRIsVuEjjOqbOlelSx4FxwV lSnogNb3Ol4F3BPB7/HAiXT3STNDOSzdXuYgGHks9MltvLfYxYE7sxnlOt9E1oGk /INE/sSg0+bFZDK63Td/rfwPK1x7r9/tZkXTsUhqSwEVfWFhPSLLcm8tY4mk0q+I Oj51dH8HXGFrW7dHY7S5nuXtZH7L8I2w7nNEW+N47oa3lq0P4kvB+Fz0LU4L3cWU dvengMk9MfoCZ5F7moahhFEAGPuf7z0too/Hg7QWitHff+L15BNMRHcs3IsGtUqm siZZZJ7IY+ve4NUe164i3RqiVJYI2LhadfVaB+munj+EEvWUqpOeuTlkjQYeJ9Uv CBjcBSITSeuukrmx+yEuTbqVitZpVQ9fXbcGxODNkOn9tVKbi85zzNTFKqIrTF8C t5M7srookbvBI+N8bRG4aA6R7ldQIDq2yrlU1SOsUdwl3fkMQcaCMieLmkRXyrZh +Ce5Tk9WlIU0lUczbsza =33qQ -----END PGP SIGNATURE----- --EiQL4O0nHxGkXFqRW7NB2usPHiv7F70v6-- From nobody Wed Jan 11 03:50: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 2417E129E00 for ; Wed, 11 Jan 2017 03:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net 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 vVbC5WfKWgos for ; Wed, 11 Jan 2017 03:50:47 -0800 (PST) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 C0822129B5A for ; Wed, 11 Jan 2017 03:50:46 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v0BBoggF009146 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Jan 2017 12:50:42 +0100 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v0BBoceO009801 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2017 11:50:41 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1484135442; bh=h72uvWPo2PTsHSkhozoFVSnHqBsU/yvxzdSmiwyTAVI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=dip+LrCsR4qUwCNrPg2TWqnO4smiEiwKcxtk/A4QJI/X3Qi9px1BdmnkbYV1tiLQq 2Tdgj4oPRhe5q9imleiGELkfnD97CrRAIoDirePA+6oKMj9IXNTCCRW3/JnrG1P0+b 9pvITWs3ZkYKTaG7J8xUZKTIqe61yAc+/FZDrEVc= X-Footer: bm9yZHUubmV0 Received: from flogsta ([84.216.33.217]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 11 Jan 2017 12:50:37 +0100 From: Linus Nordberg To: Melinda Shore Organization: NORDUnet A/S References: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> Date: Wed, 11 Jan 2017 12:50:50 +0100 In-Reply-To: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> (Melinda Shore's message of "Tue, 10 Jan 2017 15:23:28 -0900") Message-ID: <87ziixvmqt.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aSuXOG4H - c3c519f11689 - 20170111 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-ietf-trans-gossip 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, 11 Jan 2017 11:50:54 -0000 Melinda Shore wrote Tue, 10 Jan 2017 15:23:28 -0900: > Please give the document a read and let us know if you think it's > suitable for adoption as a trans working group item, and if you've > got some initial thoughts on the identification of three mechanisms > for specification this would be a good time to share them. I think you mean last call. The draft has been adopted since long. From nobody Wed Jan 11 06:53:16 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 CEC34129EF6 for ; Wed, 11 Jan 2017 06:53:14 -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 HBemSnmRDRlO for ; Wed, 11 Jan 2017 06:53:13 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 41DF4129EEF for ; Wed, 11 Jan 2017 06:53:13 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id f144so53459745pfa.2 for ; Wed, 11 Jan 2017 06:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ikZRX3CHnormeP883sSzTDj6TrvgiJYiycwWsBcIx3U=; b=jFnvZuWzvCDBgtY6GjmLiNslEm3Kl10GsbWqBDDwuiHSIlusyn+aEv7anWi8NRzNm7 2F/j2z9+TkdLc6qlWAaDrh0xyLHxO5I2ia6CtHVFtMdQ1jJnrKS/xvv1yvZevObohl8l Ox7D8JbujUQz/1/GZWZSiopEnrrKUOgd/1dvS+g8QVn+o1CC1Q0wd6yI3TaAQZCd8Oud UYQ7yki9z95AS8rXeSSRm3PiaRGQz9y7VjOc+u7j+LvAHKMngmgpw5YmHTpW6Vgwgnlx M2NOEVBtFgnJ3aD1T4t8xcpQESgjw6tMhFAwKbNSR2BHDQp+1ppPuiDsrHNM1maxKc93 QNyQ== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ikZRX3CHnormeP883sSzTDj6TrvgiJYiycwWsBcIx3U=; b=VSwbch3IQmle7WfAHmyIBrwVzgszJMQylH5688AXkj71MFqMIE3K8wJ1Tj/kj1SAsx 36RqwJW0zLLPu3QF0pWfk/aDgcAA5om/mimEfQeyE2FmGdF4qinuKT7m5OwRXKct4VRe iP5HgUh60w/24TiMsYjmlt+JVdCHMHxiJM/93hauGjq07UiH56GCnTZzLefPmQsvETIl tfQ0sUmXYEpEUBmBTnxanH2vJ1gdCIxf4+sS7KB/3jX0/wIdZLfIjHfUaY4h94esdPB3 wlG9aM/MEJBld1XVTEK0NvOX+spID2xlopOpd58/k213SYy3lgnu/f59cUv/su1944TM /2oA== X-Gm-Message-State: AIkVDXILMFnCvYT0Tka2Ib69lfMcJnzUhFZMiljQaojyJI+YHcX4eMFzzD16wTxv2Epjrg== X-Received: by 10.98.153.20 with SMTP id d20mr11040248pfe.44.1484146392709; Wed, 11 Jan 2017 06:53:12 -0800 (PST) Received: from Melindas-MacBook-Pro.local (209-193-52-208-radius.dynamic.acsalaska.net. [209.193.52.208]) by smtp.googlemail.com with ESMTPSA id r78sm14545414pfe.55.2017.01.11.06.53.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 06:53:12 -0800 (PST) To: Linus Nordberg References: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> <87ziixvmqt.fsf@nordberg.se> From: Melinda Shore Message-ID: Date: Wed, 11 Jan 2017 05:53:09 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <87ziixvmqt.fsf@nordberg.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P7Ml9nfAjtGobP5cnAOIwUOmWTqqAi2ap" Archived-At: Cc: Paul Wouters , "trans@ietf.org" Subject: Re: [Trans] Call for adoption, draft-ietf-trans-gossip 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, 11 Jan 2017 14:53:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P7Ml9nfAjtGobP5cnAOIwUOmWTqqAi2ap Content-Type: multipart/mixed; boundary="ELG1vkV11WBI37Hc1gvlCuFai6tVc3Dsc"; protected-headers="v1" From: Melinda Shore To: Linus Nordberg Cc: "trans@ietf.org" , Paul Wouters Message-ID: Subject: Re: [Trans] Call for adoption, draft-ietf-trans-gossip References: <4487be4f-c9ca-5851-ccae-b053bf8eead8@gmail.com> <87ziixvmqt.fsf@nordberg.se> In-Reply-To: <87ziixvmqt.fsf@nordberg.se> --ELG1vkV11WBI37Hc1gvlCuFai6tVc3Dsc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Many apologies, all, for the brain poot. Melinda --ELG1vkV11WBI37Hc1gvlCuFai6tVc3Dsc-- --P7Ml9nfAjtGobP5cnAOIwUOmWTqqAi2ap Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdkbWAAoJELiGRpM6HoEu0NAP/1eUGh/5PBl8ozoQWdK/kKAl Tqau4ppVh5yuEALLHzzGx/OXeF3yGo7kiCjuT0JklgI0vnuU+QWZdzechcocw/sT 3bupcmaJWL1sVGY+nVZ+x9TRM289e7mfZ1P34iz4IW/m3DObNd6km4o2HkF8grwk VZfyDHl0DDCRZgvulumYebtZWNSDnFD/l0NpgZhkmr82hNuQMykUWzVaGGU8wMWF 5Wi+u5XYiiYIJOIxAmh97Z3oAPZxX1taDb8RTgxDTGPXguuG3r9hYX8ijyouTfhe 4R7nVtIaP7XBe+BdSHE8Xfmpp58KEkuYZadF/Ggz7uEfmQQrgHURyjWRF4KX9pRe djbd1ahY/+MDBPA2VEHiybU6HpT+VvURLsvGzAS0nXw3ZnJ4FEkImz601nG+kYCe VyLJBBAwhuGWNHrGBnEZ6rX+nybLOWPiZAEZis0CrSDfjJNWoxQvhIIQDfXo29JH 9dH3doWjJB8EuDLni0ZvNiydVN+JmCUQIauIl2y3arnkWpusexF8WGKQP8Tbont2 kUHCsJR32cPJ+/RJtGAhYENJXjb9IrvNxcaD3NdphU08nT0/Wqdh2U/qlVdNCKIU fba3bzsW6qaTzHcRjT3EmkjYHNBZ7ic3O89PRmpB9QCC6Z0kU9z+IQZehoCxBjkg HdJDd56+JaGAtAbFUuEL =FREx -----END PGP SIGNATURE----- --P7Ml9nfAjtGobP5cnAOIwUOmWTqqAi2ap-- From nobody Wed Jan 11 06:55:54 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 1F058129C93 for ; Wed, 11 Jan 2017 06:55:53 -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 KHCmXRiDxj3J for ; Wed, 11 Jan 2017 06:55:52 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 05CCE129C92 for ; Wed, 11 Jan 2017 06:55:52 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 204so28860673pge.0 for ; Wed, 11 Jan 2017 06:55:51 -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=vxPj7wORP7mbl91s8vo5wb95kaT/0C/Ww6oYMFa0W98=; b=tjsi9Go8j4fy4+HCnPDYLu5LTliRzYHyaStyYTr1r+IRqHljXnj/sV3uebi8oNDU3z 7ZEAZLvbMBPmlAdtMwcTXCIhzL30Uf3gbjG8tAAndQIzyja2poqPjNajUxmHWo0E71J6 fktj9xSwxF/xe9wl6ISbyJI8MXYlSBxUlwJWu8BSFKz9Its6qHJzc6pCRLC0y4VSEhr7 3Fs3lZ5NeZ5jXl2ae3vcIGvlrK64mhlH5EaWdlu7wdMhqjG/dfNsedYEgZeHNX7hBU8f oIjFp5dE4OLYA0kxtJ8CO4y4bDK0wWc55xHQwgYKZhmcoqtz58rQ3POlUBZY4fOSFio7 XVYA== 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=vxPj7wORP7mbl91s8vo5wb95kaT/0C/Ww6oYMFa0W98=; b=oKbOKUoJyv5O2v+Xlq+kvS+gL17524Uw7Aq1GPcK5LcX1ijC4Lr55PulWwMe5H2GLS ge63P4ZJDXv8Jk6oBRQ+0QSrNYW3evzZwjsssfhqFlg3b4tnTENLbNlUrmVermDo+IBo zA5AvGYwZ7ptdeo7wOj7ITt4jgdENbq7h1aJMrc0f3dRESeqh6MI10ijwnBGRjl+9Rit Ts6+fyXfWIR+gedd/v4/V9GInBfCTV6CrZx7xwqHJ2NlfKkl+mnk9d1D61orZTt6blb/ 7Cn/OzdFgY1yzs/isFn04GsRsYPBGCsilTP59WxMxwGUp/g/3riiJcLGnQZ18EyGpOrx LTwQ== X-Gm-Message-State: AIkVDXJZ0qm2yC9HbEL4IWsd+E0ORYYjCuRirb01eo//EUHCAWG4d3dRfoO96fikcaIicQ== X-Received: by 10.99.140.28 with SMTP id m28mr11114690pgd.174.1484146551302; Wed, 11 Jan 2017 06:55:51 -0800 (PST) Received: from Melindas-MacBook-Pro.local (209-193-52-208-radius.dynamic.acsalaska.net. [209.193.52.208]) by smtp.googlemail.com with ESMTPSA id z9sm2975420pfg.86.2017.01.11.06.55.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 06:55:50 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> Date: Wed, 11 Jan 2017 05:55:49 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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="VPiPgR4uAxBCHSKXWfGiKpcD1St7hes13" Archived-At: Subject: [Trans] Working group last call, draft-ietf-trans-gossip 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, 11 Jan 2017 14:55:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VPiPgR4uAxBCHSKXWfGiKpcD1St7hes13 Content-Type: multipart/mixed; boundary="xlXL6jvPIS8wHcRG0VRfi0MJRa0oqothm"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> Subject: Working group last call, draft-ietf-trans-gossip --xlXL6jvPIS8wHcRG0VRfi0MJRa0oqothm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: Many apologies for the previous thinko. The gossip draft is obviously not up for adoption, but for working group last call. Please give it a serious read and let us know whether or not you feel it is ready to be moved along to the IESG for review and ultimately for publication. Working group last call will close on Wednesday, 1 February. The URL for the draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ Melinda & Paul --xlXL6jvPIS8wHcRG0VRfi0MJRa0oqothm-- --VPiPgR4uAxBCHSKXWfGiKpcD1St7hes13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYdkd1AAoJELiGRpM6HoEu6y4QAMXLBiXJRIg76UgXrZSUtABA Ew7aY3mrucFIM3TAalfx+cXYcGLNI51DahNYqkSUz7rqsjY5dhcFXR1w5f3Ee698 1FluUC0JtOKbE2dAbEsNvZtyh4eqVUYMO8I1Yj1aA0XU+dP6bV8yg0JR0aoeVFWD QPZhroAgH41ZIb6so+Ef9kcrGiR1Ut4fb5PzFkd33tsR4w4xBAYltIZ9RBzZVc3J 9/uZLhTukWjH6SUrNU3iHzWKZGZy9I2nkL6O82V0PD8iPJhUbE0JmJMUMXpBW02l 1bOZmv344rFLT8AePRRYHFXzObio1/VUIDOgcQgdlPd+0Sm6FfJNJzWVTZ4Uy1Ss I15Wmd+9ySOw3v++SK5Kt0qhjsf0jdW+DNUMFP4+IvXunr5GDv1skmAaR+sWNVrU DFwd90MxlVdsy5XA9pTvGEfLL+W1UXr/aDIMYacxHcb+753/h7VforlooydTiHU0 JKraTJJhsLcZax/vgubvLteDJuux+gQgMM8XwNmDV6oa8XhewmIg62lIYFTgXqQN wEpMG9bP6SBKpPM1mh1Tj5M5DcJlIILdW7f0Ukf8bE3iyqldXkVKTtuJrkQIf1J1 aBRrnjLhYIYkhTAxJvQ/g0jkUo3b0YibP5PLp9Kp82uS3FBmoc0k+g0FDAIIOwT5 uyyfVv5ypdPedyoqEtF8 =PWDd -----END PGP SIGNATURE----- --VPiPgR4uAxBCHSKXWfGiKpcD1St7hes13-- From nobody Thu Jan 12 06:41:01 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 9F142129457 for ; Thu, 12 Jan 2017 06:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 zWoKA9k3QHg7 for ; Thu, 12 Jan 2017 06:40:58 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 AFD4A1293EB for ; Thu, 12 Jan 2017 06:40:57 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r144so23045954wme.1 for ; Thu, 12 Jan 2017 06:40:57 -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:cc; bh=bIh650P8xsBrieNyChnLClo/+ICxngq+eIFUaXANf14=; b=lfuK4nqFZZOAjZfSs1dowicyGFkZbBNbCdbSpVeX/SKpV2QMDTALIvKHhEMVjdzNmQ +P8DOkGAD55TlwZ22NTuBC4CC5l8VyHp8mfGmR7+dSdi2o5kMbyXIxccZMI/2sN7o01/ t+j+aP6r1mMQKHlPGy/8IKkiuQ3RwU8XOSd1rQGUmaAnEjGtiJGNqsHF6sjsagh7VZRb X43cFcBtMrShpoh5gyIhORt6udA5GppkFnqldnr5DLtEJyz6SEl9RXa8xnmvG9fAtFR9 wLWT2r8eaA0iTnpdAAXPsI1VooMRQluIujPfYSW4bglaJA/TSh4MK4Re/bGXzr63jmJZ X+dw== 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:cc; bh=bIh650P8xsBrieNyChnLClo/+ICxngq+eIFUaXANf14=; b=ZaqQh25YnqfzHLKxv71Ubv/L9Sibdxoqq9IFgAElaoQgBhClPztx/EvmLFtGzjSV4Q sWdIMOHDtc9f7Q/r8wCicjI/ZN0AI18IEEzqVy+q58wvnysmhIca4Y1jdNPfFaVxQLVH r+BpjaV3xIGm41WfOmzQEydihfRzhV5HItjkVViBGcIwEMRSghPZVN+bd8K38hcG9glV IC1+GA0v/V0oS8wAj1Vwgo6kXQc3P687pplMk6UsXrHyR2VDrJ/6yH3jl2+TJpB0envV DfszRGICe6g9mLtKJQds+doUbis0leFCloG10RqsvX2KjL80+kYs4mw+O10mkyn5Wpa+ UJ/w== X-Gm-Message-State: AIkVDXKvFiPd2ZULbFOVFMXkQ7sRwjaFBC0iv9IrVI4Ei/ki/xu1jqbK1dJO5AWsKwDI80RRUX34Fj38lcRwq4HK X-Received: by 10.28.214.137 with SMTP id n131mr5078678wmg.120.1484232055692; Thu, 12 Jan 2017 06:40:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.207.72 with HTTP; Thu, 12 Jan 2017 06:40:25 -0800 (PST) From: Eran Messeri Date: Thu, 12 Jan 2017 14:40:25 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a1146724871f9790545e6b48a Archived-At: Cc: "certificate-transparency@googlegroups.com" Subject: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 14:40:59 -0000 --001a1146724871f9790545e6b48a Content-Type: text/plain; charset=UTF-8 All, We're soliciting feedback on the privacy implications of using the DNS-based protocol for obtaining inclusion proofs from mirrors of CT logs (link to protocol description ). I've attempted a privacy analysis, together with Daniel Kahn-Gillmor, Sara Dickinson, Melinda Shore, in the following document: https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/view The goal is to get community feedback on the correctness and completeness of the analysis, so that the privacy implications aspect of the protocol is publicly reasoned about and documented, and each CT client (in particular User Agents) could make an informed choice on implementing the protocol. Please comment on the trans IETF mailing list, not the document itself. Thanks, Eran --001a1146724871f9790545e6b48a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

We're soliciting feedback on t= he privacy implications of using the DNS-based protocol for obtaining inclu= sion proofs from mirrors of CT logs (link to = protocol description).

I've attempted a pr= ivacy analysis, together with=C2=A0Daniel Kahn-Gillmor, Sara Dickinson, Mel= inda Shore, in the following document:

The goal is to get community feedbac= k on the correctness and completeness of the analysis, so that the privacy = implications aspect of the protocol is publicly reasoned about and document= ed, and each CT client (in particular User Agents) could make an informed c= hoice on implementing the protocol.

Please comment= on the trans IETF mailing list, not the document itself.

Thanks,
Eran

--001a1146724871f9790545e6b48a-- From nobody Thu Jan 12 09:42:17 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 D42891294D2 for ; Thu, 12 Jan 2017 09:42:16 -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 hdN28_oUOk0K for ; Thu, 12 Jan 2017 09:42:15 -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 5BBD3129408 for ; Thu, 12 Jan 2017 09:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1484242934; bh=RwubHFr9XTl2TTwUFjajFU4WdczF4H/Xb4IOSAqm/AQ=; h=Date:From:To:Subject:In-Reply-To:References; b=f03d98nCwGXRr0D+86GDD0jiX0u6LMaTzVsIwmhFjIk0M3EEZkTDUxthMspipELpw J7PMaVAFY6ufPnuZkjZ7VAMgkKYtaDyej7lFZrcitEuxkJlfn+3sgtqAyiYdOhJhHI 6KFr2Am+kZBMV0VgFUpuMag+HixtVgB3Lk8Cm/j4iocqouo8TkWLt2Z/u6cHD+gHh9 +TrzwbURw1dUuYfioLQRDH6lAwSLo2Cxz2e+RI91Rdopmg6Gv+jKqQsNUQnCf1xsWQ t1AEDF8GZ64uViNUrC0rmpdba1LvRPvmcloSxbFHs33qXbusVO6onvQySvPhQ+LG+6 MriDMso3FIMUA== Date: Thu, 12 Jan 2017 09:42:14 -0800 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 17:42:17 -0000 I. Under the "Certificates for hosts whose address was not obtained via DNS lookup" section, a few scenarios come to mind: 1. The host was accessed by IP address. 2. The hostname was resolved by a SOCKS proxy server. 3. The hostname was resolved using DNS, but the local resolver forwarded the query directly to a local authoritative server instead of recurring via the root. This scenario is probably quite common in corporate networks. II. Another privacy consideration is that the log DNS frontend learns the IP address of the recursive server, which in some cases may uniquely identify a person. This is not an issue if the recursive server is shared between many people, as a large ISP's would be, but what about folks running their own recursive servers? Some home routers run a DNS server - are they recursive or just forwarding? Even if a recursive server is shared, if it's not shared with enough people, it may be possible to identify a person by correlating requests made at around the same time. I think more data is needed before concluding that this approach provides the desired privacy. Could Chrome run an experiment which resolves a DNS record for a hostname of the form ., and measure how many different es per recursive server are observed over various time periods by the authoritative servers for ? Regards, Andrew From nobody Thu Jan 12 10:03:33 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 3C4DA129447 for ; Thu, 12 Jan 2017 10:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 oTYXu4HIWEI9 for ; Thu, 12 Jan 2017 10:03:30 -0800 (PST) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B625129421 for ; Thu, 12 Jan 2017 10:03:30 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by hapkido.dreamhost.com (Postfix) with ESMTP id 23052DF6CE for ; Thu, 12 Jan 2017 10:03:30 -0800 (PST) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 106AA1406B24 for ; Thu, 12 Jan 2017 09:58:09 -0800 (PST) Received: by mail-lf0-f54.google.com with SMTP id k86so19087445lfi.0 for ; Thu, 12 Jan 2017 09:58:08 -0800 (PST) X-Gm-Message-State: AIkVDXJnqPZIhJRtxdPZM1JF/YMU+db8535Nxhd9R5BJK/DT+NDyfzpAK/qP1HCsVrGPgzLjajNtcET86sz7qA== X-Received: by 10.25.56.80 with SMTP id d16mr6063748lfj.2.1484243886604; Thu, 12 Jan 2017 09:58:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.31.12 with HTTP; Thu, 12 Jan 2017 09:58:05 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 12 Jan 2017 09:58:05 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Eran Messeri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 18:03:32 -0000 (Removing cross-posting) As a minor quibble, and for sake of distinction, the W3C Resource Hints ( https://w3c.github.io/resource-hints/#resource-hints ) that describes how browsers perform things like preconnect and prefetch makes efforts to distinguish between "dns prefetch", "preconnect", and "prefetch" - each representing different parts of the connection establishment and resource fetch. If your goal is to contextualize it in the context of user agents, then it may help to note the differences. It's also unclear whether you're looking to do the privacy analysis solely in the context of the proposal, or considering it's integrated nature. I highlight this both because of specs like http://wicg.github.io/reporting/ (which also involve queues and thus the cross-resolver issues), Service Workers ( https://w3c.github.io/ServiceWorker/ ) which can enqueue things, and more holistically, the implications of documents such as http://www.chromium.org/Home/chromium-security/client-identification-mechanisms On Thu, Jan 12, 2017 at 6:40 AM, Eran Messeri wrote: > All, > > We're soliciting feedback on the privacy implications of using the DNS-based > protocol for obtaining inclusion proofs from mirrors of CT logs (link to > protocol description). > > I've attempted a privacy analysis, together with Daniel Kahn-Gillmor, Sara > Dickinson, Melinda Shore, in the following document: > https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/view > > The goal is to get community feedback on the correctness and completeness of > the analysis, so that the privacy implications aspect of the protocol is > publicly reasoned about and documented, and each CT client (in particular > User Agents) could make an informed choice on implementing the protocol. > > Please comment on the trans IETF mailing list, not the document itself. > > Thanks, > Eran > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Thu Jan 12 10:48:36 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 61F4B1294F4 for ; Thu, 12 Jan 2017 10:48:34 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 nbbdQW_qFQ0H for ; Thu, 12 Jan 2017 10:48:32 -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 71FAA1294C5 for ; Thu, 12 Jan 2017 10:48:31 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so30210385qki.2 for ; Thu, 12 Jan 2017 10:48:31 -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; bh=NPuXoaJImwHaKjzpMF/n8TFZgLMmE+VHJgotr5F+Q9E=; b=UtF4jS/MQ0bHaj3Upa9EiNB3aw7smUI3CR6tHmzqgA8ws6C8A5czSvKGXE6NP1RZCV YgkR/8OZWQReUvIGeuUBga+dvAQt1glUXi+uM50wXmK85DXtgmBaIr7GTQ+TLFG2KI5M uB40yq4Q26xfCqD0n1HvM9YRmDbbLVZ6vY+pk= 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=NPuXoaJImwHaKjzpMF/n8TFZgLMmE+VHJgotr5F+Q9E=; b=Fst/PUWqZzWmvOQg70ebjYDj0VzuRJpHDEgtVUHNoxFZXAl+UIycmw1Ck3rjbpTMOf u3zElSJbCcJr0sw0tvWtvoqvNhhDrPKRTwq0wIs3YirWEbnrZcQurXq+Zh2m0pp5xEua ZwUBAmleFisu/QHbZu+WYzJgPe+JlQeaFt+IS4I7dbl0x9rmhuzTiEbQKcRr+qCOvHCH uKC2JQ1loWYO8S6C/9pe41PNguExtf6jT2yehr309H7rTXEqw1TVh26ywYJ/GZ5ExbOj rSEPqRsKAdbwJnlLdQpWsC2yYXbtil+JauPB4ty6x0YXXvOryO7OSvLU60wjretyT/Xu J++Q== X-Gm-Message-State: AIkVDXKNcRsUxSLVbaHnATuyGHMt8SRxgVE+jYbu4SSqB1JfvkexySZJAOrIndtKNZrPZVx/Yb+x9FmsHf7/T2dq X-Received: by 10.55.138.4 with SMTP id m4mr16396158qkd.70.1484246910062; Thu, 12 Jan 2017 10:48:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.99.73 with HTTP; Thu, 12 Jan 2017 10:48:09 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Thu, 12 Jan 2017 12:48:09 -0600 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 18:48:34 -0000 On 12 January 2017 at 08:40, 'Eran Messeri' via certificate-transparency wrote: > All, > > We're soliciting feedback on the privacy implications of using the DNS-based > protocol for obtaining inclusion proofs from mirrors of CT logs (link to > protocol description). > > I've attempted a privacy analysis, together with Daniel Kahn-Gillmor, Sara > Dickinson, Melinda Shore, in the following document: > https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/view > > The goal is to get community feedback on the correctness and completeness of > the analysis, so that the privacy implications aspect of the protocol is > publicly reasoned about and documented, and each CT client (in particular > User Agents) could make an informed choice on implementing the protocol. > > Please comment on the trans IETF mailing list, not the document itself. Awesome, thanks for this Eran! I can think of a few things that are probably worth adding. I second Andrew's comments about uniquely identifying a user (although user clustering, especially with businesses seems even more likely and similarly problematic.) It seems like query clustering (by resolver) is possible - similar to visited hosts vs resolved hosts the DNS operator can make inferences about which queries from a resolver come from the same client. (I'm not sure this is terribly useful, the most reliable attack I could imagine is traffic confirmation like "They visited besthomesinseattle.com and then 221springstseattle.com".) -tom From nobody Thu Jan 12 12:38:37 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 6C1B5129451 for ; Thu, 12 Jan 2017 12:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable 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 xFUXER4hlLbr for ; Thu, 12 Jan 2017 12:38:34 -0800 (PST) Received: from homiemail-a32.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 6215D129459 for ; Thu, 12 Jan 2017 12:32:57 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id F2D466001106 for ; Thu, 12 Jan 2017 12:32:56 -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=/APDATeYf6uihc+3EhlivsG6LHs=; b= AqPmHXAty5CZi4bQN//vJ3iIfWJ39N5h4+P9ARhcu++JVuTWK57k/ZXIxhNKSRgl TdEw/Sq5D0nBEyGJoYU9OcZrpMNnduInMA3ph+4ScZI8/V6pReXGso6bNhQS/wL1 wyYv/XATSa/QCGOtNPJnFaol8vAGCfziTlF75RyuMpM= Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id B9DBD6001105 for ; Thu, 12 Jan 2017 12:32:56 -0800 (PST) Received: by mail-lf0-f47.google.com with SMTP id k86so22211848lfi.0 for ; Thu, 12 Jan 2017 12:32:56 -0800 (PST) X-Gm-Message-State: AIkVDXLcK9lkxmzinfpsGD0RlTzHt52n4JxmFvOKGFcdwySDr34e2NJPEmA4eR8QIraFsK/Q6VqiSLDPbtPNkg== X-Received: by 10.46.83.19 with SMTP id h19mr220795ljb.72.1484253175054; Thu, 12 Jan 2017 12:32:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.31.12 with HTTP; Thu, 12 Jan 2017 12:32:54 -0800 (PST) In-Reply-To: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> References: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> From: Ryan Sleevi Date: Thu, 12 Jan 2017 12:32:54 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Ayer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 20:38:35 -0000 On Thu, Jan 12, 2017 at 9:42 AM, Andrew Ayer wrote: > I. Under the "Certificates for hosts whose address was not obtained via > DNS lookup" section, a few scenarios come to mind: > > 1. The host was accessed by IP address. To expand on this: Your assumption/model here is that the DNS resolver learns this information, but they are not otherwise on-path, correct? That is, imagine a user using a resolver of 8.8.8.8 - presumably, Google's not malicious, but this would disclose to them IP-based connections? > 2. The hostname was resolved by a SOCKS proxy server. This is only relevant to clients that support SOCKSv5-based resolutions, right? And is this just a specialized form of "using a different resolver"? Or do you think it's distinct? > I think more data is needed before concluding that this > approach provides the desired privacy. Could Chrome run an > experiment which resolves a DNS record for a hostname of the form > ., and measure how many > different es per recursive server are > observed over various time periods by the authoritative servers > for ? In expanding on your hypothetical test, what's the outcome or desired property that you're trying to measure? I imagine a total number of distinct IPs is itself not meaningful to such an analysis. From nobody Thu Jan 12 14:29:20 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 EFF64129514 for ; Thu, 12 Jan 2017 14:29:18 -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 9CTZygi8EEv6 for ; Thu, 12 Jan 2017 14:29:15 -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 B1FC212954F for ; Thu, 12 Jan 2017 14:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1484260121; bh=howRfkFDINyFFTiKFvJpGHSPhAPJg6yc2ghM8pTpB1g=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=rBD3w5l0F3KxJxlU82soEZx/IWXKK3Qc7zA8ZXAsOjJFqSijwlxVT7F3Q88kSyzKG BE1+PcsX60kvYS0pjekfKTJq4KGm+712WXvneJ63MvfZGdma3tK5PDPpjJZ/d3Nhst g8b6YhSFMZaCp0hdW5l1Vvfjrx1dGQFKw8OI1SFxlDhTfMCO4NRWMgQvUroCj9zdYp lW96PEasn54OLKRuAuxogr1IUJow0si5RZ6DwpnDUapLCJ07iYAH3yR3iXQtHCjPZD hRiJo7QgheDGhNVHOXwizwP3bT2SJNDNggOf45fuV053Dro9oCG1+FQg6HOYTgTmJ5 EWuv0KfQhwU5g== Date: Thu, 12 Jan 2017 14:28:40 -0800 From: Andrew Ayer To: Ryan Sleevi Message-Id: <20170112142840.8c95f645172301b0facfc29c@andrewayer.name> In-Reply-To: References: <20170112094214.5dbc6247f77535d91dc9fd0a@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] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 12 Jan 2017 22:29:19 -0000 On Thu, 12 Jan 2017 12:32:54 -0800 Ryan Sleevi wrote: > On Thu, Jan 12, 2017 at 9:42 AM, Andrew Ayer > wrote: > > I. Under the "Certificates for hosts whose address was not obtained > > via DNS lookup" section, a few scenarios come to mind: > > > > 1. The host was accessed by IP address. > > To expand on this: Your assumption/model here is that the DNS resolver > learns this information, but they are not otherwise on-path, correct? > That is, imagine a user using a resolver of 8.8.8.8 - presumably, > Google's not malicious, but this would disclose to them IP-based > connections? It would disclose the IP-based connection to the resolver, the log's DNS frontend, and any eavesdropper along the path taken by the DNS query. Normally when you initiate a connection based on IP address, no one learns about it except for nodes along the path to the endpoint (assuming no OCSP), and that path might not even traverse the public Internet. > > 2. The hostname was resolved by a SOCKS proxy server. > > This is only relevant to clients that support SOCKSv5-based > resolutions, right? Also clients that support SOCKS4a. > And is this just a specialized form of "using a > different resolver"? Or do you think it's distinct? It could be seen as a specialized form of using a different resolver. (To be pedantic, the hostname lookup is not performed by the UA and the SOCKS server might not even use DNS, which is why it seemed to fit better in the "not obtained via DNS" category.) > > I think more data is needed before concluding that this > > approach provides the desired privacy. Could Chrome run an > > experiment which resolves a DNS record for a hostname of the form > > ., and measure how many > > different es per recursive server are > > observed over various time periods by the authoritative servers > > for ? > > In expanding on your hypothetical test, what's the outcome or desired > property that you're trying to measure? I imagine a total number of > distinct IPs is itself not meaningful to such an analysis. We would want to know the number of distinct es per DNS resolver IP address that sends a DNS query for . The desired property is that this number is high for most DNS resolvers, as this indicates that there is privacy value to using DNS instead of fetching inclusion proofs directly from logs. Regards, Andrew From nobody Mon Jan 16 14:23:33 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 F22ED1296FB for ; Mon, 16 Jan 2017 14:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 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_SBL=1.623, URIBL_SBL_A=0.1] autolearn=no 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 OX-kibKDu767 for ; Mon, 16 Jan 2017 14:23:30 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 C5FAF1296E8 for ; Mon, 16 Jan 2017 14:23:29 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id y9so91139676uae.2 for ; Mon, 16 Jan 2017 14:23:29 -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:cc; bh=15EHcqs90Kcn/KD5NJHIgp2H/NBXHu3nNZnaYLf+jn4=; b=HEExJabaj/aCqTvopHBjIr38Vv2yiuiDLjT5gxFSLp0hkdWDPT8pMxjoT5oC883Z8S 3jpok2z6qWcbtNxQC+aCDzEFsOQOHb6IqAWdwcj0C84rRhhMjvSf9ja2+gYx/TEcOJWk NkMc2vM3Aa9mg7NJNhNSRvgfdK1tbKdv0NDTp7tuPYLTT1S94kK8S0MmKT6JWQVX5PCP Wvy8W7vgjz7zD0Jttgsn+bNmv330ffnt+wzcGJRWP+Ukr/iRZancr0IkzjfTuBXgbDgU ylJqOnXlxWRXFLfCBl9SdIvEpo6VYBI/f+JDiAEmGbWzYYhkJXp4XTGUuio9Ek9zSBzv tMLA== 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:cc; bh=15EHcqs90Kcn/KD5NJHIgp2H/NBXHu3nNZnaYLf+jn4=; b=L25MXcxvhN1O8b+kydLOJu8KWxks+X1gRXTMiUG6K99K0kaEELhYOORNzGNjV/9p1P AuOa0QCKQYaMzpGimG+f1/RT7409mZCIxyy9+Oo6qoXFhtS0A75l5pJGsGAz++eSFZBu 8U/b9uAYJEcYQbfp33ydNhTZRALgDIHAEQweOuKrVHFrcsyDQYqZxY/TDg/vZ+cv6TOX cTtFdu+5Lgij5avYYPf0MbHDlBggGgqk4FojZGYmJOz6bLl1FhuJHP8yqjjHlmjByN/w rTl2CvaQQxAAYuCCrlPt+rCiNAV7JsZkRA13RU+41mOY8XxM6m0G9knIquOEqVkCr35u EILQ== X-Gm-Message-State: AIkVDXKLtRuZIxZYLwK5A54HXfiMMyud4QH7TPa71sbPJ4QYGQGgXNqWMFUWYyLpRLdYm6oviF85fpo3QXZZ5g== X-Received: by 10.159.48.131 with SMTP id j3mr7524469uab.42.1484605408326; Mon, 16 Jan 2017 14:23:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Mon, 16 Jan 2017 14:23:27 -0800 (PST) From: Richard Barnes Date: Mon, 16 Jan 2017 17:23:27 -0500 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary=f403045e3510fee8c205463da1f4 Archived-At: Cc: Eric Rescorla Subject: [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: Mon, 16 Jan 2017 22:23:32 -0000 --f403045e3510fee8c205463da1f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey all, Sorry I=E2=80=99ve missed the WGLC deadline. I wanted to summarize for thi= s list some discussions that have been going on within the Firefox team. Basically, we=E2=80=99ve started to look at what it would take to deploy CT= inside of Firefox (including code, policy, etc), and come away with some concerns that the system as currently specified can=E2=80=99t be deployed in a way t= hat actually provides the desired guarantees, in particular protection against equivocation by logs. For what it=E2=80=99s worth, these comments apply ro= ughly equally to RFC 6962 and 6962bis. tl;dr: - It is not practical to build a publicly verifiable log system that incorporates SCTs - The existing tools for public verifiability need to be made more efficient in order to work on the scale envisioned I recognize that it=E2=80=99s very late in the day to be raising these issu= es, but we believe they go to the heart of the value proposition of CT and so it=E2= =80=99s important they be addressed before 6962bis goes to RFC. I speak for both myself and my colleagues here at Mozilla in saying that we are more than willing to put in the time to help get to consensus on these topics. Details below. Thanks, --Richard =3D=3D=3D Fundamentally, CT is a public ledger system: every certificate is supposed to be entered into a log and RPs only accept certificates which are logged. In order for this to work properly, RPs need to be able to verify that there is public consensus about the state of the log. Otherwise, logs can =E2=80=9Cequivocate=E2=80=9D: represent to the RP that a given certificate = was published when it in fact was not. Unfortunately, in practice RPs are not doing this verification (for reasons discussed below), and so CT reduces to a countersignature scheme in which the RP trusts the log not to equivocate. There are two primary challenges here, as detailed below. # SCTs, and thus immediate issuance, are incompatible with public verifiability It has been known for quite some time that the public verifiability piece of CT introduces latency in certificate issuance. In order to allow for immediate certificate issuance, logs instead issue SCTs, which are just promises to incorporate the certificate into the log; effectively the SCT is a countersignature on the certificate. However, if an RP accepts a certificate + SCT, then it is vulnerable to collusion between a CA which issues a bogus cert and a log which issues a bogus SCT but never incorporates the cert into the log. We are unaware of any way to efficiently address this issue without introducing either privacy problems or latency. In order to validate inclusion in the log, the RP needs to validate that other entities (e.g., the software manufacturer) have the same view of the log. Either the RP downloads the whole log (which is inefficient), queries for the specific certificate in question (which has privacy problems) or retrieves a checkpoint which vouches for some batch of certificates (which introduces batch latency). There seem to be two major ways to address this issue: 1. Accept issuance latency: An RP will only accept a cert as valid when accompanied by proof that it has been incorporated into the public record 2. Accept some window of vulnerability to equivocation during which SCTs are accepted and then retrospectively checked. The RP would provisionally accept a certificate that claimed to have been very recently issued and then check for log presence a few minutes later (once an inclusion proof should be available) Unfortunately, there=E2=80=99s not really an effective way to accomplish th= e latter with high reliability and without bad privacy problems. Going back to the server and asking for an inclusion proof is safe from a privacy perspective, but there=E2=80=99s a significant risk of failure given how of= ten servers are multi-homed. And asking anyone but the server leaks browsing history. It=E2=80=99s theoretically possible that some private information retrieval scheme could save us, but that would be a big new chunk of work, and unlikely to deploy in the near term. Note that it is not possible to just not require public verifiability for certificates which claim to be recently issued; because this attack depends on the log and the CA colluding, they can just issue certificates with recent timestamps. # CT=E2=80=99s public verifiability mechanisms are too inefficient to be de= ployed at scale If this WG is going to meet its charter goals, CT needs to have a working public verifiability system. What that means in practice is that it=E2=80= =99s efficient for the RP to acquire whatever information it needs to validate that a certificate is in the public record. In the current system, this basically means: - Acquire an inclusion proof [hopefully provided by the site the RP is connecting to]. - Acquire the STH that the inclusion proof chains back to and validate that the STH was publicly logged. 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). So, what this means is that the RP needs to periodically retrieve: - All the STHs that any certificate might chain to - The consistency proofs between those STHs The good news is that if the RP does this, then it will be in a position to verify that any certificate with an inclusion proof has been publicly logged; it will be protected from equivocation. The bad news is that this scheme generates so much data it cannot be deployed. To get an idea of scale here, I looked all of the submissions to the Google Pilot log over December 2016. Let=E2=80=99s assume that the log creates a = new STH for every 2048 certificates it receives, in order to minimize issuance latency; it takes around 8 minutes for Pilot to get 2048 certificates, on average. At this rate, Pilot produces around 6000 STHs per month. The good news is that at this rate, an RP can easily store all of the STHs it needs, around ~192kB of hashes per month, ~2.3MB per year. The bad news is that the RP has to download an inordinate amount of information to verify these STHs. In addition to the STHs themselves, it will need to download around 6000 consistency proofs over the course of a month. Each proof is around 20 hashes, so at the end of the day this is ~125k hashes (4MB of data) that an RP has to download every month, 48MB for the year. That=E2=80=99s a pretty big chunk of data. There are no doubt several plausible alternative data structures, but just to give a sense of what=E2=80=99s possible, consider the following design: = Replace the global Merkle tree with a series of time-windowed trees, one for each batch. Then glue these together with a conventional Haber-Stornetta hash chain. (See my cartoon at ) This has the same number of STHs as the design above but because the consistency proofs are trivial (you just validate that STH_n includes the hash of STH_{n-1}), the total download size for the month is just ~6k hashes (192kB of data). This scheme also saves you a few bytes on inclusion proofs, since you only have to go to the batch level. There are also intermediate designs that preserve the overall Merkle tree structure at the cost of a bit more data, and probably a lot of other designs we haven=E2=80=99t thought of (such as the =E2=80=9Csegmented=E2=80= =9D scheme that was in the pre-I-D versions of CT). In any case, if we claim that CT represent a system that is actually publicly verifiable, then we need to get rid of SCTs and come up with a way to push log state to RPs more efficiently. --f403045e3510fee8c205463da1f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

Sorry I=E2=80=99ve missed the WGLC deadlin= e.=C2=A0 I wanted to summarize for this list some discussions that have bee= n going on within the Firefox team.=C2=A0 Basically, we=E2=80=99ve started = to look at what it would take to deploy CT inside of Firefox (including cod= e, policy, etc), and come away with some concerns that the system as curren= tly specified can=E2=80=99t be deployed in a way that actually provides the= desired guarantees, in particular protection against equivocation by logs.= =C2=A0 For what it=E2=80=99s worth, these comments apply roughly equally to= RFC 6962 and 6962bis.=C2=A0

tl;dr:

- It is not practical to= build a publicly verifiable log system that incorporates SCTs
- The exi= sting tools for public verifiability need to be made more efficient in orde= r to work on the scale envisioned

I recognize that it=E2=80=99s very= late in the day to be raising these issues, but we believe they go to the = heart of the value proposition of CT and so it=E2=80=99s important they be = addressed before 6962bis goes to RFC. I speak for both myself and my collea= gues here at Mozilla in saying that we are more than willing to put in the = time to help get to consensus on these topics.

Details below.
Thanks,
--Richard


=3D=3D=3D

Fundamentally, CT is a pu= blic ledger system: every certificate is supposed to be entered into a log = and RPs only accept certificates which are logged. In order for this to wor= k properly, RPs need to be able to verify that there is public consensus ab= out the state of the log. Otherwise, logs can =E2=80=9Cequivocate=E2=80=9D:= represent to the RP that a given certificate was published when it in fact= was not. Unfortunately, in practice RPs are not doing this verification (f= or reasons discussed below), and so CT reduces to a countersignature scheme= in which the RP trusts the log not to equivocate. There are two primary ch= allenges here, as detailed below.


# SCTs, and thus immediate iss= uance, are incompatible with public verifiability

It has been known = for quite some time that the public verifiability piece of CT introduces la= tency in certificate issuance. In order to allow for immediate certificate = issuance, logs instead issue SCTs, which are just promises to incorporate t= he certificate into the log; effectively the SCT is a countersignature on t= he certificate. However, if an RP accepts a certificate + SCT, then it is v= ulnerable to collusion between a CA which issues a bogus cert and a log whi= ch issues a bogus SCT but never incorporates the cert into the log.

= We are unaware of any way to efficiently address this issue without introdu= cing either privacy problems or latency. In order to validate inclusion in = the log, the RP needs to validate that other entities (e.g., the software m= anufacturer) have the same view of the log. Either the RP downloads the who= le log (which is inefficient), queries for the specific certificate in ques= tion (which has privacy problems) or retrieves a checkpoint which vouches f= or some batch of certificates (which introduces batch latency).

Ther= e seem to be two major ways to address this issue:

1. Accept issuanc= e latency: An RP will only accept a cert as valid when accompanied by proof= that it has been incorporated into the public record

2. Accept some= window of vulnerability to equivocation during which SCTs are accepted and= then retrospectively checked. The RP would provisionally accept a certific= ate that claimed to have been very recently issued and then check for log p= resence a few minutes later (once an inclusion proof should be available) <= br>
Unfortunately, there=E2=80=99s not really an effective way to accomp= lish the latter with high reliability and without bad privacy problems.=C2= =A0 Going back to the server and asking for an inclusion proof is safe from= a privacy perspective, but there=E2=80=99s a significant risk of failure g= iven how often servers are multi-homed.=C2=A0 And asking anyone but the ser= ver leaks browsing history.=C2=A0 It=E2=80=99s theoretically possible that = some private information retrieval scheme could save us, but that would be = a big new chunk of work, and unlikely to deploy in the near term.=C2=A0
Note that it is not possible to just not require public verifiability = for certificates which claim to be recently issued; because this attack dep= ends on the log and the CA colluding, they can just issue certificates with= recent timestamps.


# CT=E2=80=99s public verifiability mechanis= ms are too inefficient to be deployed at scale

If this WG is going t= o meet its charter goals, CT needs to have a working public verifiability s= ystem. What that means in practice is that it=E2=80=99s efficient for the R= P to acquire whatever information it needs to validate that a certificate i= s in the public record. In the current system, this basically means:
=C2=A0 - Acquire an inclusion proof [hopefully provided by the site the RP= is connecting to].
=C2=A0 - Acquire the STH that the inclusion proof ch= ains back to and validate that the STH was publicly logged.

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 S= TH leaks which certificate you are verifying.=C2=A0 For similar privacy rea= sons, clients need to proactively download and validate every STH they migh= t encounter, to avoid making queries for STHs (which leak browsing history)= .=C2=A0 So, what this means is that the RP needs to periodically retrieve:<= br>
=C2=A0 - All the STHs that any certificate might chain to
=C2=A0 = - The consistency proofs between those STHs

The good news is that if= the RP does this, then it will be in a position to verify that any certifi= cate with an inclusion proof has been publicly logged; it will be protected= from equivocation.=C2=A0 The bad news is that this scheme generates so muc= h data it cannot be deployed.

To get an idea of scale here, I looked= all of the submissions to the Google Pilot log over December 2016.=C2=A0 L= et=E2=80=99s assume that the log creates a new STH for every 2048 certifica= tes it receives, in order to minimize issuance latency; it takes around 8 m= inutes for Pilot to get 2048 certificates, on average.=C2=A0 At this rate, = Pilot produces around 6000 STHs per month.=C2=A0 The good news is that at t= his rate, an RP can easily store all of the STHs it needs, around ~192kB of= hashes per month, ~2.3MB per year.

The bad news is that the RP has= to download an inordinate amount of information to verify these STHs. In a= ddition to the STHs themselves, it will need to download around 6000 consis= tency proofs over the course of a month.=C2=A0 Each proof is around 20 hash= es, so at the end of the day this is ~125k hashes (4MB of data) that an RP = has to download every month, 48MB for the year. That=E2=80=99s a pretty big= chunk of data.

There are no doubt several plausible alternative da= ta structures, but just to give a sense of what=E2=80=99s possible, conside= r the following design:=C2=A0 Replace the global Merkle tree with a series = of time-windowed trees, one for each batch.=C2=A0 Then glue these together = with a conventional Haber-Stornetta hash chain.=C2=A0 (See my cartoon at &l= t;https://ipv.sx/tmp/ct-hs.pdf= >)=C2=A0 This has the same number of STHs as the design above but becaus= e the consistency proofs are trivial (you just validate that STH_n includes= the hash of STH_{n-1}), the total download size for the month is just ~6k = hashes (192kB of data).=C2=A0 This scheme also saves you a few bytes on inc= lusion proofs, since you only have to go to the batch level.

There a= re also intermediate designs that preserve the overall Merkle tree structur= e at the cost of a bit more data, and probably a lot of other designs we ha= ven=E2=80=99t thought of (such as the =E2=80=9Csegmented=E2=80=9D scheme th= at was in the pre-I-D versions of CT).

In any case, if we claim that= CT represent a system that is actually publicly verifiable, then we need t= o get rid of SCTs and come up with a way to push log state to RPs more effi= ciently.
--f403045e3510fee8c205463da1f4-- From nobody Tue Jan 17 07:34:56 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 78D781294C2 for ; Tue, 17 Jan 2017 07:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 IDsLoxHBxjHE for ; Tue, 17 Jan 2017 07:34:54 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 328A31293F8 for ; Tue, 17 Jan 2017 07:34:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3v2vL16lfWz7q; Tue, 17 Jan 2017 16:34:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484667289; bh=L1n7upCd0CZSTSWStJz0sLYqdFcNv42yXTP++SGODUY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WKPkWUriJd+gC1+An4HYQ8QBPR8CZg6WPo2dE5+P2hDDI6KsAIr2FjDXpQ+TBZuGd E8mcsDiloUXx/HT64SB8RoSWLy+JAWo/PKuU4Yucov9SW+vE69I+XrPY3KwvmzIt/B yGjuUdazGMOaeE+vMjgN/NPzY8U1e+zR3HJYH49c= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eYn_tC60B9i2; Tue, 17 Jan 2017 16:34:48 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Jan 2017 16:34:48 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 83A164080E8; Tue, 17 Jan 2017 10:34:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 83A164080E8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6319C40267E2; Tue, 17 Jan 2017 10:34:34 -0500 (EST) Date: Tue, 17 Jan 2017 10:34:34 -0500 (EST) From: Paul Wouters To: Richard Barnes In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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: Tue, 17 Jan 2017 15:34:55 -0000 On Mon, 16 Jan 2017, Richard Barnes wrote: Speaking as individual only... > - It is not practical to build a publicly verifiable log system that incorporates SCTs > - The existing tools for public verifiability need to be made more efficient in order to work on the scale > envisioned So I think there might be a different perception here of the goal of CT. I think you are looking at a 100% catch-before-it-happens scenario. While the document is only about "exposing rogue parties". > Fundamentally, CT is a public ledger system: every certificate is supposed to be entered into a log and RPs > only accept certificates which are logged. In order for this to work properly, RPs need to be able to verify > that there is public consensus about the state of the log. Otherwise, logs can “equivocate”: represent to the > RP that a given certificate was published when it in fact was not. Unfortunately, in practice RPs are not > doing this verification (for reasons discussed below), and so CT reduces to a countersignature scheme in which > the RP trusts the log not to equivocate. There are two primary challenges here, as detailed below. The monitors are supposed to use multiple logs, presumably not all of which are colluding. So a rogue log would be found out and lose its trust? Maybe not in time for this one client visiting this one website, but that was never the expected goal of CT. > It has been known for quite some time that the public verifiability piece of CT introduces latency in > certificate issuance. In order to allow for immediate certificate issuance, logs instead issue SCTs, which are > just promises to incorporate the certificate into the log; effectively the SCT is a countersignature on the > certificate. However, if an RP accepts a certificate + SCT, then it is vulnerable to collusion between a CA > which issues a bogus cert and a log which issues a bogus SCT but never incorporates the cert into the log. So that is someting monitors should look at. > We are unaware of any way to efficiently address this issue without introducing either privacy problems or > latency. In order to validate inclusion in the log, the RP needs to validate that other entities (e.g., the > software manufacturer) have the same view of the log. Either the RP downloads the whole log (which is > inefficient), queries for the specific certificate in question (which has privacy problems) or retrieves a > checkpoint which vouches for some batch of certificates (which introduces batch latency). So personally, I would like to know that ACME-style issued certificates would start being accepted within a few minutes. At least for those sites that did not have a certificate before. If we are talking about renewing, then it should be able to properly submit new entries to log before actually activating the new certs, so some latency wouldn't matter. Am I missing something? Paul From nobody Tue Jan 17 07:49:17 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 3635312951E for ; Tue, 17 Jan 2017 07:49:16 -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=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 pWzBGxRMroWb for ; Tue, 17 Jan 2017 07:49:14 -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 46489129512 for ; Tue, 17 Jan 2017 07:49:14 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id r136so94936504vke.1 for ; Tue, 17 Jan 2017 07:49:14 -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=5FFYapZrbeV3cGhVHUVv5Uwxcg7wEA9fQ6wVxMD2OzE=; b=r037FoCLmC2nAIa615VpdV5KqavLxnlInSz2rWIEhaWbgaGMdQ+Ljv9qpanBLELO/R i/brNt0tPP11qN3tjxlxTLTvV5fp8fGMj1dpBFaZEIf3H4swCYLacs9K1ABTGZKG0yNf RP80koIVfkRenGILyoLR9DLGNs1Vte1iqETD9andiRQtz2tk7+/MPkgOSvv7VQcUkhWm rvSuJ8TEN9g+G6kODjuu/exGtQbWArO16TH3cXUHjYDLUZq7JgMX/s3T2us5B9ErZHjO ZDlInli8j/Y/LrAViCGdpFao74Y0iDUVlVN+CDvBdMGaNRitdDkg4vhENwg8jpARYlLw cFQQ== 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=5FFYapZrbeV3cGhVHUVv5Uwxcg7wEA9fQ6wVxMD2OzE=; b=XZwtWY240o0taBiP7v4oVCQi0wCm3QkxLyaOeyui0m6JisGdfV4772Z4vT1XGRYULN OL/EY3ZVBCPupmebmCGCwSo9PH+5SVJTJGN/ccudprHUnzKH/egb3Z6DuOd6iAqD/xDD GeMAeLW7mIPnGmDCkwDyV3ic8twso5G4cLCG1WE4/7zwoanqYT9DxP1m3xARcJpL+NFi YyvMNGp70qyFItxSk8P/k87gYBHoISrTI7NJoinXUrEfYuV9yr7lv4nlEUXs8qNKE7Ef hQnS8JR5uIRg6JJ6IRbLX1sVC9zIno//soU4WhPcirQ+NLPEIV/jb2+amntKmsgD/vzA R5Rg== X-Gm-Message-State: AIkVDXJminpfYkDK2bkw/IvNhvYsYTeSDhzRLPi1IMF4NDjuCsfNrpG1xRaT15TgdUkLROBbYMuW13FK5dsOtw== X-Received: by 10.31.248.193 with SMTP id w184mr19170438vkh.10.1484668153236; Tue, 17 Jan 2017 07:49:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Tue, 17 Jan 2017 07:49:12 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 17 Jan 2017 10:49:12 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c14bd2ae222b905464c3dd2 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: Tue, 17 Jan 2017 15:49:16 -0000 --94eb2c14bd2ae222b905464c3dd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters wrote: > On Mon, 16 Jan 2017, Richard Barnes wrote: > > Speaking as individual only... > > - It is not practical to build a publicly verifiable log system that >> incorporates SCTs >> - The existing tools for public verifiability need to be made more >> efficient in order to work on the scale >> envisioned >> > > So I think there might be a different perception here of the goal of > CT. I think you are looking at a 100% catch-before-it-happens > scenario. While the document is only about "exposing rogue parties". > Those two goals are not as different as you might think. Either way, you need for the client to detect equivocation. You need the same data; it's just a question of when. > Fundamentally, CT is a public ledger system: every certificate is suppose= d >> to be entered into a log and RPs >> only accept certificates which are logged. In order for this to work >> properly, RPs need to be able to verify >> that there is public consensus about the state of the log. Otherwise, >> logs can =E2=80=9Cequivocate=E2=80=9D: represent to the >> RP that a given certificate was published when it in fact was not. >> Unfortunately, in practice RPs are not >> doing this verification (for reasons discussed below), and so CT reduces >> to a countersignature scheme in which >> the RP trusts the log not to equivocate. There are two primary challenge= s >> here, as detailed below. >> > > The monitors are supposed to use multiple logs, presumably not all of > which are colluding. So a rogue log would be found out and lose its > trust? Maybe not in time for this one client visiting this one website, > but that was never the expected goal of CT. > I think you mean "RPs" where you say "monitors", right? Even in this scenario, in order for the rogue log to be found out, you still need a system for detecting equivocation, which we don't have now. > It has been known for quite some time that the public verifiability piece >> of CT introduces latency in >> certificate issuance. In order to allow for immediate certificate >> issuance, logs instead issue SCTs, which are >> just promises to incorporate the certificate into the log; effectively >> the SCT is a countersignature on the >> certificate. However, if an RP accepts a certificate + SCT, then it is >> vulnerable to collusion between a CA >> which issues a bogus cert and a log which issues a bogus SCT but never >> incorporates the cert into the log. >> > > So that is someting monitors should look at. > > We are unaware of any way to efficiently address this issue without >> introducing either privacy problems or >> latency. In order to validate inclusion in the log, the RP needs to >> validate that other entities (e.g., the >> software manufacturer) have the same view of the log. Either the RP >> downloads the whole log (which is >> inefficient), queries for the specific certificate in question (which ha= s >> privacy problems) or retrieves a >> checkpoint which vouches for some batch of certificates (which introduce= s >> batch latency). >> > > So personally, I would like to know that ACME-style issued certificates > would start being accepted within a few minutes. At least for those > sites that did not have a certificate before. If we are talking about > renewing, then it should be able to properly submit new entries to log > before actually activating the new certs, so some latency wouldn't matter= . > As I noted in my little quantitative analysis, you can get the data structures down to a reasonable size with a ~8min issuance delay if you're willing to refactor the log structure. --Richard > > Am I missing something? > > Paul > --94eb2c14bd2ae222b905464c3dd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 16 Jan 2017, Richard = Barnes wrote:

Speaking as individual only...

- It is not practical to build a publicly verifiable log system that incorp= orates SCTs
- The existing tools for public verifiability need to be made more efficien= t in order to work on the scale
envisioned

 So I think there might be a different perception here of the goal of
CT. I think you are looking at a 100% catch-before-it-happens
scenario. While the document is only about "exposing rogue parties&quo= t;.

Those two g= oals are not as different as you might think.=C2=A0 Either way, you need fo= r the client to detect equivocation.=C2=A0 You need the same data; it's= just a question of when.

=C2=A0
Fundamentally, CT is a public ledger system: every certificate is supposed = to be entered into a log and RPs
only accept certificates which are logged. In order for this to work proper= ly, RPs need to be able to verify
that there is public consensus about the state of the log. Otherwise, logs = can =E2=80=9Cequivocate=E2=80=9D: represent to the
RP that a given certificate was published when it in fact was not. Unfortun= ately, in practice RPs are not
doing this verification (for reasons discussed below), and so CT reduces to= a countersignature scheme in which
the RP trusts the log not to equivocate. There are two primary challenges h= ere, as detailed below.

 The monitors are supposed to use multiple logs, presumably not all of
which are colluding. So a rogue log would be found out and lose its
trust? Maybe not in time for this one client visiting this one website,
but that was never the expected goal of CT.

I think you mean "RPs" where you say= "monitors", right?

Even in this scenario, in o= rder for the rogue log to be found out, you still need a system for detecti= ng equivocation, which we don't have now.

=C2=A0
It has been known for quite some time that the public verifiability piece o= f CT introduces latency in
certificate issuance. In order to allow for immediate certificate issuance,= logs instead issue SCTs, which are
just promises to incorporate the certificate into the log; effectively the = SCT is a countersignature on the
certificate. However, if an RP accepts a certificate + SCT, then it is vuln= erable to collusion between a CA
which issues a bogus cert and a log which issues a bogus SCT but never inco= rporates the cert into the log.

 So that is someting monitors should look at.

We are unaware of any way to efficiently address this issue without introdu= cing either privacy problems or
latency. In order to validate inclusion in the log, the RP needs to validat= e that other entities (e.g., the
software manufacturer) have the same view of the log. Either the RP downloa= ds the whole log (which is
inefficient), queries for the specific certificate in question (which has p= rivacy problems) or retrieves a
checkpoint which vouches for some batch of certificates (which introduces b= atch latency).

 So personally, I would like to know that ACME-style issued certificates
would start being accepted within a few minutes. At least for those
sites that did not have a certificate before. If we are talking about
renewing, then it should be able to properly submit new entries to log
before actually activating the new certs, so some latency wouldn't matt= er.

As I noted in my little quantitativ= e analysis, you can get the data structures down to a reasonable size with = a ~8min issuance delay if you're willing to refactor the log structure.=

--Richard

=C2=A0

Am I missing something?

Paul

--94eb2c14bd2ae222b905464c3dd2-- From nobody Tue Jan 17 08:03:38 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 A07611294C6 for ; Tue, 17 Jan 2017 08:03:33 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 VnVpas6Zn0_u for ; Tue, 17 Jan 2017 08:03:28 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 EAB60129567 for ; Tue, 17 Jan 2017 08:03:27 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id x49so164089421qtc.2 for ; Tue, 17 Jan 2017 08:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to; bh=PeM38YP1Ma6c66us8My+ThmhnVheksLMJnZfwRQ8GEU=; b=xkTzeYFQWZ+WTpb92QHvYIWiAUPftX1KSTdL0wUbKv8bk3DgzK/YFgjPF0JmOJ8HNN ZBDRcqF+KkX0Yk5fp8EbVFiUCdUJMfJdm5ghBPfcSFtkAufHuTWAYGads1rHu4BAm2ss PF5LSNQ/ONf1YSf2/YqMjS63kFB0RxNcAyusU= 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=PeM38YP1Ma6c66us8My+ThmhnVheksLMJnZfwRQ8GEU=; b=DUyuBPRFPVrFaul9kXZgpGaHu93ZOtN7EaY7wpVq+TK03LBG9vFfqX/U42iziz9o+c 0JxOc56+hK0oQ03d0ApcZaWI5tYTEE4HosAc4h39yaLgC2JHB4N95Y2XuN1Hlriu+a5n U5Fd5vvee3uOd47H9IbjpljaqUnD0VducWBEFDQBtBxPX3N5rrZy35Y6NVYpWxA9ClA5 GbPcEbGQnRQTxqvSbDGm7zkmsxTqEbL6fJE/Rmx0nolujY3j28hI4fB3yqMJksTYh8xw ahx24ogDxx/eCtWpuvXgPlFxCYnHumGfoAeXhbX/PBg4IAwn6P6PMyi1EDKqvPXMcyul g7Sw== X-Gm-Message-State: AIkVDXIKMmtU466ALJU25UxEcHrxV7asRmJ4fIwuOJzPrj/T5FYLMsEAGdUsFneZjr2msa2wzSNd31O+KX8STJDl X-Received: by 10.55.134.1 with SMTP id i1mr35728021qkd.219.1484669006299; Tue, 17 Jan 2017 08:03:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.99.73 with HTTP; Tue, 17 Jan 2017 08:03:05 -0800 (PST) From: Tom Ritter Date: Tue, 17 Jan 2017 10:03:05 -0600 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Evaluating the Gossip Draft 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, 17 Jan 2017 16:03:33 -0000 Hi all, The Gossip draft has been sitting for a bit, we've gotten a few comments but we'd like more. I wanted to take this opportunity to compare/contrast it with another draft. Google has a (public, although not well-publicised) draft for something that is Gossip-like, available at https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1# I think it's pretty interesting, and even though they don't want to consider it 'Gossip', the goal of log consistency checking is pretty near and dear to Gossip. So I want to think about it and kind of do an apple-to-orange comparison with the IETF draft we've been working on and see if there are things we should incorporate or consider incorporating in our draft or (and this would be better) there are things we could remove from our draft. While it's been worked on for a while, I'm not the author of the Google draft so I don't want to speak for them in terms of their commitment to it, its status, or whatnot. When I say things like "They are" or "Chrome will" please translate that to "The draft proposes that Chrome do X". (It's also important to note that they're taking a methodical, phased approach to implementation, so while this is something they do now it doesn't mean they won't build up on it later.) Anyway, their draft takes a very reasonable phased approach to consistency checking. Chrome will receive a push of fresh STHs from Google once a day. When Chrome encounters SCTs during normal web browsing, it will request an inclusion proof via DNS. From here, one can speculate about what log consistency checking can do, but in the initial deployment phase Chrome will just be collecting metrics to answer questions like: - How often do we encounter SCTs that haven't been included yet? - How long might we have to queue these SCTs for later checking? - How often do we get inclusion proof failures? - How well does the STH push mechanism work? First, let me analyze their proposal. This is touchy - I'm not asking them to defend it really, I'm just trying to figure out why I may not like it, and what things I consider to be problematic enough to stop me from just scrapping ours and re-architecting it in a way that resembles theirs... First off, apparently we never defined the threat model we expected our Gossip draft to defend against. (Well, we kind of buried it over here: https://tools.ietf.org/html/draft-ietf-trans-gossip-03#section-10.3 but that's not very well-written.) I think I speak for my co-authors when I say we assume the below. It's reasonable that Google's threat model may not match ours and therefore evaluating their algorithm against our threat model is kind of unfair... but I'm going to do it anyway I guess. a) An attacker can compromise a CA and get a mis-issued end entity certificate (or subCA cert) b) An attacker can compromise multiple logs, such that they can get sufficient SCTs required to meet certificate acceptance policies c) An attacker can compromise those logs to cause a split-view of the log to be generated if desired d) An attacker can perform a TLS MITM (using their cert and SCT) of a client, for any individual or indeed all websites for a *limited* period of time (meaning they cannot MITM a website forever) e) An attacker can selectively _block_ network connections at will, forever, based on direct identifiers like hostnames or using heuristics. f) Additionally, we would *like* to defend against an attacker who can thoroughly compromise two CAs to do the 'Dual CA attack'. But this is not a strict requirement. Finally, we admit that there are (at least) two attacks in our threat model the attacker could perform that we do not attempt to defend against: i) Blocking all software updates for a client (such as new CT policies/code, removing compromised logs, removing compromised CAs) [1] ii) Performing a TLS MITM of a website, and then blocking the client from communicating with that website ever again (in conjunction with selective network blocking) Security: Google pushes STHs to clients. Any attempt at putting an individual Chrome client onto a split view can be detected. But Google (and therefore all Chrome clients) could be put on the same split view. Or, on the other side of the view, the attacker simply doesn't attack Chrome clients. Because it's unlikely that an attacker would decide to attempt an attack that puts Google and all Chrome clients onto a malicious side of the tree, I suppose this is acceptable for Google, but I would prefer an ecosystem where different clients will share data amongst themselves, resulting in true herd immunity, and not '5 herds, each with some level of immunity'. (To be fair, this seems like something that might be added in a later version and would be explicitly excluded from initial deployment while one tests the waters.) Nothing in this proposal can detect a Dual CA Compromise, but that's something that could be added later I suppose. There are fixed-sized buffers with well-defined behaviors and no randomization. (At least, going off the proposal.) This leads me to believe it would be fairly easy to perform a flushing attack (or a preload-the-cache attack) on a client which, when combined with a strategy of 'delay all inclusion proof requests temporarily', would lead to an undetectable attack on a client. Censorship: Consider an attack on CT: Mallory compromises a CA to sign a cert, and N logs to get N SCTs for the cert. (SCTs which are never included in the log.) I do not see a way with this proposal, or an obvious extension of it that preserves privacy, to detect the attack when the attacker also blocks (some or all) DNS inclusion proof requests. DNS filtering is in use all over the place, in both known-censored countries like those in the Middle East, but also in place in 'free' European countries like Switzerland, Sweden, Norway, Belgium, Denmark, and Estonia. Therefore, I think it's reasonable to assume a threat model where the attacker can block selected DNS queries effectively forever. Defending against this is a pain in the butt. Some solution(s) to this problem are: - Send proof requests over a different channel. Tor. Or use DNS-over-TLS or DNS-over-QUIC or something similar for all DNS - but this requires your DNS endpoint to not be run by your adversary (the ISP probably) - The main one: use SCT Feedback. (Obviously requires opt-in by the website under attack) - Use a Trusted Auditor (undesirable for a number of reasons) Privacy: There may not be any consideration given to how inclusion request ordering and clustering discloses information to logs. It implies the SCTs will be entered into an (ordered?) de-duplicated queue. Okay, now I want to compare it to our draft https://tools.ietf.org/html/draft-ietf-trans-gossip-04 I'm going to extrapolate the current proposal into one that does the following: If an inclusion proof is received that chains to a STH the client doesn't know about, and the STH is reported to be within the timeframe that the client should know 'all' the STHs - the STH is reported to Google. This still isn't Gossip, but it does start doing and reporting on actual log consistency check and might catch a malicious or compromised log. I don't know if this is Google's plan, but it seems like a natural extension of it... First off, Google's plan is so much less complex than ours. This comes from a few places: 1) There's nothing about 'Trusted Auditors'. Google obviously has some trusted auditor implementation in their crawler, but its privacy/security considerations and API format are omitted. 2) It omits SCT Feedback. 3) I am assuming it takes a 'Report weird STHs to Google' approach instead of the STH Pollination approach we define. The assumption I make I am actually okay with privacy/security wise although I prefer the Pollination approach as a more open and interacting ecosystem notion. 4) It omits talking about defenses against flushing attacks. What should we take away from this? Firstly, no one *likes* Trusted Auditors. I mean it'd be good to standardize an API for it, but maybe we should remove it from the draft and say 'We'll work on this in a different draft later?' Secondly, while I prefer STH Pollination, it could be replaced by Google's idea (and my extrapolation) of pushing STHs to clients and reporting weird ones up to the client vendor. This has the disadvantage of causing the 'multiple herds' situation, but has the advantage of requiring less work from site operators and pushes less total data around the internet. It would be necessary that the 'report weird STHs' mechanism be sufficiently protected against heuristic-based blocking though. However, because of the censorship concerns I raised, I am not eager to remove SCT Feedback... Something I am unsure about is how Google plans to handle the case of 'Requesting an inclusion proof for this SCT always fails'. Clearly 'Send the SCT to the Google' is easy but... not very privacy preserving. Maybe failure rates will indicate that this happens so infrequently that it is acceptable privacy wise?[2] In our draft we propose that one MUST NOT do this and that if the site does not support SCT Feedback... Thinking about this more, this seems like a pretty big failure scenario. We definitely want to detect SCTs that are not included in logs - that's probably the easiest possible log compromise but right now we have only a mediocre answer to it (since SCT Feedback will not be deployed by many or most websites.) I'd love to hear people's thoughts here. I've realized some additional things about the current gossip draft: - As mentioned in the paragraph above, we don't have a good story about SCTs we fail to get inclusion proofs for. - It de-facto requires resolving proofs over DNS (I'd prefer Tor but I'm being realistic), but the only provider of this functionality is Google. This isn't a good ecosystem. - Proof requests are a good target for DNS reflection attacks :-/ - We haven't done a good job of considering all the client implementations of Gossip, in particular how our proposal maps to Mobile. Which security guarantees will be de-facto relaxed, and to what degree, by the constraints of mobile? - As I mentioned above, we never put a well-described threat model into the document. -tom [1] Such an attack can be detected, using something like The Update Framework, but the behavior of a client when it knows it is being blocked is an open problem. Do you just show the user an error like "Sorry, I've decided to stop working for you. Good luck figuring out how to update me"? [2] Although such a decision would lead to de-anonymization attacks possible by logs! From nobody Tue Jan 17 08:30:32 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 185D1129549 for ; Tue, 17 Jan 2017 08:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 e3LlvOnPZEfZ for ; Tue, 17 Jan 2017 08:30:27 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 539B7129548 for ; Tue, 17 Jan 2017 08:30:27 -0800 (PST) Received: (qmail 7735 invoked by uid 1004); 17 Jan 2017 16:30:24 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 17 Jan 2017 16:30:24 +0000 Received: (qmail 18348 invoked by uid 1000); 17 Jan 2017 16:30:23 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 17 Jan 2017 16:30:23 +0000 To: trans@ietf.org References: From: Rob Stradling Message-ID: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> Date: Tue, 17 Jan 2017 16:30:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Minimum SCT age (was Re: 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: Tue, 17 Jan 2017 16:30:31 -0000 On 17/01/17 15:34, Paul Wouters wrote: > So I think there might be a different perception here of the goal of > CT. I think you are looking at a 100% catch-before-it-happens > scenario. While the document is only about "exposing rogue parties". > So personally, I would like to know that ACME-style issued certificates > would start being accepted within a few minutes. At least for those > sites that did not have a certificate before. If we are talking about > renewing, then it should be able to properly submit new entries to log > before actually activating the new certs, so some latency wouldn't matter. Forking the thread to propose an idea: Let a domain owner specify (perhaps via an extension to the proposed Expect-CT HTTP header?) the minimum age of each SCT that TLS clients may accept when establishing TLS connections to servers within that domain space. (I'm imagining that minimum SCT ages would typically be measured in days, rather than weeks or months). This mechanism would transform CT from a detection system to a prevention system. Well, sort of. Since each cert for that domain space would have to be publicly logged some number of days in advance of it being used, the legitimate domain owner would have a window of opportunity to detect a misissued cert (and request that it be revoked) before an attacker could actually use it for their nefarious purposes. Of course, the downside of this mechanism is that it's a footgun. If a domain owner forgets to obtain a cert and to publicly log it sufficiently far in advance, there will be a period of time during which they can't serve a compliant cert to TLS clients, even if they have a correctly issued cert ready to go. Any comments? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 17 09:08:11 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 E02FF127077 for ; Tue, 17 Jan 2017 09:08:09 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Q-OIsclh9KGt for ; Tue, 17 Jan 2017 09:08:08 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 8EB9B129557 for ; Tue, 17 Jan 2017 09:08:08 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l7so168415299qtd.1 for ; Tue, 17 Jan 2017 09:08:08 -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; bh=bLMJNYVJfSL+Xn2x5q+6U8iPiCUe4WPApUmrohssXtM=; b=qsq8K0Y0+0rS0ByL/R7BK7Mi0EJNIEFJQv6Ju3pcwoCfA3CPQa4YkDbeEk4PQVTss0 Ead+L3Za+9lbZC2F3jTOwJcc8QJ/l1nNfWSQk2aLklWQpHVEwrOJLvrPPbkE3jZyFEvw gWhYC+bBjcDqqUmBojjxtEmNReprLkyozmvbM= 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=bLMJNYVJfSL+Xn2x5q+6U8iPiCUe4WPApUmrohssXtM=; b=FWlXneIJDIRP5wJa1hMgKkHxz7E+K4Q8w+T7cLMuWzvhymKIOGbFTsvXz9gJ0fA5TU 5xAOrNgVZjzdafoH/NpQdyCVfaeWoTwAr1XmzsxR3QWNKQSR5/JJVFqenL0oK3BQaEpF mIQeBD9awsJfEPwICGjG97RGlmSMGcGKNjGpKEoq89EnXvFdY24otCTDXTXEPkj+v/gt rwcsehgUhhoD5TIk9cDmL3q1cqMJlL1aCHAhN0/Kc+QMQFJeRvlMI5NvcMhEWBTfR0Jx fpJlkZH+B0RplHRDgx544YlFVwmna8YtfzHNW9v4YFGPHLttsyPdoGTqGer2gTHqO90P ghZg== X-Gm-Message-State: AIkVDXKLjsQ8jSWr2C8q91Y8la36OHSr8MwhFCvf6n55/vs1IRjXHB8H5DjZ1WSYKd9qCrA3W1zDo229VhyKTp4v X-Received: by 10.200.55.178 with SMTP id d47mr37540851qtc.60.1484672887638; Tue, 17 Jan 2017 09:08:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.99.73 with HTTP; Tue, 17 Jan 2017 09:07:47 -0800 (PST) In-Reply-To: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> References: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> From: Tom Ritter Date: Tue, 17 Jan 2017 11:07:47 -0600 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Minimum SCT age (was Re: 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: Tue, 17 Jan 2017 17:08:10 -0000 On 17 January 2017 at 10:30, Rob Stradling wrote: > On 17/01/17 15:34, Paul Wouters wrote: > >> >> So I think there might be a different perception here of the goal of >> CT. I think you are looking at a 100% catch-before-it-happens >> scenario. While the document is only about "exposing rogue parties". > > >> >> So personally, I would like to know that ACME-style issued certificates >> would start being accepted within a few minutes. At least for those >> sites that did not have a certificate before. If we are talking about >> renewing, then it should be able to properly submit new entries to log >> before actually activating the new certs, so some latency wouldn't matter. > > > Forking the thread to propose an idea: > > Let a domain owner specify (perhaps via an extension to the proposed > Expect-CT HTTP header?) the minimum age of each SCT that TLS clients may > accept when establishing TLS connections to servers within that domain > space. (I'm imagining that minimum SCT ages would typically be measured in > days, rather than weeks or months). > > This mechanism would transform CT from a detection system to a prevention > system. Well, sort of. Since each cert for that domain space would have to > be publicly logged some number of days in advance of it being used, the > legitimate domain owner would have a window of opportunity to detect a > misissued cert (and request that it be revoked) before an attacker could > actually use it for their nefarious purposes. > > Of course, the downside of this mechanism is that it's a footgun. If a > domain owner forgets to obtain a cert and to publicly log it sufficiently > far in advance, there will be a period of time during which they can't serve > a compliant cert to TLS clients, even if they have a correctly issued cert > ready to go. > > Any comments? It assumes the malicious log doesn't backdate a SCT.. It also assumes the client has a clock that is correct to the order of a few days... -tom From nobody Tue Jan 17 09:16: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 C485A12958E for ; Tue, 17 Jan 2017 09:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 iXImB3Vo8nJ0 for ; Tue, 17 Jan 2017 09:16:10 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 5906A12959A for ; Tue, 17 Jan 2017 09:16:10 -0800 (PST) Received: (qmail 18273 invoked by uid 1004); 17 Jan 2017 17:16:06 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 17 Jan 2017 17:16:06 +0000 Received: (qmail 582 invoked by uid 1000); 17 Jan 2017 17:16:06 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 17 Jan 2017 17:16:06 +0000 To: Tom Ritter References: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> From: Rob Stradling Message-ID: Date: Tue, 17 Jan 2017 17:16:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Minimum SCT age (was Re: 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: Tue, 17 Jan 2017 17:16:13 -0000 On 17/01/17 17:07, Tom Ritter wrote: >> Any comments? > > It assumes the malicious log doesn't backdate a SCT.. True. So, require multiple SCTs from multiple logs, and let the TLS client consider only the age of the most recent SCT timestamp. > It also assumes the client has a clock that is correct to the order of > a few days... True. Is it, or might it soon be, reasonable to make that assumption? e.g., https://roughtime.googlesource.com/roughtime sounds promising, I think. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 17 09:40: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 6A16F129598 for ; Tue, 17 Jan 2017 09:40:45 -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 nvh9Bzzy5ZjW for ; Tue, 17 Jan 2017 09:40:44 -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 60F3D129594 for ; Tue, 17 Jan 2017 09:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1484674843; bh=Pg0O392axhobCYG35dYcbXOXH5abcM9Yikn/NMNxyaM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=is/sdDZfF60/DvsdS3hnbqIteK2WuZOIKAwa88f3WtYg5JGpElgpk0+o+7w98D6Vk A4c3muQhSZNBQPZ8TMUeLXJ97k0wC1FRqJdLZuw1fxn0BUIiI5PUTcip8dYFlrOtWV VYJKFBQnaceHBINMju7pP0l32whn9Z3H/ezpYedxgCfLW7KPdKeZ4zn3472Z8mQcWg 93dLMVI6IZqEYE6pi7IcuObLwAXwRqeWFUAeJ1eW8fCRrHa3KVTA0bN1cUW363/dDm bSOwRtSGwdQH6gWzu6wrugpsrYwY/NZu4csozzfXfzYHCTvR1lyD38joMY5TFlW2Sk VMpU71YBkrf1g== Date: Tue, 17 Jan 2017 09:40:43 -0800 From: Andrew Ayer To: Rob Stradling Message-Id: <20170117094043.e4880d80890ee4ed3d970275@andrewayer.name> In-Reply-To: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> References: <69ab4ad0-6f24-d421-849e-f5aa7e52be23@comodo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Minimum SCT age (was Re: 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: Tue, 17 Jan 2017 17:40:45 -0000 On Tue, 17 Jan 2017 16:30:23 +0000 Rob Stradling wrote: > On 17/01/17 15:34, Paul Wouters wrote: > > > So I think there might be a different perception here of the goal of > > CT. I think you are looking at a 100% catch-before-it-happens > > scenario. While the document is only about "exposing rogue parties". > > > So personally, I would like to know that ACME-style issued > > certificates would start being accepted within a few minutes. At > > least for those sites that did not have a certificate before. If we > > are talking about renewing, then it should be able to properly > > submit new entries to log before actually activating the new certs, > > so some latency wouldn't matter. > > Forking the thread to propose an idea: > > Let a domain owner specify (perhaps via an extension to the proposed > Expect-CT HTTP header?) the minimum age of each SCT that TLS clients > may accept when establishing TLS connections to servers within that > domain space. (I'm imagining that minimum SCT ages would typically > be measured in days, rather than weeks or months). > > This mechanism would transform CT from a detection system to a > prevention system. Well, sort of. Since each cert for that domain > space would have to be publicly logged some number of days in advance > of it being used, the legitimate domain owner would have a window of > opportunity to detect a misissued cert (and request that it be > revoked) before an attacker could actually use it for their nefarious > purposes. > > Of course, the downside of this mechanism is that it's a footgun. If > a domain owner forgets to obtain a cert and to publicly log it > sufficiently far in advance, there will be a period of time during > which they can't serve a compliant cert to TLS clients, even if they > have a correctly issued cert ready to go. > > Any comments? I think it's a good idea. It's a footgun, but it's much safer than HPKP, since the minimum SCT age needn't be more than a few days. If you screw up HPKP, you're bricked until the pins expire, which could be months. I would like to propose a similar mechanism that tells the client to expect that an inclusion proof be included in the TLS handshake. This will save clients from having to validate the SCT, which is fraught with difficulty. This is a worse footgun, since it will lock server operators into using a TLS server implementation that supports inclusion proofs, but this will become less bad as more TLS servers add support. It's still safer than HPKP. Regards, Andrew From nobody Tue Jan 17 16:33: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 C9E6F129442 for ; Tue, 17 Jan 2017 16:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 rx9BX-dNdxOb for ; Tue, 17 Jan 2017 16:33:10 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1FF1293DC for ; Tue, 17 Jan 2017 16:33:09 -0800 (PST) Received: from [47.143.125.195] (helo=Williams-MacBook-Pro.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cTeBO-0001XU-2N; Tue, 17 Jan 2017 19:32:58 -0500 Date: Tue, 17 Jan 2017 16:32:57 -0800 From: Bill Frantz To: Rob Stradling X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7908df2a843ba43c6a76b2cda1646d818c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.195 Archived-At: Cc: trans@ietf.org, Tom Ritter Subject: Re: [Trans] Minimum SCT age (was Re: 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: Wed, 18 Jan 2017 00:33:13 -0000 On 1/17/17 at 9:16 AM, rob.stradling@comodo.com (Rob Stradling) wrote: >On 17/01/17 17:07, Tom Ritter wrote: > >>It also assumes the client has a clock that is correct to the order of >>a few days... > >True. Is it, or might it soon be, reasonable to make that assumption? > >e.g., https://roughtime.googlesource.com/roughtime sounds promising, I thi= nk. > Machines such as the Raspberry PI and the Beaglebone do not have=20 clock chips, although it is easy to add an external real time=20 clock board. They can set their clocks from NTP if they have=20 internet access, which is more-or-less needed to run a browser,=20 unless running on private network. I can see scenerios where=20 they can have a very badly off clock though. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is=20 *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly From nobody Wed Jan 18 01:22:30 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 2FA5A129499 for ; Wed, 18 Jan 2017 01:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 H74Nyb34dfOm for ; Wed, 18 Jan 2017 01:22:27 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 9C99C129411 for ; Wed, 18 Jan 2017 01:22:27 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id l66so7384452ioi.1 for ; Wed, 18 Jan 2017 01:22:27 -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=KgP8IMZRhY2yLZzDrd870CLvv2a7a7ZRCQYM87000VY=; b=kxtU5rQwkxysHSmDF/Rui6H0kam+XFTyq4NQt5qSusV+c7HEld7PiEP9hHso7T24jO ZDbmbRX89QAU/GGcE5iFZ+O+j/U4u05Ji3ZC7dAKkVxvD1n5X/oyz0mJye7j0sZSxQq6 sQwk9JYrh7Dwcv8Cjp8PPM+Qx06Z0x89pxPPnfHZNZqHWt/K3JR/fSsNxd+UxWEV47Et tgy6QQ8FLP0QiUU1b75wopwYwBwFb9F01c2m023KCEtxz1cblwfMPgkZfZx3YtWgkYy7 DIJLWIOREZmVyq/pO3R4IcylFRdQiXW62Oq8aNkfR8h1uVoyFn1p+wRt80eQxKpJpI3a WLmQ== 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=KgP8IMZRhY2yLZzDrd870CLvv2a7a7ZRCQYM87000VY=; b=rHarbsqErSClvMZoJWfyfTOrMnojmAax2gGqp17Q1T3ttSm4shFmeFkBZR8rcISk8w 78Swc76blh7UbDqfxeLmFzeL2bxMcZa0lNVOJeWIIRPmZe+F2lBq52ugDjQrUwAKNIyB +6MRsjJCT73WNTvani7VMU9WA9UPLrYcSxaW9CBkmLyfEdZoxbYRYuvM20E86/HrCcEF DeHz34dclTrEX/zoT5rd5qzL4G26QqBZRd/vY/C8xFEDtXW4u9TDI5aYXwJ8BcbAmlYn iDgntGYBNCeeb1GZLEXothDvIYC//6gKtfusCzUh7LGhjvvukDSTJkVP7bp4I8hFGtHD qmzQ== X-Gm-Message-State: AIkVDXJUHwz4MAFPe1XifQKr16Fql8rCVG6Kn1gdYkR60BYywMPdsqIsxgcxJjqqq2PYW3gopc9/xDOs25Pb+a40 X-Received: by 10.107.136.40 with SMTP id k40mr2340556iod.99.1484731346647; Wed, 18 Jan 2017 01:22:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Wed, 18 Jan 2017 01:21:56 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Wed, 18 Jan 2017 09:21:56 +0000 Message-ID: To: Bill Frantz Content-Type: multipart/alternative; boundary=001a113ecff4813f6b05465af415 Archived-At: Cc: Tom Ritter , Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Minimum SCT age (was Re: 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: Wed, 18 Jan 2017 09:22:29 -0000 --001a113ecff4813f6b05465af415 Content-Type: text/plain; charset=UTF-8 I agree the most suitable place for this option is the Expect-CT header (because there's no other way for domain owners to signal any CT preferences to the UAs right now). As Tom points out, this is a prevention mechanism against mis-issuance by a CA and does not provide any protection against malicious logs. On Wed, Jan 18, 2017 at 12:32 AM, Bill Frantz wrote: > On 1/17/17 at 9:16 AM, rob.stradling@comodo.com (Rob Stradling) wrote: > > On 17/01/17 17:07, Tom Ritter wrote: >> > > >> >> It also assumes the client has a clock that is correct to the order of >>> a few days... >>> >> >> True. Is it, or might it soon be, reasonable to make that assumption? >> >> e.g., https://roughtime.googlesource.com/roughtime sounds promising, I >> think. >> >> > Machines such as the Raspberry PI and the Beaglebone do not have clock > chips, although it is easy to add an external real time clock board. They > can set their clocks from NTP if they have internet access, which is > more-or-less needed to run a browser, unless running on private network. I > can see scenerios where they can have a very badly off clock though. > That's a real concern - Chrome folks have data around client clock accuracy (and how that affects SSL connections), requiring client clock to be accurate to within a day may be a high bar (again, would need data to confirm). > > Cheers - Bill > > ------------------------------------------------------------ > --------------- > Bill Frantz | Re: Computer reliability, performance, and security: > 408-356-8506 | The guy who *is* wearing a parachute is *not* the > www.pwpconsult.com | first to reach the ground. - Terence Kelly > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113ecff4813f6b05465af415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree the most suitable place for this option is th= e Expect-CT header (because there's no other way for domain owners to s= ignal any CT preferences to the UAs right now).

As Tom = points out, this is a prevention mechanism against mis-issuance by a CA and= does not provide any protection against malicious logs.

On Wed, Jan 18, 2017 at 12:32 AM, Bi= ll Frantz <frantz@pwpconsult.com> wrote:
On 1/17/17 at 9:16 AM, rob.stradling@comodo.com = (Rob Stradling) wrote:

On 17/01/17 17:07, Tom Ritter wrote:
<snip>

It also assumes the client has a clock that is correct to the order of
a few days...

True.=C2=A0 Is it, or might it soon be, reasonable to make that assumption?=

e.g., https://roughtime.googlesource.com/roughtime<= /a> sounds promising, I think.


Machines such as the Raspberry PI and the Beaglebone do not have clock chip= s, although it is easy to add an external real time clock board. They can s= et their clocks from NTP if they have internet access, which is more-or-les= s needed to run a browser, unless running on private network. I can see sce= nerios where they can have a very badly off clock though.
<= div>That's a real concern - Chrome folks have data around client clock = accuracy (and how that affects SSL connections), requiring client clock to = be accurate to within a day may be a high bar (again, would need data to co= nfirm).

Cheers - Bill

-----------------------------------------------------------------= ----------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Re: Computer reliability, performa= nce, and security:
408-3= 56-8506=C2=A0 =C2=A0 =C2=A0 =C2=A0| The guy who *is* wearing a parachut= e is *not* the
= www.pwpconsult.com | first to reach the ground.=C2=A0 - Terence Kelly


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

--001a113ecff4813f6b05465af415-- From nobody Wed Jan 18 02:57:18 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 9EE591295BA for ; Wed, 18 Jan 2017 02:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 drpTLcDB3Nho for ; Wed, 18 Jan 2017 02:57:14 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 BBBDB1294AB for ; Wed, 18 Jan 2017 02:57:14 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id l66so8888179ioi.1 for ; Wed, 18 Jan 2017 02:57:14 -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=0TqA6xluam9LJ93sPkLi3JW6x/jzy5CSHnRCQfuJkdU=; b=JK5Hh+/JEZRR43Q2MZDP2ZKeSvo0qj9XksQuXeJZjfLHrEaBh3N3QnQ/GVftJmaNfU TCLwA/0O6myUqUtlE378OmfEYDMQb4IxPDCq4y4GQTZL1SOu22juFM74Xtw17t/40X7L +oKT748PIZu1tIPRwORPaTmWuUiRJUIG5hYlAdW5CnHrPj6nyvGSgxrmVoTGs4VXgyuE X0vyA3trdpyuORp//liR3KOq33aAlsj6lrUI0DxG6X0x76WCqNFf+/l2kqUBGbGrDNnZ 9ZwpWnMAEAc2//Mbajz8akCM4wQ5Ko9QaSRnCqUrXAtF6tY2kRXXagmGwVXMkDxv504W XGAA== 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=0TqA6xluam9LJ93sPkLi3JW6x/jzy5CSHnRCQfuJkdU=; b=jwnnIqRaFgMrrkx2mttYNu4cloVIuqmfifp/IThFvTFWeUs7La419RZZYqTl3NfjlB nr9ooPmxE30LKlrDt4IUEDJtdkLvxTBToaai6IzooTWZfhIlstl3ZVl0oVN3C+H6yZWw V3Js4jQapFAz7ghqPt7x9i39euqaKeecXjEGToO53FkDBzd2E/TgdIw4m+uBR21CE3qF kXJz+AprOLtc4XV2rfMJsgddxNQaOo6wXRWhLSDWHv4tdhT2KQKdT+Gw7ghGCEZ8jOWg b5hsBG81XrJ8PRwx+FZQhkoBPWTyKDQ5uyzEqAxggEMbsn3NasU6rT7Ocw3Td9pVkKPN QNCA== X-Gm-Message-State: AIkVDXI3cAGW6lqDso1NeUdSaQmiGELZqcf9ZqJUj32VDE3sNuEHm4zRIUNHdFu+ZY91Vo4w6Ng4Lh+sO8yVl4kF X-Received: by 10.107.59.69 with SMTP id i66mr2908277ioa.10.1484737033776; Wed, 18 Jan 2017 02:57:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Wed, 18 Jan 2017 02:56:43 -0800 (PST) In-Reply-To: <20170112142840.8c95f645172301b0facfc29c@andrewayer.name> References: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> <20170112142840.8c95f645172301b0facfc29c@andrewayer.name> From: Eran Messeri Date: Wed, 18 Jan 2017 10:56:43 +0000 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=001a114f7de47bf70605465c47d4 Archived-At: Cc: Ryan Sleevi , "trans@ietf.org" Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 18 Jan 2017 10:57:16 -0000 --001a114f7de47bf70605465c47d4 Content-Type: text/plain; charset=UTF-8 Thanks all for the feedback, which I've attempted summarizing below, let me know if I've missed something: - Navigating to hosts by IP which have SSL certificates logged in CT logs would now be disclosed to the UA's resolver. A mitigation could be not looking up inclusion proofs for these if data shows this is a common use case. - Inclusion proof queries may end up going through different resolvers if there's a local authoritative resolver for the domain in question: The same scenario mentioned in discussions about name redaction, where internal host-names (which are resolved by a local, authoritative resolver within an organization's network boundary, not resolvable outside of it) are secured by public CA certificates. In that scenario, it seems to me the inclusion proof queries would originate from a small number of recursive resolvers within that organization, given UAs outside the organization's network shouldn't ever observe these certificates. - Unknown how many IPs are served by recursive resolvers, as some recursive resolvers may serve very few clients or the possibility of user clustering: That's no worse than the current system, isn't it? I believe (hope!) home routers run forwarding resolvers that'd forward to the ISP's DNS servers, so only users who run their own recursive resolvers are affected, and what they disclose to the authoritative resolver for inclusion proof queries is the same as what's disclosed to root servers. - Privacy analysis in the context of client identification mechanisms: Something I definitely intend to look into, once there's consensus that the privacy analysis for this protocol is accurate (no point evaluating it in the context of other client identification mechanisms beforehand). - Resource Hints: Not sure I see how that's related to this discussion. Ryan, can you elaborate? On Thu, Jan 12, 2017 at 10:28 PM, Andrew Ayer wrote: > On Thu, 12 Jan 2017 12:32:54 -0800 > Ryan Sleevi wrote: > > > On Thu, Jan 12, 2017 at 9:42 AM, Andrew Ayer > > wrote: > > > I. Under the "Certificates for hosts whose address was not obtained > > > via DNS lookup" section, a few scenarios come to mind: > > > > > > 1. The host was accessed by IP address. > > > > To expand on this: Your assumption/model here is that the DNS resolver > > learns this information, but they are not otherwise on-path, correct? > > That is, imagine a user using a resolver of 8.8.8.8 - presumably, > > Google's not malicious, but this would disclose to them IP-based > > connections? > > It would disclose the IP-based connection to the resolver, the log's DNS > frontend, and any eavesdropper along the path taken by the DNS query. > > Normally when you initiate a connection based on IP address, no one learns > about it except for nodes along the path to the endpoint (assuming no > OCSP), and that path might not even traverse the public Internet. > > > > 2. The hostname was resolved by a SOCKS proxy server. > > > > This is only relevant to clients that support SOCKSv5-based > > resolutions, right? > > Also clients that support SOCKS4a. > > > And is this just a specialized form of "using a > > different resolver"? Or do you think it's distinct? > > It could be seen as a specialized form of using a different resolver. > (To be pedantic, the hostname lookup is not performed by the UA and the > SOCKS server might not even use DNS, which is why it seemed to fit better > in the "not obtained via DNS" category.) > > > > I think more data is needed before concluding that this > > > approach provides the desired privacy. Could Chrome run an > > > experiment which resolves a DNS record for a hostname of the form > > > ., and measure how many > > > different es per recursive server are > > > observed over various time periods by the authoritative servers > > > for ? > > > > In expanding on your hypothetical test, what's the outcome or desired > > property that you're trying to measure? I imagine a total number of > > distinct IPs is itself not meaningful to such an analysis. > > We would want to know the number of distinct es > per DNS resolver IP address that sends a DNS query for . > The desired property is that this number is high for most DNS resolvers, > as this indicates that there is privacy value to using DNS instead of > fetching inclusion proofs directly from logs. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114f7de47bf70605465c47d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks all for the feedback, which I've attempted summ= arizing below, let me know if I've missed something:

- Navigating to hosts by IP which have SSL certificates logged in CT logs = would now be disclosed to the UA's resolver. A mitigation could be not = looking up inclusion proofs for these if data shows this is a common use ca= se.

- Inclusion proof queries may end up going thr= ough different resolvers if there's a local authoritative resolver for = the domain in question: The same scenario mentioned in discussions about na= me redaction, where internal host-names (which are resolved by a local, aut= horitative resolver within an organization's network boundary, not reso= lvable outside of it) are secured by public CA certificates. In that scenar= io, it seems to me the inclusion proof queries would originate from a small= number of recursive resolvers within that organization, given UAs outside = the organization's network shouldn't ever observe these certificate= s.

- Unknown how many IPs are served by recursive = resolvers, as some recursive resolvers may serve very few clients or the po= ssibility of user clustering: That's no worse than the current system, = isn't it? I believe (hope!) home routers run forwarding resolvers that&= #39;d forward to the ISP's DNS servers, so only users who run their own= recursive resolvers are affected, and what they disclose to the authoritat= ive resolver for inclusion proof queries is the same as what's disclose= d to root servers.

- Privacy analysis in the conte= xt of client identification mechanisms: Something I definitely intend to lo= ok into, once there's consensus that the privacy analysis for this prot= ocol is accurate (no point evaluating it in the context of other client ide= ntification mechanisms beforehand).

- Resource Hin= ts: Not sure I see how that's related to this discussion. Ryan, can you= elaborate?


On Thu, Jan 12, 2017 at 10:28 PM, Andrew Ayer <agw= a@andrewayer.name> wrote:
<= span class=3D"">On Thu, 12 Jan 2017 12:32:54 -0800
Ryan Sleevi <ryan-ietf@sleevi.co= m> wrote:

> On Thu, Jan 12, 2017 at 9:42 AM, Andrew Ayer <agwa@andrewayer.name>
> wrote:
> > I. Under the "Certificates for hosts whose address was not o= btained
> > via DNS lookup" section, a few scenarios come to mind:
> >
> > 1. The host was accessed by IP address.
>
> To expand on this: Your assumption/model here is that the DNS resolver=
> learns this information, but they are not otherwise on-path, correct?<= br> > That is, imagine a user using a resolver of 8.8.8.8 - presumably,
> Google's not malicious, but this would disclose to them IP-based > connections?

It would disclose the IP-based connection to the resolver, the log&#= 39;s DNS
frontend, and any eavesdropper along the path taken by the DNS query.

Normally when you initiate a connection based on IP address, no one learns<= br> about it except for nodes along the path to the endpoint (assuming no
OCSP), and that path might not even traverse the public Internet.

> > 2. The hostname was resolved by a SOCKS proxy server.
>
> This is only relevant to clients that support SOCKSv5-based
> resolutions, right?

Also clients that support SOCKS4a.

> And is this just a specialized form of "using a
> different resolver"? Or do you think it's distinct?

It could be seen as a specialized form of using a different resolver= .
(To be pedantic, the hostname lookup is not performed by the UA and the
SOCKS server might not even use DNS, which is why it seemed to fit better in the "not obtained via DNS" category.)

> > I think more data is needed before concluding that this
> > approach provides the desired privacy.=C2=A0 Could Chrome run an<= br> > > experiment which resolves a DNS record for a hostname of the form=
> > <client-public-IP-address>.<test-domain>, and me= asure how many
> > different <client-public-IP-address>es per recursive server= are
> > observed over various time periods by the authoritative servers > > for <test-domain>?
>
> In expanding on your hypothetical test, what's the outcome or desi= red
> property that you're trying to measure? I imagine a total number o= f
> distinct IPs is itself not meaningful to such an analysis.

We would want to know the number of distinct <client-public-IP-ad= dress>es
per DNS resolver IP address that sends a DNS query for <test-domain>.=
The desired property is that this number is high for most DNS resolvers, as this indicates that there is privacy value to using DNS instead of
fetching inclusion proofs directly from logs.

Regards,
Andrew

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

--001a114f7de47bf70605465c47d4-- From nobody Wed Jan 18 04:43:30 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 DD3E8129696 for ; Wed, 18 Jan 2017 04:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Wzu0qYUKQBEM for ; Wed, 18 Jan 2017 04:43:26 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 A79E6129699 for ; Wed, 18 Jan 2017 04:43:25 -0800 (PST) Received: (qmail 3434 invoked by uid 1004); 18 Jan 2017 12:43:23 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 18 Jan 2017 12:43:23 +0000 Received: (qmail 11186 invoked by uid 1000); 18 Jan 2017 12:43:22 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 18 Jan 2017 12:43:22 +0000 To: Bill Frantz References: From: Rob Stradling Message-ID: <9b7633ec-7b54-6d6c-1660-edaaa673c4bb@comodo.com> Date: Wed, 18 Jan 2017 12:43:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Tom Ritter , trans@ietf.org Subject: Re: [Trans] Minimum SCT age (was Re: 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: Wed, 18 Jan 2017 12:43:29 -0000 On 18/01/17 00:32, Bill Frantz wrote: > On 1/17/17 at 9:16 AM, rob.stradling@comodo.com (Rob Stradling) wrote: > >> On 17/01/17 17:07, Tom Ritter wrote: > >> >>> It also assumes the client has a clock that is correct to the order of >>> a few days... >> >> True. Is it, or might it soon be, reasonable to make that assumption? >> >> e.g., https://roughtime.googlesource.com/roughtime sounds promising, I >> think. > > Machines such as the Raspberry PI and the Beaglebone do not have clock > chips, although it is easy to add an external real time clock board. > They can set their clocks from NTP if they have internet access, which > is more-or-less needed to run a browser, unless running on private > network. I can see scenerios where they can have a very badly off clock > though. Is it (or might it soon be) reasonable to expect a TLS client to know whether or not it has a reliable time source? If so, then TLS clients could just ignore "minimum SCT ages" when they're insufficiently confident of when "now" is. As a way of dealing with clocks that are far behind, perhaps TLS clients that implement CT could treat any observed SCT timestamp (that corresponds to any observed cert) and any observed STH timestamp as trustworthy evidence that these timestamps are in the past rather than in the future. (If multiple SCTs/STHs from multiple logs all agree that time X is in the past, then the TLS client can have even greater confidence that this is indeed so). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jan 18 05:29:39 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 828E912943F for ; Wed, 18 Jan 2017 05:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 tO_Bg0OvZLox for ; Wed, 18 Jan 2017 05:29:35 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 7E2141270B4 for ; Wed, 18 Jan 2017 05:29:35 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id l66so11577717ioi.1 for ; Wed, 18 Jan 2017 05:29:35 -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=LtWuf26vJF9PU9te0EPlUXY+0j5pC7vnPjuqRdUkhpE=; b=rMXHHgiSeT0wFLle8lfwcMkPHC3MZKMkAqCYy905Ftn598njxMv77dVObRH2Az9oiC pOpCb9snz5ugQR14u3OzIV6715d4AmXZtNXCJ7hW9fXNgSuuVW/4iuHebvW8kLTFHEu+ 9d6iX7BE2im44gRnUOYZZO3qUxLV2zclX43tbNhq/MhcDACd8DJwOdLQHZ3Xr+wIDGi4 laPLripXssUnQJB1tjawdFRsNUC+EoEKuFYhnip0aNmIqFKsDI4rBH2Ar2Wzs4xeGI1o 0Y5T9JQVZfA2tlWkK17gk1EwiUuXdepuTK9knFeJnpC2r0Mfl5UWMCvViugTaWtKMzNW R9kA== 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=LtWuf26vJF9PU9te0EPlUXY+0j5pC7vnPjuqRdUkhpE=; b=bKjrtoa274Fecy3y8uNb9OzVRL+juBY92Jb7EGuO/1nkxrqmMSg+Xa7z9saDHRtnoj b+jgyoJ6zFljKfUVrOuSP3NRC4LZAPiZVU9SuezuQqV+nndArLapmFk5p0StEkAY1d98 I7DDc/uDjgYrGNccqZTU01QsbavBaTuIuc+eEjSrhySBnftWxuuroZOL0zY6vQqpYiot rbpaERvsqawgWtU+V+bXtBr8c5Cv4bNzh1FWxKZLVdsZVox4jb/r4tkAnlLjZeFstLgj 7mRnjg6Nqp6hdkfJ69h/vvpqo6K3dsUbEU1LPQUuUREu094yg7AobWcYv9eVdAKBC9wC XpjA== X-Gm-Message-State: AIkVDXJXbMpC7HAQ8KIOsdvuU7G/W6TkNDl6m+Ja3nnfSAa1bCDlv2TfphA+qFrYm9SdjIQ3LR5gje5FsFJvrdkb X-Received: by 10.107.136.40 with SMTP id k40mr3178012iod.99.1484746174575; Wed, 18 Jan 2017 05:29:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Wed, 18 Jan 2017 05:29:04 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Wed, 18 Jan 2017 13:29:04 +0000 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a113ecff451a4d105465e6881 Archived-At: Cc: Eric Rescorla , Paul Wouters , "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: Wed, 18 Jan 2017 13:29:38 -0000 --001a113ecff451a4d105465e6881 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I find this analysis very useful, though some of it seems to be based on different security model than the one we currently use for CT (and as Paul pointed out, 6962 and 6962-bis are about =E2=80=9Cexposing rogue parties=E2= =80=9D). The analysis is correct on the difficulty of public verifiability when only SCTs are used, which we=E2=80=99re addressing by implementing the DNS-based= protocol (in part t= o get data about its reliability). There=E2=80=99s academic work underway to = get inclusion proofs, and report log misbehaviour, in a privacy-preserving manner (I hope to be able to share a paper soon). Ultimately I agree with Richard=E2=80=99s analysis and Andrew Ayer=E2=80=99= s comment , that inclusion proofs (and the STHs they chain to) should be embedded in the certificate, together with the SCT. 6962-bis specifies the mechanism to do it and UAs can require it as a policy. The claim that =E2=80=9CCT=E2=80=99s public verifiability mechanisms are to= o inefficient to be deployed at scale=E2=80=9D is based on the following operating assumptio= ns for CT (my understanding from an out-of-band chat with Richard): - The goal is to not require auditing after the fact but have all auditing information beforehand (stronger model). - Logs issue STHs every 8 minutes. - SCTs are augmented with inclusion proofs up to the STHs covering them. - Clients download all STHs, check consistency and store them. - When a certificate with SCT and inclusion proof is observed, it is rejected if it=E2=80=99s not chaining up to one of the STHs in the client= =E2=80=99s storage. If it is, then the SCT=E2=80=99s signature and inclusion proof are= checked. This variation of CT is supposed to provide security against log misbehaviour but is still deemed too expensive to deploy at the cost of 4MB/month of data for each client. However: - This assumes CAs are happy to wait 8 minutes for certificate issuance (issuance bandwidth is high, but that benefits only large-volume CAs). - It effectively brings down the MMD to 8 minutes. - What about clients that have been offline for a while and have yet to catch up with recently-issued STHs? If SSL connections are blocked until a client catches up, that=E2=80=99s equivalent to on-line certificate checks = (OCSP). - A clear-cached-load of Facebook clocks at 1.6MB, slashdot.org 3.2MB, bbc.co.uk 875KB, which should give some context for the 4MB/month cost (note not all clients have to participate; herd immunity means all clientns benefit even if only some audit logs). - Equivocation may not be possible, but the threat of logs presenting split-views remains (even if all clients start with a =E2=80=9Ctrusted=E2= =80=9D STH) - a collaborative way to compare the view logs present is still necessary (our auditing implementation in Chrome does not require it as STHs are pushed daily to clients). Exploration of different schemes for CT with stronger guarantees should be independent of 6962-bis. 6962-bis allows us to address some of the issues with 6962 (like enabling embedding of inclusion proofs) and even trial variants (using the extensions mechanisms). Hearing a major UA vendor state that CAs should tolerate some latency during certificate issuance for the benefit of the ecosystem is exciting news. We can do it with 6962-bis: newer CT log implementations and the upcoming Trillian based implementation are capable of integrating added chains into the tree within O(tens of seconds to minutes). Different, potentially simpler, systems can be built under that assumption (and I=E2= =80=99ll let proper cryptographers suggest them :)). Eran On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes wrote: > > > On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters wrote: > >> On Mon, 16 Jan 2017, Richard Barnes wrote: >> >> Speaking as individual only... >> >> - It is not practical to build a publicly verifiable log system that >>> incorporates SCTs >>> - The existing tools for public verifiability need to be made more >>> efficient in order to work on the scale >>> envisioned >>> >> >> So I think there might be a different perception here of the goal of >> CT. I think you are looking at a 100% catch-before-it-happens >> scenario. While the document is only about "exposing rogue parties". >> > > Those two goals are not as different as you might think. Either way, you > need for the client to detect equivocation. You need the same data; it's > just a question of when. > > > >> Fundamentally, CT is a public ledger system: every certificate is >>> supposed to be entered into a log and RPs >>> only accept certificates which are logged. In order for this to work >>> properly, RPs need to be able to verify >>> that there is public consensus about the state of the log. Otherwise, >>> logs can =E2=80=9Cequivocate=E2=80=9D: represent to the >>> RP that a given certificate was published when it in fact was not. >>> Unfortunately, in practice RPs are not >>> doing this verification (for reasons discussed below), and so CT reduce= s >>> to a countersignature scheme in which >>> the RP trusts the log not to equivocate. There are two primary >>> challenges here, as detailed below. >>> >> >> The monitors are supposed to use multiple logs, presumably not all of >> which are colluding. So a rogue log would be found out and lose its >> trust? Maybe not in time for this one client visiting this one website, >> but that was never the expected goal of CT. >> > > I think you mean "RPs" where you say "monitors", right? > > Even in this scenario, in order for the rogue log to be found out, you > still need a system for detecting equivocation, which we don't have now. > > > >> It has been known for quite some time that the public verifiability piec= e >>> of CT introduces latency in >>> certificate issuance. In order to allow for immediate certificate >>> issuance, logs instead issue SCTs, which are >>> just promises to incorporate the certificate into the log; effectively >>> the SCT is a countersignature on the >>> certificate. However, if an RP accepts a certificate + SCT, then it is >>> vulnerable to collusion between a CA >>> which issues a bogus cert and a log which issues a bogus SCT but never >>> incorporates the cert into the log. >>> >> >> So that is someting monitors should look at. >> >> We are unaware of any way to efficiently address this issue without >>> introducing either privacy problems or >>> latency. In order to validate inclusion in the log, the RP needs to >>> validate that other entities (e.g., the >>> software manufacturer) have the same view of the log. Either the RP >>> downloads the whole log (which is >>> inefficient), queries for the specific certificate in question (which >>> has privacy problems) or retrieves a >>> checkpoint which vouches for some batch of certificates (which >>> introduces batch latency). >>> >> >> So personally, I would like to know that ACME-style issued certificates >> would start being accepted within a few minutes. At least for those >> sites that did not have a certificate before. If we are talking about >> renewing, then it should be able to properly submit new entries to log >> before actually activating the new certs, so some latency wouldn't matte= r. >> > > As I noted in my little quantitative analysis, you can get the data > structures down to a reasonable size with a ~8min issuance delay if you'r= e > willing to refactor the log structure. > > --Richard > > > >> >> Am I missing something? >> >> Paul >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a113ecff451a4d105465e6881 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I find this analysis very useful, though some of it s= eems to be based on different security model than the one we currently use = for CT (and as Paul pointed out, 6962 and 6962-bis are about =E2=80=9Cexpos= ing rogue parties=E2=80=9D).

The analysis is corre= ct on the difficulty of public verifiability when only SCTs are used, which= we=E2=80=99re addressing by implementing the DNS-based protocol (in pa= rt to get data about its reliability). There=E2=80=99s academic work underw= ay to get inclusion proofs, and report log misbehaviour, in a privacy-prese= rving manner (I hope to be able to share a paper soon).=C2=A0
Ultimately I agree with Richard=E2=80=99s analysis and Andr= ew Ayer=E2=80=99s comment, that inclusion proofs (and the STHs they cha= in to) should be embedded in the certificate, together with the SCT.
<= div>6962-bis specifies the mechanism to do it and UAs can requ= ire it as a policy.

The claim that =E2=80=9CCT=E2= =80=99s public verifiability mechanisms are too inefficient to be deployed = at scale=E2=80=9D is based on the following operating assumptions for CT (m= y understanding from an out-of-band chat with Richard):
- The goa= l is to not require auditing after the fact but have all auditing informati= on beforehand (stronger model).
- Logs issue STHs every 8 minutes= .
- SCTs are augmented with inclusion proofs up to the STHs cover= ing them.
- Clients download all STHs, check consistency and stor= e them.
- When a certificate with SCT and inclusion proof is obse= rved, it is rejected if it=E2=80=99s not chaining up to one of the STHs in = the client=E2=80=99s storage. If it is, then the SCT=E2=80=99s signature an= d inclusion proof are checked.

This variation of C= T is supposed to provide security against log misbehaviour but is still dee= med too expensive to deploy at the cost of 4MB/month of data for each clien= t. However:
- This assumes CAs are happy to wait 8 minutes for ce= rtificate issuance (issuance bandwidth is high, but that benefits only larg= e-volume CAs).
- It effectively brings down the MMD to 8 minutes.=
- What about clients that have been offline for a while and have= yet to catch up with recently-issued STHs? If SSL connections are blocked = until a client catches up, that=E2=80=99s equivalent to on-line certificate= checks (OCSP).
- A clear-cached-load of Facebook clocks at 1.6MB= , slashdot.org 3.2MB, bbc.co.uk 875KB, which should give some context for the 4MB= /month cost (note not all clients have to participate; herd immunity means = all clientns benefit even if only some audit logs).
- Equivocatio= n may not be possible, but the threat of logs presenting split-views remain= s (even if all clients start with a =E2=80=9Ctrusted=E2=80=9D STH) - a coll= aborative way to compare the view logs present is still necessary (our auditing implementation= in Chrome does not require it as STHs are pushed daily to clients).

Exploration of different schemes for CT with stronge= r guarantees should be independent of 6962-bis.
6962-bis allows u= s to address some of the issues with 6962 (like enabling embedding of inclu= sion proofs) and even trial variants (using the extensions mechanisms).

Hearing a major UA vendor state that CAs should toler= ate some latency during certificate issuance for the benefit of the ecosyst= em is exciting news. We can do it with 6962-bis: newer CT log implementatio= ns and the upcoming Trillian based implementation are capable of integratin= g added chains into the tree within O(tens of seconds to minutes). Differen= t, potentially simpler, systems can be built under that assumption (and I= =E2=80=99ll let proper cryptographers suggest them :)).

Eran

On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes <= rlb@ipv.sx> w= rote:


On Tue, Jan 17= , 2017 at 10:34 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 16 Jan 2017, Richard Barnes wrote:

Speaking as individual only...

- It is not practical to build a publicly verifiable log system that incorp= orates SCTs
- The existing tools for public verifiability need to be made more efficien= t in order to work on the scale
envisioned

 So I think there might be a different perception here of the goal of
CT. I think you are looking at a 100% catch-before-it-happens
scenario. While the document is only about "exposing rogue parties&quo= t;.

Those two goals= are not as different as you might think.=C2=A0 Either way, you need for th= e client to detect equivocation.=C2=A0 You need the same data; it's jus= t a question of when.

=C2=A0
Fundamentally, CT is a public ledger system: every certificate is supposed = to be entered into a log and RPs
only accept certificates which are logged. In order for this to work proper= ly, RPs need to be able to verify
that there is public consensus about the state of the log. Otherwise, logs = can =E2=80=9Cequivocate=E2=80=9D: represent to the
RP that a given certificate was published when it in fact was not. Unfortun= ately, in practice RPs are not
doing this verification (for reasons discussed below), and so CT reduces to= a countersignature scheme in which
the RP trusts the log not to equivocate. There are two primary challenges h= ere, as detailed below.

 The monitors are supposed to use multiple logs, presumably not all of
which are colluding. So a rogue log would be found out and lose its
trust? Maybe not in time for this one client visiting this one website,
but that was never the expected goal of CT.

I think you mean "RPs" where you say &qu= ot;monitors", right?

Even in this scenario, in order= for the rogue log to be found out, you still need a system for detecting e= quivocation, which we don't have now.

=C2=A0
It has been known for quite some time that the public verifiability piece o= f CT introduces latency in
certificate issuance. In order to allow for immediate certificate issuance,= logs instead issue SCTs, which are
just promises to incorporate the certificate into the log; effectively the = SCT is a countersignature on the
certificate. However, if an RP accepts a certificate + SCT, then it is vuln= erable to collusion between a CA
which issues a bogus cert and a log which issues a bogus SCT but never inco= rporates the cert into the log.

 So that is someting monitors should look at.

We are unaware of any way to efficiently address this issue without introdu= cing either privacy problems or
latency. In order to validate inclusion in the log, the RP needs to validat= e that other entities (e.g., the
software manufacturer) have the same view of the log. Either the RP downloa= ds the whole log (which is
inefficient), queries for the specific certificate in question (which has p= rivacy problems) or retrieves a
checkpoint which vouches for some batch of certificates (which introduces b= atch latency).

 So personally, I would like to know that ACME-style issued certificates
would start being accepted within a few minutes. At least for those
sites that did not have a certificate before. If we are talking about
renewing, then it should be able to properly submit new entries to log
before actually activating the new certs, so some latency wouldn't matt= er.

As I noted in my little quan= titative analysis, you can get the data structures down to a reasonable siz= e with a ~8min issuance delay if you're willing to refactor the log str= ucture.

--Richard

=C2=A0

Am I missing something?

Paul


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


--001a113ecff451a4d105465e6881-- From nobody Wed Jan 18 07:13: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 239251293EE for ; Wed, 18 Jan 2017 07:13:04 -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 ZBD0XebHmj2x for ; Wed, 18 Jan 2017 07:13:00 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 9705A1293E1 for ; Wed, 18 Jan 2017 07:13:00 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 35so11429727uak.1 for ; Wed, 18 Jan 2017 07:13:00 -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=Eo+Tne6DDzqjc4uw1qBgYu8r5LFZefHP/84vRQeL4w0=; b=qYfOMWWZNK+4wwu1MWVBFD4/sRBMH4y52WMYAC/7PRseEzNEGNvd21xRhUo6v17DIq rLYVA59KorO/TLKUEFEC3/kG42crB6aBEYBscGbSWY2f3l67OwzXBoHBIuSYkss3GLtk p9lHn/6r8a3qT43VP72lPwyYgnDmpMIp9S+mdraezqj+jqmp6/iXKIza10IPDQcuHNkn 7KwHsz1lMfFR0kDt6gRlGxz22XhtYhkEcHbbb9XPID8Z1cQ2odciaJgvo67hGr1ZFSu4 6/WUy71tU8mcbDagZw0G+0bikJn8qd8spIbn0FzHed1Cy/25cJY+CxKMo8YNE8ld/Hzr U48g== 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=Eo+Tne6DDzqjc4uw1qBgYu8r5LFZefHP/84vRQeL4w0=; b=f7gyDnRGbsq7+TU1qNQnBAU3X06I7Q7JwFW+LqU5T/ToBtj4N6VnCTWT06cx2YlhJB ZRhLJTs3lnuzgsEGG1F3cvsRyAT+z61MQHj8yeUuPOW1qao6nNEHnnSb8ZW3n8km6dLZ F5j2OPkFA4o1w2ISdabQcJMSTkj6oNm+313eQMwf9q84ZvKQb4Ymj44PuxfpSywqdn6O xzOG5dVYTzxPctJKFxAi9Pg9Xhfb5C3nrBuk4KQgnOi75Fv8CzzxzZSSnAw8B6XgOP59 82V3z/9h1lp6urGGkbaLdpOOeC/NJ/0GXYPQ7563tLpezll+/L1sI6VXD5ZwswP2ucAF GlLA== X-Gm-Message-State: AIkVDXJloS2KjYCM+/9xbnmyI7p5VZOYlRFGqU3ubfDr7XgACmwHHmyN2PeEHWCUDTEvgg9cNa8Ws0L4/YMnxw== X-Received: by 10.159.41.198 with SMTP id s64mr2108729uas.72.1484752379541; Wed, 18 Jan 2017 07:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Wed, 18 Jan 2017 07:12:59 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Wed, 18 Jan 2017 10:12:59 -0500 Message-ID: To: Eran Messeri Content-Type: multipart/alternative; boundary=001a1148d93a2a00e505465fdae8 Archived-At: Cc: Eric Rescorla , Paul Wouters , "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: Wed, 18 Jan 2017 15:13:04 -0000 --001a1148d93a2a00e505465fdae8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 18, 2017 at 8:29 AM, Eran Messeri wrote: > I find this analysis very useful, though some of it seems to be based on > different security model than the one we currently use for CT (and as Pau= l > pointed out, 6962 and 6962-bis are about =E2=80=9Cexposing rogue parties= =E2=80=9D). > Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue logs. Without some sort of consistency checking mechanism, logs can lie without any risk of discovery. That is true of CT as deployed today. There is no way to detect a rogue log. And a consistency checking mechanism only creates risk to rogue logs to the degree that it is deployed and used. If only 5% of SCTs ever get checked for consistency, then a rogue log has a 95% chance of getting away with any particular lie. So we really need consistency checking at scale. > The analysis is correct on the difficulty of public verifiability when > only SCTs are used, which we=E2=80=99re addressing by implementing the DN= S-based > protocol > (in part to get data about its reliability). There=E2=80=99s academic wor= k underway > to get inclusion proofs, and report log misbehaviour, in a > privacy-preserving manner (I hope to be able to share a paper soon). > > Ultimately I agree with Richard=E2=80=99s analysis and Andrew Ayer=E2=80= =99s comment > , that > inclusion proofs (and the STHs they chain to) should be embedded in the > certificate, together with the SCT. > 6962-bis specifies the mechanism > > to do it and UAs can require it as a policy. > ... and I definitely agree that 6962-bis is an improvement over 6962 in this regard! > > The claim that =E2=80=9CCT=E2=80=99s public verifiability mechanisms are = too inefficient > to be deployed at scale=E2=80=9D is based on the following operating assu= mptions > for CT (my understanding from an out-of-band chat with Richard): > - The goal is to not require auditing after the fact but have all auditin= g > information beforehand (stronger model). > - Logs issue STHs every 8 minutes. > - SCTs are augmented with inclusion proofs up to the STHs covering them. > - Clients download all STHs, check consistency and store them. > - When a certificate with SCT and inclusion proof is observed, it is > rejected if it=E2=80=99s not chaining up to one of the STHs in the client= =E2=80=99s > storage. If it is, then the SCT=E2=80=99s signature and inclusion proof a= re checked. > > This variation of CT is supposed to provide security against log > misbehaviour but is still deemed too expensive to deploy at the cost of > 4MB/month of data for each client. However: > - This assumes CAs are happy to wait 8 minutes for certificate issuance > (issuance bandwidth is high, but that benefits only large-volume CAs). > - It effectively brings down the MMD to 8 minutes. > - What about clients that have been offline for a while and have yet to > catch up with recently-issued STHs? If SSL connections are blocked until = a > client catches up, that=E2=80=99s equivalent to on-line certificate check= s (OCSP). > - A clear-cached-load of Facebook clocks at 1.6MB, slashdot.org 3.2MB, > bbc.co.uk 875KB, which should give some context for the 4MB/month cost > (note not all clients have to participate; herd immunity means all client= ns > benefit even if only some audit logs). > - Equivocation may not be possible, but the threat of logs presenting > split-views remains (even if all clients start with a =E2=80=9Ctrusted=E2= =80=9D STH) - a > collaborative way to compare the view logs present is still necessary (ou= r auditing > implementation in Chrome > does not require it as STHs are pushed daily to clients). > > Exploration of different schemes for CT with stronger guarantees should b= e > independent of 6962-bis. > The problem here is that the document is not clear about what guarantees it provides, and where it tries to explain clearly it assumes a mechanism for auditing SCTs exists. For example: """ If a server presents a valid signed timestamp for a certificate, then the client knows that a log has committed to publishing the certificate. From this, the client knows that monitors acting for the subject of the certificate have had some time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate, or that the log has misbehaved, which will be discovered when the SCT is audited. """ The problem here is that there is no effective mechanism for auditing SCTs right now. The DNS thing you mention might work, though it seems to me to have really poor scaling properties (and it is completely unimplementable in Firefox, for software reasons). Or the log refactoring I'm proposing might work. But we're clearly pretty far from consensus here. So either we need to block this document on the creation of some auditing mechanism that we all feel comfortable with, or we need to put some clear warning labels on this thing in terms of the guarantees it provides, and in particular, its vulnerability to rogue logs. > 6962-bis allows us to address some of the issues with 6962 (like enabling > embedding of inclusion proofs) and even trial variants (using the > extensions mechanisms). > > Hearing a major UA vendor state that CAs should tolerate some latency > during certificate issuance for the benefit of the ecosystem is exciting > news. We can do it with 6962-bis > Indeed, it sounds like we've got some consensus here at least on the browser side of things that CAs and servers should be moving from SCTs towards inclusion proofs. I think there are a couple of straightforward things we could add to the document to facilitate that transition: * Adding an explicit lifetime to SCTs and a recommendation that RPs impose a maximum lifetime on SCTs on the order of the STH issuance frequency of the log * Adding a recommendation that RPs require signatures from multiple logs Those changes would bound the risk from SCTs in the short run, and give us a tool to phase out SCTs in the long run (in favor of inclusion proofs). > : newer CT log implementations and the upcoming Trillian based > implementation are capable of integrating added chains into the tree with= in > O(tens of seconds to minutes). > I would be interested to know what about the operation of adding to the tree causes this degree of latency. To be honest, it seems pretty extreme, given the rates at which CAs are capable of operating these days. In particular, I wonder if this is another example of the pain we have pain we have undertaken by having a single global Merkle tree instead of some more flexible structure. --Richard > Different, potentially simpler, systems can be built under that assumptio= n > (and I=E2=80=99ll let proper cryptographers suggest them :)). > > Eran > > On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes wrote: > >> >> >> On Tue, Jan 17, 2017 at 10:34 AM, Paul Wouters wrote: >> >>> On Mon, 16 Jan 2017, Richard Barnes wrote: >>> >>> Speaking as individual only... >>> >>> - It is not practical to build a publicly verifiable log system that >>>> incorporates SCTs >>>> - The existing tools for public verifiability need to be made more >>>> efficient in order to work on the scale >>>> envisioned >>>> >>> >>> So I think there might be a different perception here of the goal of >>> CT. I think you are looking at a 100% catch-before-it-happens >>> scenario. While the document is only about "exposing rogue parties". >>> >> >> Those two goals are not as different as you might think. Either way, yo= u >> need for the client to detect equivocation. You need the same data; it'= s >> just a question of when. >> >> >> >>> Fundamentally, CT is a public ledger system: every certificate is >>>> supposed to be entered into a log and RPs >>>> only accept certificates which are logged. In order for this to work >>>> properly, RPs need to be able to verify >>>> that there is public consensus about the state of the log. Otherwise, >>>> logs can =E2=80=9Cequivocate=E2=80=9D: represent to the >>>> RP that a given certificate was published when it in fact was not. >>>> Unfortunately, in practice RPs are not >>>> doing this verification (for reasons discussed below), and so CT >>>> reduces to a countersignature scheme in which >>>> the RP trusts the log not to equivocate. There are two primary >>>> challenges here, as detailed below. >>>> >>> >>> The monitors are supposed to use multiple logs, presumably not all of >>> which are colluding. So a rogue log would be found out and lose its >>> trust? Maybe not in time for this one client visiting this one website, >>> but that was never the expected goal of CT. >>> >> >> I think you mean "RPs" where you say "monitors", right? >> >> Even in this scenario, in order for the rogue log to be found out, you >> still need a system for detecting equivocation, which we don't have now. >> >> >> >>> It has been known for quite some time that the public verifiability >>>> piece of CT introduces latency in >>>> certificate issuance. In order to allow for immediate certificate >>>> issuance, logs instead issue SCTs, which are >>>> just promises to incorporate the certificate into the log; effectively >>>> the SCT is a countersignature on the >>>> certificate. However, if an RP accepts a certificate + SCT, then it is >>>> vulnerable to collusion between a CA >>>> which issues a bogus cert and a log which issues a bogus SCT but never >>>> incorporates the cert into the log. >>>> >>> >>> So that is someting monitors should look at. >>> >>> We are unaware of any way to efficiently address this issue without >>>> introducing either privacy problems or >>>> latency. In order to validate inclusion in the log, the RP needs to >>>> validate that other entities (e.g., the >>>> software manufacturer) have the same view of the log. Either the RP >>>> downloads the whole log (which is >>>> inefficient), queries for the specific certificate in question (which >>>> has privacy problems) or retrieves a >>>> checkpoint which vouches for some batch of certificates (which >>>> introduces batch latency). >>>> >>> >>> So personally, I would like to know that ACME-style issued certificates >>> would start being accepted within a few minutes. At least for those >>> sites that did not have a certificate before. If we are talking about >>> renewing, then it should be able to properly submit new entries to log >>> before actually activating the new certs, so some latency wouldn't >>> matter. >>> >> >> As I noted in my little quantitative analysis, you can get the data >> structures down to a reasonable size with a ~8min issuance delay if you'= re >> willing to refactor the log structure. >> >> --Richard >> >> >> >>> >>> Am I missing something? >>> >>> Paul >>> >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --001a1148d93a2a00e505465fdae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 8:29 AM, Eran Messeri <eranm@google.com>= wrote:
I find this analysis very useful, though some of it seems to= be based on different security model than the one we currently use for CT = (and as Paul pointed out, 6962 and 6962-bis are about =E2=80=9Cexposing rog= ue parties=E2=80=9D).

Let me ag= ain bust this myth that 6962 / 6962-bis do anything to expose rogue logs.= =C2=A0 Without some sort of consistency checking mechanism, logs can lie wi= thout any risk of discovery.=C2=A0 That is true of CT as deployed today.=C2= =A0 There is no way to detect a rogue log.

And a consistency checkin= g mechanism only creates risk to rogue logs to the degree that it is deploy= ed and used.=C2=A0 If only 5% of SCTs ever get checked for consistency, the= n a rogue log has a 95% chance of getting away with any particular lie.=C2= =A0 So we really need consistency checking at scale.

=C2= =A0
The analysis is correct on the difficulty of public verifiability whe= n only SCTs are used, which we=E2=80=99re addressing by i= mplementing the DNS-based protocol (in part to get data about its relia= bility). There=E2=80=99s academic work underway to get inclusion proofs, an= d report log misbehaviour, in a privacy-preserving manner (I hope to be abl= e to share a paper soon).=C2=A0

Ultimately I agree= with Richard=E2=80=99s analysis and Andrew Ayer=E2=80= =99s comment, that inclusion proofs (and the STHs they chain to) should= be embedded in the certificate, together with the SCT.
6962-bis = specifies the mechanism to do it and UAs can= require it as a policy.

... an= d I definitely agree that 6962-bis is an improvement over 6962 in this rega= rd!
=C2=A0

The claim that =E2=80=9CCT=E2=80= =99s public verifiability mechanisms are too inefficient to be deployed at = scale=E2=80=9D is based on the following operating assumptions for CT (my u= nderstanding from an out-of-band chat with Richard):
- The goal i= s to not require auditing after the fact but have all auditing information = beforehand (stronger model).
- Logs issue STHs every 8 minutes.
- SCTs are augmented with inclusion proofs up to the STHs covering= them.
- Clients download all STHs, check consistency and store t= hem.
- When a certificate with SCT and inclusion proof is observe= d, it is rejected if it=E2=80=99s not chaining up to one of the STHs in the= client=E2=80=99s storage. If it is, then the SCT=E2=80=99s signature and i= nclusion proof are checked.

This variation of CT i= s supposed to provide security against log misbehaviour but is still deemed= too expensive to deploy at the cost of 4MB/month of data for each client. = However:
- This assumes CAs are happy to wait 8 minutes for certi= ficate issuance (issuance bandwidth is high, but that benefits only large-v= olume CAs).
- It effectively brings down the MMD to 8 minutes.
- What about clients that have been offline for a while and have ye= t to catch up with recently-issued STHs? If SSL connections are blocked unt= il a client catches up, that=E2=80=99s equivalent to on-line certificate ch= ecks (OCSP).
- A clear-cached-load of Facebook clocks at 1.6MB, <= a href=3D"http://slashdot.org" target=3D"_blank">slashdot.org 3.2MB, bbc.co.uk 875KB, which sho= uld give some context for the 4MB/month cost (note not all clients have to = participate; herd immunity means all clientns benefit even if only some aud= it logs).
- Equivocation may not be possible, but the threat of l= ogs presenting split-views remains (even if all clients start with a =E2=80= =9Ctrusted=E2=80=9D STH) - a collaborative way to compare the view logs pre= sent is still necessary (our auditing implementation in Chrome does not = require it as STHs are pushed daily to clients).

E= xploration of different schemes for CT with stronger guarantees should be i= ndependent of 6962-bis.

The pro= blem here is that the document is not clear about what guarantees it provid= es, and where it tries to explain clearly it assumes a mechanism for auditi= ng SCTs exists.=C2=A0 For example:

"""
=C2=A0=C2= =A0 If a server
=C2=A0=C2=A0 presents a valid signed timestamp for a cer= tificate, then the client
=C2=A0=C2=A0 knows that a log has committed to= publishing the certificate.=C2=A0 From
=C2=A0=C2=A0 this, the client kn= ows that monitors acting for the subject of the
=C2=A0=C2=A0 certificate= have had some time to notice the misissue and take some
=C2=A0=C2=A0 ac= tion, such as asking a CA to revoke a misissued certificate, or
=C2=A0= =C2=A0 that the log has misbehaved, which will be discovered when the SCT i= s
=C2=A0=C2=A0 audited.=C2=A0
"""

T= he problem here is that there is no effective mechanism for auditing SCTs r= ight now.=C2=A0 The DNS thing you mention might work, though it seems to me= to have really poor scaling properties (and it is completely unimplementab= le in Firefox, for software reasons).=C2=A0 Or the log refactoring I'm = proposing might work.=C2=A0 But we're clearly pretty far from consensus= here.

So either we need to block this document on the creation of s= ome auditing mechanism that we all feel comfortable with, or we need to put= some clear warning labels on this thing in terms of the guarantees it prov= ides, and in particular, its vulnerability to rogue logs.
=C2=A0
6962-bis allows us to address some of the issues with 6962 (like = enabling embedding of inclusion proofs) and even trial variants (using the = extensions mechanisms).

Hearing a major UA vendor = state that CAs should tolerate some latency during certificate issuance for= the benefit of the ecosystem is exciting news. We can do it with 6962-bis<= /div>

Indeed, it sounds like we'v= e got some consensus here at least on the browser side of things that CAs a= nd servers should be moving from SCTs towards inclusion proofs.=C2=A0 I thi= nk there are a couple of straightforward things we could add to the documen= t to facilitate that transition:

* Adding an explicit lifetime to SC= Ts and a recommendation that RPs impose a maximum lifetime on SCTs on the o= rder of the STH issuance frequency of the log
* Adding a recommendation = that RPs require signatures from multiple logs

Those chan= ges would bound the risk from SCTs in the short run, and give us a tool to = phase out SCTs in the long run (in favor of inclusion proofs).

=C2=A0
: newer CT log implementations and the upcoming = Trillian based implementation are capable of integrating added chains into = the tree within O(tens of seconds to minutes).

I would be interested to know what about the operation of = adding to the tree causes this degree of latency.=C2=A0 To be honest, it se= ems pretty extreme, given the rates at which CAs are capable of operating t= hese days.

In particular, I wonder if this is another exa= mple of the pain we have pain we have undertaken by having a single global = Merkle tree instead of some more flexible structure.

--Ri= chard



=C2=A0
Different, potentially = simpler, systems can be built under that assumption (and I=E2=80=99ll let p= roper cryptographers suggest them :)).

Eran
<= /div>

On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes <rlb@ipv.sx= > wrote:


On Tue, Jan 17, 2017 at 1= 0:34 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 16 Jan 2017, Richard Barnes wro= te:

Speaking as individual only...

- It is not practical to build a publicly verifiable log system that incorp= orates SCTs
- The existing tools for public verifiability need to be made more efficien= t in order to work on the scale
envisioned

 So I think there might be a different perception here of the goal of
CT. I think you are looking at a 100% catch-before-it-happens
scenario. While the document is only about "exposing rogue parties&quo= t;.

Those two goals= are not as different as you might think.=C2=A0 Either way, you need for th= e client to detect equivocation.=C2=A0 You need the same data; it's jus= t a question of when.

=C2=A0
Fundamentally, CT is a public ledger system: every certificate is supposed = to be entered into a log and RPs
only accept certificates which are logged. In order for this to work proper= ly, RPs need to be able to verify
that there is public consensus about the state of the log. Otherwise, logs = can =E2=80=9Cequivocate=E2=80=9D: represent to the
RP that a given certificate was published when it in fact was not. Unfortun= ately, in practice RPs are not
doing this verification (for reasons discussed below), and so CT reduces to= a countersignature scheme in which
the RP trusts the log not to equivocate. There are two primary challenges h= ere, as detailed below.

 The monitors are supposed to use multiple logs, presumably not all of
which are colluding. So a rogue log would be found out and lose its
trust? Maybe not in time for this one client visiting this one website,
but that was never the expected goal of CT.

I think you mean "RPs" where you say &qu= ot;monitors", right?

Even in this scenario, in order= for the rogue log to be found out, you still need a system for detecting e= quivocation, which we don't have now.

=C2=A0
It has been known for quite some time that the public verifiability piece o= f CT introduces latency in
certificate issuance. In order to allow for immediate certificate issuance,= logs instead issue SCTs, which are
just promises to incorporate the certificate into the log; effectively the = SCT is a countersignature on the
certificate. However, if an RP accepts a certificate + SCT, then it is vuln= erable to collusion between a CA
which issues a bogus cert and a log which issues a bogus SCT but never inco= rporates the cert into the log.

 So that is someting monitors should look at.

We are unaware of any way to efficiently address this issue without introdu= cing either privacy problems or
latency. In order to validate inclusion in the log, the RP needs to validat= e that other entities (e.g., the
software manufacturer) have the same view of the log. Either the RP downloa= ds the whole log (which is
inefficient), queries for the specific certificate in question (which has p= rivacy problems) or retrieves a
checkpoint which vouches for some batch of certificates (which introduces b= atch latency).

 So personally, I would like to know that ACME-style issued certificates
would start being accepted within a few minutes. At least for those
sites that did not have a certificate before. If we are talking about
renewing, then it should be able to properly submit new entries to log
before actually activating the new certs, so some latency wouldn't matt= er.

As I noted in my little quan= titative analysis, you can get the data structures down to a reasonable siz= e with a ~8min issuance delay if you're willing to refactor the log str= ucture.

--Richard

=C2=A0

Am I missing something?

Paul


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



--001a1148d93a2a00e505465fdae8-- From nobody Wed Jan 18 07:52:01 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 06DCE12946C for ; Wed, 18 Jan 2017 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Hhooq1029CjE for ; Wed, 18 Jan 2017 07:51:58 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 B9F4B1293E0 for ; Wed, 18 Jan 2017 07:51:57 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3v3WgF4JMhzrV; Wed, 18 Jan 2017 16:51:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1484754713; bh=L14PrlYGRQHcJ6QpdFIAlgWOX7/d3AhtMBG2P2HwH88=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Tv0IR49fiANL+Vwg2hhDovhcfD2xuP3u4/v6mD5IMWyInELTCK+QDry6LNv/H521H 4CwNGpYbFVLjB+bfwbHui840L4OZp1NEUKXWkXN277/6dhFt/VAClTws88vlwhE++O QBz9zbvNrTK+c+6qX1KbqF8cbWEY0zqh7TVVu58A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cIwSKuRyoFH8; Wed, 18 Jan 2017 16:51:51 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 18 Jan 2017 16:51:51 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 411C635A2B2; Wed, 18 Jan 2017 10:51:47 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 411C635A2B2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2FCEA41D900C; Wed, 18 Jan 2017 10:51:47 -0500 (EST) Date: Wed, 18 Jan 2017 10:51:47 -0500 (EST) From: Paul Wouters To: Richard Barnes In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Eric Rescorla , Eran Messeri , "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: Wed, 18 Jan 2017 15:52:00 -0000 On Wed, 18 Jan 2017, Richard Barnes wrote: > Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue logs.  Without some sort of > consistency checking mechanism, logs can lie without any risk of discovery.  That is true of CT as deployed > today.  There is no way to detect a rogue log. 6962bis defines a method of logging. If you want to use that logging to discover bad parties, you need to use that logging. For example: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ Also, a description of a Monitor to perform those functions was started here: https://tools.ietf.org/html/draft-kent-trans-monitor-auditor/ > The problem here is that the document is not clear about what guarantees it provides, and where it tries to > explain clearly it assumes a mechanism for auditing SCTs exists.  For example: That got spun of into a separate document: http://tools.ietf.org/html/draft-ietf-trans-threat-analysis/ > So either we need to block this document on the creation of some auditing mechanism that we all feel > comfortable with, or we need to put some clear warning labels on this thing in terms of the guarantees it > provides, and in particular, its vulnerability to rogue logs. It was decided a long time ago not to block the 6962bis document for these other documents. Do you believe that something in the formats of 6962bis MUST be changed to accomodate its use? We had hoped that the threat document would have been ready by the time 6962bis went into LC. While it is close, there seems to be an unfortunate stalemate with a few people to move this document forward bundled with 6962bis. If you wish to offer some text for 6962bis that would satisfy you, that might be useful for the WG to make a decision on. > In particular, I wonder if this is another example of the pain we have pain we have undertaken by having a > single global Merkle tree instead of some more flexible structure. Something like TLSA records? :) Paul From nobody Wed Jan 18 08:02: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 38D78129409; Wed, 18 Jan 2017 08:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 vcxs6S5P4iDY; Wed, 18 Jan 2017 08:02:29 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 30130129436; Wed, 18 Jan 2017 08:02:29 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5C916433407; Wed, 18 Jan 2017 16:02:28 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 44A5A43341B; Wed, 18 Jan 2017 16:02:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484755348; bh=wIZKdSrjAJyu1hkKc2+22ZqAiruVt1zbxiqmxQXPBzQ=; l=374; h=From:To:CC:Date:From; b=o2WSOxJ3UR00fbsa9UlRgGpAZUKiozFMyVRcHT+nSD6NS/7kh/S3iLR/UqqJoF3zo PoJWZ36CwNPXQmaAMx5wRgFOJYNgdz/0QwiTJIGzYm3dFWJeJJ4NqMrMuNptMqRadQ Bj22Nyv1XaUJYyTtbibtSSIoJ72v0pxEeoiIgt3U= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 40AC31FC86; Wed, 18 Jan 2017 16:02:28 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 11:02:27 -0500 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, 18 Jan 2017 11:02:27 -0500 From: "Salz, Rich" To: "trans-chairs@ietf.org" Thread-Topic: Threat document stalemate (was RE: [Trans] WGLC comments on draft-ietf-trans-6962-bis-24 ) Thread-Index: AdJxpEM+Y6NPakC0Q4Wn6tJ65AyLfQ== Date: Wed, 18 Jan 2017 16:02:26 +0000 Message-ID: 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.33.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: [Trans] Threat document stalemate (was RE: 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: Wed, 18 Jan 2017 16:02:30 -0000 PiBXZSBoYWQgaG9wZWQgdGhhdCB0aGUgdGhyZWF0IGRvY3VtZW50IHdvdWxkIGhhdmUgYmVlbiBy ZWFkeSBieSB0aGUgdGltZQ0KPiA2OTYyYmlzIHdlbnQgaW50byBMQy4gV2hpbGUgaXQgaXMgY2xv c2UsIHRoZXJlIHNlZW1zIHRvIGJlIGFuIHVuZm9ydHVuYXRlDQo+IHN0YWxlbWF0ZSB3aXRoIGEg ZmV3IHBlb3BsZSB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgZm9yd2FyZCBidW5kbGVkIHdpdGgNCj4g Njk2MmJpcy4NCg0KQ2hhaXJzLA0KDQpCcmVhayB0aGUgc3RhbGVtYXRlLg0K From nobody Wed Jan 18 08:08:40 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 464141294A6 for ; Wed, 18 Jan 2017 08:08:35 -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 LibJnXvmtzSc for ; Wed, 18 Jan 2017 08:08:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1581F129497 for ; Wed, 18 Jan 2017 08:08:34 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7FEFA433416; Wed, 18 Jan 2017 16:08:33 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 68FAB433434; Wed, 18 Jan 2017 16:08:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484755713; bh=zARb0lSMR+W+A/vHLFajd4ZVXoiLMggdAKRHSIYaJz4=; l=642; h=From:To:CC:Date:References:In-Reply-To:From; b=IdrwPpt1zexZSwXuNrxZlpjGT+enapwvrJ+zhEDUgFdJiSNNqaxHrwZnEucKI3C6X aA0l1pKtelurBW09GSjIDZYwyGO5cdzAOpZ7lapLgiWNniE5WLbAvQ2uQ+gdpInp4E kepmMjZBlFj8nOyh4FjUQREwqFICGu+T8IXL2c2k= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 656CA1FC86; Wed, 18 Jan 2017 16:08:33 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 11:08:32 -0500 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, 18 Jan 2017 11:08:33 -0500 From: "Salz, Rich" To: Richard Barnes , Eran Messeri Thread-Topic: [Trans] WGLC comments on draft-ietf-trans-6962-bis-24 Thread-Index: AQHScEcucZgpfn1K5UGSRSpC7PiYxKE9IasAgAAEFgCAAWsuAIAAHQmA//+7XNA= Date: Wed, 18 Jan 2017 16:08:32 +0000 Message-ID: References: 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.33.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Eric Rescorla , Paul Wouters , "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: Wed, 18 Jan 2017 16:08:35 -0000 PiBMZXQgbWUgYWdhaW4gYnVzdCB0aGlzIG15dGggdGhhdCA2OTYyIC8gNjk2Mi1iaXMgZG8gYW55 dGhpbmcgdG8gZXhwb3NlIHJvZ3VlIGxvZ3MuwqAgV2l0aG91dCBzb21lIHNvcnQgb2YgY29uc2lz dGVuY3kgY2hlY2tpbmcgbWVjaGFuaXNtLCBsb2dzIGNhbiBsaWUgd2l0aG91dCBhbnkgcmlzayBv ZiBkaXNjb3ZlcnkuwqAgVGhhdCBpcyB0cnVlIG9mIENUIGFzIGRlcGxveWVkIHRvZGF5LsKgIFRo ZXJlIGlzIG5vIHdheSB0byBkZXRlY3QgYSByb2d1ZSBsb2cuDQoNCkl0J3MgbmVjZXNzYXJ5LCBi dXQgbm90IHN1ZmZpY2llbnQuICBKdXN0IGxpa2UgVENQIGlzIG5lY2Vzc2FyeSBidXQgbm90IHN1 ZmZpY2llbnQgdG8gZW5hYmxlIHRoZSBXZWIuIC4uLg0KDQpPbmUgY2FuIGNvbXBhcmUgdGhyZWUg bG9ncyBhbmQgaWYgdGhleSBkaWZmZXIgeW91IGtub3cgd2hvIGFuZCB3aGVyZSB0aGUgcm9ndWUg aXMsIHJpZ2h0Pw0K From nobody Wed Jan 18 11:57: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 304221298C4 for ; Wed, 18 Jan 2017 11:57:46 -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 qn3fpM3xgms4 for ; Wed, 18 Jan 2017 11:57:45 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 DB8511294E0 for ; Wed, 18 Jan 2017 11:57:44 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id j82so7571429ybg.1 for ; Wed, 18 Jan 2017 11:57:44 -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=naC6Mae9NJcpxUtbJFVKGBzRGbbXneWU7ZU3/DdRSjk=; b=UZNI7P6XUVHCssnCbk185TFeuGjXBGM3eGBfSegCVW+0wwZ+50jviALExt99RV33Jt vyu1rWXAxwjXFVS/oSyyEG0HBP2nEcbPTe2oB8OX3Zb0VI/f+m/OnnLv4yWmbfWe7G89 zikEDH/cNUI0f79TUSHAo3nm9Q9AHrejilFhoii0i2P8MditmzAlfjKW9r8/KQpyLjri M+tUNr91kmpQXrV+47rw6XJSy64Uir3lkBrD8DYOiv2io3SjzkqRFA7/MhueR0RrH6sf zM3h2/LI+WRAcL1gcAebJfMfa1yRgqAMwhiMbTxBnHyU7Zzpm3kRzAP0XFt6eByiCKPY UruQ== 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=naC6Mae9NJcpxUtbJFVKGBzRGbbXneWU7ZU3/DdRSjk=; b=LIw9sO+PY6NWSXySl2LozHe//g0zq+DqDUkTzdRC5n8Mp/YzMRkM2xXlsfeeFR1m86 T66J9oxAKg+fLzWMuLo3XASBEPiNa+P5AQ5Z2NTnrzUCtMuQVuWJtBIufMwtY22uRVAY lqGSp2CnxMlyyr27RlTHJkPs55cW0wT5/RI+ujkx0s7wP2u2Fel9H1Qkptj+O2xiv4ds TayEGt8DGNIhdkPXx6q5nFyKP7FF1zIh9GxjmAxtHvnRpFObndZ7ke/PmhdHdEeooYDd dgiT3OCltOf6d1imL/15XwoxSmrECwNCTzL/c8xWjHRluTypsVXw6j6yRab6cmuh3oJf 8haA== X-Gm-Message-State: AIkVDXJdoq9jyXf86IlhExBCIwEmUll4j/S5M6IG0J0ggFTVyi4QwvcUsQCsJ+SxLvAw2aKZW/KQ4xrtwjdBbA== X-Received: by 10.37.14.69 with SMTP id 66mr3838241ybo.64.1484769464119; Wed, 18 Jan 2017 11:57:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 18 Jan 2017 11:57:03 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 18 Jan 2017 11:57:03 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113e930c7ba5aa054663d452 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Eran Messeri , Paul Wouters 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: Wed, 18 Jan 2017 19:57:46 -0000 --001a113e930c7ba5aa054663d452 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 8:08 AM, Salz, Rich wrote: > > Let me again bust this myth that 6962 / 6962-bis do anything to expose > rogue logs. Without some sort of consistency checking mechanism, logs can > lie without any risk of discovery. That is true of CT as deployed today. > There is no way to detect a rogue log. > > It's necessary, but not sufficient. Just like TCP is necessary but not > sufficient to enable the Web. ... > > One can compare three logs and if they differ you know who and where the > rogue is, right? > Hmm.... Not unless all logs are required to have every certificate (at least within a given scope). Otherwise, the fact that a certificate is in log A but not log B doesn't tell you anything about log B. However, if all you're doing is comparing logs for consistency about a given certificate, then you can dispense with the entire Merkle tree structure and just have the logs countersign certificates they have seen. -Ekr --001a113e930c7ba5aa054663d452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 8:08 AM, Salz, Rich <rsalz@akamai.com> wrote:
> Let me= again bust this myth that 6962 / 6962-bis do anything to expose rogue logs= .=C2=A0 Without some sort of consistency checking mechanism, logs can lie w= ithout any risk of discovery.=C2=A0 That is true of CT as deployed today.= =C2=A0 There is no way to detect a rogue log.

It's necessary, but not sufficient.=C2=A0 Just like TCP is neces= sary but not sufficient to enable the Web. ...

One can compare three logs and if they differ you know who and where the ro= gue is, right?

Hmm.... Not unless all l= ogs are required to have every certificate (at least within a given scope).=
Otherwise, the fact that a certificate is in log A but not log B= doesn't tell you anything about log B.

Howeve= r, if all you're doing is comparing logs for consistency about a given = certificate, then you
can dispense with the entire Merkle tree st= ructure and just have the logs countersign certificates
they have= seen.

-Ekr


--001a113e930c7ba5aa054663d452-- From nobody Wed Jan 18 12:00:54 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 3C2A7129956 for ; Wed, 18 Jan 2017 12:00:53 -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 ArY37ykrIjuI for ; Wed, 18 Jan 2017 12:00:52 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3F12997E for ; Wed, 18 Jan 2017 12:00:44 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DBDB043342C; Wed, 18 Jan 2017 20:00:43 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C3610433429; Wed, 18 Jan 2017 20:00:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484769643; bh=CCf5bTsQs+KsUuSWltP8kFES1Z7nKKSJCdatdBQbALc=; l=678; h=From:To:CC:Date:References:In-Reply-To:From; b=V+cNXA9JKsgJwTuntyMcSrWbvRtCn8eG7n94CZQqZhFguC4YwFw7tCtX5X+ekTcP7 JtAIsvK6uXYMx7fKuNYVJDeCFa/p5F0Ngu+4rFSPgOJIsY+zSwDL2Ye8lj9q9f4z9h +2hhVsBW4Ooc0/xR68x0KjXXOnBmEYbouNOYmTwI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id ABC521FC8B; Wed, 18 Jan 2017 20:00:43 +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, 18 Jan 2017 12:00:43 -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, 18 Jan 2017 15:00:43 -0500 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [Trans] WGLC comments on draft-ietf-trans-6962-bis-24 Thread-Index: AQHScEcucZgpfn1K5UGSRSpC7PiYxKE9IasAgAAEFgCAAWsuAIAAHQmA//+7XNCAAJQCgP//rL9w Date: Wed, 18 Jan 2017 20:00:42 +0000 Message-ID: References: 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.34.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Eran Messeri , Paul Wouters 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: Wed, 18 Jan 2017 20:00:53 -0000 PiBPbmUgY2FuIGNvbXBhcmUgdGhyZWUgbG9ncyBhbmQgaWYgdGhleSBkaWZmZXIgeW91IGtub3cg d2hvIGFuZCB3aGVyZSB0aGUgcm9ndWUgaXMsIHJpZ2h0Pw0KDQo+IEhtbS4uLi4gTm90IHVubGVz cyBhbGwgbG9ncyBhcmUgcmVxdWlyZWQgdG8gaGF2ZSBldmVyeSBjZXJ0aWZpY2F0ZSAoYXQgbGVh c3Qgd2l0aGluIGEgZ2l2ZW4gc2NvcGUpLg0KPiBPdGhlcndpc2UsIHRoZSBmYWN0IHRoYXQgYSBj ZXJ0aWZpY2F0ZSBpcyBpbiBsb2cgQSBidXQgbm90IGxvZyBCIGRvZXNuJ3QgdGVsbCB5b3UgYW55 dGhpbmcgYWJvdXQgbG9nIEIuDQoNClNvIGZhciB0aGUgQ2hyb21lIHBvbGljaWVzIHJlcXVpcmVz IHR3byBvciBtb3JlLCBhbmQgdGhlIGRyYWZ0IE1veiBwb2xpY3kgaXMgdGhyZWUgb3IgbW9yZSBJ SVJDLg0KDQpTbyBmb3IgYSBnaXZlbiBDQSwgYSBkaXNhZ3JlZW1lbnQgaWRlbnRpZmllcyB0aGF0 ICpvbmUqIG9mIHRoZSBsb2dzIGlzIHdyb25nLCByaWdodD8gDQo= From nobody Wed Jan 18 12:15: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 4CCD4127ABE for ; Wed, 18 Jan 2017 12:15: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=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 1rI3TAgw88dG for ; Wed, 18 Jan 2017 12:15:13 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 1BF15129969 for ; Wed, 18 Jan 2017 12:15:12 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id l23so7741733ybj.2 for ; Wed, 18 Jan 2017 12:15:12 -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=WC2qAOKxkeQCx07UlGujsjNTQ7SKWh7Xm2cB+gb5yvI=; b=hRXfYTXXD4VvZiI/YKKs8UkAsYy+V27N/aInEnF8xo3M2ZXd7s9HTFzmAFTFqblOU7 KkxdFoJVk7Ye3O22jOAMy3xxa0m9CU1qwJVgMKfNkM7SmnmKZufO6j/SzAAFb8ImG0VC J88OsKCd+IEJHYO11+Ce5IxZotoAj4r/58dg1j8JkfAMPQR+nEzmt8AArSvX+eFRQZs2 VXXTqv7cc4JUg3aBsOcHZ80tZSNyrxwaKElZ6HgiQBjaCJLtC3WSnBJ713n6aAaKUmDh 9knHuwdge5p2pMSJHOwcQx/B0i3zSdQGmtLOl6vCEeDrOQuh+mje/lvjqn7HhxwkDLKq klfQ== 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=WC2qAOKxkeQCx07UlGujsjNTQ7SKWh7Xm2cB+gb5yvI=; b=tHcxLaRpHw/zCb97OPnup/onJhAZ2Z/cehdC4urF2GP9kXW9+t7oq6W75eaycnt5o2 RPNG8XT49UQnCeomLspqH4Rqbc9dB0nHsmKIPBMHWMWByIiwi+VMmWjd34lFencPey9T ZC3bnuSGVFetKTIiAFT/uEhtgLrUeIRcpCo4yptYUL6I3ir84E4cpai/ifCcDpXtVgit E9kI7rOadHnR75ucgZfNdnz1O9m8GUF2gMtf2pzlZKluEUYa7ecX58sFcE3NM1ckMGiC kwrhKx/Fw5MX4dCPXjnSJq+VLT+7LVYL0vL4gWqK4S1J0aNUCHihUsLlR8cvoiqZ6t9y xWsg== X-Gm-Message-State: AIkVDXLkmSwFKdtCfT4yXVcnyW2jDn6T7nNkJhnJpP/UKR0RPRparzFq0u+3Re4L4kqqIYacfUVX9yCrbOGLjg== X-Received: by 10.37.14.69 with SMTP id 66mr3913718ybo.64.1484770511322; Wed, 18 Jan 2017 12:15:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Wed, 18 Jan 2017 12:14:30 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 18 Jan 2017 12:14:30 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113e930ce6aa56054664121f Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Eran Messeri , Paul Wouters 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: Wed, 18 Jan 2017 20:15:17 -0000 --001a113e930ce6aa56054664121f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 12:00 PM, Salz, Rich wrote: > > One can compare three logs and if they differ you know who and where the > rogue is, right? > > > Hmm.... Not unless all logs are required to have every certificate (at > least within a given scope). > > Otherwise, the fact that a certificate is in log A but not log B doesn't > tell you anything about log B. > > So far the Chrome policies requires two or more, and the draft Moz policy > is three or more IIRC. > > So for a given CA, a disagreement identifies that *one* of the logs is > wrong, right? > It's quite sensitive to what the precise requirement is. So consider a requirement that site provide an SCT from N logs out of a set of M. Without loss of generality, the site gets SCTs from L_1, L_2, ... L_N but not L_N+1, ... L_M. The fact that the site's cert appears in L_1 but not L_M is normal and doesn't tell you that either one of them is wrong. (This is just the basic non-adversarial case). Now, consider the adversarial case, where an attacker as corrupted a CA and N logs out of M. Similarly, they will get N SCTs from those corrupt logs (which might not be the ones that the actual legitimate site used for their SCTs, but the client doesn't know that [0]. And again, the lack of an SCT from the non-corrupt log doesn't tell you anything. Now, in the special case where N==M, then inconsistencies are meaningful, and this is the case with Chrome's "one of the logs must be Google" policy, but as far as I can tell that's not something that's true in the general case. -Ekr [0] Modulo some sort of log pinning. --001a113e930ce6aa56054664121f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 12:00 PM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> One c= an compare three logs and if they differ you know who and where the rogue i= s, right?

> Hmm.... Not unless all logs are required to have every certificate (at= least within a given scope).
> Otherwise, the fact that a certificate is in log A but not log B doesn= 't tell you anything about log B.

So far the Chrome policies requires two or more, and the draft Moz p= olicy is three or more IIRC.

So for a given CA, a disagreement identifies that *one* of the logs is wron= g, right?

It's quite sensitive to w= hat the precise requirement is. So consider a requirement
that si= te provide an SCT from N logs out of a set of M. Without loss of generality= ,
the site gets SCTs from L_1, L_2, ... L_N but not L_N+1, ... L_= M. The fact that
the site's cert appears in L_1 but not L_M i= s normal and doesn't tell you that
either one of them is wron= g. (This is just the basic non-adversarial case).

= Now, consider the adversarial case, where an attacker as corrupted a CA and=
N logs out of M. Similarly, they will get N SCTs from those corr= upt logs (which
might not be the ones that the actual legitimate = site used for their SCTs, but the
client doesn't know that [0= ]. And again, the lack of an SCT from the non-corrupt
log doesn&#= 39;t tell you anything.

Now, in the special case w= here N=3D=3DM, then inconsistencies are meaningful,
and this is t= he case with Chrome's "one of the logs must be Google" policy= , but
as far as I can tell that's not something that's tr= ue in the general case.

-Ekr

<= div>[0] Modulo some sort of log pinning.





--001a113e930ce6aa56054664121f-- From nobody Thu Jan 19 10:09:33 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 93ABD12947D for ; Thu, 19 Jan 2017 10:09:32 -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 (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 a5sKjdMOjc2K for ; Thu, 19 Jan 2017 10:09:30 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 B1C391293DB for ; Thu, 19 Jan 2017 10:09:30 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id k127so35914185vke.0 for ; Thu, 19 Jan 2017 10:09:30 -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=IJkfP2D5z4YMMH1tq1Yfw1tbxoth6OztRqKQRXBXJsA=; b=AdaCME8VnSPsqQoNFIxTbs2eg31z+eXqM/9ZxmUL4pF80a7FtwlKUmw2DaQVPXDlPw sHyveLv40saUHXf6/AQHcwzbatWV04JW9rm4QW2vpWadl5kIlSgMoCy+80eKtZZ/DGO4 Sk4wlXPYfpJzIuJc3Au9hySQ5JooecQEmMCDjlwluMEVn7KjsiLtUpFc80LKL8Jlsp+F E4JVwTC7IwTG8Ztjo9ltPTKYo2mf+OuBX5Y8acboS5psXwBTl8UXqvpSBJO7NJjYIFA5 U9FEoB7SqHXNJP2+gnCqP1lnMwQNBeCsYRS3G36yqSl+ItotXQ0T9LK6weEgjGYChQY9 lBeg== 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=IJkfP2D5z4YMMH1tq1Yfw1tbxoth6OztRqKQRXBXJsA=; b=esv7TwuefTF/4m+8Ral1PCEYQw/mrnzzsyOtuILH9UPnZeM0cjLLvrH6zJS2ZONmwO LmH9xGFEcUnWIBYdEQxPdoqRIJVD4XgLNpwYH3ZqcUleaywca9iIsEpUwS/bTY8NEn0I oTY2K4h1yovR2zZICtvOXDYWZRaPdFV1syUaAJBWmFZBMgygo7rwzDTRZYXgPt/OxEGO 5cnT67qLOXSGCrF8umScqqc+/lCeL23Dy1WpkU8MpusnVLPP2Li8c4pOkdZht+3YNnra xDX1A886T/IYt1/IY7+mRAOWnKAHZD6eiMLpMLmHaiD7F8S+f4NMBae98LqYcyug+7sT DnMQ== X-Gm-Message-State: AIkVDXLPXZxoskKy9QVY7yick6uRE9uOxGZPIlfGaBGf1N557QtAJVTWAWEtzcJ0FrLAjlMkZ54sRK7i6B3A9BPN X-Received: by 10.31.59.137 with SMTP id i131mr5161723vka.7.1484849369609; Thu, 19 Jan 2017 10:09:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.130.199 with HTTP; Thu, 19 Jan 2017 10:09:28 -0800 (PST) In-Reply-To: References: From: Ben Laurie Date: Thu, 19 Jan 2017 18:09:28 +0000 Message-ID: To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tom Ritter , Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Minimum SCT age (was Re: 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, 19 Jan 2017 18:09:32 -0000 On 18 January 2017 at 00:32, Bill Frantz wrote: > On 1/17/17 at 9:16 AM, rob.stradling@comodo.com (Rob Stradling) wrote: > >> On 17/01/17 17:07, Tom Ritter wrote: > > >> >> >>> It also assumes the client has a clock that is correct to the order of >>> a few days... >> >> >> True. Is it, or might it soon be, reasonable to make that assumption? >> >> e.g., https://roughtime.googlesource.com/roughtime sounds promising, I >> think. >> > > Machines such as the Raspberry PI and the Beaglebone do not have clock > chips, although it is easy to add an external real time clock board. They > can set their clocks from NTP if they have internet access, which is > more-or-less needed to run a browser, unless running on private network. I > can see scenerios where they can have a very badly off clock though. So, machines in that position should not try to enjoy the full protection of CT. > > Cheers - Bill > > --------------------------------------------------------------------------- > Bill Frantz | Re: Computer reliability, performance, and security: > 408-356-8506 | The guy who *is* wearing a parachute is *not* the > www.pwpconsult.com | first to reach the ground. - Terence Kelly > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jan 19 10:13: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 163EE129491 for ; Thu, 19 Jan 2017 10:13:47 -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 (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 GPy9Jp05btdX for ; Thu, 19 Jan 2017 10:13:43 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 8A1C012947D for ; Thu, 19 Jan 2017 10:13:43 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id r136so36080847vke.1 for ; Thu, 19 Jan 2017 10:13:43 -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=MjDOgmX4iJrocE/DOvqV6YrXhaSZrVZMpkKmQRv9MkY=; b=vD2LQ4RKh0YdLd0OBG6PyPd1s7XIMkTOuqEIDJjYAMD8sSxohDF7+EEHLJB07ulT08 y/s/vKhEz1eOCbPAbcJ05NtlD2fpS2zLhlzpn+5JrFRbYj/9IRYVe1K0yX5VUUEeMfYC hljPBJdAORAN70WTyL0om1SE0LPnruk0mCW3lrDzuzg4dUFahTo+kih0M4K2KRVMquf2 b+q/CdBDK97W9bgYeaRDstlCXNYzsqoKIjJ88OYW6d/yKxlB7s58BApu5Qkg1wcov1Pa 0az/QTcKh+pgL2Mh7MXnZkgAOuShVwoiqXKGS8dDjCB8IR99B0c2cq4KjEfp4N12nwVl gq/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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MjDOgmX4iJrocE/DOvqV6YrXhaSZrVZMpkKmQRv9MkY=; b=X4oF3QAcP9ZMMzDspi1ZvWF2IyQdch+SGubD6qOKkVB6cKwUMxebFji7OLMgurRu0d qK2224x5BPwxH8AH8DSIC4qxmGCJrNLKx8dhJulUtAyaIXX0oOJeLPViSUz72qq9Z+E7 cGrHH7EtCY4umEeR8/i5FEGkbMq73iC3F3kro5geSVOQgc5ykgsz7TvJux3FAz++CYAg uzFgUY3AU4+vjftnIHdQ0lzDUt4v274wd5ax1QmYbDtK9pB+R8IuzFFTAUyzch46rZtT s0eE+MqdAScfUgRRqgk1e2STE15yy3axZmp6ksH4sg6Pphaf+MeAwXOywRVh+Dt4wjyW BwPQ== X-Gm-Message-State: AIkVDXLUrtudo0z/0ztYvF+cGy0Q1ylLvUpVmKdJwwVRjx869DBx9Nwro8977PX7/u/OCFXxTNybc3VQXDhaZ/x5 X-Received: by 10.31.220.134 with SMTP id t128mr5191999vkg.143.1484849622532; Thu, 19 Jan 2017 10:13:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.130.199 with HTTP; Thu, 19 Jan 2017 10:13:41 -0800 (PST) In-Reply-To: <9b7633ec-7b54-6d6c-1660-edaaa673c4bb@comodo.com> References: <9b7633ec-7b54-6d6c-1660-edaaa673c4bb@comodo.com> From: Ben Laurie Date: Thu, 19 Jan 2017 18:13:41 +0000 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Tom Ritter , Bill Frantz Subject: Re: [Trans] Minimum SCT age (was Re: 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, 19 Jan 2017 18:13:47 -0000 On 18 January 2017 at 12:43, Rob Stradling wrote: > On 18/01/17 00:32, Bill Frantz wrote: >> >> On 1/17/17 at 9:16 AM, rob.stradling@comodo.com (Rob Stradling) wrote: >> >>> On 17/01/17 17:07, Tom Ritter wrote: >> >> >>> >>> >>>> It also assumes the client has a clock that is correct to the order of >>>> a few days... >>> >>> >>> True. Is it, or might it soon be, reasonable to make that assumption? >>> >>> e.g., https://roughtime.googlesource.com/roughtime sounds promising, I >>> think. >> >> >> Machines such as the Raspberry PI and the Beaglebone do not have clock >> chips, although it is easy to add an external real time clock board. >> They can set their clocks from NTP if they have internet access, which >> is more-or-less needed to run a browser, unless running on private >> network. I can see scenerios where they can have a very badly off clock >> though. > > > Is it (or might it soon be) reasonable to expect a TLS client to know > whether or not it has a reliable time source? If so, then TLS clients could > just ignore "minimum SCT ages" when they're insufficiently confident of when > "now" is. Exactly. > As a way of dealing with clocks that are far behind, perhaps TLS clients > that implement CT could treat any observed SCT timestamp (that corresponds > to any observed cert) and any observed STH timestamp as trustworthy evidence > that these timestamps are in the past rather than in the future. (If > multiple SCTs/STHs from multiple logs all agree that time X is in the past, > then the TLS client can have even greater confidence that this is indeed > so). > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jan 20 06:23: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 6D57312940C for ; Fri, 20 Jan 2017 06:23:30 -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 (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 X-N1hnl7PqvS for ; Fri, 20 Jan 2017 06:23:29 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 1F9F51294EA for ; Fri, 20 Jan 2017 06:23:29 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id x75so52283656vke.2 for ; Fri, 20 Jan 2017 06:23:29 -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=mDFJG0DVox/tbgZssqVvpubmwiPZFofXRtvwcWZH704=; b=TPVwJacs3Hq2q0cY5KPmT38PnUkm/2q5JoC87F1ioHeMpI8bBWZIDGsYDlYac79IvC McQXQNif8q3oWmYzLjo9CdYIjNhonN3vD2qo/HtiLs9WcgIpXrZBmDQKlSOgZYR4Uij2 qyVld2p5xvFXKmCHW7mnebDMqzOeKf4wqZoLUFLAmc/GhXae6VqjSo6qhRQRGhGoEZd/ 3GQ+HehsxYrbexxDuOKvh5c2YIUrQUKeVWjhlXAi2ZTQkyKPpZYUf/pZFFQIjvmWacS4 S2DIFfxY7qLxVh7rCLVJWIjwJgncMuZIh6y6Dl1Pcu7VlFZ6MzbAvpALVeKxmJyOZNZw slcQ== 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=mDFJG0DVox/tbgZssqVvpubmwiPZFofXRtvwcWZH704=; b=pXv/88+ok04n+yXg8jtckTRR5+P0e79atb4xXVMoUH7UIEB4/j4sm+6nJQOL0Z3tDp BcoCuN+WUPQ+AbSHhhooz/esZwxOwquWZrZB4LHu4IsSVXuTBfsXVywXX7E48VAbIPzM UTXdXgcgKWgnSf1Pz/RU+UNpFdR/jK3yKy+0sWXOrlYGbCiufrzhffvTNtySkEq3EQ/v 8ryxKJGLYPFgwpIurD2x9Bs8ROBUI4xuZNX1leJTqSBqWdpgKKg7dHduB1BXgtfQKMZz wBQ0jWKd6Ua59KlSEfq2XCAm8qajnCZRXbKJG2XmlNHf7dQxSJWaubtCZKVbC7BMUXLt 4M2g== X-Gm-Message-State: AIkVDXLgVRE1WRiXxyczSeLZp+HPMIjvM2E/lrN4C0Vssbi1smcx0f0i3ydgEu9nkXaOIeKT6lonLzvNNvYEuzbz X-Received: by 10.31.50.84 with SMTP id y81mr5950752vky.103.1484922208012; Fri, 20 Jan 2017 06:23:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.130.199 with HTTP; Fri, 20 Jan 2017 06:23:27 -0800 (PST) In-Reply-To: References: From: Ben Laurie Date: Fri, 20 Jan 2017 14:23:27 +0000 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Eric Rescorla , Eran Messeri , Paul Wouters 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: Fri, 20 Jan 2017 14:23:30 -0000 On 18 January 2017 at 15:12, Richard Barnes wrote: > Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue > logs. Without some sort of consistency checking mechanism, logs can lie > without any risk of discovery. That is true of CT as deployed today. There > is no way to detect a rogue log. > > And a consistency checking mechanism only creates risk to rogue logs to the > degree that it is deployed and used. If only 5% of SCTs ever get checked > for consistency, then a rogue log has a 95% chance of getting away with any > particular lie. So we really need consistency checking at scale. I have two problems with this statement: 1. A 95% chance of getting away with a particular lie rapidly erodes to effectively no chance of getting away with multiple lies (for example, getting away with 100 lies is about .5% chance). 2. To get coverage better than 5% surely only requires a tiny fraction of all browsers (which vastly outnumber certificates), not "at scale". I do not disagree that it is necessary to do consistency checking, however. From nobody Fri Jan 20 07:28:37 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 91F76129961 for ; Fri, 20 Jan 2017 07:28:33 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Hk24UxgBoZlb for ; Fri, 20 Jan 2017 07:28:32 -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 EF4A4129BEB for ; Fri, 20 Jan 2017 07:28:23 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id w75so90890505ywg.1 for ; Fri, 20 Jan 2017 07:28:23 -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; bh=Y+b4Gixg/Oe0MkNWUWvjjPF/gMCEifMR9x672JH/nls=; b=2221+z3RtCfsl2n+PvVT8Dws6QtkCXeOANVMFRvJvFEIO4hJKWe/JRnSaD13o03PWc UhWDk8OPSn6MJ0ST9YKMKQWPqapnBX0u5XQVMmFBh7rVMsCFbGbzeHnzqi6NZKIvt2Ec yH6tjty5a17PH3YFUITc+EF2L6mlR7R5l5iBY= 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=Y+b4Gixg/Oe0MkNWUWvjjPF/gMCEifMR9x672JH/nls=; b=DjH7MmioDpr5cH7/OcgTWCyxFoBlDSJOkhLO6I+HDhuray1CzfLFirw+LTGqaHGpvr OkrYA2hWMaCZc+VX2f2uk913mSXLIKNupLTe7xGWPhef+yHA72Hm286z9ZogattePL2F KN5l7KIYNq9XW40MP6hB77vsmjr3YbqvweGOAnu9qO8kvmLMfVmFUx/joJobo37lT8Ln gJxvTH0nwUIlIyIrkYlpbuoqcGnhxzovfhdm/2MMXaJ82WZ/FXfxWOsQ5D2lyS23VpAc Puu58TPjecC7NsacAvCwUuunKvwA5zZ5+j/bHC3LbG3VxhNcmcNnSupHl/JSRzB1NkdF JQfA== X-Gm-Message-State: AIkVDXLgu7AyAOC4W9kUuvsbx/pEP15z/j4FF6nx6TSh+KaA9Ep2jq3CY8C7SmCSM9aquGdJmDTApkmul4X0znUq X-Received: by 10.55.42.41 with SMTP id q41mr13250294qkh.169.1484926103165; Fri, 20 Jan 2017 07:28:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.99.73 with HTTP; Fri, 20 Jan 2017 07:28:02 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Fri, 20 Jan 2017 09:28:02 -0600 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , Paul Wouters , Eric Rescorla , Eran Messeri , "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: Fri, 20 Jan 2017 15:28:33 -0000 On 20 January 2017 at 08:23, Ben Laurie wrote: > On 18 January 2017 at 15:12, Richard Barnes wrote: >> Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue >> logs. Without some sort of consistency checking mechanism, logs can lie >> without any risk of discovery. That is true of CT as deployed today. There >> is no way to detect a rogue log. >> >> And a consistency checking mechanism only creates risk to rogue logs to the >> degree that it is deployed and used. If only 5% of SCTs ever get checked >> for consistency, then a rogue log has a 95% chance of getting away with any >> particular lie. So we really need consistency checking at scale. > > I have two problems with this statement: > > 1. A 95% chance of getting away with a particular lie rapidly erodes > to effectively no chance of getting away with multiple lies (for > example, getting away with 100 lies is about .5% chance). In a perfectly random distribution, yes. But I expect that the attacker could choose the lie so the distribution is perfect or grossly in their favor - either because the website does not deploy some mechanism they need to participate (e.g. SCT Feedback) or because the attacker filters DNS from the clients they attack or they choose to attack clients they know do not enable consistency checking or by selectively blocking connections... All depends on deployment details of course. -tom From nobody Tue Jan 24 13:32:54 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 D4AA9128874 for ; Tue, 24 Jan 2017 13:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net 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 c7oXUM-tN6Po for ; Tue, 24 Jan 2017 13:32:51 -0800 (PST) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 DE07C129861 for ; Tue, 24 Jan 2017 13:32:50 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v0OLWlBH015049 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Jan 2017 22:32:47 +0100 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v0OLWi0r023146 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jan 2017 21:32:46 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1485293566; bh=1vHjmgkPbVpthBtExp0ntJbszMGqlpQ8DK0YFMDzI0c=; h=From:Subject:References:to:Date:In-Reply-To; b=TPqd/yUaBA4Tj8GyRwJDMGg5EIj2YTZUsswznE9mQTluvna4DBTQUhH8ZM2yBvu9h +QUiEYO8q8n5rtWNgSdL293lixxsk0O7d2/64yqg5UlLBTX1BjmyMrk6TAtGDOxspW wSlmKCVP8jx69m7a3sM5bmCRT89YQ5bz7czQt03Y= X-Footer: bm9yZHUubmV0 Received: from flogsta ([84.216.33.217]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for trans@ietf.org; Tue, 24 Jan 2017 22:32:42 +0100 From: Linus Nordberg Organization: NORDUnet A/S References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> to: trans@ietf.org Date: Tue, 24 Jan 2017 22:32:46 +0100 In-Reply-To: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> (Melinda Shore's message of "Wed, 11 Jan 2017 05:55:49 -0900") Message-ID: <87pojci1oh.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aSAlwLBt - bc2d7b368673 - 20170124 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 24 Jan 2017 21:32:54 -0000 Melinda Shore wrote Wed, 11 Jan 2017 05:55:49 -0900: > Working group last call will close on Wednesday, 1 February. Seems to me like none of the browser vendors have any plans on implementing CT Gossip as specified in this draft. Therefore I suggest we cancel last call for gossip and try to change the draft into something that at least one browser vendor is willing to support. Please don't hesitate to comment on the contents of the draft though. The authors are still interested in specifying something useful for catching misbehaving CT logs. From nobody Tue Jan 24 14:23:21 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 5236A12944E for ; Tue, 24 Jan 2017 14:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 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] 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 CgaTbNa3CxUa for ; Tue, 24 Jan 2017 14:23:14 -0800 (PST) Received: from homiemail-a110.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 2C58912944B for ; Tue, 24 Jan 2017 14:23:14 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id A9A752004710F for ; Tue, 24 Jan 2017 14:23:13 -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=y+q3A0r3QKgDdExfDMPWCEOSgjM=; b= tmmVIt3Y6YyZ33uyImGQH90JsKNXaNlR9VefqWChLMQYMauTOTJRAmEpQjuwB1/4 6dDZM/uzVv8y563wZ7dEVXPf4j2STYnUN0vi8lxsrb9dRhFHnF7WYFSYX8No12+T V82UbXelapXE1A6bSKa794SNdTJluWZtpMAOUJQULEo= Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id 3B3B920046906 for ; Tue, 24 Jan 2017 14:23:13 -0800 (PST) Received: by mail-lf0-f49.google.com with SMTP id v186so119236623lfa.1 for ; Tue, 24 Jan 2017 14:23:13 -0800 (PST) X-Gm-Message-State: AIkVDXL4McJoQcvr3Q0XeMiC/8GCPSFjoAGp+ei63gmjz2UMBypR+xjIbWT3VaIwsbyHRBky3gdwiAE5aEmwkQ== X-Received: by 10.25.204.197 with SMTP id c188mr10234777lfg.107.1485296591276; Tue, 24 Jan 2017 14:23:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.154 with HTTP; Tue, 24 Jan 2017 14:23:10 -0800 (PST) In-Reply-To: <87pojci1oh.fsf@nordberg.se> References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> <87pojci1oh.fsf@nordberg.se> From: Ryan Sleevi Date: Tue, 24 Jan 2017 14:23:10 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Linus Nordberg Content-Type: multipart/alternative; boundary=94eb2c19c612b59a6d0546de8fa8 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 24 Jan 2017 22:23:19 -0000 --94eb2c19c612b59a6d0546de8fa8 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 24, 2017 at 1:32 PM, Linus Nordberg wrote: > Melinda Shore wrote > Wed, 11 Jan 2017 05:55:49 -0900: > > > Working group last call will close on Wednesday, 1 February. > > Seems to me like none of the browser vendors have any plans on > implementing CT Gossip as specified in this draft. Therefore I suggest > we cancel last call for gossip and try to change the draft into > something that at least one browser vendor is willing to support. > > Please don't hesitate to comment on the contents of the draft though. > The authors are still interested in specifying something useful for > catching misbehaving CT logs. > I think it's more a question of whether we expect we can have running code to implement that draft, so that we can build rough consensus. It's not that Chrome is opposed to the Gossip draft - merely, that we haven't even begun to plan to implement/experiment with it, so can't really comment on. To be fair, we're sort of in this same issue with RFC 6962-bis, in my opinion - the economics of the Web PKI make it hard to get the "running code" part that allows us to build the "rough consensus" - so it's hard to know whether or not it's ready to maturate past WGLC. In other spaces, such as TLS WG, we're in a much better place to implement and iterate in a virtuous cycle. I mention this because I don't want you to feel that we (browsers) are either rejecting the Gossip draft or holding it hostage - just that there are enough moving parts or in-fight activities that we've not had a chance yet to fully explore this space in a way that can lead to good feedback. However, I do think Gossip is an important part of CT's future, and want to get to a place where we can really explore the draft, implement, and provide feedback. Unfortunately, I don't know if the IETF really has a good way of "This is good and important work, has what seems like a lot of good and important ideas, but let's keep this on the burner until more implementations exist" :( --94eb2c19c612b59a6d0546de8fa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 24, 2017 at 1:32 PM, Linus Nordberg <<= a href=3D"mailto:linus@nordu.net" target=3D"_blank">linus@nordu.net>= wrote:
Melinda Shore <melinda.shore@gmail.com> wrote Wed, 11 Jan 2017 05:55:49 -0900:

> Working group last call will close on Wednesday, 1 February.

Seems to me like none of the browser vendors have any plans on
implementing CT Gossip as specified in this draft. Therefore I suggest
we cancel last call for gossip and try to change the draft into
something that at least one browser vendor is willing to support.

Please don't hesitate to comment on the contents of the draft though. The authors are still interested in specifying something useful for
catching misbehaving CT logs.

I think i= t's more a question of whether we expect we can have running code to im= plement that draft, so that we can build rough consensus. It's not that= Chrome is opposed to the Gossip draft - merely, that we haven't even b= egun to plan to implement/experiment with it, so can't really comment o= n.

To be fair, we're sort of in this same issu= e with RFC 6962-bis, in my opinion - the economics of the Web PKI make it h= ard to get the "running code" part that allows us to build the &q= uot;rough consensus" - so it's hard to know whether or not it'= s ready to maturate past WGLC. In other spaces, such as TLS WG, we're i= n a much better place to implement and iterate in a virtuous cycle.

I mention this because I don't want you to feel that = we (browsers) are either rejecting the Gossip draft or holding it hostage -= just that there are enough moving parts or in-fight activities that we'= ;ve not had a chance yet to fully explore this space in a way that can lead= to good feedback. However, I do think Gossip is an important part of CT= 9;s future, and want to get to a place where we can really explore the draf= t, implement, and provide feedback.

Unfortunately,= I don't know if the IETF really has a good way of "This is good a= nd important work, has what seems like a lot of good and important ideas, b= ut let's keep this on the burner until more implementations exist"= :(

--94eb2c19c612b59a6d0546de8fa8-- From nobody Tue Jan 24 14:30:59 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 5AB82129481 for ; Tue, 24 Jan 2017 14:30:58 -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 ATWymfDL70Wx for ; Tue, 24 Jan 2017 14:30:57 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 25943129452 for ; Tue, 24 Jan 2017 14:30:57 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id t6so58314749pgt.3 for ; Tue, 24 Jan 2017 14:30:57 -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=sztJR+YGdxX3nAfP2x4jYgkcY9IVehq4b24/c8/4cbQ=; b=HZ0sRJsL6KlDUExxRwkCuYVwiCyJRF5b6hZ7hLgJXS8I6Eg/UsOi8lkYd5042J204M WpOaLz7wdCX3TGDvmR+9nhvGu27CyFUbAHZL7KooYyJygcMqnXlfEG4xd9j9rmYAscrA Fkr33vwyl2f+cqf8KNqY0bMyI2t2Bs6ZyN01+USMPxMGzyy6clb3h2snWCIx5f9Agp3C N1obPLIOhxDhcXQ4Q3vbO4dbgUw3Hfa+g2GltXB+sDOtZVZc/tHc8wepe0WpMZMpGlKf 8wslpz13vaH9VChwe8M5Icr6b7u6qxsAOgpF+qLLYsMVBA3NENh0V0SDLhtpI0PIjsBS qGrQ== 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=sztJR+YGdxX3nAfP2x4jYgkcY9IVehq4b24/c8/4cbQ=; b=FVlR1StN0H506jMVVgZploC9RRHC+7pU70SsK3wG2gKQ8LlzNxxcymUG4VcaVh6koH r8wRpJ4v6GMpaMy42dpMZHBve35STTc/DNTuhlpVLBTYJifdJA8GeFl440gqnuYgakNw mMoVdUUhG35hxIahujiAy4SX8QPh6MYK+4ciWf3lBe5fJobEogv0rAAznZ4RzHCR78Ib mWp8o3TaJ1wWOxIcvS/ed/GSsW8ddrLEOgjCHTzE4vbB1R+zrMyTVDQuyO0W4cTUq+O2 tV8oNSSLBOiMNmjpp5YAkzUE3toCBwsOxQhlRT3zxuTx5aQpt8ltq5rfNjXM8u0J/lwX eaUw== X-Gm-Message-State: AIkVDXIeakX56m5Hl8Pm3fPha3+m5Uck1N6+Ga+dX53kTuZ2WKTxVr9FhdUCdkG0dd94uw== X-Received: by 10.99.213.81 with SMTP id v17mr42769135pgi.130.1485297056279; Tue, 24 Jan 2017 14:30:56 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([209.58.138.225]) by smtp.gmail.com with ESMTPSA id t21sm47084195pfa.1.2017.01.24.14.30.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 14:30:55 -0800 (PST) To: trans@ietf.org References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> <87pojci1oh.fsf@nordberg.se> From: Melinda Shore Message-ID: Date: Tue, 24 Jan 2017 13:30:52 -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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5Pir0uLjFVBs2eP7IFcve7BQndoXpQH0Q" Archived-At: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 24 Jan 2017 22:30:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Pir0uLjFVBs2eP7IFcve7BQndoXpQH0Q Content-Type: multipart/mixed; boundary="Ro0qFLm7TMoXO0EkdPg0903MPacmKL2Ln"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> <87pojci1oh.fsf@nordberg.se> In-Reply-To: --Ro0qFLm7TMoXO0EkdPg0903MPacmKL2Ln Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/24/17 1:23 PM, Ryan Sleevi wrote: > Unfortunately, I don't know if the IETF really has a good way of "This > is good and important work, has what seems like a lot of good and > important ideas, but let's keep this on the burner until more > implementations exist" :( We really don't, but that's in part why we have an Experimental track. Hatless, I would tend to argue in favor of continuing to progress this towards publication as an experimental standard and then revving it in the future based on implementation experience. Melinda --Ro0qFLm7TMoXO0EkdPg0903MPacmKL2Ln-- --5Pir0uLjFVBs2eP7IFcve7BQndoXpQH0Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYh9WcAAoJELiGRpM6HoEuKfAP/R7cS+5qCNGd/ObcdharkHhB UBP/ArJw+Ff2BTlOMtVeAEUhy/F6purYn0s92vMwXPN/jqn+Dr/oT6cUTLMekW3Z dYsb4y4JbWGff/jA+HqWXRKqpL1SYNv37Aen7mYi/ZfA/hn0VeC162GcOqyfgkBh wZxgdzf0GU+JACo+LQgYEVt+CGeVQrsn8rKS92DlZSCqUZrZdcK6TEDSCoBjjBuu 6mfaxLhVxa9WrsyZxGeJ5faE3xxZ2S7U61pM7IQ4wg1sKvH4pyJpuJ8aOwBVQnK2 IDzOCnnAZt0YK/67ZnGgLL+LB5Vb3ySDeaKUhYN2xD5TOxWqhsIDeibRbYLH9RcJ 8C1bXG6OlkDI+AhE1mHHQlE7qfzgsmINeMSsa5z6thz9WGoxrXODnqlZIlJnrLLR l1i1NALgWoMPLRxGT/+J9YQQvI7lP0ZKkoGdB9YpveHt69arcT2CHXOmaRS72/tq 9toQhtzmigKK3I4CpftAtf5hVxjorDmr0I+WTYor+Cbf3tq3jKtcmi78Wp+XGEuh k3/h+Cdbxfl+w1zl2aZsk4EbUhTzhb/bj6kVM9EoN+fvQNSIR35i/VFnFdrrujJG +RmQiY7K3CyXMqkZqNr3Clo2rjZRMBWS9YF/ZOJzs+cgoNP668OJiy1WesO05mCP e06aG8PyjkjCE4W8EJB7 =D3Qx -----END PGP SIGNATURE----- --5Pir0uLjFVBs2eP7IFcve7BQndoXpQH0Q-- From nobody Tue Jan 24 16:05:43 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 5F8EE1295A5 for ; Tue, 24 Jan 2017 16:05:42 -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 NemhA_BpQG1w for ; Tue, 24 Jan 2017 16:05:41 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5936312958A for ; Tue, 24 Jan 2017 16:05:41 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B2709433534; Wed, 25 Jan 2017 00:05:40 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 3F934433530; Wed, 25 Jan 2017 00:05:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485302740; bh=hUurL1vqiy35l6MYHE3QNM85Cr2BrRh/a4QVNmyn9DA=; l=218; h=From:To:Date:References:In-Reply-To:From; b=DHVo9L8Gd9f0jNjaWBF8VkwMVwpyIc2BuNPUtW2B9bd/XIUpgclbbMT+RNkw7yLWF 9tf/Z/nmF7xqO1WjmWD/UwmLxxtK3Ika+nTK7BhNgMVjmdaPgDAc8LamFNCddFO5fG 5Gy7XTN+1dBV09QvQWvD3jKbeE8VRXZHKPkB+J3M= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 3A8051FC86; Wed, 25 Jan 2017 00:05:40 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 24 Jan 2017 19:05:39 -0500 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; Tue, 24 Jan 2017 19:05:39 -0500 From: "Salz, Rich" To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Working group last call, draft-ietf-trans-gossip Thread-Index: AQHSbBrRzgIJq5CxsEaROHpx/el7xKFIOqiGgABh1wCAAAImAP//xpvQ Date: Wed, 25 Jan 2017 00:05:38 +0000 Message-ID: <03be718834a24041be1fac40cb383343@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> <87pojci1oh.fsf@nordberg.se> 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.32.196] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 25 Jan 2017 00:05:42 -0000 > Hatless, I would tend to argue in favor of continuing to progress this to= wards > publication as an experimental standard and then revving it in the future > based on implementation experience. Works for me! From nobody Tue Jan 24 18:47:54 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 2A75612962E for ; Tue, 24 Jan 2017 18:47:53 -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=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 pxRZuiGqth0i for ; Tue, 24 Jan 2017 18:47:51 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::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 6D87412962B for ; Tue, 24 Jan 2017 18:47:51 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id x75so125636583vke.2 for ; Tue, 24 Jan 2017 18:47:51 -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=OuopNQouMyRq20wSmjNKPFN0/vd4HuSdQ0Z2KMXRB5c=; b=m3J7gmei0Bd3eEXg9ZuJeFN3HMuqSJA5adEeMN2gDr77lnDVOT7Heumry/H81b2Fm4 t4awybovYCvXhST7uQZDhpyhcY5kisda8KQ5YZ0ruTKNMWS/A+XDomHLjGynCDFpSkLz yKuv54pGIrzykJNhhynPcOeWOrrTKTASgpYqkPKo2fL1c77zg+ODlXh/gbn2+mRwOYCw BLr2WwkDi+8kWtVmA1LrGD/bhbTZU3LWxC79RXdfbAD3SiQ9Vuy0xxMf5uwZD7p6v3yU edqTRermNZVL6rcqDwvWF23+xjMJL9lEf0SATJkHSWK8XP/0I9u8qBpQOSWSfilfYogf s/RQ== 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=OuopNQouMyRq20wSmjNKPFN0/vd4HuSdQ0Z2KMXRB5c=; b=pzPLGpJEf8fbEMX3MUCsEYRCRPf+seEIa6y93M0ksdEDWQ76Ij6rALpeUNwkqiwSux Pk7UI9wdKsGbhAQMZtzZWqkrvJUtJoxLhzNkXM41lq6XcxXRAdh6qxGrMQrtXt6WxRM4 ZK8FwC+93kvYC6NnECyo1R4N9MxMqgjK4sdqiVcivbxyQ0Q8JMWWFnsZ7AsFBlJKU4ie 3wvLgCUu9FR9bGZBetz4JPYevKOSn8pF38ozFdtpj4ry7Jx/NTaCVl1kdd/kfguzafal KhoLbfR5y3/mvVnCVoekpnRE+BCZoDFueJZE781911p8pOWJEhDe75ByAfwgtcQSlsFC Dc7A== X-Gm-Message-State: AIkVDXL0aPZ+jZM3Lj6WV1VwxSfBY+rqELkhBntO28mziYMpio5rXV/7jvLEboTjTxpwG8nxNKrWq4hqmxcf4A== X-Received: by 10.31.150.134 with SMTP id y128mr15360048vkd.102.1485312470475; Tue, 24 Jan 2017 18:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Tue, 24 Jan 2017 18:47:50 -0800 (PST) In-Reply-To: <03be718834a24041be1fac40cb383343@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6c3c9bcd-528f-52a9-872d-441b35c0235a@gmail.com> <87pojci1oh.fsf@nordberg.se> <03be718834a24041be1fac40cb383343@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Tue, 24 Jan 2017 21:47:50 -0500 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a1141d6002f88f90546e24232 Archived-At: Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 25 Jan 2017 02:47:53 -0000 --001a1141d6002f88f90546e24232 Content-Type: text/plain; charset=UTF-8 Without commenting on the substance of the document, process-wise I would be OK with this as Experimental, if the WG thinks it's worth capturing state. On Tue, Jan 24, 2017 at 7:05 PM, Salz, Rich wrote: > > Hatless, I would tend to argue in favor of continuing to progress this > towards > > publication as an experimental standard and then revving it in the future > > based on implementation experience. > > Works for me! > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1141d6002f88f90546e24232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Without commenting on the substance of the document, proce= ss-wise I would be OK with this as Experimental, if the WG thinks it's = worth capturing state.

On Tue, Jan 24, 2017 at 7:05 PM, Salz, Rich <rsalz@akamai.= com> wrote:
> Hatless, I would tend to argue in favor of continuing to progress th= is towards
> publication as an experimental standard and then revving it in the fut= ure
> based on implementation experience.

Works for me!

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

--001a1141d6002f88f90546e24232-- From nobody Tue Jan 24 23:40:22 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 C8A31129841 for ; Tue, 24 Jan 2017 23:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Q2auKAKN0mZv for ; Tue, 24 Jan 2017 23:40:19 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473DC1297EF for ; Tue, 24 Jan 2017 23:40:19 -0800 (PST) Received: from [47.143.125.235] (helo=Williams-MacBook-Pro.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cWIBf-0005jN-20 for trans@ietf.org; Wed, 25 Jan 2017 02:40:11 -0500 Date: Tue, 24 Jan 2017 23:40:00 -0800 From: Bill Frantz To: trans@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79a2d9114804963457a5408f306ec6b8ff350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.235 Archived-At: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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, 25 Jan 2017 07:40:21 -0000 Given there are no implementations, Experimental seems right to=20 me, and a good way to capture the progress so far. Cheers - Bill On 1/24/17 at 6:47 PM, rlb@ipv.sx (Richard Barnes) wrote: >Without commenting on the substance of the document, process-wise I would >be OK with this as Experimental, if the WG thinks it's worth capturing >state. > >On Tue, Jan 24, 2017 at 7:05 PM, Salz, Rich wrote: > >>>Hatless, I would tend to argue in favor of continuing to progress this >>towards >>>publication as an experimental standard and then revving it in the futur= e >>>based on implementation experience. >> >>Works for me! ----------------------------------------------------------------------- Bill Frantz | Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345=20 Englewood Ave www.pwpconsult.com | - Jeff Frantz | Los Gatos,=20 CA 95032 From nobody Wed Jan 25 11:03:50 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 5A05D129AE5 for ; Wed, 25 Jan 2017 11:03:48 -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 l5BlYBPXTjjC for ; Wed, 25 Jan 2017 11:03:47 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 18F92129AE3 for ; Wed, 25 Jan 2017 11:03:47 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 75so20414993pgf.3 for ; Wed, 25 Jan 2017 11:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version; bh=pjVXo4Yxr5JbC/zNoD4dhK+14a3Fs1CWHwre276Xf4I=; b=gr2BoDbbUUwvC9b7ypahlDNqgDIb7yxgRjJHWbIyxaBy5XVDe35g8YrbWm7poS/8ap jLYP8yFUPMA0rNDKPr/rtZfV8GJKhlsxcsUYgqHE/9Byc6FYDuXFwHI6i3cb/VpgKgbF Kf1iH/JnLhVnoKEkmSjcy0IWiiOd+cnyBgJ/3I5ZOafaXNcK08vpthC+YOjdFupqMeMd rZeJ2VqFf5vZB8m8zCQh7mCElDHmroYAN7PFPu+S7+Q/vVemvuVMOqUg/GgcvRq3FIyc KmEgkoEcs5WirLu3uGv5t0CWGe9XH30odtgUGKAB6LjCzJ3l+uDWaVYDEksPo0L2ok5Q K0vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version; bh=pjVXo4Yxr5JbC/zNoD4dhK+14a3Fs1CWHwre276Xf4I=; b=BYmwcKP5TiezgfCmnWrUIcK3qFvt9M6F/91TJpZWATuzmIXd+hUR5TtC07mYIFM9/y rTaj4Nf5IHuLyeX+Eja17BTzhx0ig8FSL4pPm+3Vfy99LNb6LihXemHkQ5kCrPVMZQp/ 7wStA8V8P49XMwv+xxyWdD1pmGG1+50Raf4OWbDbsvjAAmPbJDC200TlV4y+Xvm0xKix JZ08yrbsHJtqpm7SrqjSNAwOdfEw4IfGwYGSYsBvaZ1gnna1s2bdaYjn/vtZvElDiJ2u tnOpzElNq8zRYABhNVnwMqGBJtyYcSe6qMs7ycVw+0k8FF/A/5yDsPKD13jzxa22M16a zrSA== X-Gm-Message-State: AIkVDXKwCw1pd5EJ9/NlrFAlJRpPjTXJq4LH4JSwcyIiG010cuD8VKqhUo1IuRNQ3xt8ig== X-Received: by 10.98.29.195 with SMTP id d186mr47826111pfd.144.1485371026476; Wed, 25 Jan 2017 11:03:46 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-95-132-radius.dynamic.acsalaska.net. [63.140.95.132]) by smtp.gmail.com with ESMTPSA id o18sm2948505pgn.36.2017.01.25.11.03.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:03:45 -0800 (PST) To: trans@ietf.org From: Melinda Shore Message-ID: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> Date: Wed, 25 Jan 2017 10:03:43 -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="jOHx0WMVDhsAoDG08OxLThOuRTaxLh3jG" Archived-At: Cc: rlb@ipv.sx, ekr@rtfm.com, Paul Wouters Subject: [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, 25 Jan 2017 19:03:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jOHx0WMVDhsAoDG08OxLThOuRTaxLh3jG Content-Type: multipart/mixed; boundary="2vxPhTEsUkjSdFAVRHEqnCKlBwTmaLoxl"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Cc: Paul Wouters , rlb@ipv.sx, ekr@rtfm.com Message-ID: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> Subject: Update on 6962-bis issues raised by Richard Barnes and EKR --2vxPhTEsUkjSdFAVRHEqnCKlBwTmaLoxl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: We've been looking at the discussion and trying to figure out next steps. Because we believe that the mechanisms Richard's asking for can be built on top of what's specified in 6962-bis, we've decided that we're going to continue progressing the document towards publication, and look to Richard and EKR to produce a draft specifying a mechanism that meets their requirements with the intent of adopting it as a working group deliverable. Thanks, Melinda --2vxPhTEsUkjSdFAVRHEqnCKlBwTmaLoxl-- --jOHx0WMVDhsAoDG08OxLThOuRTaxLh3jG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYiPaPAAoJELiGRpM6HoEu1TMP/22lT3z+5BaJqA6A0fQbVDCA za8nDIvjfi9EFxtDJOt1AGLmVNKVhQXtfTW/uas8OprYmJmDQvWJGYLuFYKe8Gd2 Mb4iMnW76izMnrpDZI9b2d4tl7cmBLejux5jf8D8b0AOfpnZ/LrajuIxTW7CzQ9t q8z/NickZzoe/6UdLtTKK3OfCkFFeXU52kXF9MDG5pGnYm7CSFX6Qd6PnaLByq2Z v3W6RJpWIgTzzDHsqtPrgzvMj9Dtp6LOtvEcWc7gT7rQGrBFTb0WbArd72ysa/+k jGILbZFS6eNUsJZLRYP5pDLz2V8P5fh9H6xfSRN7ohFCsqpgGU5+8fqtL1gCP135 cWJ9JMTY+IZAfAaVYB4Um65a/osFe1YK5fot6A0kZFy0aFqPD5WAUlJzQldw799O PElj2D8RKrH3Yb3h/sJrm51dlqaAR3jiDXvJg8emn7lr6TlOkx4F4swYBmtnap5a mFFvp7kJOwl+lxi1fSHCH/ShvzeME1vRFbZ08/b4B+8hT69eUow4eC5Ug0Ysym3m aZrHTKcspnATu0hbOaWgSvtWJ2OxHSV1+PXoW8GhTec4YGuqgbaM0pBX8VpTM2lO XHuXifywCR4ZuZH4MPksvHmuXlyRqHpLMSaGRwDkYB19N0HniQXXkKIf3xoWvBUh tJyTtH3lQXnihjp/wyfh =1n2J -----END PGP SIGNATURE----- --jOHx0WMVDhsAoDG08OxLThOuRTaxLh3jG-- From nobody Thu Jan 26 16:37:53 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 D5AFF128BA2 for ; Thu, 26 Jan 2017 16:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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_SORBS_SPAM=0.5] autolearn=no 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 uoi2TL6t1WNM for ; Thu, 26 Jan 2017 16:37:51 -0800 (PST) Received: from homiemail-a88.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 0E471120727 for ; Thu, 26 Jan 2017 16:37:51 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 8856AA003A1D for ; Thu, 26 Jan 2017 16:37:50 -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=uNG/e1eguzTzCp7FBx8G28QHi5c=; b= RdEKAFG7KIiFTRZXRgeeTwoSeYVr0wJ7jtQ5ihnnwY65ufghSpuhgCrKGcJieNqe wP9wpirSLebNuBxyHNROLWEeCOiUlXohug5taWD42PVw8KTE+TpQwZEyaRCO4IfZ oumpJqNgHnpwA0/QhArE/mPahkJljZqIKEa+FLqoi0c= Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 5366EA003A1B for ; Thu, 26 Jan 2017 16:37:50 -0800 (PST) Received: by mail-lf0-f44.google.com with SMTP id x1so67680616lff.0 for ; Thu, 26 Jan 2017 16:37:50 -0800 (PST) X-Gm-Message-State: AIkVDXKcVsmORA9D/OWH6s8vaVrxcDJOIk4YY8o3PwmgrjFV3k5Z55+0BNTIA2zyW0QIWS2s+UKGmcC//CRpJA== X-Received: by 10.46.83.19 with SMTP id h19mr2100312ljb.72.1485477468441; Thu, 26 Jan 2017 16:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.154 with HTTP; Thu, 26 Jan 2017 16:37:47 -0800 (PST) In-Reply-To: References: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> <20170112142840.8c95f645172301b0facfc29c@andrewayer.name> From: Ryan Sleevi Date: Thu, 26 Jan 2017 16:37:47 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Eran Messeri Content-Type: multipart/alternative; boundary=94eb2c1cfdcad41692054708acd6 Archived-At: Cc: Ryan Sleevi , "trans@ietf.org" , Andrew Ayer Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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, 27 Jan 2017 00:37:52 -0000 --94eb2c1cfdcad41692054708acd6 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 2:56 AM, Eran Messeri wrote: > > - Navigating to hosts by IP which have SSL certificates logged in CT logs > would now be disclosed to the UA's resolver. A mitigation could be not > looking up inclusion proofs for these if data shows this is a common use > case. > Meaning if it was an uncommon use case, the privacy leak is deemed acceptable? > - Resource Hints: Not sure I see how that's related to this discussion. > Ryan, can you elaborate? > It was a terminology issue in the section "Disclosure of visited hosts vs resolved hosts" - I was highlighting that the term "pre-fetch" in your analysis, in particular, " This is less of an issue if pre-fetches actually fetch content, rather than just looking up IP addresses for links/resources the user is likely to consume." As defined in Resource Hints (e.g. what UAs are doing), there's a distinction between "DNS prefetch" (which appears to be how you're using the term "prefetch"), "preconnect", and "prefetch" (which, in Resource Hints usage, implies an actual fetch of the resource). So what you saw as an ambiguous term ("prefetch" in your usage) is captured in Resource Hints as two distinct terms ("DNS prefetch" vs "prefetch") --94eb2c1cfdcad41692054708acd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 2:56 AM, Eran Messeri <eranm@google.com>= wrote:
- Navigating to hosts by IP which have SSL certificates logged i= n CT logs would now be disclosed to the UA's resolver. A mitigation cou= ld be not looking up inclusion proofs for these if data shows this is a com= mon use case.

Meaning if it was= an uncommon use case, the privacy leak is deemed acceptable?
=C2= =A0
- Resource Hints: Not sure I see how that's related to this discu= ssion. Ryan, can you elaborate?

It was a terminology issue in the section "Disclosure of visited host= s vs resolved hosts" - I was highlighting that the term "pre-fetc= h" in your analysis, in particular, " This is less of an issue if= pre-fetches actually fetch content, rather than just looking up IP address= es for links/resources the user is likely to consume."

<= /div>
As defined in Resource Hints (e.g. what UAs are doing), there'= ;s a distinction between "DNS prefetch" (which appears to be how = you're using the term "prefetch"), "preconnect", an= d "prefetch" (which, in Resource Hints usage, implies an actual f= etch of the resource). So what you saw as an ambiguous term ("prefetch= " in your usage) is captured in Resource Hints as two distinct terms (= "DNS prefetch" vs "prefetch")
--94eb2c1cfdcad41692054708acd6-- From nobody Sat Jan 28 12:06:20 2017 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F92D129789; Sat, 28 Jan 2017 12:06:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148563397836.17916.11890932534937296933.idtracker@ietfa.amsl.com> Date: Sat, 28 Jan 2017 12:06:18 -0800 Archived-At: Cc: trans-chairs@ietf.org, trans@ietf.org, melinda.shore@nomountain.net, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Update to a Meeting Session Request for IETF 98 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 20:06:18 -0000 An update to a meeting session request has just been submitted by Melinda Shore, a Chair of the trans working group. --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Melinda Shore Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: mtgvenue dnsop ipsecme httpbis Second Priority: curdle tls Third Priority: sacm Special Requests: --------------------------------------------------------- From nobody Sun Jan 29 09:15:18 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 8DFD212952F for ; Sun, 29 Jan 2017 09:15:16 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j87P6hKLYdZ6 for ; Sun, 29 Jan 2017 09:15:15 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 BC560129431 for ; Sun, 29 Jan 2017 09:08:49 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id f67so78744706ybc.2 for ; Sun, 29 Jan 2017 09:08:49 -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=k7uh8dc6BmKupgIavnAS6rP9MQtogGFHl3L2R7jUqjM=; b=m4IlRap8+RcDZaZ+1qJ9s+3G3vKKn02FD3CnQFU1sgW5NNubK0435K21Olw5t/cQM/ JXr6deaumenPvNBtq4SNk4zGnvA2F6I7V/YI61iR2U7zfdLlj16QGUVC5W6Jke8H2zsb 1Ea4JwFgeOoQAmZMlCmmDbyBAi416IwjzwpfdR2xiVWx1lSXn48gNBBVcIOFxaXuX+IP i6Otymj3tv9mDmvsotjY1gMRAt67wtVyy/S/RB3yDhMD0242YaFoK+Hq2exRbJRsNN/g KjmTsmsGjL/liGQNS18dIWL8ybLz9X1K9TGqXsAEW5G2Ut8kcVPcaHVFHDPs5HDBxk2t yR+w== 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=k7uh8dc6BmKupgIavnAS6rP9MQtogGFHl3L2R7jUqjM=; b=MTuQV/jEFEk4vpPKq2tjaY1cMbS4TyyMqZt6EEA3NnrfXKFSX2iiUpJf/oBTP2dNR0 Ygi5VgC3YRypEXMuA07V48SJytEm3YB7wmeBkXhFz+8ztUcJzBlBGKcYhRgYiUINVGL/ deb2koHhs4HWhMNLIjLHn12CcDwt1NkSbV9cIsOIFEa9Fp/Q5mmLu75+/yJoFVCwk2Fw zprNOaBBtQH7R/TGG9Rl3+nmXgTCYbEHwu5jxroROGkGZ2IKBvk1yfMHDZWtCcjk/vgh 1/0g8wTk9q0rhvmOw0kgMjnAt0UbjTP3n8hu5oBnW/bdue0KUCnPZX+ZyY5OqHxPUTGy j6Hw== X-Gm-Message-State: AIkVDXJsz0qaM8Zt4+FOm3VRxCCLxP4J9CbEVzx3ADJEvwcxdk2+P8Nsm7bVPeIJRew2q95dGXHnhsyXvdmJFA== X-Received: by 10.37.246.10 with SMTP id t10mr9212744ybd.107.1485709729016; Sun, 29 Jan 2017 09:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sun, 29 Jan 2017 09:08:08 -0800 (PST) In-Reply-To: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Eric Rescorla Date: Sun, 29 Jan 2017 18:08:08 +0100 Message-ID: To: Melinda Shore Content-Type: multipart/alternative; boundary=f403045dc858a35e2405473ec0c1 Archived-At: Cc: Richard Barnes , Paul Wouters , trans@ietf.org 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: Sun, 29 Jan 2017 17:15:16 -0000 --f403045dc858a35e2405473ec0c1 Content-Type: text/plain; charset=UTF-8 Hi Melinda, Unfortunately, I don't believe that the concerns that we are proposing can in fact be plausibly addressed by post-hoc mechanisms on top of the 6962-bis structure. To be precise, one might build either: (a) A system which is not publicly verifiable in which case EEs would only need to handle and provide SCTs and one can and should dispense with much of the Merkle hash tree infrastructure. (b) A system in which is publicly verifiable in which case the current Merkle hash tree infrastructure seems inadequate and would need to be revised, not just built on top of. Either of these seem like reasonable WG decisions (though the charter pretty clearly contemplates (b)) but the current draft doesn't really do either. For that reason, I don't think it makes sense to just proceed as-is. Typically for last call comments of this magnitude the process would be to discuss them at the next IETF. Accordingly, rather than pubreq the draft now, we'd ask for agenda time to discuss in Chicago. -Ekr On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore wrote: > Hi, all: > > We've been looking at the discussion and trying to figure > out next steps. Because we believe that the mechanisms > Richard's asking for can be built on top of what's specified > in 6962-bis, we've decided that we're going to > continue progressing the document towards publication, > and look to Richard and EKR to produce a draft specifying > a mechanism that meets their requirements with the intent > of adopting it as a working group deliverable. > > Thanks, > > Melinda > > --f403045dc858a35e2405473ec0c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Melinda,

Unfortunately, I= don't believe that the concerns that we are proposing
can in= fact be plausibly addressed by post-hoc mechanisms on top of
the= 6962-bis structure. To be precise, one might build either:

<= /div>
(a) A system which is not publicly verifiable in which case EEs w= ould
=C2=A0 =C2=A0 only need to handle and provide SCTs and one c= an and should
=C2=A0 =C2=A0 dispense with much of the Merkle hash= tree infrastructure.

(b) A system in which is pub= licly verifiable in which case the
=C2=A0 =C2=A0 current Merkle h= ash tree infrastructure seems inadequate and
=C2=A0 =C2=A0 would = need to be revised, not just built on top of.

Eith= er of these seem like reasonable WG decisions (though the
charter= pretty clearly contemplates (b)) but the current draft
doesn'= ;t really do either. For that reason, I don't think it makes
= sense to just proceed as-is. Typically for last call comments
of = this magnitude the process would be to discuss them at the
next I= ETF. Accordingly, rather than pubreq the draft now,
we'd ask = for agenda time to discuss in Chicago.

-Ekr
<= div>

On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore <melinda.shore@gma= il.com> wrote:
Hi, all:

We've been looking at the discussion and trying to figure
out next steps.=C2=A0 Because we believe that the mechanisms
Richard's asking for can be built on top of what's specified
in 6962-bis, we've decided that we're going to
continue progressing the document towards publication,
and look to Richard and EKR to produce a draft specifying
a mechanism that meets their requirements with the intent
of adopting it as a working group deliverable.

Thanks,

Melinda


--f403045dc858a35e2405473ec0c1-- From nobody Sun Jan 29 09:44:41 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 AF4F0129579 for ; Sun, 29 Jan 2017 09:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 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_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 fSNKvg9GkbwS for ; Sun, 29 Jan 2017 09:44:36 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 C4C6C129575 for ; Sun, 29 Jan 2017 09:44:35 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id i68so236366912uad.0 for ; Sun, 29 Jan 2017 09:44:35 -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=x4W+TtsggvT6uau+N3SvNp+fCyWKw+mX1O2lbfT9wD8=; b=TItHZBglyvr4zzBy0b7gfh7A/3HYsJ9VL64Wpzfheg30CWJCFVQMzZH4cJrB2RGcx1 2zUiSTqx8yxAyY+UpORYw1EXTdxtpXZM59kICIxZ37lVVCfN03itdQw4PKJkL58G34Ec e3KMq3Y7UmX2GN+13+56wwUAsjYmPagdgVMj0juTAX020VHkUIxFk7BaXf0b/z12akRu tPbJJ3hDwz2pRnZ0XJpT4BxlDXCUSc357klzuTw4EM8JIMx4wWJz3Iar0Hxf4y7NDDfn sAGl8n6mtVOyRBlMqR+Um1cNohBeU0oYCMln7gBnVHLtCbjyD/kBJnL1cK3K8L2qJpu+ hPcQ== 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=x4W+TtsggvT6uau+N3SvNp+fCyWKw+mX1O2lbfT9wD8=; b=C86F0VO6ldIA2YRaMdH6obl9ita+CX4sze6LvZJJFdnZyE16TRec9NrIdD0/JLGcry zVtDvr435Ksd4R96SWQ6ZSRfGwF4KhGfHG1oRIbl9LKJPkS2YyVH5zYBpSiyETfev8BM 3bVoBeCWBn8VzuHDiKbo97PURckFb7IQeUFhPDYsiZMsDEpX4LQd+qLCXvQq5Xl410Lg tArtOBiTsmqG2XOWvcY/miApDurLJPk6oWJn7fxy4Z0odHWWnitxg6l4Se9eRLJ9t3EJ cUjxbzOPiV2FYs4HyCzlN3rG6CuPdrG6eGn3huzARZ1s12yHBdp07tVv0QeeI+amauyO NHTw== X-Gm-Message-State: AIkVDXLeOCMFQHJ7B2wbKvpmvi1sJwWGQ8j2AGF/P2xj/CoNnFjreepXJ2kQAEKOwS3hv9KrNks4uPo6NlzcjDOk X-Received: by 10.176.65.198 with SMTP id 64mr9317225uap.40.1485711874677; Sun, 29 Jan 2017 09:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.130.199 with HTTP; Sun, 29 Jan 2017 09:44:34 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Ben Laurie Date: Sun, 29 Jan 2017 17:44:34 +0000 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , 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: Sun, 29 Jan 2017 17:44:40 -0000 On 29 January 2017 at 17:08, Eric Rescorla wrote: > Hi Melinda, > > Unfortunately, I don't believe that the concerns that we are proposing > can in fact be plausibly addressed by post-hoc mechanisms on top of > the 6962-bis structure. To be precise, one might build either: > > (a) A system which is not publicly verifiable in which case EEs would > only need to handle and provide SCTs and one can and should > dispense with much of the Merkle hash tree infrastructure. > > (b) A system in which is publicly verifiable in which case the > current Merkle hash tree infrastructure seems inadequate and > would need to be revised, not just built on top of. > > Either of these seem like reasonable WG decisions (though the > charter pretty clearly contemplates (b)) but the current draft > doesn't really do either. For that reason, I don't think it makes > sense to just proceed as-is. Typically for last call comments > of this magnitude the process would be to discuss them at the > next IETF. Accordingly, rather than pubreq the draft now, > we'd ask for agenda time to discuss in Chicago. I don't think you're right. In practice, there are mechanisms that address your concerns, I believe. Firstly, its important to understand that the goal of CT is to reveal misissuance, not to prevent it, nor to deal with it when it occurs. So, inclusion proofs. One way to deal with this would be to for browsers to report to servers the previous cert seen for that server. The server can then fetch the inclusion proof. If the client ever talks to the correct server having talked to an evil one, the evil one will be discovered. If the client doesn't, then the client is effectively in a bubble and beyond help. Another would be to require servers to serve inclusion proofs alongside the cert, once the SCT was past the MMD. This could be done either with OCSP stapling or with the TLS extension. Next, STH consistency. My preferred plan for this is to add a new leaf type, STH, and require (by policy) all logs to accept STHs from all other logs. Then you add a call to logs that lists the positions of those STHs, so they can be efficiently retrieved. Or maybe just retrieves the latest seen from each log. If inconsistent STHs are ever logged, monitors can detect this. In order to fork a log, you would then have to fork all logs. Of course, monitors and other interested parties could also gossip STHs for added value. All of these can be done on top of 6962-bis. > > -Ekr > > > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore > wrote: >> >> Hi, all: >> >> We've been looking at the discussion and trying to figure >> out next steps. Because we believe that the mechanisms >> Richard's asking for can be built on top of what's specified >> in 6962-bis, we've decided that we're going to >> continue progressing the document towards publication, >> and look to Richard and EKR to produce a draft specifying >> a mechanism that meets their requirements with the intent >> of adopting it as a working group deliverable. >> >> Thanks, >> >> Melinda >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Sun Jan 29 10:32:02 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 3224512956C for ; Sun, 29 Jan 2017 10:32:01 -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 8vkP6bO-AYTd for ; Sun, 29 Jan 2017 10:32:00 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 0320D129525 for ; Sun, 29 Jan 2017 10:32:00 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 189so84935930pfu.3 for ; Sun, 29 Jan 2017 10:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xZiAf5eMzDPhh480JUitdhDWOeMCMLBQjydl5NhIF4E=; b=J58luY5cAEMgZgMl8dO1bYVYZbW1GyGR/eBbr2GAy7inuxRMxiZA2CuQDJTkl99tTm h5RhAJxYD49qJgdIPOItkoLst9x74aP3tWDhcm4Zmc1+BL3xqv0t5Sazf5gp7MWdESvK qINUOloLfrqfDH7+ZWJkYQC8SKGmj5qYao7VqSBbH4HZGGCT3MhVs32Swl+C3t5MX/2l 4+i+7K9HrakjFkMDd75NREIRkX27/00d4UL+41M/mHffWE82gkOuURF7/22ymuxLxgWY fglgRvz/qmnZrYqvq7lvRQye4uBusgN157m3v6TQM1zIOXj7QjZ8Zt3+X5S8MS41/PxK Rjgw== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xZiAf5eMzDPhh480JUitdhDWOeMCMLBQjydl5NhIF4E=; b=iB4yFzG/Mqc6d+gHRhqVVoWg8hlrSduDu6QeueU40F0/Gg9RI0vgviYDdrxFU/NU/a izNK5HQLE+uoOlpmFr/5bUA5EKsLiKcZyLfNFOQymgL6vD3USMRX3eGEGG+gTiOhvgpz beOetnzhxb+f2Q2+GYXrgt437EdoJLs0W/CxgN+xLlbKfkCfSc0+wAnrROJSZcmpKsCC LWa6wDyaRxfo63hxBvkzc9uJP9Zp0zuow19kWuc++/pWZ4MTdugaz4PLX7X204Dt7LKf 5t2S5AOHIJ0cp/tFJRjqfpJeuWozoIFK0EpIIlTdNEh0ZEPj7EKeLFix8ZR+fsLlMeSG dYeA== X-Gm-Message-State: AIkVDXLz2zzzESoWgIThCbmewTdWqIE/txJheax0ScjF+6+VmpnijGuI0tfX1ys7u71ZpQ== X-Received: by 10.84.143.195 with SMTP id 61mr26644611plz.46.1485714719239; Sun, 29 Jan 2017 10:31:59 -0800 (PST) Received: from Melindas-MacBook-Pro.local (69-161-16-146-radius.dynamic.acsalaska.net. [69.161.16.146]) by smtp.gmail.com with ESMTPSA id c2sm26178517pfl.61.2017.01.29.10.31.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 10:31:58 -0800 (PST) To: Eric Rescorla References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Melinda Shore Message-ID: <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> Date: Sun, 29 Jan 2017 09:31:54 -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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1swO4qSj6m88cXrgFwRwSxba2cw8D5GkS" Archived-At: Cc: Richard Barnes , Paul Wouters , trans@ietf.org 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: Sun, 29 Jan 2017 18:32:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1swO4qSj6m88cXrgFwRwSxba2cw8D5GkS Content-Type: multipart/mixed; boundary="SxBDqJgo2GdGirjtLhX4Oe1hU9hlMSpll"; protected-headers="v1" From: Melinda Shore To: Eric Rescorla Cc: trans@ietf.org, Paul Wouters , Richard Barnes Message-ID: <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> Subject: Re: Update on 6962-bis issues raised by Richard Barnes and EKR References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> In-Reply-To: --SxBDqJgo2GdGirjtLhX4Oe1hU9hlMSpll Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/29/17 8:08 AM, Eric Rescorla wrote: > Either of these seem like reasonable WG decisions (though the > charter pretty clearly contemplates (b)) but the current draft > doesn't really do either. For that reason, I don't think it makes > sense to just proceed as-is. Typically for last call comments > of this magnitude the process would be to discuss them at the > next IETF. Accordingly, rather than pubreq the draft now, > we'd ask for agenda time to discuss in Chicago. Of course, but in the meantime I'm not really a fan of holding work hostage to meeting schedules (my own deficiencies in that area duly noted), plus -bis draft authors often don't come to meetings, plus it looks possible that a number of regular attendees may not be coming to Chicago because of the political situation. We can try to have a conference call in the next week or so, if people are up for that. Melinda --SxBDqJgo2GdGirjtLhX4Oe1hU9hlMSpll-- --1swO4qSj6m88cXrgFwRwSxba2cw8D5GkS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYjjUbAAoJELiGRpM6HoEuazoP/1dX8CUEshQ8oJOvTxzm6UzL u4gJ0W67qoarjRb3gqbLnbnvMtIRLW3kTr3ZaeKi2BCeaaBYkufsWYY0t5hkw0/A Q4gQkDUUoUNnp0yDcnqIKhyYzmMZBdF5vv5C/Un9a94HhtAoAvx7Ai4mZuGePVVg PN+pt5VRkS3I2TGtSjVTvReDWEBcS8KY4+34Hbw5BZD2+KFDSk0t2k+nAUihFow/ BmTEVzviqgo5g0FDWAgaYEBHB/TPCst2/C4/xRoKk+qgxw3JCyIYAcyOb/yvQDL0 u16/JIGUR5Aj/hRAyJ9TxF1axXnAx/H7uGh0cobdFoMWei0egw7IjHW1h5P/9sAU fDoi8IUEVjCfFLajuzfiKnjFDHmdEuAvG7sOvkwxSk0gBOWN71TH0B9oXPBiQdm+ k/IITuSz51AwBJbnHoY77iz0CydnSVpyOfqsGz7XzH3LGJ9GL7SqFH/l8nYfEtQm jYMDznxMKhPBAvUd6eFrHzHQpl6wNJI4uhnoFoKBiYLKW7PbhyCemLGikE5eBO1Z xWmP0J+Dw30nc28rkf5/OhRsvbAHl1GufpScO5el8r1y5iB4slv/Fx9FDUMtBf9Y bHeBevegO3Jln1NhdjDtCd7Om8aw4AmwOjBRPdVKs/xlZJ0IJ9hfa4njxiiW79M7 oDQyqzXCCUi2D1vY2+T8 =i4dI -----END PGP SIGNATURE----- --1swO4qSj6m88cXrgFwRwSxba2cw8D5GkS-- From nobody Sun Jan 29 15:12:46 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 5C7051296B1 for ; Sun, 29 Jan 2017 15:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 La5gKk-hR9GG for ; Sun, 29 Jan 2017 15:12:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 DF848129675 for ; Sun, 29 Jan 2017 15:12:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vBSwm51Hdz32f; Mon, 30 Jan 2017 00:12:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1485731560; bh=17MVrmfrN93xG/8UeJPNhe8KEHaPoxuzvg+/l66ZjH0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=pRC3zrhTT4PUtSPHu0s3167eCwIdjCBxxNO18Yu3RSzgvxV/R/zUn39IrusffgHbv GbuiiOgPYe1jg+PmWNkv+lL1PlZ/eS4SSwV4Kg+XFoLWGIq0Gnd9HoztJDTKfwGrDW 49nMiT+WjYoRwGfmU+20gWUmUEDV7FOBUQkS3hqU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ssMHXnaJkFXK; Mon, 30 Jan 2017 00:12:38 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 30 Jan 2017 00:12:38 +0100 (CET) Received: from [193.111.228.71] (unknown [193.111.228.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 3A27E3F2850; Sun, 29 Jan 2017 18:12:32 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3A27E3F2850 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14D27) In-Reply-To: <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> Date: Sun, 29 Jan 2017 18:12:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> To: Melinda Shore Archived-At: Cc: Richard Barnes , Eric Rescorla , trans@ietf.org 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: Sun, 29 Jan 2017 23:12:45 -0000 I think a conference call would be good. I think if we call it an interim me= eting, we might need to give more notice. Paul Sent from my iPhone > On Jan 29, 2017, at 13:31, Melinda Shore wrote: >=20 >> On 1/29/17 8:08 AM, Eric Rescorla wrote: >> Either of these seem like reasonable WG decisions (though the >> charter pretty clearly contemplates (b)) but the current draft >> doesn't really do either. For that reason, I don't think it makes >> sense to just proceed as-is. Typically for last call comments >> of this magnitude the process would be to discuss them at the >> next IETF. Accordingly, rather than pubreq the draft now, >> we'd ask for agenda time to discuss in Chicago. >=20 > Of course, but in the meantime I'm not really a fan of holding > work hostage to meeting schedules (my own deficiencies in that > area duly noted), plus -bis draft authors often don't come to > meetings, plus it looks possible that a number of regular > attendees may not be coming to Chicago because of the political > situation. We can try to have a conference call in the next > week or so, if people are up for that. >=20 > Melinda >=20 >=20 >=20 From nobody Sun Jan 29 15:25:35 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 036F0129771 for ; Sun, 29 Jan 2017 15:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 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_MED=-2.3, 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=cs.tcd.ie 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 0knBWpffUShY for ; Sun, 29 Jan 2017 15:25:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D5A12975C for ; Sun, 29 Jan 2017 15:25:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6317FBE2E; Sun, 29 Jan 2017 23:25:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltq8uJp0ogHh; Sun, 29 Jan 2017 23:25:29 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AC0A4BE2C; Sun, 29 Jan 2017 23:25:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485732329; bh=yR45JPKPW+qUnqashJNeI/pkaZpsEOQZxqvizOLYy1E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UvbNtXneLD24kqitFQxsFxHDytAvEq0jkSHM8rb7QCnCHYNT3IeKqeqnDFqVYpBfC GbR7csXDCvl4ZKOy6nlTdCcd1xPWetc/MZNv62Zd66XRYtYVDxl+pcizQeCipkGSsi 9u6LE2wkymJlmpJHmW+Vj48/6FXKN+/eGvgDUE24= To: Paul Wouters , Melinda Shore References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 29 Jan 2017 23:25:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060805080200080701050703" Archived-At: Cc: Richard Barnes , Eric Rescorla , trans@ietf.org 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: Sun, 29 Jan 2017 23:25:34 -0000 This is a cryptographically signed message in MIME format. --------------ms060805080200080701050703 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29/01/17 23:12, Paul Wouters wrote: > I think a conference call would be good. I think if we call it an > interim meeting, we might need to give more notice. You need "one week (ideally two)" [1] though the chances of finding a slot that has all the necessary folks within one week seems small. As noted in [1] you don't need AD approval for a virtual interim, but I do happen to agree it's a good idea:-) Cheers, S. [1] https://www.ietf.org/iesg/statement/interim-meetings.html >=20 > Paul >=20 > Sent from my iPhone >=20 >> On Jan 29, 2017, at 13:31, Melinda Shore >> wrote: >>=20 >>> On 1/29/17 8:08 AM, Eric Rescorla wrote: Either of these seem >>> like reasonable WG decisions (though the charter pretty clearly >>> contemplates (b)) but the current draft doesn't really do either. >>> For that reason, I don't think it makes sense to just proceed >>> as-is. Typically for last call comments of this magnitude the >>> process would be to discuss them at the next IETF. Accordingly, >>> rather than pubreq the draft now, we'd ask for agenda time to >>> discuss in Chicago. >>=20 >> Of course, but in the meantime I'm not really a fan of holding work >> hostage to meeting schedules (my own deficiencies in that area duly >> noted), plus -bis draft authors often don't come to meetings, plus >> it looks possible that a number of regular attendees may not be >> coming to Chicago because of the political situation. We can try >> to have a conference call in the next week or so, if people are up >> for that. >>=20 >> Melinda >>=20 >>=20 >>=20 >=20 > _______________________________________________ Trans mailing list=20 > Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans >=20 --------------ms060805080200080701050703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMjky MzI1MjhaMC8GCSqGSIb3DQEJBDEiBCAYSv5bnXKhPVT1pKTMmu7j+iwG50/M79a/6YOmtqvD lzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBtJXI/4rWW5Gns5ZL/WEH203XbTe9AJbBMAcdZO0AFszVtNHzCWYfZ ptLMYSBajE2HCdhK7z3/SuaC2OpLzTpL9btWYTo+YNRxA2X+PyaF5bBq4/WeBqcgaMPEkBAy hNsSEBNNjJmkWexBlFkP9C6ix2b0aFfG6yJCdCqMjckYRicGV+JEDsHs/AEdEl/WLpZPnLrq VAeJIZBhwWkWo+E/l0hBcAjOR6tFCpiD/fiNZtuD8MgZUQpiMTG6Di+5BP674oCT4FK4gFnZ XQZuzoiZWtJ0bfm6CuE8e/rcXOr9te0fwqxCCuIrh3PlhqOes9DiPdBjIMwD7oG2/xBTdQsz AAAAAAAA --------------ms060805080200080701050703-- From nobody Sun Jan 29 20:40:38 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 715C21293F8 for ; Sun, 29 Jan 2017 20:40:36 -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 2pk0GUam5VDs for ; Sun, 29 Jan 2017 20:40:34 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::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 AD1A2120727 for ; Sun, 29 Jan 2017 20:40:34 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id 123so84920950ybe.3 for ; Sun, 29 Jan 2017 20:40:34 -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=bwCI5MQCO05v1xIXCx8DnS4ov4Ai3kY86l3u3ODFAbY=; b=xHaJd13goZeOLlP1tauzDLxMzawBTve6/DMK7OTT0rgJNM2Gim+oJXKDB8C6pn2bD+ miXf0bOqaLC3cMVCPJoq50BMVY3uInLzHF72HWbJqNNMVksSKG07VQFDdzvotOmkwKNg Qq8BOX0PrOrjL9FgL30+bYiS35RUf1VyjvatHrfVN8BgKCAgEBMyE5feOvsJFJo1Vcgp aQR7DmPiHR1UdzakxVSc9pEU6GvLY6gXP+B18G071DCzJIQxBiVXXhFpCXYhkjRaPZsr EoSZvccikQIpLbadomPt0P4POGwblouG8D3dJPMTq6VjzbWC4AS4jZ6pMDmnEXmWD3A6 akSQ== 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=bwCI5MQCO05v1xIXCx8DnS4ov4Ai3kY86l3u3ODFAbY=; b=qmYAFTThioRzewse49TY/4560AuYBKAWqBByGIYULDO+wSWaQCbfm3ZwfueuDD6J7a /V+tyXl8idOhctaQbJUOI/V6ntzx9CwrrUz4g8RRv4kgpkRFNUg2Sx8o6wMgZfg7V1Ts NjOi+nWZdM03V6XInSYULJP38v4YMr6OML/ADQhCw6qxpORoR48XgY5BPqTtfgfXnJyI hiuwyQGcZg3jSQHb9V6k/G9DzBwGC29G9u8XDNHbQY+6TcvZaQvxXKi5qBVDVOg4X+kr wsSJaGd0UBQ67T6ohyroQNFB/D4X0oQlzPDynbXltANrmARg+4D73zxdoF4RXFSPetew pHMA== X-Gm-Message-State: AIkVDXK7YXJuB1m+NcZn+welx/E5SmvHRRpbzxuehvahzdFRm5bnoby+32+tiLTX7vnfqyjv59JNjImZvrw8cQ== X-Received: by 10.37.118.84 with SMTP id r81mr4362567ybc.180.1485751233921; Sun, 29 Jan 2017 20:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sun, 29 Jan 2017 20:39:53 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Eric Rescorla Date: Mon, 30 Jan 2017 05:39:53 +0100 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a114b690a85f3e80547486af6 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , 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: Mon, 30 Jan 2017 04:40:36 -0000 --001a114b690a85f3e80547486af6 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie wrote: > On 29 January 2017 at 17:08, Eric Rescorla wrote: > > Hi Melinda, > > > > Unfortunately, I don't believe that the concerns that we are proposing > > can in fact be plausibly addressed by post-hoc mechanisms on top of > > the 6962-bis structure. To be precise, one might build either: > > > > (a) A system which is not publicly verifiable in which case EEs would > > only need to handle and provide SCTs and one can and should > > dispense with much of the Merkle hash tree infrastructure. > > > > (b) A system in which is publicly verifiable in which case the > > current Merkle hash tree infrastructure seems inadequate and > > would need to be revised, not just built on top of. > > > > Either of these seem like reasonable WG decisions (though the > > charter pretty clearly contemplates (b)) but the current draft > > doesn't really do either. For that reason, I don't think it makes > > sense to just proceed as-is. Typically for last call comments > > of this magnitude the process would be to discuss them at the > > next IETF. Accordingly, rather than pubreq the draft now, > > we'd ask for agenda time to discuss in Chicago. > > I don't think you're right. In practice, there are mechanisms that > address your concerns, I believe. > > Firstly, its important to understand that the goal of CT is to reveal > misissuance, not to prevent it, nor to deal with it when it occurs. > That's a reasonable objective, but as far as I can tell it requires that the client be able to ensure that it is seeing the same thing that the rest of the world sees (i.e., "public" or "end-to-end" verifiability). The concerns that we have raised go to the practicality of achieving that. So, inclusion proofs. > > One way to deal with this would be to for browsers to report to > servers the previous cert seen for that server. The server can then > fetch the inclusion proof. > > If the client ever talks to the correct server having talked to an > evil one, the evil one will be discovered. If the client doesn't, then > the client is effectively in a bubble and beyond help. > I don't believe this is correct, at least for common clients, because the attacker can selectively interfere with just your connections to the site of interest; this would be detectable with at least some designs. Consider a trivial, inefficient, CT-like system in which the browser manufacturer scrapes the entire CT log and sends it to every browser client. As long as the manufacturer doesn't cheat (in which case you truly are beyond help, but for non-CT reasons), then a client can easily assess log-inclusion for any server as long as the connection back to the vendor is live. And if that connection fails, then the browser in fact knows it is under attack, which is different from the silent attack we have here. So, ultimately, I don't think this is that useful. Another would be to require servers to serve inclusion proofs > alongside the cert, once the SCT was past the MMD. This could be done > either with OCSP stapling or with the TLS extension. I agree that having the server serve an inclusion proof is the right design (and in fact it's what Richard and I contemplated) but this seems problematic for two reasons: 1. It's effectively retroactive consistency and so it's a weaker guarantee than prevention of compromise. I realize that that's not your objective, but it seems like it's a good one. Also, it means that if a client just goes to a site once, then compromise may never even be detected. 2. In order to operate efficiently, it requires that the client be able to verify consistency for the specific STH which this is an inclusion proof for. It's possible that this can be made efficient, especially if you minimize the number of STHs to which inclusion proofs are actually issued, but all that needs to actually be specified in some way. Next, STH consistency. > > My preferred plan for this is to add a new leaf type, STH, and require > (by policy) all logs to accept STHs from all other logs. Then you add > a call to logs that lists the positions of those STHs, so they can be > efficiently retrieved. Or maybe just retrieves the latest seen from > each log. If inconsistent STHs are ever logged, monitors can detect > this. In order to fork a log, you would then have to fork all logs. Of > course, monitors and other interested parties could also gossip STHs > for added value. > That might work, but I think again it requires some notion that there are a limited number of STHs which are actually published in practice and which there are inclusion proofs to. And then this gets into the efficiency analysis that Richard posted in his initial comments. All of these can be done on top of 6962-bis. Perhaps. However, given that these proposals are pretty essential to determining whether the public verifiability part of CT works, it would probably be good to have a fully fleshed out design to analyze prior to standardizing that piece. -Ekr > > > > > -Ekr > > > > > > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore > > wrote: > >> > >> Hi, all: > >> > >> We've been looking at the discussion and trying to figure > >> out next steps. Because we believe that the mechanisms > >> Richard's asking for can be built on top of what's specified > >> in 6962-bis, we've decided that we're going to > >> continue progressing the document towards publication, > >> and look to Richard and EKR to produce a draft specifying > >> a mechanism that meets their requirements with the intent > >> of adopting it as a working group deliverable. > >> > >> Thanks, > >> > >> Melinda > >> > > > > > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > > > --001a114b690a85f3e80547486af6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie <benl@google.com> wrote:
On 29 January= 2017 at 17:08, Eric Rescorla <ekr@rtfm.= com> wrote:
> Hi Melinda,
>
> Unfortunately, I don't believe that the concerns that we are propo= sing
> can in fact be plausibly addressed by post-hoc mechanisms on top of > the 6962-bis structure. To be precise, one might build either:
>
> (a) A system which is not publicly verifiable in which case EEs would<= br> >=C2=A0 =C2=A0 =C2=A0only need to handle and provide SCTs and one can an= d should
>=C2=A0 =C2=A0 =C2=A0dispense with much of the Merkle hash tree infrastr= ucture.
>
> (b) A system in which is publicly verifiable in which case the
>=C2=A0 =C2=A0 =C2=A0current Merkle hash tree infrastructure seems inade= quate and
>=C2=A0 =C2=A0 =C2=A0would need to be revised, not just built on top of.=
>
> Either of these seem like reasonable WG decisions (though the
> charter pretty clearly contemplates (b)) but the current draft
> doesn't really do either. For that reason, I don't think it ma= kes
> sense to just proceed as-is. Typically for last call comments
> of this magnitude the process would be to discuss them at the
> next IETF. Accordingly, rather than pubreq the draft now,
> we'd ask for agenda time to discuss in Chicago.

I don't think you're right. In practice, there are mechanism= s that
address your concerns, I believe.

Firstly, its important to understand that the goal of CT is to reveal
misissuance, not to prevent it, nor to deal with it when it occurs.

That's a reasonable objective, but as far = as I can tell it requires that
the client be able to ensure that = it is seeing the same thing that the
rest of the world sees (i.e.= , "public" or "end-to-end" verifiability).
Th= e concerns that we have raised go to the practicality of achieving
that.


So, inclusion proofs.

One way to deal with this would be to for browsers to report to
servers the previous cert seen for that server. The server can then
fetch the inclusion proof.

If the client ever talks to the correct server having talked to an
evil one, the evil one will be discovered. If the client doesn't, then<= br> the client is effectively in a bubble and beyond help.

I don't believe this is correct, at least for common cl= ients, because
the attacker can selectively interfere with just y= our connections to
the site of interest; this would be detectable= with at least some designs.

Consider a trivial, i= nefficient, CT-like system in which the browser
manufacturer scra= pes the entire CT log and sends it to every browser client.
As lo= ng as the manufacturer doesn't cheat (in which case you truly
are beyond help, but for non-CT reasons), then a client can easily
assess log-inclusion for any server as long as the connection back=
to the vendor is live. And if that connection fails, then the browser<= /div>
in fact knows it is under attack, which is different from the sil= ent
attack we have here.

So, ultimately,= I don't think this is that useful.


=
Another would be to require servers to serve inclusion proofs
alongside the cert, once the SCT was past the MMD. This could be done
either with OCSP stapling or with the TLS extension.

<= /div>
I agree that having the server serve an inclusion proof is the ri= ght design
(and in fact it's what Richard and I contemplated)= but this seems problematic
for two reasons:

=
1. It's effectively retroactive consistency and so it's a weak= er guarantee
than prevention of compromise. I realize that that&#= 39;s not your objective, but
it seems like it's a good one. A= lso, it means that if a client just goes to
a site once, then com= promise may never even be detected.

2. In order to= operate efficiently, it requires that the client be able to
veri= fy consistency for the specific STH which this is an inclusion proof for.
It's possible that this can be made efficient, especially if y= ou minimize
the number of STHs to which inclusion proofs are actu= ally issued, but
all that needs to actually be specified in some = way.


Next, STH consistency.

My preferred plan for this is to add a new leaf type, STH, and require
(by policy) all logs to accept STHs from all other logs. Then you add
a call to logs that lists the positions of those STHs, so they can be
efficiently retrieved. Or maybe just retrieves the latest seen from
each log. If inconsistent STHs are ever logged, monitors can detect
this. In order to fork a log, you would then have to fork all logs. Of
course, monitors and other interested parties could also gossip STHs
for added value.

That might work, but I= think again it requires some notion that there are
a limited num= ber of STHs which are actually published in practice and
which th= ere are inclusion proofs to. And then this gets into the efficiency
analysis that Richard posted in his initial comments.


All of these can be done on top of 6962-bis.

Perhaps. However, given that these proposals are pretty essential to
determining whether the public verifiability part of CT works, it wou= ld
probably be good to have a fully fleshed out design to analyze= prior
to standardizing that piece.

-Ekr=

=C2=A0

>
> -Ekr
>
>
> On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore <melinda.shore@gmail.com>
> wrote:
>>
>> Hi, all:
>>
>> We've been looking at the discussion and trying to figure
>> out next steps.=C2=A0 Because we believe that the mechanisms
>> Richard's asking for can be built on top of what's specifi= ed
>> in 6962-bis, we've decided that we're going to
>> continue progressing the document towards publication,
>> and look to Richard and EKR to produce a draft specifying
>> a mechanism that meets their requirements with the intent
>> of adopting it as a working group deliverable.
>>
>> Thanks,
>>
>> Melinda
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans=
>

--001a114b690a85f3e80547486af6-- From nobody Sun Jan 29 21:02:36 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 62F96129408 for ; Sun, 29 Jan 2017 21:02:35 -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 MyuYxiJAylk6 for ; Sun, 29 Jan 2017 21:02:34 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 6479E12940F for ; Sun, 29 Jan 2017 21:02:34 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id l19so222572715ywc.2 for ; Sun, 29 Jan 2017 21:02:34 -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=i2ImWl6D3GucSs3JG1cik/rZry3Z33EZFhuRRFobM+s=; b=LpZIwII3WKlAu+Z/xSl5P7xVGg5Q/DblLfyE7loQGXsrv3+HOwbGinV1vgDndWpw1A fFr6VO3h1y9YpXbpDf/VsGrfCgQ+BzWQ0aCoyGVuQr4xdQQkKXmJxSzwGmmYk8uMkdXO aVVhY62b6v9UxVItCVXH9jMAHQgoGCxE9vg071f9yEgIwNfAKNe5OPmxRRJy1pMhfGu7 0nsvcUsH7Lrg5pPuo4bQbzMEBAu+AgjAZJYNSd2g+6GxN8Gk94+PqnF3KFZJU0om6maT zMrhPFMGOe/pn4m/cgbFk7tB+0+Kx/OgvNkqVdgC3+PDlKpEdlgF9Y0WuOke+w7Hzsqz AF7Q== 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=i2ImWl6D3GucSs3JG1cik/rZry3Z33EZFhuRRFobM+s=; b=PcYsZueaT31qPu3rDGQjo4EYO0YoSD9u1Ea4yFiWP+a2/O/8Sh1IzdnY77cfX4nFMu VESahyGFWlljGd1Mtv24X22Zv/5d+a3EUAqkYyo5xzR3POnBYjO6SqvV5b4PfrhqCUh2 QFtbx4x5fdXOgbNCC1SbysXvdkx0s+roNl/0pLlSvQI3yFCTpAC9QQYwXzPWpI6XAZlc WW0iPKxYZA5T3XgfCL3Lfk0AK9v4Pfw520ctOg28p5DS1WDYSY8Ps9czUpczY4gA/elM cBKsvNLOn7y3zpr1HO6owmisOd6sfOkh5WVlPhEeIC3FYcXMTVCKq4cZmuw98ncxC/gz nxhg== X-Gm-Message-State: AIkVDXLvJEv+hlO8zI6JdvEDpP68HB2AdlIhWuJIq3qAc2OhA8/HbM/ZMJqOSskExjI0tOPYgkSMVCb2zRbMKw== X-Received: by 10.129.125.84 with SMTP id y81mr12716296ywc.120.1485752553710; Sun, 29 Jan 2017 21:02:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Sun, 29 Jan 2017 21:01:53 -0800 (PST) In-Reply-To: <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <7adc7503-0717-3390-ff8a-7770544c8a04@gmail.com> From: Eric Rescorla Date: Mon, 30 Jan 2017 06:01:53 +0100 Message-ID: To: Melinda Shore Content-Type: multipart/alternative; boundary=001a114928ba305f8a054748b924 Archived-At: Cc: Richard Barnes , Paul Wouters , trans@ietf.org 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: Mon, 30 Jan 2017 05:02:35 -0000 --001a114928ba305f8a054748b924 Content-Type: text/plain; charset=UTF-8 I'd be happy to have a call to discuss this and see if we can all come to some agreement. However, if we don't then this probably does need some kind of virtual interim or a meeting in Chicago. -Ekr On Sun, Jan 29, 2017 at 7:31 PM, Melinda Shore wrote: > On 1/29/17 8:08 AM, Eric Rescorla wrote: > > Either of these seem like reasonable WG decisions (though the > > charter pretty clearly contemplates (b)) but the current draft > > doesn't really do either. For that reason, I don't think it makes > > sense to just proceed as-is. Typically for last call comments > > of this magnitude the process would be to discuss them at the > > next IETF. Accordingly, rather than pubreq the draft now, > > we'd ask for agenda time to discuss in Chicago. > > Of course, but in the meantime I'm not really a fan of holding > work hostage to meeting schedules (my own deficiencies in that > area duly noted), plus -bis draft authors often don't come to > meetings, plus it looks possible that a number of regular > attendees may not be coming to Chicago because of the political > situation. We can try to have a conference call in the next > week or so, if people are up for that. > > Melinda > > > > --001a114928ba305f8a054748b924 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd be happy to have a call to discuss this and see if= we can all
come to some agreement. However, if we don't then this = probably
does need some kind of virtual interim or a meeting in C= hicago.

-Ekr


On Sun, Jan 29, 2017 at 7:31 PM, Melinda S= hore <melinda.shore@gmail.com> wrote:
On 1/29/17 8:08 AM, Eric Rescorla wrote:
> Either of these seem like reasonable WG decisions (though the
> charter pretty clearly contemplates (b)) but the current draft
> doesn't really do either. For that reason, I don't think it ma= kes
> sense to just proceed as-is. Typically for last call comments
> of this magnitude the process would be to discuss them at the
> next IETF. Accordingly, rather than pubreq the draft now,
> we'd ask for agenda time to discuss in Chicago.

Of course, but in the meantime I'm not really a fan of holding work hostage to meeting schedules (my own deficiencies in that
area duly noted), plus -bis draft authors often don't come to
meetings, plus it looks possible that a number of regular
attendees may not be coming to Chicago because of the political
situation.=C2=A0 We can try to have a conference call in the next
week or so, if people are up for that.

Melinda




--001a114928ba305f8a054748b924-- From nobody Mon Jan 30 06:45: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 21F7C1294CF for ; Mon, 30 Jan 2017 06:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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=-3.199, 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 4ZNDxNnbUuQ6 for ; Mon, 30 Jan 2017 06:45:25 -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 67FC212947D for ; Mon, 30 Jan 2017 06:45:25 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id 203so195099751ith.0 for ; Mon, 30 Jan 2017 06:45:25 -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=tcSmgPMTs7JY1R7oGyMCWtJnQb0IHUQLt/G30vM3bHw=; b=tPI0CJ103vw4ULi+DAQT9CXOUZmagHiMdrjE+3Azvbvr+X46kLMXE53K21+wIhX22q rlRpuNZ0cOTuyG1bCuT4exRISnQ+LDDQ2V/AJTOtMiK6iuEMCkQ5GLrqoZQ7S5Bfe2mg W5nrND0QrceVmhOkrmdDNoOUJYgpQSVq3lX1Bh0lrWHWf+JGp/qqPEhe9R4zS6Xpi7cf i0e3DrlfL0y1ASHHEa5jBPD1is65mL8CRqv1d5Z9/9NiZjsheRTp2wHT8eCLi4trB2HJ BDQMmX9aTKTlf3Rfr4dYA5su4CHLc/CtRih1WhGW7zLjjRw8ribR1LA167QGOTmZ3Csv GmmQ== 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=tcSmgPMTs7JY1R7oGyMCWtJnQb0IHUQLt/G30vM3bHw=; b=ZMoHqYxnUMmURyvH3tF0Jp4DTXtxllosi8n5XYwlIBxq9WuzQfX14JXW6xpCZ3qwMb Zz8tsMZkL+i+z8iGtHQIY3B5bhEZjjbCY1XZQ33/wLZWrU3HVqjs3cTpNjXcxEJDx24d 75yhnBAPjTJuwtXDP4aB82IObSlxSGbsNlOzuvdm0aWY27/V8eigxc8AVXzIId182MZF rFwIBi1UkJ5bV6l9TnABpg9U+aGnAIQf7Vr6kGKbxK0J8299Ck+Pmg0H1rA/pQDHxT/7 e8VYvSdnXo7FFZXnwgowiixFcL+xY2xC2pGlnxNoO86h/CY/Jl/4tnmamrGrqfeiDBBg tA8g== X-Gm-Message-State: AIkVDXIdFZuU9mjo/gTUA+68raE1lH6y/k1wEZp7wD58ZuDccw0L8E8SUKyEI5hM0I14oM3hrSrBI98+KU7PonTQ X-Received: by 10.36.217.150 with SMTP id p144mr16572645itg.90.1485787524603; Mon, 30 Jan 2017 06:45:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Mon, 30 Jan 2017 06:44:54 -0800 (PST) In-Reply-To: References: <20170112094214.5dbc6247f77535d91dc9fd0a@andrewayer.name> <20170112142840.8c95f645172301b0facfc29c@andrewayer.name> From: Eran Messeri Date: Mon, 30 Jan 2017 14:44:54 +0000 Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=001a1145e7169e018e054750dd90 Archived-At: Cc: "trans@ietf.org" , Andrew Ayer Subject: Re: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof 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: Mon, 30 Jan 2017 14:45:27 -0000 --001a1145e7169e018e054750dd90 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 27, 2017 at 12:37 AM, Ryan Sleevi wrote: > > > On Wed, Jan 18, 2017 at 2:56 AM, Eran Messeri wrote: >> >> - Navigating to hosts by IP which have SSL certificates logged in CT logs >> would now be disclosed to the UA's resolver. A mitigation could be not >> looking up inclusion proofs for these if data shows this is a common use >> case. >> > > Meaning if it was an uncommon use case, the privacy leak is deemed > acceptable? > Not sure, TBH. The way I see it, extra code could be added to avoid performing inclusion proofs in case the user has browsed directly to an IP address - this complexity would be weighted against the commonality of this use case (it could be that UAs will not deem this privacy leak acceptable at all). > > >> - Resource Hints: Not sure I see how that's related to this discussion. >> Ryan, can you elaborate? >> > > It was a terminology issue in the section "Disclosure of visited hosts vs > resolved hosts" - I was highlighting that the term "pre-fetch" in your > analysis, in particular, " This is less of an issue if pre-fetches actually > fetch content, rather than just looking up IP addresses for links/resources > the user is likely to consume." > > As defined in Resource Hints (e.g. what UAs are doing), there's a > distinction between "DNS prefetch" (which appears to be how you're using > the term "prefetch"), "preconnect", and "prefetch" (which, in Resource > Hints usage, implies an actual fetch of the resource). So what you saw as > an ambiguous term ("prefetch" in your usage) is captured in Resource Hints > as two distinct terms ("DNS prefetch" vs "prefetch") > Acknowledged, updated the document to use this terminology. --001a1145e7169e018e054750dd90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 27, 2017 at 12:37 AM, Ryan Sleevi <ryan-ietf@sleevi.com= > wrote:
<= br>

On Wed, Jan 18, 2017 at 2:56 AM, Eran Messeri <eranm@google.com><= /span> wrote:
- Navigating to hosts by IP which have SSL certificates logged in= CT logs would now be disclosed to the UA's resolver. A mitigation coul= d be not looking up inclusion proofs for these if data shows this is a comm= on use case.

Meaning if = it was an uncommon use case, the privacy leak is deemed acceptable?
Not sure, TBH. The way I see it, extra co= de could be added to avoid performing inclusion proofs in case the user has= browsed directly to an IP address - this complexity would be weighted agai= nst the commonality of this use case (it could be that UAs will not deem th= is privacy leak acceptable at all).=C2=A0
<= span class=3D"">
=C2=A0
- Resource Hints: Not sure I see how that'= ;s related to this discussion. Ryan, can you elaborate?

It was a terminology issue in the section &= quot;Disclosure of visited hosts vs resolved hosts" - I was highlighti= ng that the term "pre-fetch" in your analysis, in particular, &qu= ot; This is less of an issue if pre-fetches actually fetch content, rather = than just looking up IP addresses for links/resources the user is likely to= consume."

As defined in Resource Hints (e.g.= what UAs are doing), there's a distinction between "DNS prefetch&= quot; (which appears to be how you're using the term "prefetch&quo= t;), "preconnect", and "prefetch" (which, in Resource H= ints usage, implies an actual fetch of the resource). So what you saw as an= ambiguous term ("prefetch" in your usage) is captured in Resourc= e Hints as two distinct terms ("DNS prefetch" vs "prefetch&q= uot;)
Acknowledged, updated the document to use this terminolo= gy.
--001a1145e7169e018e054750dd90-- From nobody Mon Jan 30 09:04:40 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 91F641299D4 for ; Mon, 30 Jan 2017 09:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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=-3.199, 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 AYeLH_Hi6Osc for ; Mon, 30 Jan 2017 09:04:36 -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 664981299D3 for ; Mon, 30 Jan 2017 09:04:36 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c7so105699387itd.1 for ; Mon, 30 Jan 2017 09:04:36 -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=mQt8SfKCJatCIXiY7tf3swqAPuZuYcLYHxFAfB9RhCw=; b=eOpW5YU9rwLHKsTx8MXXO6j4X7xwl58hBKKdqBwaeXTpwLMOxZWmL0GAgpZZWevidI 6rBgJNZehcGsp7qU7rxADDOn838P+YuB/FDzNAS+widRuQEDEu/H4V1zs9j1gjwskhKV Alo717oBPRt2QZILtcLt1iNKnVYkPSulSNCUJPxg2sOzEQTiXmJTuOudbiqVMxiCkmGj A1EWD/1aUaFUFRCNeQcuafrOOFXTWqEb0pUWCAPEJhg0gryn3OArZyCcWbEOjD5KQMOm Eq7WdMxC9dd9hOZGMhuqnoJt/KcJWWFKAsrYIioEfed/ZVt1HG5LidIjgt43XWMO+fSM qyDA== 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=mQt8SfKCJatCIXiY7tf3swqAPuZuYcLYHxFAfB9RhCw=; b=g29kmoSMsFjIvf1nRkEIfr6O/Nr5DX475aEFJGZFPdIcPZY2Nv7TSNkNUUDU0Rb+YN LkpROa4pgwikuqwRFrXksR3aOgX3ltwG+LPUfFVGOI+aPGe6c9t+XHT/canZlerm2Wb5 ZGv3nb4eUHl1dRsBW+VGkb7fyyqwRDy0lWHZDblRgCG8+V/xo9WZ/Km4ezGJk+j3m1ww OENQrYj0l+Y1L4VjIdtDcubU9B+7qnk37Ac/MI0uBADteSCuYJ7JOE/XiXjZIBIFfURq iS7vsov+uZV6wvQZs4yEQxNfGe9PiUsaStRbf30uXUeKON2NHoXZEgsdsd7y8V8+uXYs Lyvw== X-Gm-Message-State: AIkVDXIoB4RiOBu8lqX9LjLfO7inqn8ViRYWcUpt7VDRBenkj52bMCTeawdRKNuWsS5zvOqfrFaBA6Ja8aFbc1Jp X-Received: by 10.36.93.213 with SMTP id w204mr17848491ita.60.1485795875248; Mon, 30 Jan 2017 09:04:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.23 with HTTP; Mon, 30 Jan 2017 09:04:04 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Mon, 30 Jan 2017 17:04:04 +0000 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113a62965aa9c5054752cf7b Archived-At: Subject: Re: [Trans] Working group last call, draft-ietf-trans-gossip 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: Mon, 30 Jan 2017 17:04:38 -0000 --001a113a62965aa9c5054752cf7b Content-Type: text/plain; charset=UTF-8 I'm also in favour of progressing towards publication as an experimental RFC. In particular, the SCT Feedback mechanism and Trusted Auditor Relationship seem like useful protocol descriptions that be useful in the short term. The document also does a good job of capturing many of the privacy/security aspects of different gossip mechanisms (and the implications on the CT system as a whole), another good reason IMHO to progress towards publication. On Wed, Jan 25, 2017 at 7:40 AM, Bill Frantz wrote: > Given there are no implementations, Experimental seems right to me, and a > good way to capture the progress so far. > > Cheers - Bill > > On 1/24/17 at 6:47 PM, rlb@ipv.sx (Richard Barnes) wrote: > > Without commenting on the substance of the document, process-wise I would >> be OK with this as Experimental, if the WG thinks it's worth capturing >> state. >> >> On Tue, Jan 24, 2017 at 7:05 PM, Salz, Rich wrote: >> >> Hatless, I would tend to argue in favor of continuing to progress this >>>> >>> towards >>> >>>> publication as an experimental standard and then revving it in the >>>> future >>>> based on implementation experience. >>>> >>> >>> Works for me! >>> >> > ----------------------------------------------------------------------- > Bill Frantz | Concurrency is hard. 12 out | Periwinkle > (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave > www.pwpconsult.com | - Jeff Frantz | Los Gatos, CA 95032 > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113a62965aa9c5054752cf7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also in favour of progressing towards publication = as an experimental RFC.
In particular, the SCT Feedback mechanism and T= rusted Auditor Relationship seem like useful protocol descriptions that be = useful in the short term.

The document also does a= good job of capturing many of the privacy/security aspects of different go= ssip mechanisms (and the implications on the CT system as a whole), another= good reason IMHO to progress towards publication.

On Wed, Jan 25, 2017 at 7:40 A= M, Bill Frantz <frantz@pwpconsult.com> wrote:
Given there are no implementations, Experimental se= ems right to me, and a good way to capture the progress so far.

Cheers - Bill

On 1/24/17 at 6:47 PM, rlb@ipv.sx (Richard Barnes) wrote:

Without commenting on the substance of the document, process-wise I would be OK with this as Experimental, if the WG thinks it's worth capturing<= br> state.

On Tue, Jan 24, 2017 at 7:05 PM, Salz, Rich <rsalz@akamai.com> wrote:

Hatless, I would tend to argue in favor of continuing to progress this
towards
publication as an experimental standard and then revving it in the future based on implementation experience.

Works for me!

 -----------------------------------------------------------------= ------
Bill Frantz=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Concurrency is hard. 12 out=C2=A0 = | Periwinkle
= (408)356-8506=C2=A0 =C2=A0 =C2=A0 | 10 programmers get it wrong. | 1634= 5 Englewood Ave
= www.pwpconsult.com |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 - Jeff Frantz | Los Gatos, CA 95032


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

--001a113a62965aa9c5054752cf7b-- From nobody Mon Jan 30 10:13:43 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 A5DCD129A7D for ; Mon, 30 Jan 2017 10:13:42 -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 EScEANkB_xS1 for ; Mon, 30 Jan 2017 10:13:42 -0800 (PST) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83C9129A75 for ; Mon, 30 Jan 2017 10:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1485800020; bh=ORVP9NyGn3S2Tb4dVVWg3wigiV2cs9ZKjEhMY5/RHSQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DVqntn65lDaJntbV8GsdNPViiZ406THCWmcHPJjx+k6NAT86swlQxrf+/V01eSTBK zYBce0RFI1yD5NKGP1ZMCicw5l+ZQkuPjEru2Ayc+JFbbzggXZM7MjZWSr0vflhpHe 9GQwitw10MfMCECF9KqYcMr4gi1TL+pZ2J4Q58F24LxWX5/XSKuy7+Dgy64u7Ap02/ 4+6g1PSPrex3k2rfrpmfW5Sp4c1GVmrerSXGxZ0vDebImKD607LbFVobVCqALqM192 +WkhMDzaf0kJvxxtn3ZyO0/xq7C6oV8qEgP6vHThxdiZ3ICcyoRNB7c+xQND1768v/ oMi+mWsmBnIsA== Date: Mon, 30 Jan 2017 10:13:40 -0800 From: Andrew Ayer To: Eran Messeri Message-Id: <20170130101340.f772ddf7fdaa0c817c38074c@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] Working group last call, draft-ietf-trans-gossip 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: Mon, 30 Jan 2017 18:13:42 -0000 On Mon, 30 Jan 2017 17:04:04 +0000 Eran Messeri wrote: > I'm also in favour of progressing towards publication as an > experimental RFC. > In particular, the SCT Feedback mechanism and Trusted Auditor > Relationship seem like useful protocol descriptions that be useful in > the short term. I'll add that I am adding support for STH Pollination to Cert Spotter, and hope to create an ecosystem of monitors sharing STHs, so +1 for publication. Regards, Andrew From nobody Tue Jan 31 03:51:59 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 8EE4112944F for ; Tue, 31 Jan 2017 03:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 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_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 gaGdUqcYEfMO for ; Tue, 31 Jan 2017 03:51:57 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 0B19612943A for ; Tue, 31 Jan 2017 03:51:57 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id y9so272333434uae.2 for ; Tue, 31 Jan 2017 03:51:56 -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=y13jM4mLr57E/oiwcVpIFzXHSw6Slw5SWAjUL/GRK8c=; b=dfJOsm0XIeaRjlpK/hNvLCqNZv6DKNVWgXEQDvS/T3/sloh/nPOoUo/VxJlyeabIi+ EKPy2Pf6RmtGvMjLjLVHj/cV45sXo7EJ0mV7Bnts6YDRkS8BgxIw84oYsDo7TGfGck2U 3r13Qv9oHoipYswgqb4Tlyp9qMC3KSiSr7rQRnN9McIvNVtuMUs4EBkVCObeCGpJIKF3 L/bj1L24+KnZeFcUuY7XlosHr68zhEEXbiynACc8OEE8apmVP3qGmhchZ0Okd2VDYhhe hXRq2FO+IX1oRyNb0HoBWd3MpHrL/p5oATT5ltBCT2Su9HtdcshXAf0BtU+qClhNs67x jS0w== 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=y13jM4mLr57E/oiwcVpIFzXHSw6Slw5SWAjUL/GRK8c=; b=DLYKxptE6v4eKSDUivgu1WZlyvP2o8TVDgEdkC6cMMKW8ENHAN1fEq07FtDptnF6ZN 8LdsuNXbpFevCpLmGld9ilTsHF3nfiuvkfjwPZ9/Yk7gJQ3Qya7sCrBCBO/4ZWsKG//m knlwOJBVer57L1SHr6/XVpGqYj8/EJQfiaYCHGFuw70V47Gik+z+iGVyPjDXdSP4QDgq cm1T5loatyy68DLQ4vFzbE44rgrLPCeI5TGG50atklK5KeupiMcBuR52T0EEFWw5BpZB RhV2ErJgJbtB5Brmkg7jAqnwApD7D+o8kc4/hXkPUtzTJqozgTaIdBDK2PewTCSH71qE CAtQ== X-Gm-Message-State: AIkVDXIbnzCeoRDpkhqL/z3471Cgnak+8N6AK104nxL5nbr0kBS0ZsQixWAmHVpSHnkG2BKZkdH4T0f6wKgVbfEG X-Received: by 10.176.65.198 with SMTP id 64mr13683620uap.40.1485863515850; Tue, 31 Jan 2017 03:51:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.130.199 with HTTP; Tue, 31 Jan 2017 03:51:55 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Ben Laurie Date: Tue, 31 Jan 2017 11:51:55 +0000 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , 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: Tue, 31 Jan 2017 11:51:58 -0000 On 30 January 2017 at 04:39, Eric Rescorla wrote: > > > On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie wrote: >> >> On 29 January 2017 at 17:08, Eric Rescorla wrote: >> > Hi Melinda, >> > >> > Unfortunately, I don't believe that the concerns that we are proposing >> > can in fact be plausibly addressed by post-hoc mechanisms on top of >> > the 6962-bis structure. To be precise, one might build either: >> > >> > (a) A system which is not publicly verifiable in which case EEs would >> > only need to handle and provide SCTs and one can and should >> > dispense with much of the Merkle hash tree infrastructure. >> > >> > (b) A system in which is publicly verifiable in which case the >> > current Merkle hash tree infrastructure seems inadequate and >> > would need to be revised, not just built on top of. >> > >> > Either of these seem like reasonable WG decisions (though the >> > charter pretty clearly contemplates (b)) but the current draft >> > doesn't really do either. For that reason, I don't think it makes >> > sense to just proceed as-is. Typically for last call comments >> > of this magnitude the process would be to discuss them at the >> > next IETF. Accordingly, rather than pubreq the draft now, >> > we'd ask for agenda time to discuss in Chicago. >> >> I don't think you're right. In practice, there are mechanisms that >> address your concerns, I believe. >> >> Firstly, its important to understand that the goal of CT is to reveal >> misissuance, not to prevent it, nor to deal with it when it occurs. > > > That's a reasonable objective, but as far as I can tell it requires that > the client be able to ensure that it is seeing the same thing that the > rest of the world sees (i.e., "public" or "end-to-end" verifiability). > The concerns that we have raised go to the practicality of achieving > that. Given that CT has revealed a good deal of misissuance it is clear that it does not _require_ that, but it is, of course, a desirable property. In other words: don't let the perfect be the enemy of the good. >> So, inclusion proofs. >> >> One way to deal with this would be to for browsers to report to >> servers the previous cert seen for that server. The server can then >> fetch the inclusion proof. >> >> If the client ever talks to the correct server having talked to an >> evil one, the evil one will be discovered. If the client doesn't, then >> the client is effectively in a bubble and beyond help. > > > I don't believe this is correct, at least for common clients, because > the attacker can selectively interfere with just your connections to > the site of interest; this would be detectable with at least some designs. > > Consider a trivial, inefficient, CT-like system in which the browser > manufacturer scrapes the entire CT log and sends it to every browser client. > As long as the manufacturer doesn't cheat (in which case you truly > are beyond help, but for non-CT reasons), then a client can easily > assess log-inclusion for any server as long as the connection back > to the vendor is live. And if that connection fails, then the browser > in fact knows it is under attack, which is different from the silent > attack we have here. > > So, ultimately, I don't think this is that useful. Really? You think the common case is where an attacker controls connections to a single site? > > >> Another would be to require servers to serve inclusion proofs >> alongside the cert, once the SCT was past the MMD. This could be done >> either with OCSP stapling or with the TLS extension. > > > I agree that having the server serve an inclusion proof is the right design > (and in fact it's what Richard and I contemplated) but this seems > problematic > for two reasons: > > 1. It's effectively retroactive consistency and so it's a weaker guarantee > than prevention of compromise. I realize that that's not your objective, but > it seems like it's a good one. Also, it means that if a client just goes to > a site once, then compromise may never even be detected. I agree it is a good objective, but not one I know how to achieve practically. If you have a plan, I'm all ears. > > 2. In order to operate efficiently, it requires that the client be able to > verify consistency for the specific STH which this is an inclusion proof > for. > It's possible that this can be made efficient, especially if you minimize > the number of STHs to which inclusion proofs are actually issued, but > all that needs to actually be specified in some way. Eh? It is specified in 6962-bis. > > >> Next, STH consistency. >> >> My preferred plan for this is to add a new leaf type, STH, and require >> (by policy) all logs to accept STHs from all other logs. Then you add >> a call to logs that lists the positions of those STHs, so they can be >> efficiently retrieved. Or maybe just retrieves the latest seen from >> each log. If inconsistent STHs are ever logged, monitors can detect >> this. In order to fork a log, you would then have to fork all logs. Of >> course, monitors and other interested parties could also gossip STHs >> for added value. > > > That might work, but I think again it requires some notion that there are > a limited number of STHs which are actually published in practice and > which there are inclusion proofs to. And then this gets into the efficiency > analysis that Richard posted in his initial comments. There are a limited number of STHs, again, required by 6962-bis. I will have to look again at the efficiency analysis, but I am sceptical having done the same thing myself when we started the project! > > >> All of these can be done on top of 6962-bis. > > > Perhaps. However, given that these proposals are pretty essential to > determining whether the public verifiability part of CT works, it would > probably be good to have a fully fleshed out design to analyze prior > to standardizing that piece. > > -Ekr > > >> >> >> > >> > -Ekr >> > >> > >> > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore >> > wrote: >> >> >> >> Hi, all: >> >> >> >> We've been looking at the discussion and trying to figure >> >> out next steps. Because we believe that the mechanisms >> >> Richard's asking for can be built on top of what's specified >> >> in 6962-bis, we've decided that we're going to >> >> continue progressing the document towards publication, >> >> and look to Richard and EKR to produce a draft specifying >> >> a mechanism that meets their requirements with the intent >> >> of adopting it as a working group deliverable. >> >> >> >> Thanks, >> >> >> >> Melinda >> >> >> > >> > >> > _______________________________________________ >> > Trans mailing list >> > Trans@ietf.org >> > https://www.ietf.org/mailman/listinfo/trans >> > > > From nobody Tue Jan 31 05:11:58 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 1C299129EA7 for ; Tue, 31 Jan 2017 05:11:58 -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 EK6GyR1ZRHy7 for ; Tue, 31 Jan 2017 05:11:55 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 A3F04129EA4 for ; Tue, 31 Jan 2017 05:11:55 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id 123so120395758ybe.3 for ; Tue, 31 Jan 2017 05:11:55 -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=XMTMTx5RbLMDm+y+B3q+WHMKfyL9bKJ97SKAiaaU7ns=; b=RemokGrdmqY/6CwG7SDBnvjTkC2FfY3jYY8o2I4nTU1/QiezVU3wTxqAMHcn2/GUux EXA5Cztgg3kIMXjxSiYIF0y3Hs6d9kAdoiyM2xTbt3f9HPBgkl9wmJHQoDNPOWABh7yX 6pbuX8BJ+eV4qsr5i30SsjKC9H/m6i1zfwwMtgmL4wxU4rLSwDMd5oTWnlt51w+vxtPN RoE84Hw0CFGtdOmXf4uTQaXBIMutZ9ajwQI93AP01MOrD1o5lrubcgJXGtoXNT4ct5be NGCcD9GCgweKmyUa0I+w0ccFioSybxovjbntfkJypzS1xwU+eQDXAG4wJnGIlghcz2Et yayQ== 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=XMTMTx5RbLMDm+y+B3q+WHMKfyL9bKJ97SKAiaaU7ns=; b=bV3KOzUAsnFu4PgdsSEfxdhacrWcfde4f3BxpbfYIXF23ApIwnZ52dbJJZpgRKFIgK i5IBOskDIEIDbAwuhzRt5Llzxao1MFeWZuL5gu23Tacc01S/6QFZtG0T6wgSJOalm5sS cPpq6zRHpE1TGfcqemHYdTh3PpvTmEaj73FSsZVwc6YjhlE71KMvpgTGGHYggEK40IkQ bN+qFrSOuCFt1vFAaiuc/Zg6hnqorF2c1mKQxGNlu1GshX9euljF2UMZbh70U8U/0rGC jySxVDiMOaSFPoMGkn1wUwlKkabSgAdKqVbLFAWOSOMEXW/IrzCWxNKLIjVF2za8XAo7 wVsA== X-Gm-Message-State: AIkVDXILlRSmogkIqyn8GMjzfQQ2ELz8BX/J4eHinRSdqd9H+d0lds+5u+cQPb/80i6uHCACRB7lf63p+8Wxsg== X-Received: by 10.129.108.131 with SMTP id h125mr17515561ywc.71.1485868314933; Tue, 31 Jan 2017 05:11:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 31 Jan 2017 05:11:14 -0800 (PST) In-Reply-To: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Eric Rescorla Date: Tue, 31 Jan 2017 14:11:14 +0100 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a114dcf7818742d054763ad15 Archived-At: Cc: Richard Barnes , "trans@ietf.org" , Melinda Shore , 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: Tue, 31 Jan 2017 13:11:58 -0000 --001a114dcf7818742d054763ad15 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 31, 2017 at 12:51 PM, Ben Laurie wrote: > On 30 January 2017 at 04:39, Eric Rescorla wrote: > > > > > > On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie wrote: > >> > >> On 29 January 2017 at 17:08, Eric Rescorla wrote: > >> > Hi Melinda, > >> > > >> > Unfortunately, I don't believe that the concerns that we are proposing > >> > can in fact be plausibly addressed by post-hoc mechanisms on top of > >> > the 6962-bis structure. To be precise, one might build either: > >> > > >> > (a) A system which is not publicly verifiable in which case EEs would > >> > only need to handle and provide SCTs and one can and should > >> > dispense with much of the Merkle hash tree infrastructure. > >> > > >> > (b) A system in which is publicly verifiable in which case the > >> > current Merkle hash tree infrastructure seems inadequate and > >> > would need to be revised, not just built on top of. > >> > > >> > Either of these seem like reasonable WG decisions (though the > >> > charter pretty clearly contemplates (b)) but the current draft > >> > doesn't really do either. For that reason, I don't think it makes > >> > sense to just proceed as-is. Typically for last call comments > >> > of this magnitude the process would be to discuss them at the > >> > next IETF. Accordingly, rather than pubreq the draft now, > >> > we'd ask for agenda time to discuss in Chicago. > >> > >> I don't think you're right. In practice, there are mechanisms that > >> address your concerns, I believe. > >> > >> Firstly, its important to understand that the goal of CT is to reveal > >> misissuance, not to prevent it, nor to deal with it when it occurs. > > > > > > That's a reasonable objective, but as far as I can tell it requires that > > the client be able to ensure that it is seeing the same thing that the > > rest of the world sees (i.e., "public" or "end-to-end" verifiability). > > The concerns that we have raised go to the practicality of achieving > > that. > > Given that CT has revealed a good deal of misissuance it is clear that > it does not _require_ that, but it is, of course, a desirable > property. > > In other words: don't let the perfect be the enemy of the good. > Sorry, I should have been clearer. As I said in my earlier mail, I think there are several threat models: - Security if you trust the CAs to accurately log their certs. - Security if you trust the logs to accurately log certs. - Security even if you don't trust the logs. ISTM that the misissuance that CT has revealed is under the first threat model, namely that the CAs are misbehaving but correctly logging. However this doesn't require any of the Merkle tree machinery specified here; indeed it doesn't even require the browser to check SCTs, because these events happened when people don't check them. > > >> Next, STH consistency. > >> > >> My preferred plan for this is to add a new leaf type, STH, and require > >> (by policy) all logs to accept STHs from all other logs. Then you add > >> a call to logs that lists the positions of those STHs, so they can be > >> efficiently retrieved. Or maybe just retrieves the latest seen from > >> each log. If inconsistent STHs are ever logged, monitors can detect > >> this. In order to fork a log, you would then have to fork all logs. Of > >> course, monitors and other interested parties could also gossip STHs > >> for added value. > > > > > > That might work, but I think again it requires some notion that there are > > a limited number of STHs which are actually published in practice and > > which there are inclusion proofs to. And then this gets into the > efficiency > > analysis that Richard posted in his initial comments. > > There are a limited number of STHs, again, required by 6962-bis. > > I will have to look again at the efficiency analysis, but I am > sceptical having done the same thing myself when we started the > project! > It would certainly be very helpful to get your thoughts on why you think Richard's analysis is wrong. -Ekr > > > > > > >> All of these can be done on top of 6962-bis. > > > > > > Perhaps. However, given that these proposals are pretty essential to > > determining whether the public verifiability part of CT works, it would > > probably be good to have a fully fleshed out design to analyze prior > > to standardizing that piece. > > > > -Ekr > > > > > >> > >> > >> > > >> > -Ekr > >> > > >> > > >> > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore < > melinda.shore@gmail.com> > >> > wrote: > >> >> > >> >> Hi, all: > >> >> > >> >> We've been looking at the discussion and trying to figure > >> >> out next steps. Because we believe that the mechanisms > >> >> Richard's asking for can be built on top of what's specified > >> >> in 6962-bis, we've decided that we're going to > >> >> continue progressing the document towards publication, > >> >> and look to Richard and EKR to produce a draft specifying > >> >> a mechanism that meets their requirements with the intent > >> >> of adopting it as a working group deliverable. > >> >> > >> >> Thanks, > >> >> > >> >> Melinda > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Trans mailing list > >> > Trans@ietf.org > >> > https://www.ietf.org/mailman/listinfo/trans > >> > > > > > > --001a114dcf7818742d054763ad15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 12:51 PM, Ben Laurie <benl@google.com> wrote:
On 30 January 2017 at 04:39, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Sun, Jan 29, 2017 at 6:44 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 29 January 2017 at 17:08, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Hi Melinda,
>> >
>> > Unfortunately, I don't believe that the concerns that we = are proposing
>> > can in fact be plausibly addressed by post-hoc mechanisms on = top of
>> > the 6962-bis structure. To be precise, one might build either= :
>> >
>> > (a) A system which is not publicly verifiable in which case E= Es would
>> >=C2=A0 =C2=A0 =C2=A0only need to handle and provide SCTs and o= ne can and should
>> >=C2=A0 =C2=A0 =C2=A0dispense with much of the Merkle hash tree= infrastructure.
>> >
>> > (b) A system in which is publicly verifiable in which case th= e
>> >=C2=A0 =C2=A0 =C2=A0current Merkle hash tree infrastructure se= ems inadequate and
>> >=C2=A0 =C2=A0 =C2=A0would need to be revised, not just built o= n top of.
>> >
>> > Either of these seem like reasonable WG decisions (though the=
>> > charter pretty clearly contemplates (b)) but the current draf= t
>> > doesn't really do either. For that reason, I don't th= ink it makes
>> > sense to just proceed as-is. Typically for last call comments=
>> > of this magnitude the process would be to discuss them at the=
>> > next IETF. Accordingly, rather than pubreq the draft now,
>> > we'd ask for agenda time to discuss in Chicago.
>>
>> I don't think you're right. In practice, there are mechani= sms that
>> address your concerns, I believe.
>>
>> Firstly, its important to understand that the goal of CT is to rev= eal
>> misissuance, not to prevent it, nor to deal with it when it occurs= .
>
>
> That's a reasonable objective, but as far as I can tell it require= s that
> the client be able to ensure that it is seeing the same thing that the=
> rest of the world sees (i.e., "public" or "end-to-end&q= uot; verifiability).
> The concerns that we have raised go to the practicality of achieving > that.

Given that CT has revealed a good deal of misissuance it is cle= ar that
it does not _require_ that, but it is, of course, a desirable
property.

In other words: don't let the perfect be the enemy of the good.

Sorry, I should have been clearer.
<= br>
As I said in my earlier mail, I think there are several threa= t models:

- Security if you trust the CAs to accur= ately log their certs.
- Security if you trust the logs to accura= tely log certs.
- Security even if you don't trust the logs.<= /div>

ISTM that the misissuance that CT has revealed is = under the first threat
model, namely that the CAs are misbehaving= but correctly logging. However
this doesn't require any of t= he Merkle tree machinery specified here; indeed
it doesn't ev= en require the browser to check SCTs, because these events
happen= ed when people don't check them.


>
>> Next, STH consistency.
>>
>> My preferred plan for this is to add a new leaf type, STH, and req= uire
>> (by policy) all logs to accept STHs from all other logs. Then you = add
>> a call to logs that lists the positions of those STHs, so they can= be
>> efficiently retrieved. Or maybe just retrieves the latest seen fro= m
>> each log. If inconsistent STHs are ever logged, monitors can detec= t
>> this. In order to fork a log, you would then have to fork all logs= . Of
>> course, monitors and other interested parties could also gossip ST= Hs
>> for added value.
>
>
> That might work, but I think again it requires some notion that there = are
> a limited number of STHs which are actually published in practice and<= br> > which there are inclusion proofs to. And then this gets into the effic= iency
> analysis that Richard posted in his initial comments.

There are a limited number of STHs, again, required by 6962-bis.

I will have to look again at the efficiency analysis, but I am
sceptical having done the same thing myself when we started the
project!

It would certainly be = very helpful to get your thoughts on why you think
Richard's = analysis is wrong.

-Ekr
=C2=A0
=C2=A0
>
>
>> All of these can be done on top of 6962-bis.
>
>
> Perhaps. However, given that these proposals are pretty essential to > determining whether the public verifiability part of CT works, it woul= d
> probably be good to have a fully fleshed out design to analyze prior > to standardizing that piece.
>
> -Ekr
>
>
>>
>>
>> >
>> > -Ekr
>> >
>> >
>> > On Wed, Jan 25, 2017 at 8:03 PM, Melinda Shore <melinda.shore@gmail.com>
>> > wrote:
>> >>
>> >> Hi, all:
>> >>
>> >> We've been looking at the discussion and trying to fi= gure
>> >> out next steps.=C2=A0 Because we believe that the mechani= sms
>> >> Richard's asking for can be built on top of what'= s specified
>> >> in 6962-bis, we've decided that we're going to >> >> continue progressing the document towards publication, >> >> and look to Richard and EKR to produce a draft specifying=
>> >> a mechanism that meets their requirements with the intent=
>> >> of adopting it as a working group deliverable.
>> >>
>> >> Thanks,
>> >>
>> >> Melinda
>> >>
>> >
>> >
>> > _______________________________________________
>> > Trans mailing list
>> > Trans@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/trans
>> >
>
>

--001a114dcf7818742d054763ad15-- From nobody Tue Jan 31 08:10: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 50AE0129482 for ; Tue, 31 Jan 2017 08:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-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 u7iV5BTfFeh1 for ; Tue, 31 Jan 2017 08:10:26 -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 A1B8E129469 for ; Tue, 31 Jan 2017 08:10:26 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F176016CA1B; Tue, 31 Jan 2017 16:10:25 +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 D0C0C16CA12; Tue, 31 Jan 2017 16:10:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485879025; bh=uZhlXA+NWOdjvrhi8KstDg0hp36f0MWlbLXR146Egb8=; l=5688; h=From:To:CC:Date:References:In-Reply-To:From; b=XNwRw3MCYkcgeWbWmB3fyNgBdQrbBv2jE035CM+9SwWRCJ26To6WvxhGvvnUki7u+ Ad5z79g2eVmOgrNORKLudwd9k+uYJQ9r8YwHq+H3Y1HH9ZtVD4vkuCcdLcxxb9mJ3H be2RYLgLQm9LjgP2S4vsSbHkRfc5a3fa/QKw1lbc= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 9B78B98E7E; Tue, 31 Jan 2017 16:10:25 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Jan 2017 11:10:24 -0500 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; Tue, 31 Jan 2017 11:10:24 -0500 From: "Salz, Rich" To: Eric Rescorla , Ben Laurie Thread-Topic: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR Thread-Index: AQHSelNT1wQuPWhT70W7e6NPtKqSzKFQDd8AgAC3GICAAgsKgIAAFikA///dMUA= Date: Tue, 31 Jan 2017 16:10:24 +0000 Message-ID: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@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.35.122] Content-Type: multipart/alternative; boundary="_000_b3ed4ab44d8547eb9922f93c65c1292busma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , Paul Wouters , Melinda Shore , "trans@ietf.org" 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: Tue, 31 Jan 2017 16:10:28 -0000 --_000_b3ed4ab44d8547eb9922f93c65c1292busma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgd2UgaGFkIGEgdGhyZWF0IG1vZGVsIGRvY3VtZW50LCBpdCB3b3VsZCBiZSBlYXNpZXIgdG8g ZGV0ZXJtaW5lIHdoaWNoIGtpbmRzIG9mIHRocmVhdHMgYW5kIHVzZXMgYXJlIGluLXNjb3BlIGFu ZCBvdXQgb2Ygc2NvcGUuDQoNCk9oIHdhaXQsIOKApiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFucy10aHJlYXQtYW5hbHlzaXMvDQoNCkkgYWdhaW4gYXNr IHRoZSBDaGFpcnMgdG8gZGV0ZXJtaW5lIHRoZSBjb25zZW5zdXMgYW5kIGFkdmFuY2UgdGhpcyBk b2N1bWVudC4NCg0KLS0NClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1l bWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBS aWNoU2Fseg0K --_000_b3ed4ab44d8547eb9922f93c65c1292busma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgd2UgaGFkIGEgdGhyZWF0IG1vZGVsIGRv Y3VtZW50LCBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gZGV0ZXJtaW5lIHdoaWNoIGtpbmRzIG9mIHRo cmVhdHMgYW5kIHVzZXMgYXJlIGluLXNjb3BlIGFuZCBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P aCB3YWl0LCDigKYmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtdHJhbnMtdGhyZWF0LWFuYWx5c2lzLyI+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFucy10aHJlYXQtYW5hbHlzaXMvPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhZ2FpbiBhc2sgdGhlIENoYWlycyB0byBkZXRlcm1pbmUgdGhlIGNvbnNlbnN1cyBh bmQgYWR2YW5jZSB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0mbmJzcDsNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5TZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0 ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_b3ed4ab44d8547eb9922f93c65c1292busma1exdag1mb1msgcorpak_-- From nobody Tue Jan 31 10:41:08 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 21EC7129526 for ; Tue, 31 Jan 2017 10:41:07 -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 hMnzf-UNkDuB for ; Tue, 31 Jan 2017 10:41:05 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 CA7A9129546 for ; Tue, 31 Jan 2017 10:41:05 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id f144so29192158pfa.2 for ; Tue, 31 Jan 2017 10:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=M2CreMWhQDkOteJZ8eaQfnQdKwf8BX14ZLukuHWX7Wk=; b=PQuO+TeUuOOiSpU7E47IsKQKtgthO4cTD6rF5s1KEEJynrkm7hyCdvsxK1X8svO+ml ccBDPuTKwYw9TcAqr7llYGdkDzssnJQT5y7qMvK9XAZsjXPFJq6a7Na4p1BxDf2Lk3Cb pM8rDVrZazb7vCpgJFAbOSxemOyQryoZn8QPAGtRWSiFbzDa0OfUIephkHHQBMGHSs60 HsK//B7oAYbev5EAb7WMzlYFeo65XwfgzvmE9mnhwqjpMRWR6FtteYm+s3Zv1HD8INnq 3d02E5UcmMF9himYos5gQ6RXLQZiLtBSZBsGjoryE8v7fhNxyE7nPLlbumRY3OG8n+di 1HQA== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=M2CreMWhQDkOteJZ8eaQfnQdKwf8BX14ZLukuHWX7Wk=; b=dh4q6VeLbish/xWu/8ZeUzs4ClmUFMVfna0hT067JhoAywp2Et4lvkc4stK4oYyG/5 pxV/xlqvjJM1rGnUAlQdQfq/JJrnnIXswb4+7fArd7zNnqai8xcLlMtON2H1n3PIgKKa rXffg361fByLfyga2fNavqGVJcLzZbdvhpj4Gb1f+GDGJP0aZzAbPEJotwcrK/mDMnIZ jivKWQjAVhdasVbPyi0uOz2ThkwsDdwQp6M62YfeBR00jQOEFaf3WuckD8ePnqFo1Sgl dlfuO5+GNbEKltxxd9MnP+WrXpYvXXS8+0iVF+6q0yBAjv/SWQx90kNF3o5mqSUNHvHJ Ot4g== X-Gm-Message-State: AIkVDXLxF2tGImM2cbtDzmSvOvasLAaov+bblWOmNZYXbx84O7d4/LX2PEk2+EtaAWtNAQ== X-Received: by 10.84.142.1 with SMTP id 1mr41858828plw.127.1485888065089; Tue, 31 Jan 2017 10:41:05 -0800 (PST) Received: from Melindas-MacBook-Pro.local (74-124-96-230-radius.dynamic.acsalaska.net. [74.124.96.230]) by smtp.gmail.com with ESMTPSA id m12sm43340184pgc.46.2017.01.31.10.41.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 10:41:04 -0800 (PST) To: "Salz, Rich" , Eric Rescorla , Ben Laurie References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> From: Melinda Shore Message-ID: <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> Date: Tue, 31 Jan 2017 09:41:01 -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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gbwuL1TfqF9qpPFllX6AAorGMI37M6bPr" Archived-At: Cc: Richard Barnes , Paul Wouters , "trans@ietf.org" 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: Tue, 31 Jan 2017 18:41:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gbwuL1TfqF9qpPFllX6AAorGMI37M6bPr Content-Type: multipart/mixed; boundary="nflHEacm4jE0DCXAqBrTwh9h0pl7oOWHQ"; protected-headers="v1" From: Melinda Shore To: "Salz, Rich" , Eric Rescorla , Ben Laurie Cc: Richard Barnes , "trans@ietf.org" , Paul Wouters Message-ID: <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> In-Reply-To: --nflHEacm4jE0DCXAqBrTwh9h0pl7oOWHQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/31/17 7:10 AM, Salz, Rich wrote: > I again ask the Chairs to determine the consensus and advance this docu= ment. We don't have consensus. We're deadlocked and we're not getting sufficient input from the working group to break the deadlock. 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 said, we're only deadlocked on one particular item (the description of a conspiring CA attack) and there's been no dissent on the rest of the document. I would think it's safe to use it as the basis for a decision about how to go forward on the issues raised by Richard and EKR, except that I also anticipate that they'll argue that the threat model is incomplete. Frankly, this working group was chartered under the assumption that the goal was detection, not prevention. Melinda --nflHEacm4jE0DCXAqBrTwh9h0pl7oOWHQ-- --gbwuL1TfqF9qpPFllX6AAorGMI37M6bPr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYkNo+AAoJELiGRpM6HoEuwD0QAJb5ybwVoR21SQRMKb3Wx7ab NkfS4h1XVN12Ym03+RqWPK6Znwo4wG+UM7xqB5mpBNZ5yuDkEkd/V9nIRbT0w8BX QDbMnR0sYGSi50PzCkvDjee2qFrfARNmiNAAzOm5xdyfkEvERawFp7ooJMo4prNV EEqS6pLyIpWFbL9p5sGaymoE+NEnhJ+nVB8xVALW8d+HpGFt0D9ibdI2RVsD20Hs XUUqdRJdjfVc7Zk/66SjUn+/bwdudE9wotTQALWl9WBpbv4l1e63dMAmXy5fiz+z 8SQfO7WbH5r6dI/5JSSOkWgtrenmK/qSvwm0g1FuvJ6UTtnrU6LsOHRxIVlKl2v3 hIC8TKU007aiyYfhWT/0dc0Vv8ZpMXNv80bI6DFHasRTV+fLOGp2FkwTSANaTB/U oiV5Uu1enn7hyggaUKPsTzIEpOFmhjZuPzeFrj+Hc9gJeFNn9wtTX9xbnbs49Bwj Yops189OIi5ILTEp8KvjfQ1SP5To2PVlN6ftOqffML3ojaULoqx2UubW0vwycNCZ Boe52uHLl+PJIfcdcNU3zI5RuCGyjWw7KhcYIk7g0kxpqFEph2Icoj/SLvD53sTo f7GM1z/NpAlFmix/BSMnGisicE7rlMxplbiQPkCc3VK+yB2i/ed3P5a+aXDptyYL Hp+F9L9stUHBTDPSCok/ =pA/K -----END PGP SIGNATURE----- --gbwuL1TfqF9qpPFllX6AAorGMI37M6bPr-- From nobody Tue Jan 31 10:50:20 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 634A1129551 for ; Tue, 31 Jan 2017 10:50:19 -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 TyqOGxuEwz2U for ; Tue, 31 Jan 2017 10:50:18 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7112956D for ; Tue, 31 Jan 2017 10:50:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 93DF343340C; Tue, 31 Jan 2017 18:50:08 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7D6D0433401; Tue, 31 Jan 2017 18:50:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485888608; bh=sq243U6ZhvR8CF76fnyU0Z5SkyIhBEeYTcb++YdWgFM=; l=776; h=From:To:CC:Date:References:In-Reply-To:From; b=itMH6u9NSpItJKiFgy/8gIx6SiuMyH0Ldo1iwieDaZ6R06qQj42C7eTUY+J3/x9bl EyG7X7rjHXnNt74eYdK1zRacNBoTGxrTltpOETZ/RTL0qxRuLukZIvNn/zR5u3eean l49g7sHfNbnC2V/BgqyD/z0p0dpNPdUYAgg6HYmI= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 79AFD1FC88; Tue, 31 Jan 2017 18:50:08 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 31 Jan 2017 13:50:08 -0500 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; Tue, 31 Jan 2017 13:50:08 -0500 From: "Salz, Rich" To: Melinda Shore , Eric Rescorla , "Ben Laurie" Thread-Topic: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR Thread-Index: AQHSe/GW0YKLOLxGL067P4dSkvMytKFS7XNg Date: Tue, 31 Jan 2017 18:50:07 +0000 Message-ID: References: <8f6852d8-05ae-5f72-8c09-0437cc963b2c@gmail.com> <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> In-Reply-To: <4c0baba3-f85a-4154-c8af-10f84540cb12@gmail.com> 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.35.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , Paul Wouters , "trans@ietf.org" 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: Tue, 31 Jan 2017 18:50:19 -0000 PiBXZSBkb24ndCBoYXZlIGNvbnNlbnN1cy4gIFdlJ3JlIGRlYWRsb2NrZWQgYW5kIHdlJ3JlIG5v dCBnZXR0aW5nDQo+IHN1ZmZpY2llbnQgaW5wdXQgZnJvbSB0aGUgd29ya2luZyBncm91cCB0byBi cmVhayB0aGUgZGVhZGxvY2suDQoNCldlbGwsIHllYWgsIHRoYXQncyB3aHkgeW91IGdldCBwYWlk IHRoZSBiaWcgYnVja3MsIHJpZ2h0PyA6KQ0KDQo+IFBhdWwgYW5kIEkgY2FuIG1ha2UgYSBkZWNp c2lvbiBvbiB0aGUgcGFydGljdWxhciBxdWVzdGlvbiB0aGF0J3MgYSBwcm9ibGVtIGJ1dA0KPiBp dCBwcm9iYWJseSBtZWFucyBhbiBhcHBlYWwgYW5kIGZ1cnRoZXIgZGVsYXkuDQoNClRoYXQncyB0 aGUgcHJvY2Vzcy4NCiANCj4gRnJhbmtseSwgdGhpcyB3b3JraW5nIGdyb3VwIHdhcyBjaGFydGVy ZWQgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUNCj4gZ29hbCB3YXMgZGV0ZWN0aW9uLCBu b3QgcHJldmVudGlvbi4NCg0KVGhhdCdzIG15IHBlcmNlcHRpb24gYXMgd2VsbC4gIElzIHRoZXJl IGFueW9uZSB3aG8gdGhpbmtzIHByZXZlbnRpb24gd2FzIHBhcnQgb2YgdGhlIHNjb3BlPw0K From nobody Tue Jan 31 20:10:46 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 1AD64129C53 for ; Tue, 31 Jan 2017 20:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 94fo1kQEuKoK for ; Tue, 31 Jan 2017 20:10:43 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 B264C129C4F for ; Tue, 31 Jan 2017 20:10:43 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id y143so115124100pfb.0 for ; Tue, 31 Jan 2017 20:10:43 -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=taRxys1WfsTiELcXmSmhEh9i1h6N9glBDGMg1lQ56sg=; b=Ab9XXDllhdyP/q6NBq1d4QE1ZV7PynxDZsthBv9OBPEaxQh3ECAZnX7BId36l/vgun PKHnDLobEuMf0cKgHKLQEh1QScKtAqjCVstPN/l7ajUS6cYkHuNPpIN355AobjMKtjyg kb+RXnPPWx5bEOurh1d8HlRW+XdlMwH4jvnfKN6/Oq5tp2WhrZEtoZKkWTj3KLOrPYq0 JKFq6CDMiPysjqS1EcCGN6lXV27af9KkVIRiMjIu9yf1SGzIcBE1hfX+VQKxz7eBDAHq kzwSlzG92k+ABNsPrktHBcDhiW9qAZoWqpMNCRqT1maN+n8AAKBH+/wdrVbv4QXOHurq 5Wvw== 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=taRxys1WfsTiELcXmSmhEh9i1h6N9glBDGMg1lQ56sg=; b=APDHqQF6kNF8OY003iOqBHuEATmzu7nPJjgOj6l2o3zzMLgIuTbOYbe4Z4gmKroMV5 wmVVRUVzPr1o4ORnD/AYbUwZdIc878HYb7oW1+50KnSQWL5TklT8YS+BvV7U1gsRzlud SnHt4t0sC2k+TKw1mQL2E3JFnXjxwluISp52wtPFMyGklN/1ndNFRsihRrbFoq2hSUqr Vp/iiQFddNf/E1LOMFp99L9HhQ6vhERsEU3nTC4WNz/IJI8vo13NRoYH1Pns782t2jdS kVUrSrBsRhAGH1NQMmSb9YDoAcgBOwH2zcCRgxRzKridK+Xw1yS1mfCgvb0k8q6kjUuQ tq4w== X-Gm-Message-State: AIkVDXJrQcuB3o7qdjfQWopt+xz9+cRnA6gvgfQ4pe3KjJkXxQJobPZjVCmiz2nV8Fz7Lw== X-Received: by 10.99.185.25 with SMTP id z25mr1102611pge.50.1485922242957; Tue, 31 Jan 2017 20:10:42 -0800 (PST) Received: from Melindas-MacBook-Pro.local (74-124-96-230-radius.dynamic.acsalaska.net. [74.124.96.230]) by smtp.gmail.com with ESMTPSA id u14sm44721710pfg.18.2017.01.31.20.10.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 20:10:42 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Tue, 31 Jan 2017 19:10:39 -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="W6bLgvXXBf3XhaCjaT6u0hUGcNK3Qx1qI" Archived-At: Subject: [Trans] Reminder, WGLC for 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: Wed, 01 Feb 2017 04:10:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W6bLgvXXBf3XhaCjaT6u0hUGcNK3Qx1qI Content-Type: multipart/mixed; boundary="5NbsB9FC6DF2Xfh9ldH1R45rX3dljiF99"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: Subject: Reminder, WGLC for gossip document --5NbsB9FC6DF2Xfh9ldH1R45rX3dljiF99 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: This is a reminder that working group last call for the gossip draft closes tomorrow. The URL is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/. Thanks, Melinda --5NbsB9FC6DF2Xfh9ldH1R45rX3dljiF99-- --W6bLgvXXBf3XhaCjaT6u0hUGcNK3Qx1qI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYkV/AAAoJELiGRpM6HoEurTkQAKAlWJaIbK8odk61bk9XHIoN JH/dk9k1788W3jj0EtoNueSp/Z47sgqmnRc9SFyhyxUW64Kaz0jricVcPEpZmR4N RNBzbidAPBy5pHJ7OI8786dhvhyNDbHh18SqVsZr07InDF+6DUtK5gzNOp7MzipV 5YpxBWBHGqr3SQR2cU2WrnxYdL7X1JGQZYGqnTIgElTQOKr/JPQkyXuJVFDYw40z t4MR8ccuuxeNPuxWMHlPDpapRVN+Wclpdv1Ysc8zAD6tWoWeniWwp9FWJQFY4dTJ ob24s3ISEprqTBmWT8AOJAleay01l3bw9q2+dEMl76PWAAA1Tpp5FR98OAv09jEd SbGDQivjZfcI0nLcMVHxmDr3QCyReF65CZX/0/7oyjgk6jY+cTWczLvQ7cyYyA2p Osux0ZzfAjxXdhteW1wgILcslQIKffCyZr3bVBYtqKOHTsgiszC/USQE6oY/32pG rsAo2Dd1aMRibIzMmWc0j9PLPwyhppTFwdDnF/mg4CiqIUAwMaR3PVQb46/7YUiA QD9HByYWBBAXm6/qBKq47RX0THTX4AqQsVu6Wv8BykCN8Vcrq8Z2tBLrKV5WovSD dUKhjlAMibd9uszUXnk/YkX36Pq0GxYA0zhg5iQ6qfLSE9SO9XY4dGccJimx/T0m dChzcw1EHEgqCcpGavgB =4Rlf -----END PGP SIGNATURE----- --W6bLgvXXBf3XhaCjaT6u0hUGcNK3Qx1qI-- From nobody Tue Jan 31 22:51: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 692F01293FD for ; Tue, 31 Jan 2017 22:51:49 -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=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 Ydrdo4raMG8T for ; Tue, 31 Jan 2017 22:51:48 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D843C120727 for ; Tue, 31 Jan 2017 22:51:47 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id w75so56514674ywg.1 for ; Tue, 31 Jan 2017 22:51:47 -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=fYvvlRb87sX1MxUGCd+mdjQ8LEHxESHPmNFV3LsCqfA=; b=P8DNcaxUp0ZC/TA3UGrlj/5W+bnrnRgTZkVUQsJ/aW9JjHO7gTyr62Bw/xFPIL+mit t0hA6urZbnCUQtPlgmy5Tk2qjDj7nfhhTJRwcmWrSIYHR9CipMdYoDUEU0/0AWVG+cm+ GhoiD44SQ+4HVZQlpRw/lP4eb1j/vpheOs/9HZ1vV169oBVCWgn4nDXCcWM7FwDJveNI LmIPMubnLAWcG2R9kkOUH+kbcoxo/gkfCnFp0N/Y956bUaS33ti8+CV9ohhkdN0Vj5jx z9VCGJuzuEADFOcKD4uNhd6GS/U3SWwNIhEZ9gpFB7FdVdXeP1olYc9A0+/4mnxpXQMN ocZw== 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=fYvvlRb87sX1MxUGCd+mdjQ8LEHxESHPmNFV3LsCqfA=; b=b6HKreac1TuJ5wjNFjApWjPjqo1y9eyutrwSFOB4b4u9bcntkF8Ml7uaJPDKQuMRy9 dGaSzLQggMDb0qmzWg7Ar+RYn6aocVVvTtTldrBiy9ygEX7gFEhCfu4ldXXx+W6Yo7uQ EPbZZTvWtCo58fnu7E+ZGFQ+l82qqdTZDcFrNWECxladMtVE+apx6sfIJK7VmTejiyWH pmtjwvk8xq6kusRZmUIPQZ23D2z2HAHgPSvviXfv5lUR2k6H4BtYbWaykLrfMAi5Q4ma PTLZYcHwLzNDMoVd8bONAFl6kmANkrYV8BK+JtFdd6uRZO27/JSgKY6qNJG6fqC73jag 0uRw== X-Gm-Message-State: AIkVDXLi/EmuUgakSSc36tMCm+zIkHsCWekAraetrGx8p12MhpePFtQ05GvzmDG/mujl+w8izfZTpYJVUhe0TA== X-Received: by 10.129.137.129 with SMTP id z123mr778671ywf.327.1485931907147; Tue, 31 Jan 2017 22:51:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 31 Jan 2017 22:51: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: Wed, 1 Feb 2017 07:51:06 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c06bf387c9a530547727b1c 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 06:51:49 -0000 --94eb2c06bf387c9a530547727b1c Content-Type: text/plain; charset=UTF-8 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 --94eb2c06bf387c9a530547727b1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jan 31, 2017 at 7:50 PM, Salz, Rich <rsalz@akamai.com> wrote:
> We don&#= 39;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 pai= nting with a bit too broad a brush. One needs to talk about
detection under a specific threat model, as I indicated pr= eviously. 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 technolog= ical solution is adequate to detect misissuance depends on which
of these three threat models you think applies.
=

-Ekr

--94eb2c06bf387c9a530547727b1c--