From nobody Thu Mar 2 15:58: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 414F21293E4 for ; Thu, 2 Mar 2017 15:58:53 -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 0SB3u4AbFgN7 for ; Thu, 2 Mar 2017 15:58:51 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 58F23128BA2 for ; Thu, 2 Mar 2017 15:58:51 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 72so97809176uaf.3 for ; Thu, 02 Mar 2017 15:58:51 -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=ykwdlQa3jhOIQVCj0DRCLYxV8PkkiPhTCmk1D3jeJBw=; b=f8Toee/UabfrBuOIarCdqqHdhyjiPFtfXPEVprQildS7m661ErmLOpHkeSzWppae+3 3yvMyiF4cqnS0ueKsBnA7tUBgfs/nSDAKLVLq9VWpc454LFYN8vHH89KeuI5tnz4xPYX Thqmqf6r7mQs9CtIAjoEjNBnIUr6eLwL82Nk1WMMdrsVl4LaxLgBULdgaBhA3WuypErA YJKU5P5inY7WNam7hfhw1pbiLpXk449WBsOBbcFqWx8LPgCwCtn6IHPRkR7beysoYB4e 5mRtaCGnZb9NNFiEIGhcizkRlSk/XOVDReX/56NSI2Mh1YhGJnFAK2LLfz7UFgCWW4vX hjwA== 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=ykwdlQa3jhOIQVCj0DRCLYxV8PkkiPhTCmk1D3jeJBw=; b=s/mGW5tECKYYNmAXtO6mSjXORp5DnwYSf2JDkPhmuuqkiXxVxLo/Oqr+wWrDWw2ykR shHrP0Xt58UJBmrrBNEtEj+apq0WZa7LuH5pwhBcngrB//94mEjA5oMsBRvjCItGE4SZ 7FRG8F+3EfpyYFNIodqbWARGZdBAifoRObGJFIxCfNgRUvnfUuwhnH0tP1/Esr+2x3m2 2kVPg1mos/V6EvFbUgCN0CJg+Z8tqx1e2KWyRNqB00Y9IU7TzNsrQYllHbJL2TlyvI8k A7iORTvT4EYOn+AOlPN1OK5sG/fyWNumnwQssFmuz5ha/jDHjVfbbeibHhldL4DWuksa enhw== X-Gm-Message-State: AMke39m6ZLKuaU470d2a7+pWr03jryDdXaLXlruVMgGOXFj6u3yPRmpiQe7tkOEO2oZHsEK5hnv7NmUinkwSiw== X-Received: by 10.159.40.202 with SMTP id d68mr8443224uad.122.1488499130147; Thu, 02 Mar 2017 15:58:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.179.140 with HTTP; Thu, 2 Mar 2017 15:58:49 -0800 (PST) From: Richard Barnes Date: Thu, 2 Mar 2017 18:58:49 -0500 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary=94eb2c12382ee6bedb0549c83507 Archived-At: Cc: Zakir Durumeric , Nick Sullivan Subject: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:58:53 -0000 --94eb2c12382ee6bedb0549c83507 Content-Type: text/plain; charset=UTF-8 Hey all, This might not be quite the right list for this, but since I'm not aware of a "ct-implementors" list, I thought I'd go ahead and post it. tl;dr: Logging with live updates to the Merkle tree can be done at rates of at least 10-150qps. It had bothered me for a while that there was this 24-hour delay at the heart of CT, and I was never satisfied with the hand-wavy answers about distributed consensus. At the CT policy days last week, Nick, Zakir, and I decided to see if we could build a log with two properties: 1. It updates in real time, i.e., it ensures that the Merkle tree is updated before returning 200/OK to an add-chain query. 2. It updates fast enough that it could plausibly keep up with real log loads Property (1) means that if your signer was fast enough to keep up, you could return an STH instead of an SCT in response to an add-chain query. This should be appealing to log operators, since if you log this way, you never have to worry about missing your MMD -- your MMD is zero. The only real innovation needed here is to focus on the bare minimum that needs to be done to update a Merkle tree. In order to add a certificate to the tree, you don't need to track the whole tree, you just need to keep track of a log-size "frontier" of the heads of complete subtrees; these also happen to be the elements of an inclusion proof from the new cert to the tree head immediately after its addition. Then all you need to do to add a cert to the tree is ensure that the following are done atomically: - Fetch the latest frontier - Update it with the new certificate - Store the certificate and the new frontier Then you can update your log as fast as your database can do those transactions. To estimate how fast this can happen in practice, we tested out a few storage configurations behind a simple Go front-end that implements the add-chain endpoint from RFC 6962 [1]: A. Google Cloud Spanner [2] B. Postgres running on a dedicated SSD, on the same server as the front end C. Postgres running remote, on a shared hard disk (All of these can trivially support multiple front-ends, due to transaction wrapping; it turns out not to help, because you're limited by the transaction processing rate.) Spanner turned out to be the slowest by quite a bit [3], operating at around 10qps. Postgres on an SSD was fastest, at 150-200qps. Postgres in a more realistic configuration was in the middle, at around 60qps. Obviously, there's some trade-off with reliability here, but since Google is using Spanner for their logs, it seems like the Spanner number should represent a pretty acceptable reliability level. The upshot is that this style of logging seems eminently feasible. Almost all CT logs are growing at well less than 10qps [2], and even Let's Encrypt on its worst days only generates about 115qps. And I have pretty high confidence that if you actually put some thought into designing the storage scheme, you could get some additional margin here. ===== What does this mean for CT? I'm not totally sure. On the one hand, it seems like it adds some credibility to the idea of relying more on inclusion proofs, since in principle, a log can issue an inclusion proof to a tree head immediately on cert submission. It certainly makes me wonder if there's an argument in here for getting rid of SCTs entirely. On the other hand, it may not be dispositive. Even if you can create an inclusion proof to *a* tree head, it's not going to be that useful unless that a client/auditor can connect that tree head up to some notion of the global state -- and it will not be feasible for that global state to be the entire set of tree heads, one per certificate! Assuming then that logs will have to only issue global state periodically, there will still be delay in issuance, just driven by client/auditor caching capabilities instead of log ingress capabilities. On the third hand, it may be possible to hack around even this. Even if logs are checkpointed, so that only some tree heads are "official" and used by clients/auditors, the log could produce a consistency proof to the last official head at ingress time, which would provide the client/auditor some assurance that the cert fits into the global history, which could be verified when the next official tree head comes out. In any case, we should stop thinking that log delay and the MMD are essential properties of this system. --Richard [1] https://github.com/bifurcation/loggerhead [2] https://github.com/bifurcation/loggerhead/tree/spanner [3] It was also really expensive! Cost almost $100 in free trial credit to run this experiment :) [4] https://sslmate.com/labs/ct_growth/ --94eb2c12382ee6bedb0549c83507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

This might = not be quite=20 the right list for this, but since I'm not aware of a "ct-implemen= tors"=20 list, I thought I'd go ahead and post it.

tl;dr: Logging w= ith live updates to the Merkle tree can be done at rates of at least 10-150= qps.

It had bothered me for a while that there was this 24-hour delay at the=20 heart of CT, and I was never satisfied with the hand-wavy answers about=20 distributed consensus.=C2=A0 At the CT policy days last week, Nick, Zakir,= =20 and I decided to see if we could build a log with two properties:

1. It updates in real time, i.e., it ensures that the Merkle tree is up= dated before returning 200/OK to an add-chain query.
2. It updates= fast enough that it could plausibly keep up with real log loads

Property (1) means that if your signer was fast enough to keep up, you could=20 return an STH instead of an SCT in response to an add-chain query.=C2=A0 Th= is should be appealing to log operators, since if you log this way, you nev= er have to worry about missing your MMD -- your MMD is zero.

<= div>The only real innovation needed here is to focus on the bare minimum that need= s to be done to update a Merkle tree.=C2=A0 In order to add a certificate t= o the=C2=A0 tree, you don't need to track the whole tree, you just need= to=20 keep track of a log-size "frontier" of the heads of complete subt= rees; these also happen to be the=20 elements of an inclusion proof from the new cert to the tree head immediate= ly=20 after its addition.=C2=A0 Then all you need to do to add a cert to the tree= =20 is ensure that the following are done atomically:

- Fetch= the latest frontier
- Update it with the new certificate
=
- Store the certificate and the new frontier

<= /div>
Then you can update your log as fast as your database can do those=20 transactions.=C2=A0 To estimate how fast this can happen in practice, we=20 tested out a few storage configurations behind a simple Go front-end=20 that implements the add-chain endpoint from RFC 6962 [1]:

A. Google Cloud Spanner [2]
B. Postgres running on a dedicat= ed SSD, on the same server as the front end
C. Postgres runni= ng remote, on a shared hard disk

(All of these can trivially support multiple front-ends, due to transaction=20 wrapping; it turns out not to help, because you're limited by the=20 transaction processing rate.)

Spanner=20 turned out to be the slowest by quite a bit [3], operating at around 10qps.= =C2=A0 Postgres on an SSD was fastest, at 150-200qps.=C2=A0 Postgres in a more realistic configurati= on was in the middle, at around 60qps.=C2=A0 Obviously, there's some trad= e-off with reliability here, but since Google is using Spanner for their lo= gs, it seems like the Spanner number should represent a pretty acceptable r= eliability level.=C2=A0

The upshot is=20 that this style of logging seems eminently feasible.=C2=A0 Almost all CT lo= gs are growing at well less than 10qps [2], and even Let's Encrypt on its= =20 worst days only generates about 115qps.=C2=A0 And I have pretty high confid= ence that if you actually put some thought into designing the storage schem= e, you could get some additional margin here.

=3D=3D=3D= =3D=3D

What does this mean for CT?=C2=A0 I'm not tota= lly sure.

On the one hand, it seems like it adds some credibility to the idea of=20 relying more on inclusion proofs, since in principle, a log can issue an inclusion proof to a tree head immediately on cert submission.=C2=A0 It=20 certainly makes me wonder if there's an argument in here for getting ri= d of SCTs entirely.

On the other hand, it may not be=20 dispositive.=C2=A0 Even if you can create an inclusion proof to *a* tree=20 head, it's not going to be that useful unless that a client/auditor can= =20 connect that tree head up to some notion of the global state -- and it=20 will not be feasible for that global state to be the entire set of tree=20 heads, one per certificate!=C2=A0 Assuming then that logs will have to only= =20 issue global state periodically, there will still be delay in issuance,=20 just driven by client/auditor caching capabilities instead of log=20 ingress capabilities.

On the third hand, it may be=20 possible to hack around even this.=C2=A0 Even if logs are checkpointed, so= =20 that only some tree heads are "official" and used by clients/audi= tors,=20 the log could produce a consistency proof to the last official head at=20 ingress time, which would provide the client/auditor some assurance that the cert fits into the global history, which could be verified when the next official tree head comes out.

In any cas= e, we should stop thinking that log delay and the MMD are essential propert= ies of this system.

--Richard


[1] https://git= hub.com/bifurcation/loggerhead
[2] https://github.com/bifurcation/loggerhead= /tree/spanner
[3] It was also really expensive!=C2=A0 Cos= t almost $100 in free trial credit to run this experiment :)





<= /div>
--94eb2c12382ee6bedb0549c83507-- From nobody Thu Mar 2 17:05: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 4494C128DF6 for ; Thu, 2 Mar 2017 17:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 lSt0ynAfxQEB for ; Thu, 2 Mar 2017 17:05:00 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8E612941C for ; Thu, 2 Mar 2017 17:05:00 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id E2ED220051C24 for ; Thu, 2 Mar 2017 17:04:59 -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=2FjXjpnn/WIZIZVua7w3o+V8efs=; b= thZRDnlnAeUahuAGyetMAFRthHCytGCg7Twz5AiUcrGtbz7UK4z78ZS+ZeApFMut 4Gh84EdpIB8JeRDz1P23EpuoxTkXijz4EgjOvLWbIQG4BkY7404BLW9SaPdvUfRc SsVaDo+nevpkTlvzWHMBzyMNe41R1+i6lm0j6rLkBcE= Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id B62C220051C23 for ; Thu, 2 Mar 2017 17:04:59 -0800 (PST) Received: by mail-lf0-f43.google.com with SMTP id a6so41258848lfa.0 for ; Thu, 02 Mar 2017 17:04:59 -0800 (PST) X-Gm-Message-State: AMke39nd5lOR/+R69VzUtI2ZGifm2bpda9GSGw/TUfYIGLtR+8PJNSTBlOotZIaIyrkMLY5R0v+VmxWY/tTbAA== X-Received: by 10.46.92.195 with SMTP id q186mr34269ljb.107.1488503097880; Thu, 02 Mar 2017 17:04:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 2 Mar 2017 17:04:57 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 2 Mar 2017 17:04:57 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=94eb2c1b3fd0657fde0549c922e6 Archived-At: Cc: Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:05:01 -0000 --94eb2c1b3fd0657fde0549c922e6 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: > > In any case, we should stop thinking that log delay and the MMD are > essential properties of this system. > I'm confused by this conclusion, and apologies if I've misunderstood. Can you explain how this statement differs, from say a discussion about keeping a database in RAM and never flushing to disk? You can have amazing QPS - but terrible reliability. It sounds like you're describing that you've built an unreliable, but efficient, system, and are using that as proof that reliability is not a critical property? --94eb2c1b3fd0657fde0549c922e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes <rlb@ipv.sx> wro= te:
In any case, we should stop thinking that log delay and the MMD are essent= ial properties of this system.

I'm confused by this con= clusion, and apologies if I've misunderstood.

Can you explain how this statem= ent differs, from say a discussion about keeping a database in RAM and neve= r flushing to disk? You can have amazing QPS - but terrible reliability. It= sounds like you're describing that you've built an unreliable, but= efficient, system, and are using that as proof that reliability is not a c= ritical property?
--94eb2c1b3fd0657fde0549c922e6-- From nobody Thu Mar 2 17:06:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760C7129450 for ; Thu, 2 Mar 2017 17:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2go102LzdY7h for ; Thu, 2 Mar 2017 17:06:22 -0800 (PST) Received: from homiemail-a54.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 63CDA12941C for ; Thu, 2 Mar 2017 17:06:22 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 791224800012B for ; Thu, 2 Mar 2017 17:06:21 -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=s98l36VcGBMD3m57EvN3iRtmn6Q=; b= V2lv+uMgvpwZjSk6yh1NuPFE0ZPi3H+lwPwF2otp4MH7d3RyU+m9qhM/FoAN7U6m BOr4A2hbwbm96j7+wjPSqZclTHwCDZKgTN2LaZwJoAsXfvhpCdBbLx56CGrfnpDZ MmKyhUkBiWbU1/yrVAFqhtSXOmLLPdCICv/GJqYGlaQ= 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-a54.g.dreamhost.com (Postfix) with ESMTPSA id 4863C4800103F for ; Thu, 2 Mar 2017 17:06:21 -0800 (PST) Received: by mail-lf0-f54.google.com with SMTP id k202so41218558lfe.1 for ; Thu, 02 Mar 2017 17:06:21 -0800 (PST) X-Gm-Message-State: AMke39kxRboxE6Vtl4QGPTy8K2wOnbTGzg2EsCbSg3JcK9l3t9W06u+xT0n6K/hwZpEJuo53kJhfrb9iMLCfFw== X-Received: by 10.46.83.92 with SMTP id t28mr48622ljd.70.1488503179684; Thu, 02 Mar 2017 17:06:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 2 Mar 2017 17:06:19 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 2 Mar 2017 17:06:19 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=f4030436050e45b4d60549c92792 Archived-At: Cc: Richard Barnes , Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:06:23 -0000 --f4030436050e45b4d60549c92792 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 5:04 PM, Ryan Sleevi wrote: > > I'm confused by this conclusion, and apologies if I've misunderstood. > > Can you explain how this statement differs, from say a discussion about > keeping a database in RAM and never flushing to disk? You can have amazing > QPS - but terrible reliability. It sounds like you're describing that > you've built an unreliable, but efficient, system, and are using that as > proof that reliability is not a critical property? > And as a concrete example, consider https://groups.google.com/a/chromium.org/d/msg/ct-policy/ohtZ64gLN3I/q4nSPkrWCQAJ --f4030436050e45b4d60549c92792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f4030436050e45b4d60549c92792-- From nobody Thu Mar 2 17:38: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 A21551293E8 for ; Thu, 2 Mar 2017 17:38: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=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 eur6eyq8AFSI for ; Thu, 2 Mar 2017 17:38:35 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 7B155129416 for ; Thu, 2 Mar 2017 17:38:35 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id u48so64460841wrc.0 for ; Thu, 02 Mar 2017 17:38:35 -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=Nsw2fari0iOnrW5bhfmWia1+SsWoLClfcLgYY38SeYU=; b=WaVze/hcmTvR9tJHnylAgtTBKFTkEx8zhz21TZKKrNKnqMg/WExWO/zsIHDrUQ6kYB CS8D6oKRT034uF5CEdAxhTNer+lc2e4c4f7GP0fCfks9wNjMgaT808xrtAddd+HFX13u oDWV/uPngPTq+jgonwBcFQzzq1PSAkpyYnRiFdO8Yl8SAJtnMAbrIekNRCmzrrJD7Kdl Po3rpFBi8LOhR9CMsQszU/LxyoMOOgtCx4H3EkaKhGNbYCpqHRRuBE4xbwARAbvQfLJ+ zyaigkLOR3kudKYj1uth2RnDbaIEiDtmMXwxa7FCGVUxWjtdqYaLZebBM0b4bJ1H/+DN 43Rg== 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=Nsw2fari0iOnrW5bhfmWia1+SsWoLClfcLgYY38SeYU=; b=EW+NMKZmLwq2ZoDRpDQeRkZ+/P29WbmNIVP7qJNykRQgPaEO5Xzbk3ZkFZ2+uEfXAQ tKHRKaI8GD7cH+KXe8IqALt6+gI4YiiCcrC3l4tkca4F6Jksn9P/WdjkOE2x4NpK6zKi djERtTiCTerVYuK2BzOsvdqA9pBSuyGyTFCJjCnTDAE5FM9i6X8VHnK9UWotgIpt7y5J lRJrRVNVMX7lDsJ4o/gMn7rSSbTSYfP1YB2TGI2tigwUxtP7ayc5aIz72o7VK0da83EA OsMRgHzibloiVPM+LXpIcTy1nFdXyUzxC9aJH1bKxnf3BZPtzYjq5lLrzX8sszPZxSFv Bo+Q== X-Gm-Message-State: AMke39mSs7/Sxrz9odJLjrrVmNoOYxPHGZRPJT5aimkbZZViZ6E1yoUELQd7wCX+jZ0pJtg/F4xWnCQu5MLnhg== X-Received: by 10.223.139.152 with SMTP id o24mr155380wra.61.1488505113560; Thu, 02 Mar 2017 17:38:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Thu, 2 Mar 2017 17:38:32 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Thu, 2 Mar 2017 20:38:32 -0500 Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=f403045e9ace8a61510549c99a86 Archived-At: Cc: Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:38:36 -0000 --f403045e9ace8a61510549c99a86 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi wrote: > > > On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: >> >> In any case, we should stop thinking that log delay and the MMD are >> essential properties of this system. >> > > I'm confused by this conclusion, and apologies if I've misunderstood. > > Can you explain how this statement differs, from say a discussion about > keeping a database in RAM and never flushing to disk? You can have amazing > QPS - but terrible reliability. It sounds like you're describing that > you've built an unreliable, but efficient, system, and are using that as > proof that reliability is not a critical property? > That's part of why I used Spanner as one of our test points. At least according to Al at the CT policy days, that's what his team is using as storage for their logs. So presumably it's suitably reliable? I'm definitely willing to admit there's a trade-off here. My point is just that the reliability requirements are not inconsistent with a sufficiently high transaction rate to serve existing needs. --Richard --f403045e9ace8a61510549c99a86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi <ryan-ietf= @sleevi.com> wrote:


On Thu= , Mar 2, 2017 at 3:58 PM, Richard Barnes <rlb@ipv.sx> wrote:
In any ca= se, we should stop thinking that log delay and the MMD are essential proper= ties of this system.
=
I'm confused by this conclu= sion, and apologies if I've misunderstood.

Can you explain how this statement= differs, from say a discussion about keeping a database in RAM and never f= lushing to disk? You can have amazing QPS - but terrible reliability. It so= unds like you're describing that you've built an unreliable, but ef= ficient, system, and are using that as proof that reliability is not a crit= ical property?

That's part = of why I used Spanner as one of our test points.=C2=A0 At least according t= o Al at the CT policy days, that's what his team is using as storage fo= r their logs.=C2=A0 So presumably it's suitably reliable?

I'm definitely willing to admit= there's a trade-off here.=C2=A0 My point is just that the reliability = requirements are not inconsistent with a sufficiently high transaction rate= to serve existing needs.

--Richard
--f403045e9ace8a61510549c99a86-- From nobody Thu Mar 2 17:55: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 AC7D71295B7 for ; Thu, 2 Mar 2017 17:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8nH0OSOsREQ for ; Thu, 2 Mar 2017 17:55: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 E0A7A12946E for ; Thu, 2 Mar 2017 17:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1488506115; bh=Wwh9UQ1FBcSXvQWTgLGA6KVgdS4uNOqvBNYTnmzSKxk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=tnF3PyDDOVa9z4kgKjzIA9iLwO3P3j0apMr/rU0D4n0ecMqv4LGtvPtw98YQDE0Iw quFstRvl2aYpBhdBnci6Q3r15tjhcafbxSpwdfvFArL+Nldk/KQdv6TxWfpYopiJCl JzWxkb30J6IONjacQzDnOq4yVBUhk6Nz/zx1xqsGBXibmnjiQ3XhgloeAX3kCQMRu8 9h8t33HVgY20YfRQMzuQYQ1E8EC4haN00linQxPssUqymgCsVo5dV0GJLGJRFba/XB nMqf1t+F/o180dvZrW3b1G6EjR9ZDef9u7QcNCkWqBqvole+QxWEHrnU0vVsFP2y63 QrqZNcXyS7WIg== Date: Thu, 2 Mar 2017 17:55:14 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170302175514.e1845a0b6314b08527ee5703@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:55:16 -0000 Hi Richard, On Thu, 2 Mar 2017 18:58:49 -0500 Richard Barnes wrote: > On the third hand, it may be possible to hack around even this. Even > if logs are checkpointed, so that only some tree heads are "official" > and used by clients/auditors, the log could produce a consistency > proof to the last official head at ingress time, which would provide > the client/auditor some assurance that the cert fits into the global > history, which could be verified when the next official tree head > comes out. This sounds interesting - could you elaborate? Regards, Andrew From nobody Thu Mar 2 19:29: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 8BD1C12968D for ; Thu, 2 Mar 2017 19:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCS4uPz7EJYa for ; Thu, 2 Mar 2017 19:29:14 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 AA2AA129407 for ; Thu, 2 Mar 2017 19:29:13 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n11so5918152wma.0 for ; Thu, 02 Mar 2017 19:29:13 -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=lUV6v+YgouFVPjFjaaNEj4Fb+mEur+g2Hq/ar7/AJt4=; b=R06b6x+EHGjNvb2q/97A0YcdeJf2UAzpNwxE2nkHlmpz/ko23CBSEBbhALYaGoVue8 vCBTRoXv+cuUYZtUubAisxxWC9tgQeMzJ8OoNe9craDiwDfc/27rjA94/9/BpNpLbGH4 3GStCLr6JWClrDkJ5RyQZuPNqyCngI1n/di3E72piVJGNh+M44j/6SIJsWH0aKkEGbpq d5R8Gd9BSR42zzBqXb+VbhzWJVHMeeGynUhSd2nCgOxSkNWtFKhBwmBRjdLRjIfbacHC 6BkJ3RpNG9zF765mch0xv1nXWhc3C2H5G9BRUTy7e7XCUnMKvZnndNBm1FHTzUSAmYUo G1kg== 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=lUV6v+YgouFVPjFjaaNEj4Fb+mEur+g2Hq/ar7/AJt4=; b=P0c7xpikLqWZ8nwplLdv/fEAGxZEjj9808L1rkVUrxVcdchdadVcVc3Z+waJPGoKQA jVZfTLrs1N7iedtCT7ST47IYuk67Ipwg5B6+7ppNo+xwpip+4W23upWCgrtV8OLCpYtF 761M3JSQ5oVQKBsh+5ZsX6LejUSpL1yh/ESh+hDau36k4EDQmWnMG95/f8beD02388D4 PAVkud3IJjk5aZoWVhrHkoSMVYwu072Mr/o3Qkh49tj3rjkty6YTyA+IpaPkPowtet3+ RA1AIBPGY0HEpY84/LzLWqrmdDMxryr3CcOieYAjr4zcAtbzpEbuon3owg/a+6DIMgGJ FC5g== X-Gm-Message-State: AMke39lG/WnNqki8sAQVxxOd55v974iSl6Hu+QV0zphSOVIDy7UZCfe0vXChlI4XhY2nAzARBj3qJ/IO+sqFGQ== X-Received: by 10.28.93.68 with SMTP id r65mr696466wmb.133.1488511751877; Thu, 02 Mar 2017 19:29:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Thu, 2 Mar 2017 19:29:11 -0800 (PST) In-Reply-To: <20170302175514.e1845a0b6314b08527ee5703@andrewayer.name> References: <20170302175514.e1845a0b6314b08527ee5703@andrewayer.name> From: Richard Barnes Date: Thu, 2 Mar 2017 22:29:11 -0500 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=001a11467a9a370e770549cb26ca Archived-At: Cc: Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 03:29:15 -0000 --001a11467a9a370e770549cb26ca Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 8:55 PM, Andrew Ayer wrote: > Hi Richard, > > On Thu, 2 Mar 2017 18:58:49 -0500 > Richard Barnes wrote: > > > On the third hand, it may be possible to hack around even this. Even > > if logs are checkpointed, so that only some tree heads are "official" > > and used by clients/auditors, the log could produce a consistency > > proof to the last official head at ingress time, which would provide > > the client/auditor some assurance that the cert fits into the global > > history, which could be verified when the next official tree head > > comes out. > > This sounds interesting - could you elaborate? > (To be clear: Credit for this idea goes to Zakir, I'm just recapping.) Obviously, every time you add a cert to the Merkle tree, you get a new tree head. Say a log produces "official" tree heads ever 5 certs and all official heads get sync'ed out to clients, who cache them all. (Just for the sake of argument; obviously you could also fetch.) So you would have a history something like this: O1 - H2 - H3 - H4 - H5 - O6 - H7 - H8 - ... At the time the fourth certificate (C4) is added, the log can produce two things: 1. An inclusion proof from C4 to H4 2. A consistency proof from O1 to H4 If these can be provided to the client (say in the cert or stapled OCSP) and the client has O1, then the client can verify that there is a causal link between the two. This is slightly better than an SCT (e.g., it can't be back-dated to before O1), but doesn't prevent forked history. In order to prevent that, the client still has to verify that the head H4 is "forward consistent" with the next tree head O6. So you still need to get a consistency proof that proves that H4 is consistent with O6. You can do that by fetching it from the log, but that's no better from a privacy / log scaling POV than fetching inclusion proofs. It would be lovely if the consistency proof between O1 and O6 could also be used to verify any intermediate heads you have, since then the client could just sync down the consistency between official heads and use that to check the intermediates. TBH, I don't have good enough intuition for consistency proofs to know whether this works off the top of my head, and I haven't sat down to figure it out. --Richard --001a11467a9a370e770549cb26ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 2, 2017 at 8:55 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
Hi Richard,

On Thu, 2 Mar 2017 18:58:49 -0500
Richard Barnes <rlb@ipv.sx> wrote:

> On the third hand, it may be possible to hack around even this.=C2=A0 = Even
> if logs are checkpointed, so that only some tree heads are "offic= ial"
> and used by clients/auditors, the log could produce a consistency
> proof to the last official head at ingress time, which would provide > the client/auditor some assurance that the cert fits into the global > history, which could be verified when the next official tree head
> comes out.

This sounds interesting - could you elaborate?
=
(To be clear: Credit for this idea goes to Zakir, I'm ju= st recapping.)

Obviously, every time you add a cert to th= e Merkle tree, you get a new tree head.=C2=A0 Say a log produces "offi= cial" tree heads ever 5 certs and all official heads get sync'ed o= ut to clients, who cache them all.=C2=A0 (Just for the sake of argument; ob= viously you could also fetch.)=C2=A0 So you would have a history something = like this:

O1 - H2 - H3 - H4 - H5 - O6 - H7 - H8 - ...

At the time the fourth certificate (C4) is added= , the log can produce two things:

1. An inclusion proof f= rom C4 to H4
2. A consistency proof from O1 to H4



<= /div>
--001a11467a9a370e770549cb26ca-- From nobody Thu Mar 2 21:38: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 1BC5F12947C for ; Thu, 2 Mar 2017 21:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwoYjCNPfSKe for ; Thu, 2 Mar 2017 21:37:59 -0800 (PST) Received: from homiemail-a108.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 BC99B12940A for ; Thu, 2 Mar 2017 21:37:59 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 3EEA620047613 for ; Thu, 2 Mar 2017 21:37:59 -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=aGYPcmqie3wGTce2t6drJ+HSHXk=; b= J2RYHCjaizQSwIMQPnRIbkyz3LhDIYF9bRAL89DDwd+qwLinh6/G4B2xpozITziv xp80xNSOigSlKIQgMa33lFubY8xTQWw3n8lF/uk8/NHDm1+C4D1eN8jbkIdIb/Np hdJwn6R/EtzRq0IfvdktIOEsa4UBCZjfANREKeQCGG4= Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 1214420047612 for ; Thu, 2 Mar 2017 21:37:59 -0800 (PST) Received: by mail-lf0-f42.google.com with SMTP id k202so42839873lfe.1 for ; Thu, 02 Mar 2017 21:37:58 -0800 (PST) X-Gm-Message-State: AMke39nYbYI+DVTLW9O3oRpaL4qwK9faDnIkdKJ6ztnkt86fZzKuegPtUshZERKj9M8nfyLq0uK60TMrdWAR+Q== X-Received: by 10.25.190.76 with SMTP id o73mr288599lff.80.1488519477178; Thu, 02 Mar 2017 21:37:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 2 Mar 2017 21:37:56 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Thu, 2 Mar 2017 21:37:56 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=94eb2c1a1b3eadbae70549ccf283 Archived-At: Cc: Ryan Sleevi , Zakir Durumeric , trans@ietf.org, Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 05:38:01 -0000 --94eb2c1a1b3eadbae70549ccf283 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes wrote: > On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi wrote: > >> >> >> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: >>> >>> In any case, we should stop thinking that log delay and the MMD are >>> essential properties of this system. >>> >> >> I'm confused by this conclusion, and apologies if I've misunderstood. >> >> Can you explain how this statement differs, from say a discussion about >> keeping a database in RAM and never flushing to disk? You can have amazing >> QPS - but terrible reliability. It sounds like you're describing that >> you've built an unreliable, but efficient, system, and are using that as >> proof that reliability is not a critical property? >> > > That's part of why I used Spanner as one of our test points. At least > according to Al at the CT policy days, that's what his team is using as > storage for their logs. So presumably it's suitably reliable? > > I'm definitely willing to admit there's a trade-off here. My point is > just that the reliability requirements are not inconsistent with a > sufficiently high transaction rate to serve existing needs. > Again, I'm confused as to how you reach that conclusion, so apologies if I'm just dense here. You've compared an extremely reliable, globally consistent storage system and established one bound (10qps) for your idea. You've then compared an extremely unreliable, globally inconsistent storage system and established another bound (60qps-200qps) I'm not sure why you've introduced the unreliable system - which has SPOF written all over it - or how it relates to this proposal. Are you suggesting that reliability is no longer necessary? Assuming reliability is necessary, and we accept 10qps for 'extremely high' reliability, and 60qps for 'extremely low reliability', doesn't your solution only provide value iff the growth rate of the ecosystem is somewhere within these bounds? Are you asserting that "10-60 qps should be enough for everyone"? I guess what I'm trying to figure out is what the consequence of this experiment is - are you proposing change? Because aren't those bounds only relevant to the specific experiment you did, which is related to your proposed solution for STH-on-every-cert? I apologize if I'm simply dense from what this implementation feedback is related to, or understanding the objective of this experiment. You suggest it may be feasible, but I see those numbers and reach the opposite conclusion, so I'm trying to understand where I'm misunderstanding. --94eb2c1a1b3eadbae70549ccf283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes <rlb@ipv.sx> wro= te:
On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes <rlb@ipv.sx> wrot= e:
= In any case, we should stop thinking that log delay and the MMD are essenti= al properties of this system.

I'm confused by th= is conclusion, and apologies if I've misunderstood.

Can you explain how this = statement differs, from say a discussion about keeping a database in RAM an= d never flushing to disk? You can have amazing QPS - but terrible reliabili= ty. It sounds like you're describing that you've built an unreliabl= e, but efficient, system, and are using that as proof that reliability is n= ot a critical property?

=
That's part of why I used Spanner as one of our test points.=C2=A0= At least according to Al at the CT policy days, that's what his team i= s using as storage for their logs.=C2=A0 So presumably it's suitably re= liable?

I'm defini= tely willing to admit there's a trade-off here.=C2=A0 My point is just = that the reliability requirements are not inconsistent with a sufficiently = high transaction rate to serve existing needs.

Again, I'm confused as to how you reach that conclusion= , so apologies if I'm just dense here.

You'= ;ve compared an extremely reliable, globally consistent storage system and = established one bound (10qps) for your idea. You've then compared an ex= tremely unreliable, globally inconsistent storage system and established an= other bound (60qps-200qps)

I'm not sure why yo= u've introduced the unreliable system - which has SPOF written all over= it - or how it relates to this proposal. Are you suggesting that reliabili= ty is no longer necessary?

Assuming reliability is= necessary, and we accept 10qps for 'extremely high' reliability, a= nd 60qps for 'extremely low reliability', doesn't your solution= only provide value iff the growth rate of the ecosystem is somewhere withi= n these bounds? Are you asserting that "10-60 qps should be enough for= everyone"?

I guess what I'm trying to fi= gure out is what the consequence of this experiment is - are you proposing = change? Because aren't those bounds only relevant to the specific exper= iment you did, which is related to your proposed solution for STH-on-every-= cert?

I apologize if I'm simply dense from wha= t this implementation feedback is related to, or understanding the objectiv= e of this experiment. You suggest it may be feasible, but I see those numbe= rs and reach the opposite conclusion, so I'm trying to understand where= I'm misunderstanding.
--94eb2c1a1b3eadbae70549ccf283-- From nobody Fri Mar 3 02:19:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF171294D0 for ; Fri, 3 Mar 2017 02:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR4mvscMzm-R for ; Fri, 3 Mar 2017 02:19:21 -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 CDA0E12942F for ; Fri, 3 Mar 2017 02:19:20 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id p77so77091737ywg.1 for ; Fri, 03 Mar 2017 02:19:20 -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=bxHle8z+gQL18BXCaKe6n9KAVdU5MqCo6bTeJPaBLjM=; b=mWupt4SDtD5IVIkcO6dW2ZcxcUQRRsw+R8oZZqVYlc8y29fcw6ERjqJ/ZxI2qirS78 xhKMkePfsMm8wQJhfCqX8lfIi3Q4sR42HG9ZoVJtWou1ZwWmUpEz48YuHxSFDoEmVRv/ 3aaTdbIl0c2ye6EHFOJJnkr/KwN8tymZqC8VJURXN4hrGoAgLpmn2JzEbUptA5WCq6Q/ QkVfu2P5YtL5MgRh3TrHsuemqT2AuDCpuX52pG4fr6YBxux6tSdLzdAM1SCB2Ovr3qcH RxafdM7vW8QJav01EJ+s6L5B3HnjRTt3PwLx2/pTQHX8gSrPTDcv8wVvETSCA8Q2Gn65 av7Q== 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=bxHle8z+gQL18BXCaKe6n9KAVdU5MqCo6bTeJPaBLjM=; b=GdUuq0ODSbW1ELfGMRXG98Y56pHU8cTQP4FFGXxWYqAKO7jIvezLLNHzHcYSJ+qC6O OkjA9aAELoRiTkZ29BwA2VDO2+2gRjOJRel6ulx8Z4G1URArL9NxJMHigPVq0nGHi3d0 tltwBpqRCxw04oabJ5F+FvvIziKwoc+J4BbvyUGVEsyxAzsxE/7T3FItZ0+fXuNfiO4e pXGnwlUtdKortJPWn95tFjp4uHhljCC0VtqSVvJVmgwVqQMTdRSGPRRVhQJNJ9ADMFLN yTjz0bp4tGJCufzJLwqP3PZSqA5iH1j+Q4U6qVCAEyrQ3uxSOivpYC7ZiDTR+0rZzI8z jXAw== X-Gm-Message-State: AMke39lyHd77izclm/Hj2mlrEtT9qHTe2DQWkTw9ycbQKo6ouBXVNEA9vPBhccdGE7XNRYmgLFiuJNlYsHrMWGJX X-Received: by 10.37.20.68 with SMTP id 65mr1176769ybu.0.1488536359741; Fri, 03 Mar 2017 02:19:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.76.65 with HTTP; Fri, 3 Mar 2017 02:19:19 -0800 (PST) In-Reply-To: References: From: Al Cutter Date: Fri, 3 Mar 2017 10:19:19 +0000 Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=001a113e9242f58cfc0549d0e032 Archived-At: Cc: Richard Barnes , Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:19:22 -0000 --001a113e9242f58cfc0549d0e032 Content-Type: text/plain; charset=UTF-8 I thought I'd throw a few things into the discussion... So, I think what Richard, Nick and Zakir have reinvented, is more or less the original plan for how CT was going to work; chains would be submitted, and the caller would be told either a) here's your inclusion proof+STH, or b) come back and try again in a bit. At that time, CAs were understandably wary of blocking their issuance on processes with an unbounded (or at least slightly hand-wavy) deadline. Enter SCTs, which we we all know and, um, love. (You all probably knew that already, and if you've been following or involved with CT for a while also probably know a lot of the trade-offs that we made in our Google log implementation, mostly swapping speed and comfort for quite paranoid levels of redundancy.) As I said during the talk Pierre and I gave at the start of the CT policy days about running logs at scale, personally, I really like the idea of serving proofs directly (I think I said something along the lines of it holding a special place in my heart) and I suspect that's at least in part what's triggered this to resurface. To detour for a moment, Richard's right in that you certainly can update Merkle trees in real time, and very quickly - in fact, if you forgo the full-fat Merkle tree and use what we term a "compact" merkle tree (see github [1] for details - I believe this is what Richard describes as his "frontier" tree), then you can update it at many hundreds of thousands of qps, when you start trying to actually store and sign things it slows down a fair bit, but depending on storage layer/layout/and whatnots you could still reasonably expect to be able to do many thousands per second. Obviously as you crank the hypothetical lever away from "low reliability" (perhaps not really useful* in the current CT system, but impressively fast) over to "reliable and globally consistent" things slow down further, but our recent experiences with Trillian suggest that you can still do this sort of thing at multiple hundreds to a couple of thousand qps if you're willing to batch a bit (Trillian has levers too, in particular to trade off between throughput, scale, and low integration latency, but we need to do more testing to better understand the full implications.) Back to the policy day; the next thing I said after sharing my wistful dreams, was that I felt that in order for anything like those dreams to become reality there would need to be changes in the ecosystem, the ones I called out in particular were that we'd need to have many logs, and that they'd need to be open. The reason for this, which I think I didn't go into any detail about and Ryan has touched on above, is because cold hard operational reality has a habit of crashing through the door whenever there's something I'd like to have - things like machines failing, software updates (even rolling ones), bugs, master elections, network partitions, and Stuff, all mean that you will not *always* be able to have your throughput, and there *will* be stretches of time you are completely unable to update your tree (I'm assuming the local/global level is pulled over towards the global side here). If the ecosystem has sufficient open logs and CAs were all attempting to log in parallel to sufficiently large subset of those, they maybe that's fine and it turns out to be overwhelmingly likely that there are enough logs not having a bad day for the world to roll on. I think none of this dream world is in conflict with the current state of -bis, other than possibly that requirement to limit STH issuance to one per hour. I understand why it got put in, but I do wonder if it really belongs in the Gossip doc rather than -bis where it's potentially discouraging This Sort of Thing. Anyway, I just thought I'd chip in with some colour. [1] https://github.com/google/certificate-transparency/blob/master/cpp/merkletree/compact_merkle_tree.h On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi wrote: > > > On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes wrote: > >> On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi wrote: >> >>> >>> >>> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: >>>> >>>> In any case, we should stop thinking that log delay and the MMD are >>>> essential properties of this system. >>>> >>> >>> I'm confused by this conclusion, and apologies if I've misunderstood. >>> >>> Can you explain how this statement differs, from say a discussion about >>> keeping a database in RAM and never flushing to disk? You can have amazing >>> QPS - but terrible reliability. It sounds like you're describing that >>> you've built an unreliable, but efficient, system, and are using that as >>> proof that reliability is not a critical property? >>> >> >> That's part of why I used Spanner as one of our test points. At least >> according to Al at the CT policy days, that's what his team is using as >> storage for their logs. So presumably it's suitably reliable? >> >> I'm definitely willing to admit there's a trade-off here. My point is >> just that the reliability requirements are not inconsistent with a >> sufficiently high transaction rate to serve existing needs. >> > > Again, I'm confused as to how you reach that conclusion, so apologies if > I'm just dense here. > > You've compared an extremely reliable, globally consistent storage system > and established one bound (10qps) for your idea. You've then compared an > extremely unreliable, globally inconsistent storage system and established > another bound (60qps-200qps) > > I'm not sure why you've introduced the unreliable system - which has SPOF > written all over it - or how it relates to this proposal. Are you > suggesting that reliability is no longer necessary? > > Assuming reliability is necessary, and we accept 10qps for 'extremely > high' reliability, and 60qps for 'extremely low reliability', doesn't your > solution only provide value iff the growth rate of the ecosystem is > somewhere within these bounds? Are you asserting that "10-60 qps should be > enough for everyone"? > > I guess what I'm trying to figure out is what the consequence of this > experiment is - are you proposing change? Because aren't those bounds only > relevant to the specific experiment you did, which is related to your > proposed solution for STH-on-every-cert? > > I apologize if I'm simply dense from what this implementation feedback is > related to, or understanding the objective of this experiment. You suggest > it may be feasible, but I see those numbers and reach the opposite > conclusion, so I'm trying to understand where I'm misunderstanding. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a113e9242f58cfc0549d0e032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought I'd throw a few things into the discussion..= .=C2=A0

So, I think what Richard, Nick and Zakir have re= invented, is more or less the original plan for how CT was going to work; c= hains would be submitted, and the caller would be told either a) here's= your inclusion proof+STH, or b) come back and try again in a bit.
At that time, CAs were understandably wary of blocking their issuance on = processes with an unbounded (or at least slightly hand-wavy) deadline.=C2= =A0 Enter SCTs, which we we all know and, um, love.
(You all prob= ably knew that already, and if you've been following or involved with C= T for a while also probably know a lot of the trade-offs that we made in ou= r Google log implementation, mostly swapping speed and comfort for quite pa= ranoid levels of redundancy.)

As I said during the= talk Pierre and I gave at the start of the CT policy days about running lo= gs at scale, personally, I really like the idea of serving proofs directly = (I think I said something along the lines of it holding a special place in = my heart) and I suspect that's at least in part what's triggered th= is to resurface.

To detour for a moment, Richard&#= 39;s right in that you certainly can update Merkle trees in real time, and = very quickly - in fact, if you forgo the full-fat Merkle tree and use what = we term a "compact" merkle tree (see github [1] for details - I b= elieve this is what Richard describes as his "frontier" tree), th= en you can update it at many hundreds of thousands of qps, when you start t= rying to actually store and sign things it slows down a fair bit, but depen= ding on storage layer/layout/and whatnots you could still reasonably expect= to be able to do many thousands per second.=C2=A0 Obviously as you crank t= he hypothetical lever away from "low reliability" (perhaps not re= ally useful* in the current CT system, but impressively fast) over to "= ;reliable and globally consistent" things slow down further, but our r= ecent experiences with Trillian suggest that you can still do this sort of = thing at multiple hundreds to a couple of thousand qps if you're willin= g to batch a bit (Trillian has levers too, in particular to trade off betwe= en throughput, scale, and low integration latency, but we need to do more t= esting to better understand the full implications.)
=C2=A0
<= div>Back to the policy day; the next thing I said after sharing my wistful = dreams, was that I felt that in order for anything like those dreams to bec= ome reality there would need to be changes in the ecosystem, the ones I cal= led out in particular were that we'd need to have many logs, and that t= hey'd need to be open.=C2=A0 The reason for this, which I think I didn&= #39;t go into any detail about and Ryan has touched on above, is because co= ld hard operational reality has a habit of crashing through the door whenev= er there's something I'd like to have - things like machines failin= g, software updates (even rolling ones), bugs, master elections, network pa= rtitions, and Stuff, all mean that you will not *always* be able to have yo= ur throughput, and there *will* be stretches of time you are completely una= ble to update your tree (I'm assuming the local/global level is pulled = over towards the global side here). If the ecosystem has sufficient open lo= gs and CAs were all attempting to log in parallel to sufficiently large sub= set of those, they maybe that's fine and it turns out to be overwhelmin= gly likely that there are enough logs not having a bad day for the world to= roll on.=C2=A0

I think none of this dream world i= s in conflict with the current state of -bis, other than possibly that requ= irement to limit STH issuance to one per hour. I understand why it got put = in, but I do wonder if it really belongs in the Gossip doc rather than -bis= where it's potentially discouraging This Sort of Thing.

=
Anyway, I just thought I'd chip in with some colour.



=
On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes <rlb@ipv.s= x> wrote:
=
On Thu, Mar 2, 2017 at 8:04 PM,= Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On Thu, Ma= r 2, 2017 at 3:58 PM, Richard Barnes <rlb@ipv.sx> wrote:
In any case, = we should stop thinking that log delay and the MMD are essential properties= of this system.

=
I'm confused by this conclusion= , and apologies if I've misunderstood.
=
Can you explain how this statement dif= fers, from say a discussion about keeping a database in RAM and never flush= ing to disk? You can have amazing QPS - but terrible reliability. It sounds= like you're describing that you've built an unreliable, but effici= ent, system, and are using that as proof that reliability is not a critical= property?

That'= ;s part of why I used Spanner as one of our test points.=C2=A0 At least acc= ording to Al at the CT policy days, that's what his team is using as st= orage for their logs.=C2=A0 So presumably it's suitably reliable?
<= /div>

I'm definitely willing = to admit there's a trade-off here.=C2=A0 My point is just that the reli= ability requirements are not inconsistent with a sufficiently high transact= ion rate to serve existing needs.

Again, I'm confused as to how you reach that conclusion, so a= pologies if I'm just dense here.

You've co= mpared an extremely reliable, globally consistent storage system and establ= ished one bound (10qps) for your idea. You've then compared an extremel= y unreliable, globally inconsistent storage system and established another = bound (60qps-200qps)

I'm not sure why you'= ve introduced the unreliable system - which has SPOF written all over it - = or how it relates to this proposal. Are you suggesting that reliability is = no longer necessary?

Assuming reliability is neces= sary, and we accept 10qps for 'extremely high' reliability, and 60q= ps for 'extremely low reliability', doesn't your solution only = provide value iff the growth rate of the ecosystem is somewhere within thes= e bounds? Are you asserting that "10-60 qps should be enough for every= one"?

I guess what I'm trying to figure o= ut is what the consequence of this experiment is - are you proposing change= ? Because aren't those bounds only relevant to the specific experiment = you did, which is related to your proposed solution for STH-on-every-cert?<= /div>

I apologize if I'm simply dense from what this= implementation feedback is related to, or understanding the objective of t= his experiment. You suggest it may be feasible, but I see those numbers and= reach the opposite conclusion, so I'm trying to understand where I'= ;m misunderstanding.

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


--001a113e9242f58cfc0549d0e032-- From nobody Fri Mar 3 07: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 3FF711294F3 for ; Fri, 3 Mar 2017 07:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9Xb9em43Elc for ; Fri, 3 Mar 2017 07:23:17 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 BEBBB129577 for ; Fri, 3 Mar 2017 07:23:16 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id l37so75957158wrc.1 for ; Fri, 03 Mar 2017 07:23:16 -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=+ZpQG0r5DKTjBqvPe/8B3DaQFxa3WACkkpsCYCxMSyM=; b=LYHYsNDFNafoCGrOl61ipVy3lTZmwl2RopeFak53Dhptlf4fR3zRNs3/yV3a2PdDs1 YxhSQKzb6/IsKvcO+umARkKIGQ3qCULsUcaRXARI5u2I2CTkTUJjvkrs8bfEtbwMWC8m QUugpWNLdQqlRefvAb9T3LA5By3lgcHJXcSgQ+a8Y8s8hMRVhdJMiiuIACh4sog73CRG mJ16qdOdERiRHQhkunrUMveQKICuXFceGP5of/ixD2rW5R/2D9mFRMH0ILZlGYnaq3l+ fAto+f3uwkAMN0ezpLELCbxjqoJ14N4vcMDa1tymTU6AMNx1rQ5JxixtVGp5W9XXo0v3 cksA== 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=+ZpQG0r5DKTjBqvPe/8B3DaQFxa3WACkkpsCYCxMSyM=; b=RaDBfYFXWZX+HuuL9DZaEV2/PoRifYCuIHlbZCKaVZYyWsZjgdIgTSf4ess4CsgDHy zpJP6XcRmNnUrLTl5R6m3LrT11I9wZMwS6dqJBL8S5Dp5mN/+i8V//a1GKc/oPEaabTK oih31gxxN0bRA2YAlck46RNu7CViA0tAmkpWLfX5oNr1aY2vn5RD5x+QV26YNpTLK7zw 7bu2kSaVBoKfT5+bmmLKrndf5IP+Dicdf0JgGwu/MKqVFfdS2zuvw63GNaPDQUYgC32z /N6em8X+yAqm4gKToMqqy/LjGy3Hofrd5uLBsjSXLhyO3yjK008Ysm+orWtjgz8N1/mU XKAQ== X-Gm-Message-State: AMke39nlPh2c2hTCshw1T+tAB3/zUnS5YmbVjjjf0UAfxWly7GSZkkSY4KBmSTmL7N9kq/tO8VBX57dQ1HEytQ== X-Received: by 10.223.162.130 with SMTP id s2mr2306294wra.149.1488554594799; Fri, 03 Mar 2017 07:23:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Fri, 3 Mar 2017 07:23:14 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Fri, 3 Mar 2017 10:23:14 -0500 Message-ID: To: Al Cutter Content-Type: multipart/alternative; boundary=f403045ea688da319a0549d51f0b Archived-At: Cc: Ryan Sleevi , Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:23:20 -0000 --f403045ea688da319a0549d51f0b Content-Type: text/plain; charset=UTF-8 Hey Al, Thanks for chipping in. I'm not surprised to hear that this stuff is not novel :) Since I've got you here, here's one thing I'm confused about: Why don't you have the same reliability problems with SCTs? Before you issue the SCT, you've got to be really sure that you've got that cert and it's going to make it into the log. The only difference we're talking about here is that in addition to that append operation, you also have a read operation. Either way, you have a stack of things you're appending to, either a stack of just certs or a stack of (cert, frontier) pairs. In the SCT case, you have to reliably push a cert onto the stack. In the no-MMD case, you have to peek at the top of the stack to get the last frontier, then push the new (cert, frontier) pair. That does extend the scope of the transaction a bit, but it certainly doesn't seem like it should take you from "effectively instantaneous" to "we'll get back to you tomorrow". Am I misunderstanding how reliability works for SCTs? If you have a reliability problem with updating the tree in this way, don't you already have a reliability problem with SCTs? --Richard On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter wrote: > I thought I'd throw a few things into the discussion... > > So, I think what Richard, Nick and Zakir have reinvented, is more or less > the original plan for how CT was going to work; chains would be submitted, > and the caller would be told either a) here's your inclusion proof+STH, or > b) come back and try again in a bit. > At that time, CAs were understandably wary of blocking their issuance on > processes with an unbounded (or at least slightly hand-wavy) deadline. > Enter SCTs, which we we all know and, um, love. > (You all probably knew that already, and if you've been following or > involved with CT for a while also probably know a lot of the trade-offs > that we made in our Google log implementation, mostly swapping speed and > comfort for quite paranoid levels of redundancy.) > > As I said during the talk Pierre and I gave at the start of the CT policy > days about running logs at scale, personally, I really like the idea of > serving proofs directly (I think I said something along the lines of it > holding a special place in my heart) and I suspect that's at least in part > what's triggered this to resurface. > > To detour for a moment, Richard's right in that you certainly can update > Merkle trees in real time, and very quickly - in fact, if you forgo the > full-fat Merkle tree and use what we term a "compact" merkle tree (see > github [1] for details - I believe this is what Richard describes as his > "frontier" tree), then you can update it at many hundreds of thousands of > qps, when you start trying to actually store and sign things it slows down > a fair bit, but depending on storage layer/layout/and whatnots you could > still reasonably expect to be able to do many thousands per second. > Obviously as you crank the hypothetical lever away from "low reliability" > (perhaps not really useful* in the current CT system, but impressively > fast) over to "reliable and globally consistent" things slow down further, > but our recent experiences with Trillian suggest that you can still do this > sort of thing at multiple hundreds to a couple of thousand qps if you're > willing to batch a bit (Trillian has levers too, in particular to trade off > between throughput, scale, and low integration latency, but we need to do > more testing to better understand the full implications.) > > Back to the policy day; the next thing I said after sharing my wistful > dreams, was that I felt that in order for anything like those dreams to > become reality there would need to be changes in the ecosystem, the ones I > called out in particular were that we'd need to have many logs, and that > they'd need to be open. The reason for this, which I think I didn't go > into any detail about and Ryan has touched on above, is because cold hard > operational reality has a habit of crashing through the door whenever > there's something I'd like to have - things like machines failing, software > updates (even rolling ones), bugs, master elections, network partitions, > and Stuff, all mean that you will not *always* be able to have your > throughput, and there *will* be stretches of time you are completely unable > to update your tree (I'm assuming the local/global level is pulled over > towards the global side here). If the ecosystem has sufficient open logs > and CAs were all attempting to log in parallel to sufficiently large subset > of those, they maybe that's fine and it turns out to be overwhelmingly > likely that there are enough logs not having a bad day for the world to > roll on. > > I think none of this dream world is in conflict with the current state of > -bis, other than possibly that requirement to limit STH issuance to one per > hour. I understand why it got put in, but I do wonder if it really belongs > in the Gossip doc rather than -bis where it's potentially discouraging This > Sort of Thing. > > Anyway, I just thought I'd chip in with some colour. > > > [1] https://github.com/google/certificate-transparency/blob/ > master/cpp/merkletree/compact_merkle_tree.h > > On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi wrote: > >> >> >> On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes wrote: >> >>> On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi >>> wrote: >>> >>>> >>>> >>>> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: >>>>> >>>>> In any case, we should stop thinking that log delay and the MMD are >>>>> essential properties of this system. >>>>> >>>> >>>> I'm confused by this conclusion, and apologies if I've misunderstood. >>>> >>>> Can you explain how this statement differs, from say a discussion about >>>> keeping a database in RAM and never flushing to disk? You can have amazing >>>> QPS - but terrible reliability. It sounds like you're describing that >>>> you've built an unreliable, but efficient, system, and are using that as >>>> proof that reliability is not a critical property? >>>> >>> >>> That's part of why I used Spanner as one of our test points. At least >>> according to Al at the CT policy days, that's what his team is using as >>> storage for their logs. So presumably it's suitably reliable? >>> >>> I'm definitely willing to admit there's a trade-off here. My point is >>> just that the reliability requirements are not inconsistent with a >>> sufficiently high transaction rate to serve existing needs. >>> >> >> Again, I'm confused as to how you reach that conclusion, so apologies if >> I'm just dense here. >> >> You've compared an extremely reliable, globally consistent storage system >> and established one bound (10qps) for your idea. You've then compared an >> extremely unreliable, globally inconsistent storage system and established >> another bound (60qps-200qps) >> >> I'm not sure why you've introduced the unreliable system - which has SPOF >> written all over it - or how it relates to this proposal. Are you >> suggesting that reliability is no longer necessary? >> >> Assuming reliability is necessary, and we accept 10qps for 'extremely >> high' reliability, and 60qps for 'extremely low reliability', doesn't your >> solution only provide value iff the growth rate of the ecosystem is >> somewhere within these bounds? Are you asserting that "10-60 qps should be >> enough for everyone"? >> >> I guess what I'm trying to figure out is what the consequence of this >> experiment is - are you proposing change? Because aren't those bounds only >> relevant to the specific experiment you did, which is related to your >> proposed solution for STH-on-every-cert? >> >> I apologize if I'm simply dense from what this implementation feedback is >> related to, or understanding the objective of this experiment. You suggest >> it may be feasible, but I see those numbers and reach the opposite >> conclusion, so I'm trying to understand where I'm misunderstanding. >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --f403045ea688da319a0549d51f0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Al,

Thanks for chipping in.=C2= =A0 I'm not surprised to hear that this stuff is not novel :)
=

Since I've got you here, here's one thing I'= ;m confused about: Why don't you have the same reliability problems wit= h SCTs?=C2=A0 Before you issue the SCT, you've got to be really sure th= at you've got that cert and it's going to make it into the log.
=
The only difference we're talking about here is that in addition to= that append operation, you also have a read operation.=C2=A0 Either way, y= ou have a stack of things you're appending to, either a stack of just c= erts or a stack of (cert, frontier) pairs.=C2=A0 In the SCT case, you have = to reliably push a cert onto the stack.=C2=A0 In the no-MMD case, you have = to peek at the top of the stack to get the last frontier, then push the new= (cert, frontier) pair.=C2=A0 That does extend the scope of the transaction= a bit, but it certainly doesn't seem like it should take you from &quo= t;effectively instantaneous" to "we'll get back to you tomorr= ow".

Am I misunderstanding how reliability works for= SCTs?=C2=A0 If you have a reliability problem with updating the tree in th= is way, don't you already have a reliability problem with SCTs?

--Richard


On Fri, Mar 3, 2017 at 5:19 AM= , Al Cutter <al@google.com> wrote:
I thought I'd throw a few things into the discu= ssion...=C2=A0

So, I think what Richard, Nick and Zakir = have reinvented, is more or less the original plan for how CT was going to = work; chains would be submitted, and the caller would be told either a) her= e's your inclusion proof+STH, or b) come back and try again in a bit.
At that time, CAs were understandably wary of blocking their issua= nce on processes with an unbounded (or at least slightly hand-wavy) deadlin= e.=C2=A0 Enter SCTs, which we we all know and, um, love.
(You all= probably knew that already, and if you've been following or involved w= ith CT for a while also probably know a lot of the trade-offs that we made = in our Google log implementation, mostly swapping speed and comfort for qui= te paranoid levels of redundancy.)

As I said durin= g the talk Pierre and I gave at the start of the CT policy days about runni= ng logs at scale, personally, I really like the idea of serving proofs dire= ctly (I think I said something along the lines of it holding a special plac= e in my heart) and I suspect that's at least in part what's trigger= ed this to resurface.

To detour for a moment, Rich= ard's right in that you certainly can update Merkle trees in real time,= and very quickly - in fact, if you forgo the full-fat Merkle tree and use = what we term a "compact" merkle tree (see github [1] for details = - I believe this is what Richard describes as his "frontier" tree= ), then you can update it at many hundreds of thousands of qps, when you st= art trying to actually store and sign things it slows down a fair bit, but = depending on storage layer/layout/and whatnots you could still reasonably e= xpect to be able to do many thousands per second.=C2=A0 Obviously as you cr= ank the hypothetical lever away from "low reliability" (perhaps n= ot really useful* in the current CT system, but impressively fast) over to = "reliable and globally consistent" things slow down further, but = our recent experiences with Trillian suggest that you can still do this sor= t of thing at multiple hundreds to a couple of thousand qps if you're w= illing to batch a bit (Trillian has levers too, in particular to trade off = between throughput, scale, and low integration latency, but we need to do m= ore testing to better understand the full implications.)
=C2=A0
Back to the policy day; the next thing I said after sharing my wis= tful dreams, was that I felt that in order for anything like those dreams t= o become reality there would need to be changes in the ecosystem, the ones = I called out in particular were that we'd need to have many logs, and t= hat they'd need to be open.=C2=A0 The reason for this, which I think I = didn't go into any detail about and Ryan has touched on above, is becau= se cold hard operational reality has a habit of crashing through the door w= henever there's something I'd like to have - things like machines f= ailing, software updates (even rolling ones), bugs, master elections, netwo= rk partitions, and Stuff, all mean that you will not *always* be able to ha= ve your throughput, and there *will* be stretches of time you are completel= y unable to update your tree (I'm assuming the local/global level is pu= lled over towards the global side here). If the ecosystem has sufficient op= en logs and CAs were all attempting to log in parallel to sufficiently larg= e subset of those, they maybe that's fine and it turns out to be overwh= elmingly likely that there are enough logs not having a bad day for the wor= ld to roll on.=C2=A0

I think none of this dream wo= rld is in conflict with the current state of -bis, other than possibly that= requirement to limit STH issuance to one per hour. I understand why it got= put in, but I do wonder if it really belongs in the Gossip doc rather than= -bis where it's potentially discouraging This Sort of Thing.

Anyway, I just thought I'd chip in with some colour.



On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi = <ryan-ietf@sle= evi.com> wrote:

On Thu, Mar 2, 2017 at 5:38 PM, Richard B= arnes <rlb@ipv.sx> wrote:
= On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi <ryan-ietf@sleevi.com= > wrote:


On Thu, Mar 2, 2017 at 3:58 PM,= Richard Barnes <rlb@ipv.sx> wrote:
=
In any case, we should stop think= ing that log delay and the MMD are essential properties of this system.

I'm confused by this conclusion, and apologies if I= 've misunderstood.

Can you explain how this statement differs, from say a dis= cussion about keeping a database in RAM and never flushing to disk? You can= have amazing QPS - but terrible reliability. It sounds like you're des= cribing that you've built an unreliable, but efficient, system, and are= using that as proof that reliability is not a critical property?

That's part of why I use= d Spanner as one of our test points.=C2=A0 At least according to Al at the = CT policy days, that's what his team is using as storage for their logs= .=C2=A0 So presumably it's suitably reliable?

I'm definitely willing to admit there's= a trade-off here.=C2=A0 My point is just that the reliability requirements= are not inconsistent with a sufficiently high transaction rate to serve ex= isting needs.

Again, I&#= 39;m confused as to how you reach that conclusion, so apologies if I'm = just dense here.

You've compared an extremely = reliable, globally consistent storage system and established one bound (10q= ps) for your idea. You've then compared an extremely unreliable, global= ly inconsistent storage system and established another bound (60qps-200qps)=

I'm not sure why you've introduced the un= reliable system - which has SPOF written all over it - or how it relates to= this proposal. Are you suggesting that reliability is no longer necessary?=

Assuming reliability is necessary, and we accept = 10qps for 'extremely high' reliability, and 60qps for 'extremel= y low reliability', doesn't your solution only provide value iff th= e growth rate of the ecosystem is somewhere within these bounds? Are you as= serting that "10-60 qps should be enough for everyone"?

I guess what I'm trying to figure out is what the conse= quence of this experiment is - are you proposing change? Because aren't= those bounds only relevant to the specific experiment you did, which is re= lated to your proposed solution for STH-on-every-cert?

=
I apologize if I'm simply dense from what this implementation feed= back is related to, or understanding the objective of this experiment. You = suggest it may be feasible, but I see those numbers and reach the opposite = conclusion, so I'm trying to understand where I'm misunderstanding.=

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



--f403045ea688da319a0549d51f0b-- From nobody Fri Mar 3 07:40:34 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EB51294CC for ; Fri, 3 Mar 2017 07:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 mcQTgkxKthAy for ; Fri, 3 Mar 2017 07:40:32 -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 8453612949F for ; Fri, 3 Mar 2017 07:40:32 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vZYKn6PH2z3BT; Fri, 3 Mar 2017 16:40:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488555630; bh=oiwUWBrUW97yT1axz0yENQFDhCp/aFaKK33Stjy6pUY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BcFlArYopH5DTLpV225JKhisv5I+2e6kV3IX/Jvzse6skEdqbzmTq1UZYCf+lgZua izOHOS5+Jpo58D7PuCdKYyZRvJnnuK8AARCbNdUP+42whiSFrNkapM+wa73YJwHynM 9lmJVLY3jn37WMkasBIFXeOR6Xs3JHLnKoVrp1AI= 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 CmHaTC4PZLDQ; Fri, 3 Mar 2017 16:40:28 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Mar 2017 16:40:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C03A63F2852; Fri, 3 Mar 2017 10:40:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C03A63F2852 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD1CB420AC94; Fri, 3 Mar 2017 10:40:26 -0500 (EST) Date: Fri, 3 Mar 2017 10:40:26 -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=US-ASCII; format=flowed Archived-At: Cc: Zakir Durumeric , Nick Sullivan , Trans Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:40:34 -0000 On Thu, 2 Mar 2017, Richard Barnes wrote: Richard, > This might not be quite the right list for this, but since I'm not aware of a "ct-implementors" list, I thought > I'd go ahead and post it. > > tl;dr: Logging with live updates to the Merkle tree can be done at rates of at least 10-150qps. Thanks for the update. Am I right that this resolves your concerns about 6962bis, and that you no longer think the specification needs changing to support the expected load for the deployment you have in mind? I'm trying to determine if we are now ready to send the document to the IESG. Paul From nobody Fri Mar 3 07:59: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 BCCAE1294E1 for ; Fri, 3 Mar 2017 07:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrI7AhHfXJgv for ; Fri, 3 Mar 2017 07:59:10 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 9EA881294CC for ; Fri, 3 Mar 2017 07:59:09 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id v186so18711217wmd.0 for ; Fri, 03 Mar 2017 07:59:09 -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=nyGDP7Adf+d5lZV70koyH5/ZB85IPdfMFAihu2jzNB8=; b=ct3W4PMd0znNCcA+oW25xxNGy8uivA/CE/8zcTQXHhmjw3x1vPraGHpA6g3O5Uf/LZ xq8YMBjcChMKr8T9rNfY/31NDw/jM2BwUbMQKVICkYQO1hES2df0gemLGsQkZrFQPTIV fECxJ7OsPZx/bFj+oAK3fef3QpfNHWJkJLo6rmbc7caFPGHAu3ce6buaeZr4O+68cQ+g KXQJmJYKW1bPAWOm0C4Y5Ohn00bqJuSTC743C8epUk9HdmJRhFaCxVi3aKwtvBrr73AH cFnnbHX5GNXN43ISahFOqxONst2yMz2VXQ5nd+xXeknOL2GGdR+UMSMCa2onSBsCjHHH +klw== 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=nyGDP7Adf+d5lZV70koyH5/ZB85IPdfMFAihu2jzNB8=; b=PNsQCObO3vVHUs6y2I+qDDHCOoZPOLS8DBRUFiVE5MogkL9Rqbbzw4gjBkkEdBQWZo SvFFgMWzqHntz/8dJ2T/McVpOln0hEUR1L2ksnp/ai1i6qhdpztalIESJpd38b3mOnsL K0cnlv/vn23lORZZ8phTMAumbA1dKQXC3355bJgkxDZb6xccB/LF7l5V47i4o1PbuRtL vBtDkmehkK/12I7tPTjR3LBinLQrGS7vVO6D5Y/KOpB8eM6wqgVhqhsVolS/YUPjOAiq gMK2Vbh3c4eo9TB6AVn6Tx1eKDmUwi5HGCgokEfNSrX1b2oDOuTjiW0OkPF5SzpJ/uLm tTwA== X-Gm-Message-State: AMke39l4U6MZyCB2Lg7zXhMLNhmm7UomnI69S2CtEsNkiH1j1vzHiQPZ+0LtTjkeeeyMTY/CW5f7komP83V/RQ== X-Received: by 10.28.156.69 with SMTP id f66mr21297wme.56.1488556747785; Fri, 03 Mar 2017 07:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Fri, 3 Mar 2017 07:59:07 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Fri, 3 Mar 2017 10:59:07 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a114b7e2a2e20b00549d5a0cd Archived-At: Cc: Zakir Durumeric , Nick Sullivan , Trans Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:59:10 -0000 --001a114b7e2a2e20b00549d5a0cd Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 10:40 AM, Paul Wouters wrote: > On Thu, 2 Mar 2017, Richard Barnes wrote: > > Richard, > > This might not be quite the right list for this, but since I'm not aware >> of a "ct-implementors" list, I thought >> I'd go ahead and post it. >> >> tl;dr: Logging with live updates to the Merkle tree can be done at rates >> of at least 10-150qps. >> > > Thanks for the update. Am I right that this resolves your concerns about > 6962bis, and that you no longer think the specification needs changing > to support the expected load for the deployment you have in mind? > > I'm trying to determine if we are now ready to send the document to the > IESG. > Short answer: No. Longer answer: After a late-night pizza / scotch / whiteboard session with Eran and a few others last week, I have some more focused asks. I'll try to get them written up this afternoon. --Richard --001a114b7e2a2e20b00549d5a0cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 10:40 AM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 2 Mar 2017, Richard Ba= rnes wrote:

Richard,

This might not be quite the right list for this, but since I'm not awar= e of a "ct-implementors" list, I thought
I'd go ahead and post it.

tl;dr: Logging with live updates to the Merkle tree can be done at rates of= at least 10-150qps.

 Thanks for the update. Am I right that this resolves your concerns about 6962bis, and that you no longer think the specification needs changing
to support the expected load for the deployment you have in mind?

I'm trying to determine if we are now ready to send the document to the= IESG.

Short answer: No.

Longer ans= wer: After a late-night pizza / scotch / whiteboard session with Eran and a= few others last week, I have some more focused asks.=C2=A0 I'll try to= get them written up this afternoon.

--Richard
<= div>
--001a114b7e2a2e20b00549d5a0cd-- From nobody Fri Mar 3 08: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 67C601294D6 for ; Fri, 3 Mar 2017 08:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=pobox.com header.b=TLRS8LAf; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=BTU8hz12 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 veJNB_j0agWp for ; Fri, 3 Mar 2017 08:13:41 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F031129495 for ; Fri, 3 Mar 2017 08:13:41 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id D07995F6AA for ; Fri, 3 Mar 2017 11:13:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=dLFhIgzKxIcq72U5ASUEDLVyTn4=; b=TLRS8L Af78AWpsf+Bp5gDdR36ihGB4VA2JUL+/dHF7ux0OHvmQub+wSoFQqgs51Iu79bNr xtnVjeroKsTrO9heF00ck1uEL3eOM518QHpm/TrBSI5W9SruFTpYk9Rot21BVlaB rmACgjz/uLsI1ZOWfOGZGa4ZmOSK10NvlGwYE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C9A0A5F6A8 for ; Fri, 3 Mar 2017 11:13:37 -0500 (EST) Received: from mail-yw0-f172.google.com (unknown [209.85.161.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 537115F6A4 for ; Fri, 3 Mar 2017 11:13:37 -0500 (EST) Received: by mail-yw0-f172.google.com with SMTP id o4so21862374ywd.3 for ; Fri, 03 Mar 2017 08:13:37 -0800 (PST) X-Gm-Message-State: AMke39li0A3chGe4MakCK9A4e18h3foPK4W29DpMzUlPo79LteXuPugwBtBRi3PwP021oedFS9FNtjoa1TwWEw== X-Received: by 10.129.70.197 with SMTP id t188mr2309707ywa.112.1488557616727; Fri, 03 Mar 2017 08:13:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.119.14 with HTTP; Fri, 3 Mar 2017 08:12:56 -0800 (PST) In-Reply-To: References: From: Eric Mill Date: Fri, 3 Mar 2017 11:12:56 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Al Cutter Content-Type: multipart/alternative; boundary=001a114d70eef92c350549d5d374 X-Pobox-Relay-ID: 5B9ADEC0-002C-11E7-AA42-97B1B46B9B0B-82875391!pb-smtp1.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=dLFhIgzKxIcq72U5ASUEDLVyTn4=; b=BTU8hz124E3goWYmmk8HfsBHMvFVr1cEroyaEgkGT4/DOcViGubhNESHziimMHm3RyeR3jvpigvjZRnZB7g0QtcTGKomUT88g4MMPH8ttA2ooj5BLnlnniAUy4s33QuSJTwNIexY4R9lYcCfIMSnbD34Ig+onyN61yECy65fHYU= Archived-At: Cc: Ryan Sleevi , Richard Barnes , Zakir Durumeric , trans@ietf.org, Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:13:42 -0000 --001a114d70eef92c350549d5d374 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter wrote: > I thought I'd throw a few things into the discussion... > > So, I think what Richard, Nick and Zakir have reinvented, is more or less > the original plan for how CT was going to work; chains would be submitted, > and the caller would be told either a) here's your inclusion proof+STH, or > b) come back and try again in a bit. > At that time, CAs were understandably wary of blocking their issuance on > processes with an unbounded (or at least slightly hand-wavy) deadline. > Enter SCTs, which we we all know and, um, love. > (You all probably knew that already, and if you've been following or > involved with CT for a while also probably know a lot of the trade-offs > that we made in our Google log implementation, mostly swapping speed and > comfort for quite paranoid levels of redundancy.) > Is it possible to "let the market decide" whether STHs can be served in a reasonable timeframe so we have a chance to figure this out in practice? For example, what if browsers with a CT policy allowed either SCTs *or* STHs to qualify? Logs could optionally offer endpoints that produce STHs immediately upon logging (in addition to their SCT endpoints), and CAs could see whether logs can produce STHs at levels of latency and reliability acceptable to production use. -- Eric --001a114d70eef92c350549d5d374 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter <al@google.com> wr= ote:
I thought I'd t= hrow a few things into the discussion...=C2=A0

So, I thi= nk what Richard, Nick and Zakir have reinvented, is more or less the origin= al plan for how CT was going to work; chains would be submitted, and the ca= ller would be told either a) here's your inclusion proof+STH, or b) com= e back and try again in a bit.
At that time, CAs were understanda= bly wary of blocking their issuance on processes with an unbounded (or at l= east slightly hand-wavy) deadline.=C2=A0 Enter SCTs, which we we all know a= nd, um, love.
(You all probably knew that already, and if you'= ;ve been following or involved with CT for a while also probably know a lot= of the trade-offs that we made in our Google log implementation, mostly sw= apping speed and comfort for quite paranoid levels of redundancy.)

Is it possible to "let the market = decide" whether STHs can be served in a reasonable timeframe so we hav= e a chance to figure this out in practice? For example, what if browsers wi= th a CT policy allowed either SCTs *or* STHs to qualify?=C2=A0
Logs could optionally offer endpoints that produce STHs immedi= ately upon logging (in addition to their SCT endpoints), and CAs could see = whether logs can produce STHs at levels of latency and reliability acceptab= le to production use.

-- Eric
--001a114d70eef92c350549d5d374-- From nobody Fri Mar 3 08:15: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 58AAD129558 for ; Fri, 3 Mar 2017 08:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wqOGG4Pc5yp for ; Fri, 3 Mar 2017 08:15:29 -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 66CF11294D6 for ; Fri, 3 Mar 2017 08:15:29 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id n11so19165812wma.0 for ; Fri, 03 Mar 2017 08:15:29 -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=ExSoCSL3rXgCvXspSkIUcPCW7cQtWmEw1wXlSJq14b0=; b=yIEDWNA9b3n77Pn8KiewtNtk7J/LyE3oeuugOBaRqyNDNUn/yVMstANM+FUD225ZYw g9tA9lMibcq5+Z3nWrdTuKau8s29y9aIUoKSdyiZal9v4N6lvvLCeEWocq5gCIzwfaCE 1b33SwG54m080vI3MmUx6GANc4qWnm7eL31u/bzm8cRnt9I0Vc/dEYvVTzmCVz9s6vTP c/mT5v2lWa2Mh0q8xzi/9PDa5weUYzc8rk0y0ZhZHrMMJcTjad89Z2qdbPCTzw5ZvSPT 4k53T61UGdFD6pjySZCK9M7UKdHCDEM00od7EgWJIzCiS8hYvS3S+u7iB7vHd0kXYKii chXA== 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=ExSoCSL3rXgCvXspSkIUcPCW7cQtWmEw1wXlSJq14b0=; b=UzhsHVrIIjMP+2VWpd4pOJGlzUT8xk4rHbMeYrYdIiOo5SqazoFjdxeL8xUL+0TLxP OGoI9UumH+IWemMcGyABUNBbL15WPiByv5mAjHOX6jvGUlqvwHzMP/ziavBqNnYw/fDl lsm0qsZ5WBPEyANZ7aU4qF7Z8W0LYUfWCbStNg2JB2i1AS4m+Pk1Ytvxj61ZptFy+oaV 6mRWroa8+TSaJCiIITXHsTYXzphX2hSAZ9Gs0Q9Vywr2tSAkB6yyPeGe1pMtkpdfljRF CU6aUedULxyCoTuMrZ8PmwBIgV6G49c2/VHtgoFbam3ugIbtEXg3t0qQUW0AwYqxKCvy X4Vg== X-Gm-Message-State: AMke39l9VS2xgRIsS31um8iXHXO52k44ly/nc5MuQ4maufLXLBXuhsXR1WISLijTXV+r6dubhxMz87oXYd8CdQ== X-Received: by 10.28.130.139 with SMTP id e133mr3094142wmd.133.1488557727683; Fri, 03 Mar 2017 08:15:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Fri, 3 Mar 2017 08:15:27 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Fri, 3 Mar 2017 11:15:27 -0500 Message-ID: To: Eran Messeri Content-Type: multipart/alternative; boundary=001a114433a69640150549d5da6f Archived-At: Cc: "trans@ietf.org" , "certificate-transparency@googlegroups.com" Subject: Re: [Trans] Public verification of log behaviour - obtaining proofs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:15:31 -0000 --001a114433a69640150549d5da6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 2:31 PM, Eran Messeri wrote: > I=E2=80=99d like to overview a few options for clients to obtain inclusio= n proofs > of log entries (each comprising of the corresponding SCT=E2=80=99s timest= amp + > certificate) in a privacy-preserving manner. > > The naive approach, of contacting the CT log itself (or a proxy), > discloses to the operator of the service the certificates each client (as > defined by IP) observed. > > Option 1: DNS-based protocol [1]. > Clients perform two types of queries, under this protocol: > * Getting the index of an entry. > * Getting an inclusion proof for entry with the given index. > > This protocol preserves the client=E2=80=99s privacy by using the client= =E2=80=99s > recursive resolver to proxy the request (rather than directly connecting = to > a service) - full privacy analysis is at [2]. > > An upside of this protocol is that responses to queries generated under > this protocol are constant and can be cached infinitely - an entry=E2=80= =99s index > will never change, as well as the inclusion proof from a particular index > for a particular tree size. > > This is the approach the CT team and Chrome team at Google are working on > implementing - currently DNS queries are authoritatively resolved by a DN= S > front-end of the CT log mirror operated by Google. The intent is to measu= re > success rates and validate correct operation under most scenarios, then > standardize the protocol. > > Option 2: SSL Proxy for log traffic. > Clients connect to a proxy that will relay the TCP connection to the log > (much like SOCKS5), but perform an SSL handshake with the log. Since the > connection is coming from the proxy, the log will not learn which clients > observed which certificate. As the connection is encrypted, the proxy wil= l > not learn which clients observed which certificates. > > One downside of the protocol is that responses are not cacheable by the > log / proxy (at least not with a naive implementation). It should be note= d > that clients only need to fetch an inclusion proof once per observed > certificate, not once per connection, and that information can be cached = on > the client. > > The other downside, and the reason we didn=E2=80=99t implement this appro= ach at > Google, is that collusion between the proxy operator and the log operator > could easily correlate requests to the proxy with requests to the log and > de-cloak clients. > > Note the underlying assumption of clients having up-to-date Signed Tree > Heads, provided to them by the UA vendor. While the original design calle= d > for clients obtaining STHs themselves, having UA vendors push down STHs > improves the scalability aspect and does not change the threat model (sin= ce > clients already trust the UA vendor). If anything, it serves to guarantee > all clients have the same view of the tree, making it harder for the log = to > present split views. > I find this option much more appealing than the DNS option. With Mozilla hat on, I would probably be willing to support deployment of such a service. It doesn't rely on the DNS to provide privacy properties (something the DNS is not designed for). Note that this solution still allows the log to associate all of a user's queries (at least all on the same TLS connection); it just doesn't give it an IP address to associate to this set. So I would be slightly happier queries were encrypted independently, e.g., using S/MIME or JWE. That will cost an extra X25519 operation per query and some extra engineering effort, but seems probably worth it for the additional privacy. Assuming that logs are going to want to use some sort of caching layer / CDN, that leaves you with kind of a four-level system: Browser --- Proxy --- Cache --- Log ... where the query encryption goes from browser to cache. This is like 2/3 of Tor, but should be a little easier to build :) --Richard > > I=E2=80=99ll post separately about dealing with the result of an inclusio= n proof > check. > > Eran > > [1] https://github.com/google/certificate-transparency-rfcs/ > blob/master/dns/draft-ct-over-dns.md > [2] https://www.ietf.org/mail-archive/web/trans/current/msg02617.html > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a114433a69640150549d5da6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 23, 2017 at 2:31 PM, Eran Messeri <eranm@google.com>= wrote:
I=E2= =80=99d like to overview a few options for clients to obtain inclusion proo= fs of log entries (each comprising of the corresponding SCT=E2=80=99s times= tamp + certificate) in a privacy-preserving manner.

The naive approach, of contacting the CT log itself (or a proxy), disclos= es to the operator of the service the certificates each client (as defined = by IP) observed.

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

This protocol pr= eserves the client=E2=80=99s privacy by using the client=E2=80=99s recursiv= e resolver to proxy the request (rather than directly connecting to a servi= ce) - full privacy analysis is at [2].

An upside o= f this protocol is that responses to queries generated under this protocol = are constant and can be cached infinitely - an entry=E2=80=99s index will n= ever change, as well as the inclusion proof from a particular index for a p= articular tree size.

This is the approach the CT t= eam and Chrome team at Google are working on implementing - currently DNS q= ueries are authoritatively resolved by a DNS front-end of the CT log mirror= operated by Google. The intent is to measure success rates and validate co= rrect operation under most scenarios, then standardize the protocol.
<= div>
Option 2: SSL Proxy for log traffic.
Clients c= onnect to a proxy that will relay the TCP connection to the log (much like = SOCKS5), but perform an SSL handshake with the log. Since the connection is= coming from the proxy, the log will not learn which clients observed which= certificate. As the connection is encrypted, the proxy will not learn whic= h clients observed which certificates.

One downsid= e of the protocol is that responses are not cacheable by the log / proxy (a= t least not with a naive implementation). It should be noted that clients o= nly need to fetch an inclusion proof once per observed certificate, not onc= e per connection, and that information can be cached on the client.

The other downside, and the reason we didn=E2=80=99t impl= ement this approach at Google, is that collusion between the proxy operator= and the log operator could easily correlate requests to the proxy with req= uests to the log and de-cloak clients.

Note the un= derlying assumption of clients having up-to-date Signed Tree Heads, provide= d to them by the UA vendor. While the original design called for clients ob= taining STHs themselves, having UA vendors push down STHs improves the scal= ability aspect and does not change the threat model (since clients already = trust the UA vendor). If anything, it serves to guarantee all clients have = the same view of the tree, making it harder for the log to present split vi= ews.

I find this option much mo= re appealing than the DNS option.=C2=A0 With Mozilla hat on, I would probab= ly be willing to support deployment of such a service.=C2=A0 It doesn't= rely on the DNS to provide privacy properties (something the DNS is not de= signed for).

Note that this solution still all= ows the log to associate all of a user's queries (at least all on the s= ame TLS connection); it just doesn't give it an IP address to associate= to this set.=C2=A0 So I would be slightly happier queries were encrypted i= ndependently, e.g., using S/MIME or JWE.=C2=A0 That will cost an extra X255= 19 operation per query and some extra engineering effort, but seems probabl= y worth it for the additional privacy.

Assuming that logs= are going to want to use some sort of caching layer / CDN, that leaves you= with kind of a four-level system:

Browser --- Proxy --- = Cache --- Log

... where the query encryption goes from br= owser to cache.=C2=A0 This is like 2/3 of Tor, but should be a little easie= r to build :)

--Richard
=C2=A0

I= =E2=80=99ll post separately about dealing with the result of an inclusion p= roof check.

Eran



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


--001a114433a69640150549d5da6f-- From nobody Fri Mar 3 08:37:03 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 BC73C1298C6 for ; Fri, 3 Mar 2017 08:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYsnHdLCMlZm for ; Fri, 3 Mar 2017 08:36:57 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093AF1298CA for ; Fri, 3 Mar 2017 08:36:56 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id d1so84293606ywd.2 for ; Fri, 03 Mar 2017 08:36: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=r4c/IpLr/wO2VK9OyKw3YftbG7gQ25MFj4qv21nWTcA=; b=W/qEIq02K4UmncJ3yJFXQeCROX4F82PV9fv5SkU8xEXhlkBAfIpw2TgRoFLhGeaC8s hrhXTLnEeWwA+tJnP0Qtuu0EyriGpaBkGgT8Aml3WcoWIPfAcvP2PyXjpSL8vJPBUXzM SdxxVZ6ZU/z3UCU+qNE90KMUdayYpY0ssj+2ejJ/QY/LFNU+eQflhUKEydn2hf6vHVNq RN5/BhxwfsmCkZUP3nQmk/5EWDdbYVr0u7AwlxwgqqQb5a2qc4r+fLSl9CjF1Ol1YYiZ fb0B46fQhtLAKuM7POpZ04yLRXm7uB3Kv+oP6oUlNIX0z3kZKv3ui9Z1GzFa0pQLnSVY LK8A== 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=r4c/IpLr/wO2VK9OyKw3YftbG7gQ25MFj4qv21nWTcA=; b=WuW4XiAamhILlVyy/BFr9IYaSE9Sy5Fr9N2Hw1uXYZxN37kIqe9wuFJUAEzjCnMW6A dDQJLHJ7QVuA2K1ubm1daQmFXaFo7lHEDQUFcu7ATanb1l4pFBTDWc/IzZnuSpeSOTx0 L/fWY7kQGY7G3mlCzV1XnY3HvRQW9QMFlk24OougFWyuSdQnEMK5wKkMJeHk0iqawRmd EE4aTYEjNY0tLEeeAg4byiOWiBeDp7hQwUkq8JRRQOFuGq4/GqEppunFBbH1knX6K2JW M96zHsNK74GseIaQOkMkAwbrGeYWYPThsH33MLVtxLqX9dRiVUWQBAxa1B5rb25B5Tf5 RlqQ== X-Gm-Message-State: AMke39l9oys39eIXStpH7PWUrHCRicbEEmH7ISGTAdrhi1+CHg6fzDK8+dT5C5F3JO+MNXAebUIASt+Tqp8kHOaX X-Received: by 10.129.70.197 with SMTP id t188mr2389961ywa.112.1488559015846; Fri, 03 Mar 2017 08:36:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.76.65 with HTTP; Fri, 3 Mar 2017 08:36:55 -0800 (PST) In-Reply-To: References: From: Al Cutter Date: Fri, 3 Mar 2017 16:36:55 +0000 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a114d70ee5e5c6e0549d62731 Archived-At: Cc: Ryan Sleevi , Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:37:01 -0000 --001a114d70ee5e5c6e0549d62731 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 3:23 PM, Richard Barnes wrote: > Hey Al, > > Thanks for chipping in. I'm not surprised to hear that this stuff is not > novel :) > You're welcome, and yeah - we've been at this a while :) > > Since I've got you here, here's one thing I'm confused about: Why don't > you have the same reliability problems with SCTs? Before you issue the > SCT, you've got to be really sure that you've got that cert and it's going > to make it into the log. > Because this decouples the acceptance (distributed) side from the (serial) sequencing side. So, for example, our first generation logs do this for every add-*chain: - write to a journal file in a quorum of geographically distributed datacentres, if that fails, return an error to the CA - write the requested cert to the queue of things to integrate (which is also a distributed store, Megastore in ye olde logs, and Spanner nowadays), if that fails, journal it and return an error to the CA - write "Win!" to the journal, and return the SCT to the CA, otherwise return an error. You're probably thinking that's bordering on the excessively paranoid, and I'm not going to argue, but I hope you'd agree that we've got your cert, or at least told you otherwise. Note that to do this doesn't **require** global consensus (unless you promise not to include dupes in your log). So I get to stay available, potentially even in the event of loss of global consensus, and certainly in the case where the dog ate my signer, it's just that I only have twentyish hours in which to sort it out (rather than a handful of seconds). > > The only difference we're talking about here is that in addition to that > append operation, you also have a read > Well, you have a transactional operation consisting of a read and one or more writes which must all be [globally] strongly consistent or you'll fork your tree, which is a bit different. operation. Either way, you have a stack of things you're appending to, > either a stack of just certs or a stack of (cert, frontier) pairs. In the > SCT case, you have to reliably push a cert onto the stack. In the no-MMD > case, you have to peek at the top of the stack to get the last frontier, > then push the new (cert, frontier) pair. That does extend the scope of the > transaction a bit, but it certainly doesn't seem like it should take you > from "effectively instantaneous" to "we'll get back to you tomorrow". > How do you this in practice? - have a single webserver handling all the add requests and sequencing in-line? - have lots of webservers all internally RPC to a single "sequencing" server? What happens when they catch fire? Failover - you're down until everything is back up and running, you can probably do that in O(tens of seconds) say (you really don't want multiple of these things believing they're the one and only though, so do it properly), and depending on your storage infrastructure your master node/group leader/whatever could be far away from the new location slowing these operations down until it migrates or your old machines come back. - Have all your frontends try to transactionally update the tree state when they get a request At anything above very noddy add-chain rates (i.e. where they're arriving in parallel to different frontends) you're going to fail almost all of these transactions because they have to be strongly consistent or you fork your tree. Like I said, I really love the idea of embedding proofs, and I even think it's likely to be technically doable with Trillian based logs at a broadly acceptable latency, but only with the ecosystem evolution I mentioned in the last mail. Modulo the STH frequency thing, I'm not aware of a reason why -bis can't support that in its current state, although certainly if this is something which were desired/not universally despised then the text around the add-chain (or whatever it's called in -bis) method could perhaps be widened to allow for returning TransItems containing things other than X.509 SCTs for example. But I believe you could compose several calls to get a similar result as it stands currently. > Am I misunderstanding how reliability works for SCTs? If you have a > reliability problem with updating the tree in this way, don't you already > have a reliability problem with SCTs? > Maybe, a little bit :) But I wouldn't hold it against you or anyone else who hasn't already built and operated a Log at scale. > > > --Richard > > > On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter wrote: > >> I thought I'd throw a few things into the discussion... >> >> So, I think what Richard, Nick and Zakir have reinvented, is more or less >> the original plan for how CT was going to work; chains would be submitted, >> and the caller would be told either a) here's your inclusion proof+STH, or >> b) come back and try again in a bit. >> At that time, CAs were understandably wary of blocking their issuance on >> processes with an unbounded (or at least slightly hand-wavy) deadline. >> Enter SCTs, which we we all know and, um, love. >> (You all probably knew that already, and if you've been following or >> involved with CT for a while also probably know a lot of the trade-offs >> that we made in our Google log implementation, mostly swapping speed and >> comfort for quite paranoid levels of redundancy.) >> >> As I said during the talk Pierre and I gave at the start of the CT policy >> days about running logs at scale, personally, I really like the idea of >> serving proofs directly (I think I said something along the lines of it >> holding a special place in my heart) and I suspect that's at least in part >> what's triggered this to resurface. >> >> To detour for a moment, Richard's right in that you certainly can update >> Merkle trees in real time, and very quickly - in fact, if you forgo the >> full-fat Merkle tree and use what we term a "compact" merkle tree (see >> github [1] for details - I believe this is what Richard describes as his >> "frontier" tree), then you can update it at many hundreds of thousands of >> qps, when you start trying to actually store and sign things it slows down >> a fair bit, but depending on storage layer/layout/and whatnots you could >> still reasonably expect to be able to do many thousands per second. >> Obviously as you crank the hypothetical lever away from "low reliability" >> (perhaps not really useful* in the current CT system, but impressively >> fast) over to "reliable and globally consistent" things slow down further, >> but our recent experiences with Trillian suggest that you can still do this >> sort of thing at multiple hundreds to a couple of thousand qps if you're >> willing to batch a bit (Trillian has levers too, in particular to trade off >> between throughput, scale, and low integration latency, but we need to do >> more testing to better understand the full implications.) >> >> Back to the policy day; the next thing I said after sharing my wistful >> dreams, was that I felt that in order for anything like those dreams to >> become reality there would need to be changes in the ecosystem, the ones I >> called out in particular were that we'd need to have many logs, and that >> they'd need to be open. The reason for this, which I think I didn't go >> into any detail about and Ryan has touched on above, is because cold hard >> operational reality has a habit of crashing through the door whenever >> there's something I'd like to have - things like machines failing, software >> updates (even rolling ones), bugs, master elections, network partitions, >> and Stuff, all mean that you will not *always* be able to have your >> throughput, and there *will* be stretches of time you are completely unable >> to update your tree (I'm assuming the local/global level is pulled over >> towards the global side here). If the ecosystem has sufficient open logs >> and CAs were all attempting to log in parallel to sufficiently large subset >> of those, they maybe that's fine and it turns out to be overwhelmingly >> likely that there are enough logs not having a bad day for the world to >> roll on. >> >> I think none of this dream world is in conflict with the current state of >> -bis, other than possibly that requirement to limit STH issuance to one per >> hour. I understand why it got put in, but I do wonder if it really belongs >> in the Gossip doc rather than -bis where it's potentially discouraging This >> Sort of Thing. >> >> Anyway, I just thought I'd chip in with some colour. >> >> >> [1] https://github.com/google/certificate-transparency/blob/ >> master/cpp/merkletree/compact_merkle_tree.h >> >> On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi wrote: >> >>> >>> >>> On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes wrote: >>> >>>> On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes wrote: >>>>>> >>>>>> In any case, we should stop thinking that log delay and the MMD are >>>>>> essential properties of this system. >>>>>> >>>>> >>>>> I'm confused by this conclusion, and apologies if I've misunderstood. >>>>> >>>>> Can you explain how this statement differs, from say a discussion >>>>> about keeping a database in RAM and never flushing to disk? You can have >>>>> amazing QPS - but terrible reliability. It sounds like you're describing >>>>> that you've built an unreliable, but efficient, system, and are using that >>>>> as proof that reliability is not a critical property? >>>>> >>>> >>>> That's part of why I used Spanner as one of our test points. At least >>>> according to Al at the CT policy days, that's what his team is using as >>>> storage for their logs. So presumably it's suitably reliable? >>>> >>>> I'm definitely willing to admit there's a trade-off here. My point is >>>> just that the reliability requirements are not inconsistent with a >>>> sufficiently high transaction rate to serve existing needs. >>>> >>> >>> Again, I'm confused as to how you reach that conclusion, so apologies if >>> I'm just dense here. >>> >>> You've compared an extremely reliable, globally consistent storage >>> system and established one bound (10qps) for your idea. You've then >>> compared an extremely unreliable, globally inconsistent storage system and >>> established another bound (60qps-200qps) >>> >>> I'm not sure why you've introduced the unreliable system - which has >>> SPOF written all over it - or how it relates to this proposal. Are you >>> suggesting that reliability is no longer necessary? >>> >>> Assuming reliability is necessary, and we accept 10qps for 'extremely >>> high' reliability, and 60qps for 'extremely low reliability', doesn't your >>> solution only provide value iff the growth rate of the ecosystem is >>> somewhere within these bounds? Are you asserting that "10-60 qps should be >>> enough for everyone"? >>> >>> I guess what I'm trying to figure out is what the consequence of this >>> experiment is - are you proposing change? Because aren't those bounds only >>> relevant to the specific experiment you did, which is related to your >>> proposed solution for STH-on-every-cert? >>> >>> I apologize if I'm simply dense from what this implementation feedback >>> is related to, or understanding the objective of this experiment. You >>> suggest it may be feasible, but I see those numbers and reach the opposite >>> conclusion, so I'm trying to understand where I'm misunderstanding. >>> >>> _______________________________________________ >>> Trans mailing list >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >>> >>> >> > --001a114d70ee5e5c6e0549d62731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 3:23 PM, Richard Barnes <rlb@ipv.sx> wro= te:
<= div>Hey Al,

Thanks for chipping in.=C2=A0 I'm not sur= prised to hear that this stuff is not novel :)
=

You're welcome, and yeah - we've been at this a= while :)=C2=A0

Since I've got you here, he= re's one thing I'm confused about: Why don't you have the same = reliability problems with SCTs?=C2=A0 Before you issue the SCT, you've = got to be really sure that you've got that cert and it's going to m= ake it into the log.

Becaus= e this decouples the acceptance (distributed) side from the (serial) sequen= cing side.
So, for example, our first generation logs do this for= every add-*chain:
=C2=A0- write to a journal file in a quorum of= geographically distributed datacentres, if that fails, return an error to = the CA
=C2=A0- write the requested cert to the queue of things to= integrate (which is also a distributed store, Megastore in ye olde logs, a= nd Spanner nowadays), if that fails, journal it and return an error to the = CA
=C2=A0- write "Win!" to the journal, and return the = SCT to the CA, otherwise return an error.

You'= re probably thinking that's bordering on the excessively paranoid, and = I'm not going to argue, but I hope you'd agree that we've got y= our cert, or at least told you otherwise.=C2=A0 Note that to do this doesn&= #39;t *require* global consensus (unless you promise not to include = dupes in your log). =C2=A0

So I get to stay availa= ble, potentially even in the event of loss of global consensus, and certain= ly in the case where the dog ate my signer, it's just that I only have = twentyish hours in which to sort it out (rather than a handful of seconds).=
=C2=A0

The only difference we're talking about her= e is that in addition to that append operation, you also have a read
<= /div>

Well, you have a transactional operat= ion consisting of a read and one or more writes which must all be [globally= ] strongly consistent or you'll fork your tree, which is a bit differen= t.

operation.=C2=A0 Either way, you have a stack of things= you're appending to, either a stack of just certs or a stack of (cert,= frontier) pairs.=C2=A0 In the SCT case, you have to reliably push a cert o= nto the stack.=C2=A0 In the no-MMD case, you have to peek at the top of the= stack to get the last frontier, then push the new (cert, frontier) pair.= =C2=A0 That does extend the scope of the transaction a bit, but it certainl= y doesn't seem like it should take you from "effectively instantan= eous" to "we'll get back to you tomorrow".

How do you this in practice?=C2=A0
=C2=A0- have a single webserver handling all the add requests and sequenci= ng in-line?
=C2=A0- have lots of webservers all internally RPC to= a single "sequencing" server?

What happ= ens when they catch fire?
Failover - you're down until ev= erything is back up and running, you can probably do that in O(tens of seco= nds) say (you really don't want multiple of these things believing they= 're the one and only though, so do it properly), and depending on your = storage infrastructure your master node/group leader/whatever could be far = away from the new location slowing these operations down until it migrates = or your old machines come back.

=C2=A0- Have all y= our frontends try to transactionally update the tree state when they get a = request
At anything above very noddy add-chain rates (i.e. where = they're arriving in parallel to different frontends) you're going t= o fail almost all of these transactions because they have to be strongly co= nsistent or you fork your tree.

Like I said, I rea= lly love the idea of embedding proofs, and I even think it's likely to = be technically doable with Trillian based logs at a broadly acceptable late= ncy, but only with the ecosystem evolution I mentioned in the last mail.=C2= =A0
Modulo the STH frequency thing, I'm not aware of a reason= why -bis can't support that in its current state, although certainly i= f this is something which were desired/not universally despised then the te= xt around the add-chain (or whatever it's called in -bis) method could = perhaps be widened to allow for returning TransItems containing things othe= r than X.509 SCTs for example.=C2=A0 But I believe you could compose severa= l calls to get a similar result as it stands currently.

Am I misunderstanding how reliability works for SCTs?=C2=A0 If= you have a reliability problem with updating the tree in this way, don'= ;t you already have a reliability problem with SCTs?

Maybe, a little bit :)
But I wouldn't h= old it against you or anyone else who hasn't already built and operated= a Log at scale.
=C2=A0


--Richard


On Fri, Mar 3, 2017 at 5:= 19 AM, Al Cutter <al@google.com> wrote:
I thought I'd throw a few= things into the discussion...=C2=A0

So, I think what Ri= chard, Nick and Zakir have reinvented, is more or less the original plan fo= r how CT was going to work; chains would be submitted, and the caller would= be told either a) here's your inclusion proof+STH, or b) come back and= try again in a bit.
At that time, CAs were understandably wary o= f blocking their issuance on processes with an unbounded (or at least sligh= tly hand-wavy) deadline.=C2=A0 Enter SCTs, which we we all know and, um, lo= ve.
(You all probably knew that already, and if you've been f= ollowing or involved with CT for a while also probably know a lot of the tr= ade-offs that we made in our Google log implementation, mostly swapping spe= ed and comfort for quite paranoid levels of redundancy.)

As I said during the talk Pierre and I gave at the start of the CT p= olicy days about running logs at scale, personally, I really like the idea = of serving proofs directly (I think I said something along the lines of it = holding a special place in my heart) and I suspect that's at least in p= art what's triggered this to resurface.

To det= our for a moment, Richard's right in that you certainly can update Merk= le trees in real time, and very quickly - in fact, if you forgo the full-fa= t Merkle tree and use what we term a "compact" merkle tree (see g= ithub [1] for details - I believe this is what Richard describes as his &qu= ot;frontier" tree), then you can update it at many hundreds of thousan= ds of qps, when you start trying to actually store and sign things it slows= down a fair bit, but depending on storage layer/layout/and whatnots you co= uld still reasonably expect to be able to do many thousands per second.=C2= =A0 Obviously as you crank the hypothetical lever away from "low relia= bility" (perhaps not really useful* in the current CT system, but impr= essively fast) over to "reliable and globally consistent" things = slow down further, but our recent experiences with Trillian suggest that yo= u can still do this sort of thing at multiple hundreds to a couple of thous= and qps if you're willing to batch a bit (Trillian has levers too, in p= articular to trade off between throughput, scale, and low integration laten= cy, but we need to do more testing to better understand the full implicatio= ns.)
=C2=A0
Back to the policy day; the next thing I sa= id after sharing my wistful dreams, was that I felt that in order for anyth= ing like those dreams to become reality there would need to be changes in t= he ecosystem, the ones I called out in particular were that we'd need t= o have many logs, and that they'd need to be open.=C2=A0 The reason for= this, which I think I didn't go into any detail about and Ryan has tou= ched on above, is because cold hard operational reality has a habit of cras= hing through the door whenever there's something I'd like to have -= things like machines failing, software updates (even rolling ones), bugs, = master elections, network partitions, and Stuff, all mean that you will not= *always* be able to have your throughput, and there *will* be stretches of= time you are completely unable to update your tree (I'm assuming the l= ocal/global level is pulled over towards the global side here). If the ecos= ystem has sufficient open logs and CAs were all attempting to log in parall= el to sufficiently large subset of those, they maybe that's fine and it= turns out to be overwhelmingly likely that there are enough logs not havin= g a bad day for the world to roll on.=C2=A0

I thin= k none of this dream world is in conflict with the current state of -bis, o= ther than possibly that requirement to limit STH issuance to one per hour. = I understand why it got put in, but I do wonder if it really belongs in the= Gossip doc rather than -bis where it's potentially discouraging This S= ort of Thing.

Anyway, I just thought I'd chip = in with some colour.



On Fri, Mar = 3, 2017 at 5:37 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wr= ote:
=


On Thu, Mar 2, 2017 = at 5:38 PM, Richard Barnes <rlb@ipv.sx> wrote:
On Thu, = Mar 2, 2017 at 8:04 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:
In any case, we should stop thinking that log delay an= d the MMD are essential properties of this system.
<= /div>

I= 'm confused by this conclusion, and apologies if I've misunderstood= .

Can = you explain how this statement differs, from say a discussion about keeping= a database in RAM and never flushing to disk? You can have amazing QPS - b= ut terrible reliability. It sounds like you're describing that you'= ve built an unreliable, but efficient, system, and are using that as proof = that reliability is not a critical property?
<= br>
That's part of why I used Spanner as one of o= ur test points.=C2=A0 At least according to Al at the CT policy days, that&= #39;s what his team is using as storage for their logs.=C2=A0 So presumably= it's suitably reliable?

I'm definitely willing to admit there's a trade-off here.=C2= =A0 My point is just that the reliability requirements are not inconsistent= with a sufficiently high transaction rate to serve existing needs.

Again, I'm confused as to h= ow you reach that conclusion, so apologies if I'm just dense here.

You've compared an extremely reliable, globally co= nsistent storage system and established one bound (10qps) for your idea. Yo= u've then compared an extremely unreliable, globally inconsistent stora= ge system and established another bound (60qps-200qps)

=
I'm not sure why you've introduced the unreliable system - whi= ch has SPOF written all over it - or how it relates to this proposal. Are y= ou suggesting that reliability is no longer necessary?

=
Assuming reliability is necessary, and we accept 10qps for 'extrem= ely high' reliability, and 60qps for 'extremely low reliability'= ;, doesn't your solution only provide value iff the growth rate of the = ecosystem is somewhere within these bounds? Are you asserting that "10= -60 qps should be enough for everyone"?

I gue= ss what I'm trying to figure out is what the consequence of this experi= ment is - are you proposing change? Because aren't those bounds only re= levant to the specific experiment you did, which is related to your propose= d solution for STH-on-every-cert?

I apologize if I= 'm simply dense from what this implementation feedback is related to, o= r understanding the objective of this experiment. You suggest it may be fea= sible, but I see those numbers and reach the opposite conclusion, so I'= m trying to understand where I'm misunderstanding.

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




--001a114d70ee5e5c6e0549d62731-- From nobody Fri Mar 3 10:24: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 5D33212996F for ; Fri, 3 Mar 2017 10:24:56 -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 GAKZ6_o_v4mO for ; Fri, 3 Mar 2017 10:24:54 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 47DEB129958 for ; Fri, 3 Mar 2017 10:24:54 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id u108so79198858wrb.3 for ; Fri, 03 Mar 2017 10:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=whYP2RX/6/H09OQE51TLNtZl/dBFmEuZgg5GOjm8L3w=; b=uQBC9wX1918WFxz2yw2tdbPYBm6fTIhRzbcTD031Joc2v+P3W7MJzBRYqR0RKdYxo2 Q3CcAw73WNbP7DNG6sUj2fl+GQGIzZVr27YHs3zhJFTsZ76LCCuRbM2FDm2j/ZusLOpc jLV6sQtBySIwhtEsQ3k+UHFi56WqvwxhfNmXBj4gNLtBCK5ex4D2e8WPL8QPONaAKY+C ETZ/PH7/l5SDd4oTwOIlxbVO4ieYeekCe/krhpfL4j8Txqw6wbJNw+f5bxuD3KV83Qn4 kBx6EyjVKYM36P7Lrc9+ecITtoHytx4xDLwaXGXbh1NQ6oI3MdmrGYTy8d/oLu034LOC rq6w== 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=whYP2RX/6/H09OQE51TLNtZl/dBFmEuZgg5GOjm8L3w=; b=A9l+CQcfZeP52iCuTjghx4OPq/Mr+lj4LKQuBU74P2AsqhLhsk5V1OnBzKiiq2TeRJ SE7dtqDmDLlpDcO/IEnbayFMyW8NsuNEUDt4bqMVPRcSpe3FunVx5Xky688BqWfNgdEY 5A2aubMs0wJEYkaXTDLy4dkBdGH7TQ/xCg4QukrY2V2/tnf7G93dWBrg0pO79WU2ASsK twBvZeEMpEefSRHfIRAzjaD1rsBEnFWya0IW8FAgqOrQQl1LAK9w7AaVugqlXnznvSkk ms1IhG3PalwcWukqHNejBKHniDa5YlwO5NLZUihBE6P6q2hD0pkmdYLZJjoTSJnhf+Y2 T7qA== X-Gm-Message-State: AMke39ndIwDjgyRXiWDnXaQkb1HwvfEplEFoCbRwEGfevkxiA6hVDdL0Fzbqt6NsnbaotSnujgAa2W3UGMTOIA== X-Received: by 10.223.139.152 with SMTP id o24mr3869101wra.61.1488565491760; Fri, 03 Mar 2017 10:24:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Fri, 3 Mar 2017 10:24:51 -0800 (PST) From: Richard Barnes Date: Fri, 3 Mar 2017 13:24:51 -0500 Message-ID: To: Trans Content-Type: multipart/alternative; boundary=f403045e9ace5c98420549d7a9e3 Archived-At: Subject: [Trans] STH Discipline & Security Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:24:56 -0000 --f403045e9ace5c98420549d7a9e3 Content-Type: text/plain; charset=UTF-8 Hey all, I wanted to follow up on my earlier comments and a bunch of side conversations I've had with people since then with a revised change proposal that I think can get -rfc6962-bis to a point we can live with. tl;dr: 1. We/Mozilla can live with the Merkle tree for now, though we/community might ultimately want something different later 2. At a systemic level, we need to move toward servers providing inclusion proofs, but -rfc6962-bis provides sufficient tools for this 3. We need to better document "STH discipline", and define a "canonical STH" for each element in the log 4. We need to update the security considerations to describe more clearly the implications of various levels of auditing I'm willing to write up a PR for (2); EKR has volunteered for (3). # Auditing Models There are basically two approaches to auditing available to clients: 1. Prospective: Browser does auditing checks at TLS connection time 2. Retrospective: Browser does auditing checks after TLS connection time Prospective checking provides better assurance than retrospective, since it prevents any harm that would come from a mis-issued, improperly-attested certificate. The cost is that the server has to send enough information the cert and the browser has to cache enough information about the log that the two can be married up without further requests. In practice, however, it looks like some degree of retrospective checking will be necessary even in browsers that support the cache enough information for prospective checking. On the one hand, if an inclusion proof can't be embedded in a cert, then we can't count on all server operators providing it (via OCSP / TLS). On the other hand, including proofs in certs imposes issuance delays that will not be acceptable in many circumstances, even if it is O(minutes). And given Eran's SSL proxy proposal, with the amendments I suggested, I'm now pretty well convinced that the fetches you need for retrospective validation can be done privately with something short of Tor (just). The scalability problems are bad, but probably ultimately workable. It should be clear that either of these models work much better if the server provides inclusion proofs. Together with the STH discipline notions below, this would enable prospective auditing for all but very new certificates if a browser is willing to cache STHs. Even in cases where CT information must be fetched, having the server send an inclusion proof would mean that the only fetch would be for consistency, which is a less privacy-sensitive, more cacheable query. # STH Discipline Either style of auditing also works better if logs have a notion of "STH discipline", in the following sense: 1. The official state of the log comprises a sequence of STHs issued at specified intervals. 2. For each certificate in the log, there is a single "canonical STH" to which the log will produce an inclusion proof. Proofs to other STHs are done by adding a consistency proof to the inclusion proof. This property makes things work more smoothly in both auditing models: - If the browser is willing to cache STHs, this tells the browser exactly which STHs it needs to cache in order to validate all inclusion proofs. - Everything is more cacheable, since there's only one inclusion proof per certificate, and a limited set of heads among which consistency needs to be calculated. - Cacheability means that the fetches of inclusion proofs get greater privacy benefit from caching, since they depend only on the certificate, not the STH that the client is using. Likewise for consistency proofs, because of the reduced variety. >From a protocol point of view, I haven't done a thorough evaluation of the document, but there are at least a few things you would want to make this model work: - Prose that articulates the above bounds on logs / inclusion proofs / STHs. Probably a notion of "STH issuance frequency" parallel to MMD. - A field in an SCT that indicates the canonical STH for the certificate in question. Possibly a serial number in STH that SCTs could refer to. - An API endpoint for fetching STHs in the official sequence (in addition to the current one, which is the only option right now). If this line of thinking sounds generally sane to people, I'll take a pass through the document and make some concrete proposals. Thanks, --Richard --f403045e9ace5c98420549d7a9e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

I wanted to follow up on my earlier commen= ts and a bunch of side conversations
I've had with people since then= with a revised change proposal that I think can
get -rfc6962-bis to a p= oint we can live with.

tl;dr:
1. We/Mozilla can live with the Mer= kle tree for now, though we/community might
=C2=A0=C2=A0 ultimately want= something different later
2. At a systemic level, we need to move towar= d servers providing inclusion
=C2=A0=C2=A0 proofs, but -rfc6962-bis prov= ides sufficient tools for this
3. We need to better document "STH d= iscipline", and define a "canonical STH"
=C2=A0=C2=A0 for= each element in the log
4. We need to update the security consideration= s to describe more clearly the
=C2=A0=C2=A0 implications of various leve= ls of auditing

I'm willing to write up a PR for (2); EKR has vol= unteered for (3).


# Auditing Models

There are basically t= wo approaches to auditing available to clients:

1. Prospective: Brow= ser does auditing checks at TLS connection time
2. Retrospective: Browse= r does auditing checks after TLS connection time

Prospective checkin= g provides better assurance than retrospective, since it
prevents any ha= rm that would come from a mis-issued, improperly-attested
certificate.= =C2=A0 The cost is that the server has to send enough information the
ce= rt and the browser has to cache enough information about the log that the t= wo
can be married up without further requests.

In practice, howev= er, it looks like some degree of retrospective checking will
be necessar= y even in browsers that support the cache enough information for
prospec= tive checking.=C2=A0 On the one hand, if an inclusion proof can't be em= bedded
in a cert, then we can't count on all server operators provid= ing it (via OCSP /
TLS).=C2=A0 On the other hand, including proofs in ce= rts imposes issuance delays
that will not be acceptable in many circumst= ances, even if it is O(minutes).

And given Eran's SSL proxy prop= osal, with the amendments I suggested, I'm now
pretty well convinced= that the fetches you need for retrospective validation
can be done priv= ately with something short of Tor (just).=C2=A0 The scalability
problems= are bad, but probably ultimately workable.

It should be clear that = either of these models work much better if the server
provides inclusion= proofs.=C2=A0 Together with the STH discipline notions below,
this woul= d enable prospective auditing for all but very new certificates if a
bro= wser is willing to cache STHs.=C2=A0 Even in cases where CT information mus= t be
fetched, having the server send an inclusion proof would mean that = the only
fetch would be for consistency, which is a less privacy-sensiti= ve, more
cacheable query.


# STH Discipline

Either styl= e of auditing also works better if logs have a notion of "STH
disci= pline", in the following sense:

1. The official state of the lo= g comprises a sequence of STHs issued at
=C2=A0=C2=A0 specified interval= s.

2. For each certificate in the log, there is a single "canon= ical STH" to which
=C2=A0=C2=A0 the log will produce an inclusion p= roof.=C2=A0 Proofs to other STHs are done by
=C2=A0=C2=A0 adding a consi= stency proof to the inclusion proof.

This property makes things work= more smoothly in both auditing models:

- If the browser is willing = to cache STHs, this tells the browser exactly which
=C2=A0 STHs it needs= to cache in order to validate all inclusion proofs.

- Everything is= more cacheable, since there's only one inclusion proof per
=C2=A0 c= ertificate, and a limited set of heads among which consistency needs to be<= br>=C2=A0 calculated.

- Cacheability means that the fetches of inclu= sion proofs get greater privacy
=C2=A0 benefit from caching, since they = depend only on the certificate, not the STH
=C2=A0 that the client is us= ing.=C2=A0 Likewise for consistency proofs, because of the
=C2=A0 reduce= d variety.

From a protocol point of view, I haven't done a thoro= ugh evaluation of the
document, but there are at least a few things you = would want to make this model
work:

- Prose that articulates the = above bounds on logs / inclusion proofs / STHs.
=C2=A0 Probably a notion= of "STH issuance frequency" parallel to MMD.

- A field in= an SCT that indicates the canonical STH for the certificate in
=C2=A0 q= uestion.=C2=A0 Possibly a serial number in STH that SCTs could refer to.
- An API endpoint for fetching STHs in the official sequence (in addit= ion to
=C2=A0 the current one, which is the only option right now).
<= br>If this line of thinking sounds generally sane to people, I'll take = a pass
through the document and make some concrete proposals.

Tha= nks,
--Richard
--f403045e9ace5c98420549d7a9e3-- From nobody Fri Mar 3 11:08:27 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC061295BA for ; Fri, 3 Mar 2017 11:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0fJF-M-XUDX for ; Fri, 3 Mar 2017 11:08:25 -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 2D077129550 for ; Fri, 3 Mar 2017 11:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1488568103; bh=Bt98QSR3/Ow8Q+N3xmwfkr6ifUaz0LSR6hxJiFa880o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=IOJ+G8EfRfOV9q/a2UsDDAJvyjcYWZdxjDrdaO8iy62CGAq8bY0PQLBffpEG4RJSg VDOmpKe8GsNmEoh8OBHSF8Bh3wFpQeG3918SRdO5N6DqOCEI2AqbnLdh1mBK2VdQTx EHPjllDTW8hBrXUrzp9lcJejeR0sLwuztfu+wld7emodwUw2YgNUMKK4fdBY0gX8la vX+46Ax2yLuSmQn6AZNQspPmEQiAI7SkI51xSkq/wjZD71G+iqFwb3FV2CRnqDwr0Q IGp0TETV8szk3ZphBDkSPS5UZ9juEql/b1mGlqZyaHlYcgrJw+NqC6PyHjCTlB4vnK tKWf5R8OuAOWg== Date: Fri, 3 Mar 2017 11:08:23 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170303110823.037b95b47617934f2f97e425@andrewayer.name> In-Reply-To: References: <20170302175514.e1845a0b6314b08527ee5703@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: Zakir Durumeric , trans@ietf.org, Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:08:26 -0000 On Thu, 2 Mar 2017 22:29:11 -0500 Richard Barnes wrote: > On Thu, Mar 2, 2017 at 8:55 PM, Andrew Ayer > wrote: > > > Hi Richard, > > > > On Thu, 2 Mar 2017 18:58:49 -0500 > > Richard Barnes wrote: > > > > > On the third hand, it may be possible to hack around even this. > > > Even if logs are checkpointed, so that only some tree heads are > > > "official" and used by clients/auditors, the log could produce a > > > consistency proof to the last official head at ingress time, > > > which would provide the client/auditor some assurance that the > > > cert fits into the global history, which could be verified when > > > the next official tree head comes out. > > > > This sounds interesting - could you elaborate? > > > > (To be clear: Credit for this idea goes to Zakir, I'm just recapping.) > > Obviously, every time you add a cert to the Merkle tree, you get a > new tree head. Say a log produces "official" tree heads ever 5 certs > and all official heads get sync'ed out to clients, who cache them > all. (Just for the sake of argument; obviously you could also > fetch.) So you would have a history something like this: > > O1 - H2 - H3 - H4 - H5 - O6 - H7 - H8 - ... > > At the time the fourth certificate (C4) is added, the log can produce > two things: > > 1. An inclusion proof from C4 to H4 > 2. A consistency proof from O1 to H4 > > If these can be provided to the client (say in the cert or stapled > OCSP) and the client has O1, then the client can verify that there is > a causal link between the two. This is slightly better than an SCT > (e.g., it can't be back-dated to before O1), but doesn't prevent > forked history. In order to prevent that, the client still has to > verify that the head H4 is "forward consistent" with the next tree > head O6. > > So you still need to get a consistency proof that proves that H4 is > consistent with O6. You can do that by fetching it from the log, but > that's no better from a privacy / log scaling POV than fetching > inclusion proofs. Due to the need to get a consistency proof for the intermediate head, I don't see how this is any better than SCTs - this proposal just swaps SCTs with intermediate heads and inclusion proofs with consistency proofs. The backdating prevention isn't compelling, because a malicious log can just fork off history from an earlier official SCT if it wants to backdate an entry. > It would be lovely if the consistency proof between O1 and O6 could > also be used to verify any intermediate heads you have, since then > the client could just sync down the consistency between official > heads and use that to check the intermediates. TBH, I don't have > good enough intuition for consistency proofs to know whether this > works off the top of my head, and I haven't sat down to figure it out. Unfortunately, a consistency proof does not contain enough information to do this - the proof contains the minimal number of hashes needed, so entire subtrees tend to get condensed into their root hash. Regards, Andrew From nobody Fri Mar 3 11:09: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 B5AA012998E for ; Fri, 3 Mar 2017 11:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7acziqdvi0z for ; Fri, 3 Mar 2017 11:09:51 -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 7B7941295BA for ; Fri, 3 Mar 2017 11:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1488568191; bh=aXfWBaWXx3LBsQBppEhZvTNi8GEe8/UTphT1obmhrHg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=U6Cqpjv3qGNF/zFdOFlmNh+io0SHgdF+cZLCn16FY6jOf/NfCOOti05FwFVsRIiMU q8IDrOBFI72tCmfm/Mkx9yyVIXOTDw6vk5YmZRHxpuu9vLtNE/sAa/u+dZd+N/MWpW vQ3NgAFcUf3/7GQCdJLuq2b6WLgzpw0QCizZmbeIFjcIbuC0TDxlF/1JflmIqdCFxn mvNLBbI7I0E1S8OAcRU3ys3ij85gino7DgNO7gZD0EOlLfqbIzzOiKJ4x7kWg8fxfJ ZAM72cEVRGl46KdPZLov2eO8RzIhpzSBGkE/F3qLVCaEDYW/2W0xPxXpXuE+M5iiCe kiNyuUZmtkICg== Date: Fri, 3 Mar 2017 11:09:50 -0800 From: Andrew Ayer To: Richard Barnes Message-Id: <20170303110950.b04152416b71a5873b74fa37@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 Subject: Re: [Trans] STH Discipline & Security Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:09:52 -0000 On Fri, 3 Mar 2017 13:24:51 -0500 Richard Barnes wrote: > # STH Discipline > > Either style of auditing also works better if logs have a notion of > "STH discipline", in the following sense: > > 1. The official state of the log comprises a sequence of STHs issued > at specified intervals. > > 2. For each certificate in the log, there is a single "canonical STH" > to which > the log will produce an inclusion proof. To be clear, would there still be a way to get inclusion proofs to non-canonical STHs? Clients wouldn't have to use them if they didn't want to. > Proofs to other STHs are > done by > adding a consistency proof to the inclusion proof. > > This property makes things work more smoothly in both auditing models: > > - If the browser is willing to cache STHs, this tells the browser > exactly which > STHs it needs to cache in order to validate all inclusion proofs. > > - Everything is more cacheable, since there's only one inclusion > proof per certificate, and a limited set of heads among which > consistency needs to be > calculated. > > - Cacheability means that the fetches of inclusion proofs get greater > privacy > benefit from caching, since they depend only on the certificate, > not the STH > that the client is using. Likewise for consistency proofs, because > of the reduced variety. > > >From a protocol point of view, I haven't done a thorough evaluation > >of the > document, but there are at least a few things you would want to make > this model > work: > > - Prose that articulates the above bounds on logs / inclusion > proofs / STHs. Probably a notion of "STH issuance frequency" parallel > to MMD. > > - A field in an SCT that indicates the canonical STH for the > certificate in question. Possibly a serial number in STH that SCTs > could refer to. Is this necessary? Why not define the canonical STH as the first STH issued after the SCT (based on timestamp)? > - An API endpoint for fetching STHs in the official sequence (in > addition to the current one, which is the only option right now). +1. I think any privacy-preserving auditing mechanism will need such an endpoint so that STHs can be reliably distributed to clients. Regards, Andrew From nobody Fri Mar 3 11:30:00 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 42E311295C9 for ; Fri, 3 Mar 2017 11:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtyd3m1L8LJz for ; Fri, 3 Mar 2017 11:29:57 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 8E0081295C6 for ; Fri, 3 Mar 2017 11:29:57 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 5FC28A8A098D; Fri, 3 Mar 2017 19:29:52 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 17C101FE07EE; Fri, 3 Mar 2017 20:29:51 +0100 (CET) Date: Fri, 3 Mar 2017 20:29:51 +0100 From: Kurt Roeckx To: Richard Barnes Message-ID: <20170303192951.xqcdta6uc2ukgriv@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: Zakir Durumeric , Nick Sullivan , trans@ietf.org Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:29:59 -0000 On Thu, Mar 02, 2017 at 06:58:49PM -0500, Richard Barnes wrote: > The upshot is that this style of logging seems eminently feasible. Almost > all CT logs are growing at well less than 10qps [2], and even Let's Encrypt > on its worst days only generates about 115qps. And I have pretty high > confidence that if you actually put some thought into designing the storage > scheme, you could get some additional margin here. Let's encrypt seems to be doing around 1M per day on "its worst days", which is still only in the range of 10 per second. Kurt From nobody Fri Mar 3 11:53: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 216281299A8 for ; Fri, 3 Mar 2017 11:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hJMuST4-b_r for ; Fri, 3 Mar 2017 11:53:30 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 D355D1295D2 for ; Fri, 3 Mar 2017 11:53:29 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id p77so87836541ywg.1 for ; Fri, 03 Mar 2017 11:53: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=4NVgEkcQVkzvnpOZcY4v5rL81XmcwVvLZIJagCI/bCg=; b=S+hi6fztqOeVXi5fx19UEXnANFliL3eknNcxLAQMUTJ/Yv812Jp0DQHrekYDkR0/8J tjLzXSHTXhp0Xl/BlROva2BAK1o9n0LOYe1Oas1M9D+FQGEIS+OeTJ4dU/YzBOxjjl5/ NF+iSVbjHeUCf+yFuVJcCMHAylR3EUVDuot/krEWYUsC0SWUFv3xMD/xW1WK1Dj4JCrn uOy9Uc5WD3rT0oDe+7qpEWvlHG+Iy0rjlfgjJYIgmCRiOEgdJR5EUiKtU8vZ/Z7u/GLH RMuHoE/svDEBqJpA/KuGwsZdxqa/7shwd1wgZQo+PwVluJwQbyCHJCi0SB8iWZ1Io2OY Cm8w== 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=4NVgEkcQVkzvnpOZcY4v5rL81XmcwVvLZIJagCI/bCg=; b=erwVNr3OpXrOdOlOoFYDHY7By4eomqAkPB/uslFtEv/ue22D9tFuWTESJpXDZ7cMwQ bRqYQYbSsbfnWIgm8OXtFgl2ktJ+Z8Ud2Vi/O9Qry+a3FDlea9DrfyboYi19Xqq20sEM 8GqN9qDuyogfqZ4bRhATjd/L1FNyD1+dMnWa0xuMeIKwuWDKlVNyVqBksW3ShU9KtrUF 4XjAaxrgm2k52JNd34NNtJXBsN+ACgdp4xmEzf5Hwbz1rlS0er+fLkAq87ajk8Mgn076 uNuM7xvXrTUGsV87ZLwD0YZ7WMVC3JFYqqULO78ClHrSNHcD1iaJkPf4iGcqJcjJntbY xPaA== X-Gm-Message-State: AMke39kQWEQkCHuFmUwBZY4vXkOVY1XAgseEi0yKleQUDQKefR353rkCVfjTHyIuXa1RjiIQvijj/G70+odQ7SM8 X-Received: by 10.37.33.133 with SMTP id h127mr2972741ybh.159.1488570808705; Fri, 03 Mar 2017 11:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.76.65 with HTTP; Fri, 3 Mar 2017 11:53:27 -0800 (PST) In-Reply-To: References: From: Al Cutter Date: Fri, 3 Mar 2017 19:53:27 +0000 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a1143e92a47139f0549d8e608 Archived-At: Cc: Trans Subject: Re: [Trans] STH Discipline & Security Considerations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:53:32 -0000 --001a1143e92a47139f0549d8e608 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 6:24 PM, Richard Barnes wrote: > Hey all, > > I wanted to follow up on my earlier comments and a bunch of side > conversations > I've had with people since then with a revised change proposal that I > think can > get -rfc6962-bis to a point we can live with. > > tl;dr: > 1. We/Mozilla can live with the Merkle tree for now, though we/community > might > ultimately want something different later > 2. At a systemic level, we need to move toward servers providing inclusion > proofs, but -rfc6962-bis provides sufficient tools for this > 3. We need to better document "STH discipline", and define a "canonical > STH" > for each element in the log > 4. We need to update the security considerations to describe more clearly > the > implications of various levels of auditing > > I'm willing to write up a PR for (2); EKR has volunteered for (3). > > > # Auditing Models > > There are basically two approaches to auditing available to clients: > > 1. Prospective: Browser does auditing checks at TLS connection time > 2. Retrospective: Browser does auditing checks after TLS connection time > > Prospective checking provides better assurance than retrospective, since it > prevents any harm that would come from a mis-issued, improperly-attested > certificate. The cost is that the server has to send enough information > the > cert and the browser has to cache enough information about the log that > the two > can be married up without further requests. > > In practice, however, it looks like some degree of retrospective checking > will > be necessary even in browsers that support the cache enough information for > prospective checking. On the one hand, if an inclusion proof can't be > embedded > in a cert, then we can't count on all server operators providing it (via > OCSP / > TLS). On the other hand, including proofs in certs imposes issuance delays > that will not be acceptable in many circumstances, even if it is > O(minutes). > > And given Eran's SSL proxy proposal, with the amendments I suggested, I'm > now > pretty well convinced that the fetches you need for retrospective > validation > can be done privately with something short of Tor (just). The scalability > problems are bad, but probably ultimately workable. > > It should be clear that either of these models work much better if the > server > provides inclusion proofs. Together with the STH discipline notions below, > this would enable prospective auditing for all but very new certificates > if a > browser is willing to cache STHs. Even in cases where CT information must > be > fetched, having the server send an inclusion proof would mean that the only > fetch would be for consistency, which is a less privacy-sensitive, more > cacheable query. > Here's a half-baked idea for a third (well, kinda), following on from today's theme of embedded proofs + STH, and an ecosystem with more open logs. Can we trust that some fraction of the logs in the ecosystem are honest? If so, then it feels like mostly the danger comes come allowing an issuer of cert to select which logs they want to log to, because they can choose their naughty log operator friends who'll collude. How about if we reduce the choice of logs, for example: 1. we define a function of, say, the hash of the log's public key to determine which of a fixed number of "groups" each log belongs to 2. we define a function of the hash of a precert (might be the same as [1]) which returns 1 (or perhaps several) groups to which that precert must be logged. 2. anyone creating a precert must log to the logs in the group(s) defined by the function in [2] 3. logs & CAs do their thing, proofs + STHs are embedded, certs are built, and websites updated. 4. the RP can verify the validity of the proofs, and the sigs on the STHs, but they can also verify that the STHs are from the set of logs the well known function [2] says they should for the precertificate they re-construct from the cert they were served (similar to how embedded SCTs are verified currently) IANAC, but I'm thinking that perhaps if the functions in [1] and [2] are sufficiently indistinguishable from random the client has reasonable confidence (given that we trust some fraction of the ecosystem is honest) that a bad cert will be detected by monitors and the game's up, and no need to talk to anyone (unless the proofs/sigs don't work and they want to tell someone about it). I suspect this precise scheme might be weak because of the low number of groups; perhaps it's too easy to "mine" log keys and percerts to line up groups, but maybe there are mitigations for that (e.g. making the hashing more expensive*, and/or requiring the not_before to be within some window of the embedded SCT timestamps so your mining work is wasted if you take too long, or maybe the groups functions also take issuance time into account, or only takes the domain from the first SAN, or the OU, or ... - I dunno, I said it was half-baked! Anyway, I'm sure there are people here who know a lot more about this sort of thing than I do. Perhaps you can pull a similar trick for logs too - forcing logs to commit to tree timelines in a set of locations defined by a function of the hash tree root from the STH they're logging (this is really a tweak to an idea Ben had about gossip a while back). * On the expensive hashing, I realise that it'd be undesirable for some classes of UAs (mobiles in particular) to have to perform the expensive hashing to verify the set of logs, but since I'm rattling on anyway, I vaguely recall a scheme from somewhere else (I don't remember where, sadly) which was cute: we define the hashing function to be, say, 100,000,000 rounds of SHA256 where each round is SHA256(hash_n-1||precert hash), then we embed the 99,999,999th hash somewhere in the cert so that the client can recalculate the last round using that and the reconstructed precert and verify the STHs come from the right group(s) - expensive for the logger, but cheap for the verifier. Ok, I'll stop now. Have a nice weekend, all. > > # STH Discipline > > Either style of auditing also works better if logs have a notion of "STH > discipline", in the following sense: > > 1. The official state of the log comprises a sequence of STHs issued at > specified intervals. > > 2. For each certificate in the log, there is a single "canonical STH" to > which > the log will produce an inclusion proof. Proofs to other STHs are done > by > adding a consistency proof to the inclusion proof. > > This property makes things work more smoothly in both auditing models: > > - If the browser is willing to cache STHs, this tells the browser exactly > which > STHs it needs to cache in order to validate all inclusion proofs. > > - Everything is more cacheable, since there's only one inclusion proof per > certificate, and a limited set of heads among which consistency needs to > be > calculated. > > - Cacheability means that the fetches of inclusion proofs get greater > privacy > benefit from caching, since they depend only on the certificate, not the > STH > that the client is using. Likewise for consistency proofs, because of > the > reduced variety. > > From a protocol point of view, I haven't done a thorough evaluation of the > document, but there are at least a few things you would want to make this > model > work: > > - Prose that articulates the above bounds on logs / inclusion proofs / > STHs. > Probably a notion of "STH issuance frequency" parallel to MMD. > > - A field in an SCT that indicates the canonical STH for the certificate in > question. Possibly a serial number in STH that SCTs could refer to. > > - An API endpoint for fetching STHs in the official sequence (in addition > to > the current one, which is the only option right now). > > If this line of thinking sounds generally sane to people, I'll take a pass > through the document and make some concrete proposals. > > Thanks, > --Richard > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a1143e92a47139f0549d8e608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 6:24 PM, Richard Barnes <rlb@ipv.sx> wro= te:
Hey all,

I wa= nted to follow up on my earlier comments and a bunch of side conversations<= br>I've had with people since then with a revised change proposal that = I think can
get -rfc6962-bis to a point we can live with.

tl;dr:<= br>1. We/Mozilla can live with the Merkle tree for now, though we/community= might
=C2=A0=C2=A0 ultimately want something different later
2. At a= systemic level, we need to move toward servers providing inclusion
=C2= =A0=C2=A0 proofs, but -rfc6962-bis provides sufficient tools for this
3.= We need to better document "STH discipline", and define a "= canonical STH"
=C2=A0=C2=A0 for each element in the log
4. We ne= ed to update the security considerations to describe more clearly the
= =C2=A0=C2=A0 implications of various levels of auditing

I'm will= ing to write up a PR for (2); EKR has volunteered for (3).


# Aud= iting Models

There are basically two approaches to auditing availabl= e to clients:

1. Prospective: Browser does auditing checks at TLS co= nnection time
2. Retrospective: Browser does auditing checks after TLS c= onnection time

Prospective checking provides better assurance than r= etrospective, since it
prevents any harm that would come from a mis-issu= ed, improperly-attested
certificate.=C2=A0 The cost is that the server h= as to send enough information the
cert and the browser has to cache enou= gh information about the log that the two
can be married up without furt= her requests.

In practice, however, it looks like some degree of ret= rospective checking will
be necessary even in browsers that support the = cache enough information for
prospective checking.=C2=A0 On the one hand= , if an inclusion proof can't be embedded
in a cert, then we can'= ;t count on all server operators providing it (via OCSP /
TLS).=C2=A0 On= the other hand, including proofs in certs imposes issuance delays
that = will not be acceptable in many circumstances, even if it is O(minutes).
=
And given Eran's SSL proxy proposal, with the amendments I suggeste= d, I'm now
pretty well convinced that the fetches you need for retro= spective validation
can be done privately with something short of Tor (j= ust).=C2=A0 The scalability
problems are bad, but probably ultimately wo= rkable.

It should be clear that either of these models work much bet= ter if the server
provides inclusion proofs.=C2=A0 Together with the STH= discipline notions below,
this would enable prospective auditing for al= l but very new certificates if a
browser is willing to cache STHs.=C2=A0= Even in cases where CT information must be
fetched, having the server s= end an inclusion proof would mean that the only
fetch would be for consi= stency, which is a less privacy-sensitive, more
cacheable query.

Here's a half-baked idea for a third= (well, kinda), following on from today's theme of embedded proofs + ST= H, and an ecosystem with more open logs.

Can we tr= ust that some fraction of the logs in the ecosystem are honest?
I= f so, then it feels like mostly the danger comes come allowing an issuer of= cert to select which logs they want to log to, because they can choose the= ir naughty log operator friends who'll collude.

How about if we reduce the choice of logs, for example:
1. we d= efine a function of, say, the hash of the log's public key to determine= which of a fixed number of "groups" each log belongs to
2. we define a function of the hash of a precert (might be the same as [1= ]) which returns 1 (or perhaps several) groups to which that precert must b= e logged.
2. anyone creating a precert must log to the logs in th= e group(s) defined by the function in [2]
3. logs & CAs do th= eir thing, proofs + STHs are embedded, certs are built, and websites update= d.
4. the RP can verify the validity of the proofs, and the sigs = on the STHs, but they can also verify that the STHs are from the set of log= s the well known function [2] says they should for the precertificate they = re-construct from the cert they were served (similar to how embedded SCTs a= re verified currently)

IANAC, but I'm thinking= that perhaps if the functions in [1] and [2] are sufficiently indistinguis= hable from random the client has reasonable confidence (given that we trust= some fraction of the ecosystem is honest) that a bad cert will be detected= by monitors and the game's up, and no need to talk to anyone (unless t= he proofs/sigs don't work and they want to tell someone about it).

I suspect this precise scheme might be weak because of= the low number of groups; perhaps it's too easy to "mine" lo= g keys and percerts to line up groups, but maybe there are mitigations for = that (e.g. making the hashing more expensive*, and/or requiring the not_bef= ore to be within some window of the embedded SCT timestamps so your mining = work is wasted if you take too long, or maybe the groups functions also tak= e issuance time into account, or only takes the domain from the first SAN, = or the OU, or ... - I dunno, I said it was half-baked! Anyway, I'm sure= there are people here who know a lot more about this sort of thing than I = do.

Perhaps you can pull a similar trick for logs = too - forcing logs to commit to tree timelines in a set of locations define= d by a function of the hash tree root from the STH they're logging (thi= s is really a tweak to an idea Ben had about gossip a while back).

* On the expensive hashing, I realise that it'd be und= esirable for some classes of UAs (mobiles in particular) to have to perform= the expensive hashing to verify the set of logs, but since I'm rattlin= g on anyway, I vaguely recall a scheme from somewhere else (I don't rem= ember where, sadly) which was cute: =C2=A0we define the hashing function to= be, say, 100,000,000 rounds of SHA256 where each round is SHA256(hash_n-1|= |precert hash), then we embed the 99,999,999th hash somewhere in the cert s= o that the client can recalculate the last round using that and the reconst= ructed precert and verify the STHs come from the right group(s) - expensive= for the logger, but cheap for the verifier.

Ok, I= 'll stop now.
Have a nice weekend, all.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


# STH Discipline
=
Either style of auditing also works better if logs have a notion of &qu= ot;STH
discipline", in the following sense:

1. The official = state of the log comprises a sequence of STHs issued at
=C2=A0=C2=A0 spe= cified intervals.

2. For each certificate in the log, there is a sin= gle "canonical STH" to which
=C2=A0=C2=A0 the log will produce= an inclusion proof.=C2=A0 Proofs to other STHs are done by
=C2=A0=C2=A0= adding a consistency proof to the inclusion proof.

This property ma= kes things work more smoothly in both auditing models:

- If the brow= ser is willing to cache STHs, this tells the browser exactly which
=C2= =A0 STHs it needs to cache in order to validate all inclusion proofs.
- Everything is more cacheable, since there's only one inclusion proo= f per
=C2=A0 certificate, and a limited set of heads among which consist= ency needs to be
=C2=A0 calculated.

- Cacheability means that the= fetches of inclusion proofs get greater privacy
=C2=A0 benefit from cac= hing, since they depend only on the certificate, not the STH
=C2=A0 that= the client is using.=C2=A0 Likewise for consistency proofs, because of the=
=C2=A0 reduced variety.

From a protocol point of view, I haven&#= 39;t done a thorough evaluation of the
document, but there are at least = a few things you would want to make this model
work:

- Prose that= articulates the above bounds on logs / inclusion proofs / STHs.
=C2=A0 = Probably a notion of "STH issuance frequency" parallel to MMD.
- A field in an SCT that indicates the canonical STH for the certifica= te in
=C2=A0 question.=C2=A0 Possibly a serial number in STH that SCTs c= ould refer to.

- An API endpoint for fetching STHs in the official s= equence (in addition to
=C2=A0 the current one, which is the only option= right now).

If this line of thinking sounds generally sane to peopl= e, I'll take a pass
through the document and make some concrete prop= osals.

Thanks,
--Richard

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


--001a1143e92a47139f0549d8e608-- From nobody Fri Mar 3 12:32: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 45B57129616 for ; Fri, 3 Mar 2017 12:32:30 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T05OCizDLanL for ; Fri, 3 Mar 2017 12:32:27 -0800 (PST) Received: from dwdccgokm1.dela.clif.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:400:430::d201:8a76]) (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 0626C129615 for ; Fri, 3 Mar 2017 12:32:26 -0800 (PST) Received: (korumail 22041 invoked from network); 3 Mar 2017 20:32:25 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 3 Mar 2017 20:32:25 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703032032241183; Fri, 03 Mar 2017 20:32:24 +0000 To: Kurt Roeckx , Richard Barnes References: <20170303192951.xqcdta6uc2ukgriv@roeckx.be> From: Rob Stradling Message-ID: Date: Fri, 3 Mar 2017 20:32:23 +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: <20170303192951.xqcdta6uc2ukgriv@roeckx.be> X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Zakir Durumeric , trans@ietf.org, Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:32:30 -0000 On 03/03/17 19:29, Kurt Roeckx wrote: > On Thu, Mar 02, 2017 at 06:58:49PM -0500, Richard Barnes wrote: >> The upshot is that this style of logging seems eminently feasible. Almost >> all CT logs are growing at well less than 10qps [2], and even Let's Encrypt >> on its worst days only generates about 115qps. And I have pretty high >> confidence that if you actually put some thought into designing the storage >> scheme, you could get some additional margin here. > > Let's encrypt seems to be doing around 1M per day on "its worst > days", which is still only in the range of 10 per second. That assumes an even distribution throughout the day, which isn't the reality. A couple of days ago, Google's Pilot log generated 582 SCTs during a single second (2017-03-01 14:01:07 UTC). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Mar 3 16:01:38 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 8F35B129A47; Fri, 3 Mar 2017 15:55:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533558.15846.17869492344342361459.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:35 -0800 Archived-At: Cc: trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Requested session has been scheduled 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: Fri, 03 Mar 2017 23:55:36 -0000 Dear Melinda Shore, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:30:00) Tuesday, Afternoon Session I 1300-1430 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- 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 People who must be present: Stephen Farrell Melinda Shore Paul Wouters Resources Requested: Projector in room Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sun Mar 5 22:06: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 F252E127071 for ; Sun, 5 Mar 2017 22:06:37 -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 w9D6j_0hDJZM for ; Sun, 5 Mar 2017 22:06:37 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EE212961B for ; Sun, 5 Mar 2017 22:06:33 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id i1so106144704ota.3 for ; Sun, 05 Mar 2017 22:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=m0/kqAotCrOgqSoNz4N4wDSX4C3GHFKhRYc7six5ZOM=; b=NvszMF9DED89HkmGT0M0XlVP0UqKEtCEgml62tujK+4PwwvIAv3shwOHusr3OkuTbr svdCZTSWVfoInLAuQ9+6iyHu7I4wpDglx7607u4tjvx5d5u2dk3Knw6n+tX/RTYQ10+2 51zEYtVsh85IkqxSoTzb/FUmGZA8hJNGUSTfFesSMwzzCgZFclKhQGxErHPnsfI1cjzz 3fPGAUNCxI3VH57glw6SygmtSr17HkH7rviPimfsuPyyEy9yD3zrv4/Pft3HLn0fB3I/ 5+ozq5enDrehM3Do6+x2qf02Jy7JeYXp/SHsz6RN1AbNt8mwJwuiDWYhB46k8th7HHbq ZF2w== 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=m0/kqAotCrOgqSoNz4N4wDSX4C3GHFKhRYc7six5ZOM=; b=neD8cms5SYoqxMdmty7VtQyqAJ5mF6NzDo+49NoUl/vy0saLiw84udg6aMzVxJAP/T gwRci9yhaqTzJy4YK5lQ9g6nVXxjVXOdLLRqkWsgZUzlBKU3wMcElN/yyKd2o3Eh/CzN jqhomBphoprFvaSuEOTsq08Ha1K6V3l8Quf9vDLJWG85IaS9bSIPvwOMuFFMGX/1uXqv 2yLFFv5gOqJkGFwFfjRHkr1SC56z8NtcyQX8hv2sx21JyoTCyY6wgdqhNqQXDcf3JKuG 4SxeX0IFcf4pfeJz4y/DSib3fgKm2q5fSDAsqQ4HJnXXKJpfDi9K7hG0v7E60byXX9KN ftPQ== X-Gm-Message-State: AMke39lQBXcB07tbIyXypXXMb72bvBkXn/DHJFWRTC2yd3yORNlE3zEoxMA6HfwC81rHlnNLts1YrULg79xWnw== X-Received: by 10.157.15.253 with SMTP id m58mr7442207otd.209.1488780392131; Sun, 05 Mar 2017 22:06:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Sun, 5 Mar 2017 22:06:31 -0800 (PST) From: Peter Bowen Date: Sun, 5 Mar 2017 22:06:31 -0800 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Reviving Redaction 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, 06 Mar 2017 06:06:38 -0000 I started to review the redaction draft to determine current state, but realized that it isn't clear we have a common baseline from which to start any review. I've put together a few statements that I think are true, but would like to see if others agree. 1) A registered domain is a label plus a registration suffix, which is frequently the TLD. The existence (or non-existence) of a registered domain is public information. Rationale: The zone files for all ICANN gTLDs, are available for download. While some ccTLDs don't offer similar service, the basic registered/registerable domain should not be considered private information. 2) Logging certificates to a CT log is optional. An unlogged certificate may not be accepted by some clients or relying parties, but is not a mis-issued certificate. Rationale: While some might want to see 100% logging, it is clear there is not currently support for making it mandatory. 3) Split horizon DNS exists as does delegation to private name servers. This means that names that are unique in the global namespace might not be resolvable from the public Internet. Rationale: Many TLDs allow DNS name servers to have addresses in reserved IP ranges that are not designated as globally unique (e.g. in 10.0.0.0/8). Even if the TLD does not, subordinate domain of registered domains may have such. Even if using public IP addresses, network ACLs may prevent access. 4) Given a full certificate, it must be possible to deterministically reconstruct the precertificate. Rationale: Without this, it becomes impossible to determine if a signature of a precertificate matches the final certificate. 5) Given a precertificate and full certificate, it should be possible to confirm the full certificate is the only viable match for the precertificate. Rationale: If multiple different full certificates could reasonably match a single precertificate, then it becomes trivial to issue "hidden" certificates. 6) Given a precertificate and full certificate, it should not be possible to (re)construct other full certificates given only their precertificates. Rationale: Leak/discovery of a single full certificate should not cause a system collapse. 7) The only entity that knows if a certificate for their domain was not supposed to be issued is entity who was the domain registrant at the time of issuance. Rationale: While others can guess based on heuristics, only the registrant can say with authority "I think this was unauthorized" 8) The only way to get the content of a full certificate is to have a full certificate. Rationale: An alternative option is to have some sort of escrow key that can "unlock" a precertificate. This quickly turns into 'where do we keep the escrow key?' and 'who gets to access the escrow key?'. If there is no such thing, then these questions don't exist. Do others agree that these are true and can be used as givens for reviewing any proposed designs? Thanks, Peter From nobody Mon Mar 6 06:48: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 771731297CF for ; Mon, 6 Mar 2017 06:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, 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 VPAbNZHQ1NbE for ; Mon, 6 Mar 2017 06:48:56 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E5E99129449 for ; Mon, 6 Mar 2017 06:48:55 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 48FB943342D; Mon, 6 Mar 2017 14:48:45 +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 320EB433417; Mon, 6 Mar 2017 14:48:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488811725; bh=LwsBeDTm8mjfzTi05XHiCzkxYSND/MCPgQT0YSMFfCw=; l=72; h=From:To:Date:References:In-Reply-To:From; b=GMbecUHeSCMEAm6/cr5PTzYqAP8zx81qb+ja5tWHJ9+tA9kkuPLjS/9lPetDTVzev GK6QO6gZz3eSYvcCOVXizevSzjoG5dfEi7CTOC4Xw6tvtn8wTVC3gfnZ5/HAv6Qlnr CYXBAUTYm9NAisr11hW6AJvSaunRPp3DPTlHX/+0= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2E54D1FC88; Mon, 6 Mar 2017 14:48:45 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Mar 2017 09:48:44 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Mon, 6 Mar 2017 09:48:44 -0500 From: "Salz, Rich" To: Peter Bowen , "trans@ietf.org" Thread-Topic: [Trans] Reviving Redaction Thread-Index: AQHSlj/WFPtl5rorEUu1yEmLjcFcNqGH5O1A Date: Mon, 6 Mar 2017 14:48:44 +0000 Message-ID: <9e2135521bb14ac99166bcb0b169cf3f@usma1ex-dag1mb3.msg.corp.akamai.com> 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.85] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 14:48:57 -0000 Looks great, but what does viable mean in "is the only viable match" ? From nobody Mon Mar 6 07:06: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 A0B0F1297EA for ; Mon, 6 Mar 2017 07:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 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, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daHzWHSyaW1S for ; Mon, 6 Mar 2017 07:05:56 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2E6128824 for ; Mon, 6 Mar 2017 07:05:56 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 19so43713148oti.0 for ; Mon, 06 Mar 2017 07:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RFH1B+6FWb6MRPge7DWkA0eTJ4y+4WVFDqF1SM3DMnU=; b=mkhkbjljHhIlubOA0g25FreU9/GhTf17WjmtiPng+xGer03M4ETmRXYcUtnOmA7F9b aQfuA2Xp4GZqVw2zLQtR8cgJ1hIZhmREYxpcXlm5mBT2pdkBdRB/dSFwZqrxrIO6lJjj JHcBpT1TIjyx9Skfp6dNYDrEtxBNsdprx3BhfjVyUU4Bm6DB5BBWKOirqOGh1YPWCBWX 0jWgzxCDfFlKc9bcgtedxvV00qGIB9/ctu26hHUcLuvHO/ogSOSNRnPxcmLJcjeKNFRX 7rGa9/624thSseRLsks+gN6Ty3u/12Dx38rgVzPmdsaausYtIFzw/ejv5QCTZkx/Prg+ qPng== 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=RFH1B+6FWb6MRPge7DWkA0eTJ4y+4WVFDqF1SM3DMnU=; b=O+pWtph+KmUHfFSw6J4qfVv+Ubftflss6cHpk4Z1/0kvyeToSX3LcCoDJ2lCAR71aA EiffVWDIXg0HC8F3UTLJ6d/XXJFNIYTXK4rxESANBugdwSDHUgIrAbwcuhnAw01SyA/w MyZNkvskU6YWnQMq4ouClsJqmZUCIWjXCtQ/NA4iGjgtsQP7YDGj3WZX1YuBbhCUbffC IU/lW1+C8gq2nMVG1iImfFGJruqOjv28yH0SOqYNvap1ZeMhgjWaw4idY9ZeFHzx//z6 jCURJpZ39LRw5j6h9wdZC0mmU2PXRPRmOeEHMOP3vkn6+l/6KM+JAPeStA8PcgLTrtEv dXCw== X-Gm-Message-State: AMke39l843aXWRf1VTL64m49wmAnWpbZSB2IqyZSqCLIo4dgb5ml+V1sTPtkNkqzZDgZq2Rj2IqYuC09VVuGaw== X-Received: by 10.157.15.253 with SMTP id m58mr8499268otd.209.1488812756278; Mon, 06 Mar 2017 07:05:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Mon, 6 Mar 2017 07:05:55 -0800 (PST) In-Reply-To: <9e2135521bb14ac99166bcb0b169cf3f@usma1ex-dag1mb3.msg.corp.akamai.com> References: <9e2135521bb14ac99166bcb0b169cf3f@usma1ex-dag1mb3.msg.corp.akamai.com> From: Peter Bowen Date: Mon, 6 Mar 2017 07:05:55 -0800 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 15:05:57 -0000 On Mon, Mar 6, 2017 at 6:48 AM, Salz, Rich wrote: > Looks great, but what does viable mean in "is the only viable match" ? For example, if a redacted name looks like '??.example.com' and the definition of '??' is "matches one or more labels", then a precert with: "dNSName:??.example.com, dNSName:??.example.com, dNSName:??.example.com" could match infinite names. On the other hand, a redacted name is "??ab347e5e.example.com" and the value after the "??" is a truncated hash, then the number of matches is much lower. Once you consider that these are dNSName, so the only valid characters are a-z, A-Z, 0-9, '-', '.', and maybe '_', the chance of two strings colliding is very low, even with a severely truncated hash. If the '??' rule is used, then a malicious CA could issue two different certificates with the same serial number, one that is "innocent" and one that has the real target name. Thanks, Peter From nobody Mon Mar 6 07:12: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 18624128824 for ; Mon, 6 Mar 2017 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-0.001, 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 A-p4CBeh_p4i for ; Mon, 6 Mar 2017 07:12:49 -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 2E2AC129801 for ; Mon, 6 Mar 2017 07:12:49 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8C1D116CA56; Mon, 6 Mar 2017 15:12:48 +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 7606016C86C; Mon, 6 Mar 2017 15:12:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488813168; bh=mdn8A/c9XEm72iiRTnCJ2wyfdPCABP9G4pW+jQi3J1w=; l=264; h=From:To:CC:Date:References:In-Reply-To:From; b=ZG2rhsxKQ6eWF2m1tVAK3XSLJeLhzwyzpTHBNRXtXFKhmQ6optfPuV7qp23UyBbLU Ird7uE4RiPAGmeRbKEHFai1CFae+Vqw/YCw2wem1Kwib2UvL+yZeZ08BtDkeAdUG6d h1XcvLxvo28/SSkEcmHkakQLF/BIFwRpAAcJFKa8= 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 5BAE198082; Mon, 6 Mar 2017 15:12:48 +0000 (GMT) Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 6 Mar 2017 10:12:47 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1178.000; Mon, 6 Mar 2017 10:12:47 -0500 From: "Salz, Rich" To: Peter Bowen Thread-Topic: [Trans] Reviving Redaction Thread-Index: AQHSlj/WFPtl5rorEUu1yEmLjcFcNqGH5O1AgABYs4D//64KgA== Date: Mon, 6 Mar 2017 15:12:46 +0000 Message-ID: References: <9e2135521bb14ac99166bcb0b169cf3f@usma1ex-dag1mb3.msg.corp.akamai.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.34.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 15:12:50 -0000 PiBPbiBNb24sIE1hciA2LCAyMDE3IGF0IDY6NDggQU0sIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1h aS5jb20+IHdyb3RlOg0KPiA+IExvb2tzIGdyZWF0LCBidXQgd2hhdCBkb2VzIHZpYWJsZSBtZWFu IGluICJpcyB0aGUgb25seSB2aWFibGUgbWF0Y2giID8NCj4gDQo+IEZvciBleGFtcGxlIC4uLg0K DQpHb3QgaXQsIHRoYW5rcy4NCg== From nobody Mon Mar 6 08:27: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 2978D129546 for ; Mon, 6 Mar 2017 08:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9S1hyNd9z-8 for ; Mon, 6 Mar 2017 08:27:03 -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 4E78F129540 for ; Mon, 6 Mar 2017 08:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1488817622; bh=3IunS6mIh6C0IR0rwSc4+xHsjbMXFX76/GyvMZqMXiw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=bPFaASyvfJh0OmB9+GJX+qRmtDH9UkInJUw6fSBjeMkyzn0kLco5fTasPNEHIkzpK 1CrR17yc86SVkGbwPAfog45NkRoio6yiLsoT4f3ixFeonvgyIx1wvC16T1S66SqaBR YbGkqAH5+PytQ1gO9VbYFsFQ7QITNGARtJVCYSGWs97AYhF2m4FZlwENmGDon60PfT FEA8Xme8d6X2j6wWwN3tuPS3uO4ZEdnswroVEFunw7+pEFfxsc33YyHilP9IHEzemT UqVsXUWJBY5cU6n+Eks4b0HOmHbuQssZbtx8WiX91hR2W0LUUqB+JVDq3huiAVhi8i H+LmZz1F7w8MA== Date: Mon, 6 Mar 2017 08:27:01 -0800 From: Andrew Ayer To: Peter Bowen Message-Id: <20170306082701.e78b6e5f02d2edfe04c8af12@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] Reviving Redaction 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, 06 Mar 2017 16:27:04 -0000 Hi Peter, I generally agree with your list of statements, but #7 is imprecise: On Sun, 5 Mar 2017 22:06:31 -0800 Peter Bowen wrote: > 7) The only entity that knows if a certificate for their domain was > not supposed to be issued is entity who was the domain registrant at > the time of issuance. To be more precise, the only entity that knows if a certificate for their domain *did not undergo proper domain validation* is the entity who was the domain registrant at the time of issuance[1]. Many other types of misissuances can be detected by anyone, such as SHA-1, encoding errors, illegal characters in dnsName SANs, overly-long validity, etc. Regards, Andrew [1] technically, at the time the CA is required to check, but that's beside the point From nobody Mon Mar 6 11:12: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 A20DE12987F for ; Mon, 6 Mar 2017 11:12:41 -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 j0BcvkRedGOx for ; Mon, 6 Mar 2017 11:12:40 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 3695512997D for ; Mon, 6 Mar 2017 11:12:40 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id n11so73116893wma.0 for ; Mon, 06 Mar 2017 11:12:40 -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=OKGjrqRmnfGQ66jW5qVbdZ0dIJH+UlIqlkpm6NH1DuA=; b=RzbLxB81oVCfmlWIB3bO5maLi0HJy9/UBlYkWgvI0VD28wDwr9Z91d2/FXdYKVyYyC GEna/BuTGvyYbdbTapUYjrilJJ9Dx5M+r5bG+y4h4kkZLkW3eQtn7/saffersUY5CO5f GeoKpajefitpCVO05ZXfpY3I86ZnJ+CysitcVHyYvahPWRDrKBmR04+eoFMGflBC/f+R w+ioPaLlD6rupF4Cu6MrRUq/utt4cHo/dQDPqC2faPT79w/1O8T48e2VvznLiv/T5LqV ah3qV2DxqhkIPSsgWTl5mNq2fhmx5qMABaDC4PnMXaDi6VOrFUeGzNPhm2Ktkplt9OHb +DAA== 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=OKGjrqRmnfGQ66jW5qVbdZ0dIJH+UlIqlkpm6NH1DuA=; b=fAFhIZpq5+rnnzcoP7lwc4GRIv3bLH5VWTwxWzPB4YLVVp9tZZzWksRBvSlIR5vxQ4 7aUbW4tiYT7FPaICe9P6lxPmvdSleGze13JgzpQm3hB9jHaivkcWqjyxDJKmWpDx9LCY b4/acyTNJLbakDsOK+MBmUvEn6WtjWfykurvgjAcK96m/5rNaz4uxQHt4t2JAHQkiD9s NXoBh/n6+ondfQgZYYxR4MhGqG8z49QUUlVHBITuW+9rGuXRODkw0lYB42mjCfHZY/qh 7bANJsU7i+yjaExO2jl6LveEwPjXHkW94za7AUbv4fDNHgD01qquke6AnUjHCemrXMcf dGvw== X-Gm-Message-State: AMke39ncX/uV8HBpFjielukCqoFhK1zPa8Q4QQowMzM4CQEZdVROm6cpUlHRAfP0vTRdTqSOIR8os59zOUPdGg== X-Received: by 10.28.93.68 with SMTP id r65mr15699296wmb.133.1488827558271; Mon, 06 Mar 2017 11:12:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Mon, 6 Mar 2017 11:12:37 -0800 (PST) In-Reply-To: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name> References: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name> From: Richard Barnes Date: Mon, 6 Mar 2017 14:12:37 -0500 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=001a11467a9abe4237054a14ada9 Archived-At: Cc: Trans Subject: Re: [Trans] STH Discipline & Security Considerations 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, 06 Mar 2017 19:12:41 -0000 --001a11467a9abe4237054a14ada9 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 2:09 PM, Andrew Ayer wrote: > On Fri, 3 Mar 2017 13:24:51 -0500 > Richard Barnes wrote: > > > # STH Discipline > > > > Either style of auditing also works better if logs have a notion of > > "STH discipline", in the following sense: > > > > 1. The official state of the log comprises a sequence of STHs issued > > at specified intervals. > > > > 2. For each certificate in the log, there is a single "canonical STH" > > to which > > the log will produce an inclusion proof. > > To be clear, would there still be a way to get inclusion proofs to > non-canonical STHs? Clients wouldn't have to use them if they didn't > want to. > I could go either way. My preference would probably be to make it OPTIONAL for a log to provide such proofs, because caching. The client can always just fetch the canonical proof and consistency. (Maybe that needs to be a new endpoint.) > > Proofs to other STHs are > > done by > > adding a consistency proof to the inclusion proof. > > > > This property makes things work more smoothly in both auditing models: > > > > - If the browser is willing to cache STHs, this tells the browser > > exactly which > > STHs it needs to cache in order to validate all inclusion proofs. > > > > - Everything is more cacheable, since there's only one inclusion > > proof per certificate, and a limited set of heads among which > > consistency needs to be > > calculated. > > > > - Cacheability means that the fetches of inclusion proofs get greater > > privacy > > benefit from caching, since they depend only on the certificate, > > not the STH > > that the client is using. Likewise for consistency proofs, because > > of the reduced variety. > > > > >From a protocol point of view, I haven't done a thorough evaluation > > >of the > > document, but there are at least a few things you would want to make > > this model > > work: > > > > - Prose that articulates the above bounds on logs / inclusion > > proofs / STHs. Probably a notion of "STH issuance frequency" parallel > > to MMD. > > > > - A field in an SCT that indicates the canonical STH for the > > certificate in question. Possibly a serial number in STH that SCTs > > could refer to. > > Is this necessary? Why not define the canonical STH as the first STH > issued after the SCT (based on timestamp)? > The reason you want an indicator in the SCT is so that you know which STH to ask for, e.g., if you're fetching a consistency proof. Otherwise, you have to scan around for the right one. > > - An API endpoint for fetching STHs in the official sequence (in > > addition to the current one, which is the only option right now). > > +1. I think any privacy-preserving auditing mechanism will need such an > endpoint so that STHs can be reliably distributed to clients. > Thanks for the feedback! --Richard > > Regards, > Andrew > --001a11467a9abe4237054a14ada9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 2:09 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
On = Fri, 3 Mar 2017 13:24:51 -0500
Richard Barnes <rlb@ipv.sx> wrote:

> # STH Discipline
>
> Either style of auditing also works better if logs have a notion of > "STH discipline", in the following sense:
>
> 1. The official state of the log comprises a sequence of STHs issued > at specified intervals.
>
> 2. For each certificate in the log, there is a single "canonical = STH"
> to which
>=C2=A0 =C2=A0 the log will produce an inclusion proof.

To be clear, would there still be a way to get inclusion proofs to non-canonical STHs?=C2=A0 Clients wouldn't have to use them if they did= n't
want to.

=
I could go either way.=C2=A0 My preference would probably be to make i= t OPTIONAL for a log to provide such proofs, because caching.=C2=A0 The cli= ent can always just fetch the canonical proof and consistency.=C2=A0 (Maybe= that needs to be a new endpoint.)

=C2=A0
> Proofs to other STHs are
> done by
>=C2=A0 =C2=A0 adding a consistency proof to the inclusion proof.
>
> This property makes things work more smoothly in both auditing models:=
>
> - If the browser is willing to cache STHs, this tells the browser
> exactly which
>=C2=A0 =C2=A0STHs it needs to cache in order to validate all inclusion = proofs.
>
> - Everything is more cacheable, since there's only one inclusion > proof per certificate, and a limited set of heads among which
> consistency needs to be
>=C2=A0 =C2=A0calculated.
>
> - Cacheability means that the fetches of inclusion proofs get greater<= br> > privacy
>=C2=A0 =C2=A0benefit from caching, since they depend only on the certif= icate,
> not the STH
>=C2=A0 =C2=A0that the client is using.=C2=A0 Likewise for consistency p= roofs, because
> of the reduced variety.
>
> >From a protocol point of view, I haven't done a thorough evalu= ation
> >of the
> document, but there are at least a few things you would want to make > this model
> work:
>
> - Prose that articulates the above bounds on logs / inclusion
> proofs / STHs. Probably a notion of "STH issuance frequency"= parallel
> to MMD.
>
> - A field in an SCT that indicates the canonical STH for the
> certificate in question.=C2=A0 Possibly a serial number in STH that SC= Ts
> could refer to.

Is this necessary?=C2=A0 Why not define the canonical STH as th= e first STH
issued after the SCT (based on timestamp)?

The reason you want an indicator in the SCT is = so that you know which STH to ask for, e.g., if you're fetching a consi= stency proof.=C2=A0 Otherwise, you have to scan around for the right one.

=C2=A0
> - An API endpoint for fetching STHs in the official sequence (in
> addition to the current one, which is the only option right now).

+1. I think any privacy-preserving auditing mechanism will need such= an
endpoint so that STHs can be reliably distributed to clients.

Thanks for the feedback!

--Richard=

=C2=A0

Regards,
Andrew

--001a11467a9abe4237054a14ada9-- From nobody Mon Mar 6 11:35: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 913ED12999E for ; Mon, 6 Mar 2017 11:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=pobox.com header.b=TwdoA1fU; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=I8hbnPwe 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 mVrr1I3q_n0o for ; Mon, 6 Mar 2017 11:35:36 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D99129443 for ; Mon, 6 Mar 2017 11:35:35 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id E39F86ED16 for ; Mon, 6 Mar 2017 14:35:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=8/0Hk8hwOOnBEGGZb4AQ2nZ80jQ=; b=TwdoA1 fUZziyIl82TjQLLH3HuUW4h+KyvgvDOBgbS5GUtpt+vxq8JdF15GiTXl/Mx1C5Mf 6ZO0XhGNwgW1UO1i+xtLMVfAga0RB0B9HyD0wq2pgNZ19UShf9GGoL75C3Y3+ZhC a7Ia6TLUQqp9Ct2wmSYVIypRbYjQalj8ZHx5s= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CFA296ED15 for ; Mon, 6 Mar 2017 14:35:34 -0500 (EST) Received: from mail-yw0-f172.google.com (unknown [209.85.161.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 5E0916ED13 for ; Mon, 6 Mar 2017 14:35:34 -0500 (EST) Received: by mail-yw0-f172.google.com with SMTP id o4so67814395ywd.3 for ; Mon, 06 Mar 2017 11:35:34 -0800 (PST) X-Gm-Message-State: AMke39lpoJi9CtPhKF6o/EYwdRV8wdeIaB+xzrTURd1lfBTymf7CBTDElxd1CZGurW7lzlHLoTnwuyGx6vyz6g== X-Received: by 10.37.75.131 with SMTP id y125mr12948315yba.160.1488828933515; Mon, 06 Mar 2017 11:35:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.119.14 with HTTP; Mon, 6 Mar 2017 11:34:53 -0800 (PST) In-Reply-To: References: From: Eric Mill Date: Mon, 6 Mar 2017 14:34:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=94eb2c092c48b6b3da054a14ff39 X-Pobox-Relay-ID: 112A1674-02A4-11E7-AAC7-97B1B46B9B0B-82875391!pb-smtp1.pobox.com DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=8/0Hk8hwOOnBEGGZb4AQ2nZ80jQ=; b=I8hbnPwegouHl5AjF5FUFJ9Y5rreExecrZp2y28bZ6i71+Uqxd2vYSfXM9TnohoWK+b961RyYxZdA56mPVcWg5iEZmXVOgoFLa1x2ixC2E2Fx1gd/IMm3/sZn2YTM+JOwhcbsk89aVqCLwTuFiIwqGorBEGgbQfF0Zo/lnr2d0o= Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 19:35:38 -0000 --94eb2c092c48b6b3da054a14ff39 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen wrote: > > 2) Logging certificates to a CT log is optional. An unlogged > certificate may not be accepted by some clients or relying parties, > but is not a mis-issued certificate. > > Rationale: While some might want to see 100% logging, it is clear > there is not currently support for making it mandatory. Just to be clear, I think you're saying there is not currently support by *any* client or relying party for making non-logging equivalent to misissuance. That is different than saying that there is not currently broad support across the client/RP ecosystem for refusing to accept non-logged certificates. > 7) The only entity that knows if a certificate for their domain was > not supposed to be issued is entity who was the domain registrant at > the time of issuance. > > Rationale: While others can guess based on heuristics, only the > registrant can say with authority "I think this was unauthorized" > While this is true, including Andrew's caveats, this does risk unintentionally implying that the only benefit to CT that must be considered when discussing redaction proposals is that of detecting certificates issued without proper domain validation control. CT provides broader benefits than that, some of which are implied by Andrew's notes about automatable detections of BR Violations. Some benefits can also be seen in the identification of undisclosed cross-signatures that create gaps in the audited PKI that can range from small to tremendously large. -- Eric > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- konklone.com | @konklone --94eb2c092c48b6b3da054a14ff39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen <pzbowen@gmail.com>= wrote:

2) Logging certificates to a CT log is optional.=C2=A0 An unlogged
certificate may not be accepted by some clients or relying parties,
but is not a mis-issued certificate.

Rationale: While some might want to see 100% logging, it is clear
there is not currently support for making it mandatory.
Just to be clear, I think you're saying there is not curre= ntly support by *any* client or relying party for making non-logging equiva= lent to misissuance. That is different than saying that there is not curren= tly broad support across the client/RP ecosystem for refusing to accept non= -logged certificates.
=C2=A0
7) The only entity that knows if a certificate for their domain was
not supposed to be issued is entity who was the domain registrant at
the time of issuance.

Rationale: While others can guess based on heuristics, only the
registrant can say with authority "I think this was unauthorized"=

While this is true, including Andrew&#= 39;s caveats, this does risk unintentionally implying that the only benefit= to CT that must be considered when discussing redaction proposals is that = of detecting certificates issued without proper domain validation control.<= /div>

CT provides broader benefits than that, some of wh= ich are implied by Andrew's notes about automatable detections of BR Vi= olations. Some benefits can also be seen in the identification of undisclos= ed cross-signatures that create gaps in the audited PKI that can range from= small to tremendously large.

-- Eric
= =C2=A0

Thanks,
Peter

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



--
--94eb2c092c48b6b3da054a14ff39-- From nobody Mon Mar 6 13:16: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 2E52D129A1E for ; Mon, 6 Mar 2017 13:16:35 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSa_0qw7HzNs for ; Mon, 6 Mar 2017 13:16:30 -0800 (PST) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (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 52A76129A23 for ; Mon, 6 Mar 2017 13:16:30 -0800 (PST) Received: (korumail 6905 invoked from network); 6 Mar 2017 21:16:28 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 6 Mar 2017 21:16:28 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703062116280284; Mon, 06 Mar 2017 21:16:28 +0000 To: Peter Bowen , "trans@ietf.org" References: From: Rob Stradling Message-ID: Date: Mon, 6 Mar 2017 21:16:27 +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: X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 21:16:35 -0000 On 06/03/17 06:06, Peter Bowen wrote: > 8) The only way to get the content of a full certificate is to have a > full certificate. > > Rationale: An alternative option is to have some sort of escrow key > that can "unlock" a precertificate. In previous iterations of 6962-bis, we proposed a redaction mechanism that envisaged replacing domains labels with ?s in precertificates. That mechanism was deemed problematic by the Chrome team precisely because "The only way to get the content of a full certificate is to have a full certificate". What recourse does a domain owner have when they discover a precertificate for their domain space that they don't recognize? How do they figure out whether the (pre)cert was misissued or whether it was legitimately requested by a different team within their organization? The redaction mechanism that's documented in https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 attempted to find a solution to this problem of recourse by swapping ?s for a hash of the unredacted domain. However, this mechanism has also been deemed problematic, because it could be trivial to determine unredacted labels via dictionary attacks. I think a "sort of escrow key" may be the only viable way to construct a redaction mechanism that is deemed non-problematic by everyone. > This quickly turns into 'where do we keep the escrow key?' and 'who gets > to access the escrow key?'. If there is no such thing, then these > questions don't exist. I think these questions will need to be both asked and answered, although I'd be delighted to be proved wrong. > Do others agree that these are true and can be used as givens for > reviewing any proposed designs? Your other points all LGTM. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Mar 6 13:22:34 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B7129A2E for ; Mon, 6 Mar 2017 13:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n90VsmHu74W2 for ; Mon, 6 Mar 2017 13:22:32 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 1C8FE129A23 for ; Mon, 6 Mar 2017 13:22:32 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id f54so184495556uaa.1 for ; Mon, 06 Mar 2017 13:22:32 -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=P4Boqqp5OFB6QK0zuXXXZZsy4G7H6QLvIBAwwLJz6QE=; b=Q+eTkQ72pTfQe67ucEADkw/rcQuxmobFbDJekQImake7sba8hPw6txFQPN4nrB9c5w 9DCDLgcwYet+wXga8N7ZkyCkQW7BRoWGDeNT2d4xdlD0786sqdGK2l/pkiNABWehZGP1 lzJAvxFpb/AZsUX6OmQf9fGB0X1FeXO3xl3LuobVuQ2uDGW7yRsbAfJPvhNp4SPsUSrS tuWAJvgqRNK/9ChGjKYpCaJbXlpb9IVTHoavRuS232roJgo0T+cVI6C8XhvENEJPG2Pt 2f2srID6mS1FCA9tzGAowUPn5p4A/dzdcvKyuX2+2POChCc0Tum8KJS9G9uR8ksGXvll mQ/Q== 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=P4Boqqp5OFB6QK0zuXXXZZsy4G7H6QLvIBAwwLJz6QE=; b=SboiM7w2ItQ1PaNsY3ph7KLYBLlqpwvYL0cfLOJ9I9y7k4fsqI6+90DtHs/AXzRLzg 18rRNPGyOmeG+liGa4Tx0i/h/cHwTBVgeQJ7WeqVSP0xGShwoVlXkoMwKanLNnzJ44VZ jzt8t67tV7Hm2krU3/CRBG0/tu+9ZosqAS9+tHV6lTTenyQ/COAKUreOZ1AT4MySlwO/ tFlxGJ1WTvqKhuVjxQNPdk1Xd/SXhs3d44VScX12f4uWNbc0Bzwe0k0nxUVCx9Vtrjff d1B6AA7ZvIQ2EwXioNAeFBJJqjhgYEhvbGMqakFLmkybf+8mXbtBV/D1tVZ/hgz0iTvg ovuQ== X-Gm-Message-State: AMke39mmeiTtLuoMzfzIw6D4V2qsN7JFCbhTvgS8VPNDj1zKH7S7wCbRbeuXu7KYDyxr9TZN65z0Z//oYeOp/x6x X-Received: by 10.176.86.30 with SMTP id y30mr6833371uaa.130.1488835350954; Mon, 06 Mar 2017 13:22:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Mon, 6 Mar 2017 13:22:30 -0800 (PST) In-Reply-To: References: From: Ben Laurie Date: Mon, 6 Mar 2017 21:22:30 +0000 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=94eb2c1813a439526a054a167e74 Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 21:22:33 -0000 --94eb2c1813a439526a054a167e74 Content-Type: text/plain; charset=UTF-8 I think you can waste a lot of brainpower on redaction, but really the answer is: if you don't want to publish your names, then don't use a mechanism that requires you to. There are alternatives: name-constrained sub-CAs. Private CAs. You can even have private CT to go along with them. Why mess up a protocol whose intent is to show everything? On 6 March 2017 at 21:16, Rob Stradling wrote: > On 06/03/17 06:06, Peter Bowen wrote: > > >> 8) The only way to get the content of a full certificate is to have a >> full certificate. >> >> Rationale: An alternative option is to have some sort of escrow key >> that can "unlock" a precertificate. >> > > In previous iterations of 6962-bis, we proposed a redaction mechanism that > envisaged replacing domains labels with ?s in precertificates. That > mechanism was deemed problematic by the Chrome team precisely because "The > only way to get the content of a full certificate is to have a full > certificate". > What recourse does a domain owner have when they discover a precertificate > for their domain space that they don't recognize? How do they figure out > whether the (pre)cert was misissued or whether it was legitimately > requested by a different team within their organization? > > The redaction mechanism that's documented in > https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 > attempted to find a solution to this problem of recourse by swapping ?s for > a hash of the unredacted domain. However, this mechanism has also been > deemed problematic, because it could be trivial to determine unredacted > labels via dictionary attacks. > > I think a "sort of escrow key" may be the only viable way to construct a > redaction mechanism that is deemed non-problematic by everyone. > > This quickly turns into 'where do we keep the escrow key?' and 'who gets >> to access the escrow key?'. If there is no such thing, then these >> questions don't exist. >> > > I think these questions will need to be both asked and answered, although > I'd be delighted to be proved wrong. > > Do others agree that these are true and can be used as givens for >> reviewing any proposed designs? >> > > Your other points all LGTM. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c1813a439526a054a167e74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you can waste a lot of brainpower on redaction, bu= t really the answer is: if you don't want to publish your names, then d= on't use a mechanism that requires you to. There are alternatives: name= -constrained sub-CAs. Private CAs. You can even have private CT to go along= with them. Why mess up a protocol whose intent is to show everything?

On 6 March 2017 = at 21:16, Rob Stradling <rob.stradling@comodo.com> wr= ote:
On 06/03/17 06:06, Peter Bowen wrote= :
<snip>
8) The only way to get the content of a full certificate is to have a
full certificate.

Rationale: An alternative option is to have some sort of escrow key
that can "unlock" a precertificate.

 In previous iterations of 6962-bis, we proposed a redaction mechanism that = envisaged replacing domains labels with ?s in precertificates. That mechani= sm was deemed problematic by the Chrome team precisely because "The on= ly way to get the content of a full certificate is to have a full certifica= te".
What recourse does a domain owner have when they discover a precertificate = for their domain space that they don't recognize?=C2=A0 How do they fig= ure out whether the (pre)cert was misissued or whether it was legitimately = requested by a different team within their organization?

The redaction mechanism that's documented in https://tools.ietf.org/html/draft-strad-trans-redac= tion-01#section-3.3 attempted to find a solution to this problem o= f recourse by swapping ?s for a hash of the unredacted domain.=C2=A0 Howeve= r, this mechanism has also been deemed problematic, because it could be tri= vial to determine unredacted labels via dictionary attacks.

I think a "sort of escrow key" may be the only viable way to cons= truct a redaction mechanism that is deemed non-problematic by everyone.

This quickly turns into 'where do we keep the escrow key?' and '= ;who gets
to access the escrow key?'.=C2=A0 If there is no such thing, then these=
questions don't exist.

I think these questions will need to be both asked and answered, although I= 'd be delighted to be proved wrong.

Do others agree that these are true and can be used as givens for
reviewing any proposed designs?

 Your other points all LGTM.<= br>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


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

--94eb2c1813a439526a054a167e74-- From nobody Mon Mar 6 13:36: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 CA638129A3C for ; Mon, 6 Mar 2017 13:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 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=-0.001, 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 8iyHf8I65fBi for ; Mon, 6 Mar 2017 13:36:44 -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 0ADB11294A9 for ; Mon, 6 Mar 2017 13:36:44 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 898D6A003A1D for ; Mon, 6 Mar 2017 13:36:43 -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=JSzt3UYmMPSiaYguSf7EThAWRrU=; b= etKShK7EPzIFSvqVN5FlfE1VmoKHyaDFRYO4MfSMjd8sGzLJ09Ooh11gSH068NNS j4nh7vDskW642vLfC+xNtNRqE11A+hZ21p7bF46veHRPTZV+uXMBkJ8telCtMcmL Lqm8v3vHO+bCLQZKto9PWVwZkuHRZZK0GOyAmVh8NDc= Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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 54EA6A00012B for ; Mon, 6 Mar 2017 13:36:43 -0800 (PST) Received: by mail-lf0-f45.google.com with SMTP id k202so78684459lfe.1 for ; Mon, 06 Mar 2017 13:36:43 -0800 (PST) X-Gm-Message-State: AMke39nx1G2yKl5CyBGKfomTgc+9UIbwOWoKivObU1OXE8H6b5vMlXh/G9ChPXrRErvD0sfkFZ9P78buaBF92A== X-Received: by 10.46.92.195 with SMTP id q186mr6209686ljb.107.1488836201568; Mon, 06 Mar 2017 13:36:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Mon, 6 Mar 2017 13:36:40 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Mon, 6 Mar 2017 16:36:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=94eb2c1b3fd0ec639a054a16b000 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 21:36:45 -0000 --94eb2c1b3fd0ec639a054a16b000 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 4:22 PM, Ben Laurie wrote: > I think you can waste a lot of brainpower on redaction, but really the > answer is: if you don't want to publish your names, then don't use a > mechanism that requires you to. There are alternatives: name-constrained > sub-CAs. Private CAs. You can even have private CT to go along with them. > Why mess up a protocol whose intent is to show everything? > Ben: Name-constrained sub-CAs have not been accepted by Chrome as a redaction mechanism. They were moved to the redaction spec precisely because they are a variation of redaction. --94eb2c1b3fd0ec639a054a16b000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 4:22 PM, Ben Laurie <benl@google.com> wrote:
I think you ca= n waste a lot of brainpower on redaction, but really the answer is: if you = don't want to publish your names, then don't use a mechanism that r= equires you to. There are alternatives: name-constrained sub-CAs. Private C= As. You can even have private CT to go along with them. Why mess up a proto= col whose intent is to show everything?

Ben:

Name-constrained sub-CAs have not been acc= epted by Chrome as a redaction mechanism. They were moved to the redaction = spec precisely because they are a variation of redaction.

--94eb2c1b3fd0ec639a054a16b000-- From nobody Mon Mar 6 13:39: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 EBE401294A9 for ; Mon, 6 Mar 2017 13:39:31 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrOdTQkdGvSe for ; Mon, 6 Mar 2017 13:39:29 -0800 (PST) Received: from dwdccgokm1.dela.clif.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:400:430::d201:8a76]) (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 9F2FF129A47 for ; Mon, 6 Mar 2017 13:39:29 -0800 (PST) Received: (korumail 30140 invoked from network); 6 Mar 2017 21:39:28 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 6 Mar 2017 21:39:28 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703062139273630; Mon, 06 Mar 2017 21:39:27 +0000 To: Ben Laurie References: From: Rob Stradling Message-ID: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> Date: Mon, 6 Mar 2017 21:39:26 +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: X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 21:39:32 -0000 On 06/03/17 21:22, Ben Laurie wrote: > I think you can waste a lot of brainpower on redaction, but really the > answer is: if you don't want to publish your names, then don't use a > mechanism that requires you to. I agree that that's the ideal answer, but as we've seen, there is resistance to that answer from various participants in the CT ecosystem. > There are alternatives: name-constrained sub-CAs. We removed that option from 6962-bis. It's now in draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're unlikely to ever support it (at least in its current form). > Private CAs. You can even have private CT to go along with them. Private CAs don't suit every use case, AFAIK. > Why mess up a protocol whose intent is to show everything? Because Security and Useability aren't always in perfect harmony? Much as I'd love to stop wasting brainpower on redaction, I think it's a conversation that needs to continue for now (although not indefinitely!) > On 6 March 2017 at 21:16, Rob Stradling wrote: > > On 06/03/17 06:06, Peter Bowen wrote: > > > 8) The only way to get the content of a full certificate is to > have a > full certificate. > > Rationale: An alternative option is to have some sort of escrow key > that can "unlock" a precertificate. > > > In previous iterations of 6962-bis, we proposed a redaction > mechanism that envisaged replacing domains labels with ?s in > precertificates. That mechanism was deemed problematic by the Chrome > team precisely because "The only way to get the content of a full > certificate is to have a full certificate". > What recourse does a domain owner have when they discover a > precertificate for their domain space that they don't recognize? > How do they figure out whether the (pre)cert was misissued or > whether it was legitimately requested by a different team within > their organization? > > The redaction mechanism that's documented in > https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 > > attempted to find a solution to this problem of recourse by swapping > ?s for a hash of the unredacted domain. However, this mechanism has > also been deemed problematic, because it could be trivial to > determine unredacted labels via dictionary attacks. > > I think a "sort of escrow key" may be the only viable way to > construct a redaction mechanism that is deemed non-problematic by > everyone. > > This quickly turns into 'where do we keep the escrow key?' and > 'who gets > to access the escrow key?'. If there is no such thing, then these > questions don't exist. > > > I think these questions will need to be both asked and answered, > although I'd be delighted to be proved wrong. > > Do others agree that these are true and can be used as givens for > reviewing any proposed designs? > > > Your other points all LGTM. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Mar 6 14:26:44 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 A12DD129A65 for ; Mon, 6 Mar 2017 14:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2HGXBY8T2AQ for ; Mon, 6 Mar 2017 14:26:41 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5309B129A63 for ; Mon, 6 Mar 2017 14:26:41 -0800 (PST) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id 5E4138FA2B9; Mon, 6 Mar 2017 22:26:40 +0000 (GMT) From: Jeremy Rowley To: Rob Stradling , Ben Laurie Thread-Topic: [Trans] Reviving Redaction Thread-Index: AQHSlj/UDHFynVHRl0+/4kcvcSShtKGIxq6AgAABsACAAAS8AP//lbCA Date: Mon, 6 Mar 2017 22:26:37 +0000 Message-ID: <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> In-Reply-To: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C8_01D2968E.0B410A60" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 22:26:42 -0000 ------=_NextPart_000_00C8_01D2968E.0B410A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On the CT days, there was an emphasis on a distinction between white washing a cert (removing it from CT) and redaction. Is the white washing in scope for the Trans list and this discussion or should it be separate? I ask because two of the main arguments cited for redaction tend to be: 1) Network/New project mapping reveals 2) Inclusion if PII in logged certs If white washing address the second concern, a specification around that process could eliminate a good deal of the push for redaction. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling Sent: Monday, March 6, 2017 2:39 PM To: Ben Laurie Cc: trans@ietf.org; Peter Bowen Subject: Re: [Trans] Reviving Redaction On 06/03/17 21:22, Ben Laurie wrote: > I think you can waste a lot of brainpower on redaction, but really the > answer is: if you don't want to publish your names, then don't use a > mechanism that requires you to. I agree that that's the ideal answer, but as we've seen, there is resistance to that answer from various participants in the CT ecosystem. > There are alternatives: name-constrained sub-CAs. We removed that option from 6962-bis. It's now in draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're unlikely to ever support it (at least in its current form). > Private CAs. You can even have private CT to go along with them. Private CAs don't suit every use case, AFAIK. > Why mess up a protocol whose intent is to show everything? Because Security and Useability aren't always in perfect harmony? Much as I'd love to stop wasting brainpower on redaction, I think it's a conversation that needs to continue for now (although not indefinitely!) > On 6 March 2017 at 21:16, Rob Stradling wrote: > > On 06/03/17 06:06, Peter Bowen wrote: > > > 8) The only way to get the content of a full certificate is to > have a > full certificate. > > Rationale: An alternative option is to have some sort of escrow key > that can "unlock" a precertificate. > > > In previous iterations of 6962-bis, we proposed a redaction > mechanism that envisaged replacing domains labels with ?s in > precertificates. That mechanism was deemed problematic by the Chrome > team precisely because "The only way to get the content of a full > certificate is to have a full certificate". > What recourse does a domain owner have when they discover a > precertificate for their domain space that they don't recognize? > How do they figure out whether the (pre)cert was misissued or > whether it was legitimately requested by a different team within > their organization? > > The redaction mechanism that's documented in > https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 > > attempted to find a solution to this problem of recourse by swapping > ?s for a hash of the unredacted domain. However, this mechanism has > also been deemed problematic, because it could be trivial to > determine unredacted labels via dictionary attacks. > > I think a "sort of escrow key" may be the only viable way to > construct a redaction mechanism that is deemed non-problematic by > everyone. > > This quickly turns into 'where do we keep the escrow key?' and > 'who gets > to access the escrow key?'. If there is no such thing, then these > questions don't exist. > > > I think these questions will need to be both asked and answered, > although I'd be delighted to be proved wrong. > > Do others agree that these are true and can be used as givens for > reviewing any proposed designs? > > > Your other points all LGTM. > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_00C8_01D2968E.0B410A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA2MjIyNjM2WjAj BgkqhkiG9w0BCQQxFgQUbv1h1iwvpIHbSyOhZrpdTofoSj4wgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBANcfYpN211xxp1Cd4UNOzytf1a9LQIeI1omhDSEu pMJhJVoFaeW/dX1PSh3tM+jtNGsM3wQ0iTxj9Jyyf0fg4Wf8AZI+x16U8fCcaHukotEOFB2S3Erx fB37eCgryNxXd/TL8P0DVcTDwaIWrS3503ovOPs41zjfuaVqQOfwU1mBR21oAyHmL3AyCOEusrek cssL43rgAMfV18y0wr8HdENQsHgiVWCcIk4HnTedwRaAgJDmcm4tHhppxBri+QkAFU2AUCl4DUhV x241yIM09xexRlPkChi/U81CXjgYq1aqu+G+zmp/vmtKZQITKUYWW607tkQmEgta1OZln8EK40QA AAAAAAA= ------=_NextPart_000_00C8_01D2968E.0B410A60-- From nobody Mon Mar 6 14:50: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 B35A2129547 for ; Mon, 6 Mar 2017 14:50:36 -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 OztIRB8FmMFs for ; Mon, 6 Mar 2017 14:50:35 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 4A12B129493 for ; Mon, 6 Mar 2017 14:50:35 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id x37so79428712ota.2 for ; Mon, 06 Mar 2017 14:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PXZBTeTPKq+Ty4LUo8OtnhqCIyF4gpUZ7r1+kmuVBLo=; b=QPpKs9oGMXsYq7gozMOuUYnwT2T+bWnw8y1X7lMznbWZRxXEm6TMKpwhdyxceH4r0v 1BxhsqGxVeZylXW/Zc6wmCQ0+BOAoui6zotf6vsbQT5HgRJdrsclUOnLKJ5CFJhcekrk VvIivy9v2yzHhndg29o1Tb6yuKuKADZnoVyCcWDDsD8D2i/WwbtEQXF3RA74h82BG7id fnitoAUJqI6Qb7EBWENX/E7gsEkbntSBnENY+WEDEcE8myQP2wO7yxRS/Wp6+jjU6oj5 1RyRhmTVb+nXx20DvnOe2y0s8rOf6rKGVeuaHSkOX2dBi9HrP8VAqY6lYLyVvTZEk61r Jw/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=PXZBTeTPKq+Ty4LUo8OtnhqCIyF4gpUZ7r1+kmuVBLo=; b=KBDXKxKzf1pnOjZSfcc8hdd/P5uY7iM74dXUsOH30KkB1TyED4HAdmjLs4iSmoIXlF kISRtgvXC5d3rs+h+OgxFly64mWZ3lUC0eA+N3cuMuZiMtNpEJpQhSYItRTXJWbaJ3sM tZuC3F4lVV0jYInUQtwPLGdPU8BuL0ef6zzbwAEL+tAkF29vgOYomZXzFLrZurDZ2Ngd 2U2D1DjUlrrFxkqMylGcNYnlgfL7JEsOD3YpsgD/ktM7ekktMX5ohdBpkwwkCI4aEdG0 0s3amU9brAMh44TdGrWK5SK8iJaef6jTJWJZNuFAgSs5+o5+D1nGgxmAeMkEA0jj6Jxu Xk+Q== X-Gm-Message-State: AMke39l3ArJlkp21zyzzncv/ExiWGqxj+JXxEycro0HK/sAKrj40nRacee7FbXTMEdObiVF8BSVZcmDJwBR5TQ== X-Received: by 10.157.82.22 with SMTP id e22mr11135576oth.76.1488840634637; Mon, 06 Mar 2017 14:50:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Mon, 6 Mar 2017 14:50:34 -0800 (PST) In-Reply-To: References: From: Peter Bowen Date: Mon, 6 Mar 2017 14:50:34 -0800 Message-ID: To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Rob Stradling , Ben Laurie Subject: Re: [Trans] Reviving Redaction 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, 06 Mar 2017 22:50:37 -0000 On Mon, Mar 6, 2017 at 1:36 PM, Ryan Sleevi wrote: > On Mon, Mar 6, 2017 at 4:22 PM, Ben Laurie wrote: >> >> I think you can waste a lot of brainpower on redaction, but really the >> answer is: if you don't want to publish your names, then don't use a >> mechanism that requires you to. There are alternatives: name-constrained >> sub-CAs. Private CAs. You can even have private CT to go along with them. >> Why mess up a protocol whose intent is to show everything? > > Name-constrained sub-CAs have not been accepted by Chrome as a redaction > mechanism. They were moved to the redaction spec precisely because they are > a variation of redaction. Yes, Ryan hit the nail on the head. I'm trying to waste brainpower on coming up with a plan Chrome will accept that allows named-constrained sub-CAs not log the full details of all the certs they issue. If Chrome had accepted logging the named-constrained CA certificate in lieu of logging the end-entity certificate, we would be done. Thanks, Peter From nobody Mon Mar 6 15:30:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B061299EF for ; Mon, 6 Mar 2017 15:30:40 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW54-y0639Xw for ; Mon, 6 Mar 2017 15:30:37 -0800 (PST) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (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 20AE01297A5 for ; Mon, 6 Mar 2017 15:30:34 -0800 (PST) Received: (korumail 22332 invoked from network); 6 Mar 2017 23:30:33 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 6 Mar 2017 23:30:33 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703062330333524; Mon, 06 Mar 2017 23:30:33 +0000 To: Jeremy Rowley , Ben Laurie References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> From: Rob Stradling Message-ID: <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> Date: Mon, 6 Mar 2017 23:30:32 +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: <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: [Trans] White out (was Re: Reviving Redaction) 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, 06 Mar 2017 23:30:40 -0000 I think the "white out" proposal that was discussed at the CT Policy Days is likely to be far more controversial than the various redaction proposals. "White out" proposes a mechanism for removing or omitting entire certificates from logs whilst still "proving" that those certificates are "included". Relying parties have to trust the log to only "white out" certs for good reasons. ISTM that this defeats most of the purpose of CT! From https://tools.ietf.org/html/rfc6962#section-1... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates." ISTM that supporting "white out" would turn that sentence into this... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, modifiable, trusted logs of some issued certificates." That sounds not too dissimilar to the WebPKI minus CT! On 06/03/17 22:26, Jeremy Rowley wrote: > On the CT days, there was an emphasis on a distinction between white washing > a cert (removing it from CT) and redaction. Is the white washing in scope > for the Trans list and this discussion or should it be separate? > > I ask because two of the main arguments cited for redaction tend to be: > 1) Network/New project mapping reveals > 2) Inclusion if PII in logged certs > > If white washing address the second concern, a specification around that > process could eliminate a good deal of the push for redaction. > > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Monday, March 6, 2017 2:39 PM > To: Ben Laurie > Cc: trans@ietf.org; Peter Bowen > Subject: Re: [Trans] Reviving Redaction > > On 06/03/17 21:22, Ben Laurie wrote: >> I think you can waste a lot of brainpower on redaction, but really the >> answer is: if you don't want to publish your names, then don't use a >> mechanism that requires you to. > > I agree that that's the ideal answer, but as we've seen, there is resistance > to that answer from various participants in the CT ecosystem. > >> There are alternatives: name-constrained sub-CAs. > > We removed that option from 6962-bis. It's now in > draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're > unlikely to ever support it (at least in its current form). > >> Private CAs. You can even have private CT to go along with them. > > Private CAs don't suit every use case, AFAIK. > >> Why mess up a protocol whose intent is to show everything? > > Because Security and Useability aren't always in perfect harmony? > > Much as I'd love to stop wasting brainpower on redaction, I think it's a > conversation that needs to continue for now (although not indefinitely!) > >> On 6 March 2017 at 21:16, Rob Stradling wrote: >> >> On 06/03/17 06:06, Peter Bowen wrote: >> >> >> 8) The only way to get the content of a full certificate is to >> have a >> full certificate. >> >> Rationale: An alternative option is to have some sort of escrow > key >> that can "unlock" a precertificate. >> >> >> In previous iterations of 6962-bis, we proposed a redaction >> mechanism that envisaged replacing domains labels with ?s in >> precertificates. That mechanism was deemed problematic by the Chrome >> team precisely because "The only way to get the content of a full >> certificate is to have a full certificate". >> What recourse does a domain owner have when they discover a >> precertificate for their domain space that they don't recognize? >> How do they figure out whether the (pre)cert was misissued or >> whether it was legitimately requested by a different team within >> their organization? >> >> The redaction mechanism that's documented in >> https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 >> > >> attempted to find a solution to this problem of recourse by swapping >> ?s for a hash of the unredacted domain. However, this mechanism has >> also been deemed problematic, because it could be trivial to >> determine unredacted labels via dictionary attacks. >> >> I think a "sort of escrow key" may be the only viable way to >> construct a redaction mechanism that is deemed non-problematic by >> everyone. >> >> This quickly turns into 'where do we keep the escrow key?' and >> 'who gets >> to access the escrow key?'. If there is no such thing, then these >> questions don't exist. >> >> >> I think these questions will need to be both asked and answered, >> although I'd be delighted to be proved wrong. >> >> Do others agree that these are true and can be used as givens for >> reviewing any proposed designs? >> >> >> Your other points all LGTM. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Mar 6 15:46: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 B799C1294AE for ; Mon, 6 Mar 2017 15:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHWR_LvRSRo0 for ; Mon, 6 Mar 2017 15:46:18 -0800 (PST) Received: from homiemail-a55.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 4FDB71299EF for ; Mon, 6 Mar 2017 15:46:18 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id E1ECF68003C29 for ; Mon, 6 Mar 2017 15:46:17 -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=04kg4vE3RwG9ge9YeuGkErZhwR8=; b= AKBSOQlPtGQT8DzDuaTCyEquDUilS7TKtZnurbn/sPJwpHZW2HHsZ5fac9dhyrmI 8Iw96qgkHko0M7MH1G5fyQ8f9faUWOL9Q0NgRpPIDdRDRLjCFev8+7ng3EFfsSEx Z4+PilapUNag89y2dSaLAp0N4pwGS3FErf5nuRkbFSE= Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id AE67768003C0F for ; Mon, 6 Mar 2017 15:46:17 -0800 (PST) Received: by mail-lf0-f53.google.com with SMTP id j90so42909528lfk.2 for ; Mon, 06 Mar 2017 15:46:17 -0800 (PST) X-Gm-Message-State: AMke39k/+n2j1JAooMJ5FlgfK6+ksyvEYpG8Keq5Wd0Sf27JOpvA6vXDk/IKkqRgfPXgW8WOxDVRG6jEWQr4EA== X-Received: by 10.25.157.65 with SMTP id g62mr5848141lfe.29.1488843976001; Mon, 06 Mar 2017 15:46:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Mon, 6 Mar 2017 15:46:15 -0800 (PST) In-Reply-To: <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> From: Ryan Sleevi Date: Mon, 6 Mar 2017 18:46:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11411ca250e315054a1880b8 Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Peter Bowen , Jeremy Rowley Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 06 Mar 2017 23:46:20 -0000 --001a11411ca250e315054a1880b8 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling wrote: > I think the "white out" proposal that was discussed at the CT Policy Days > is likely to be far more controversial than the various redaction proposals. > > "White out" proposes a mechanism for removing or omitting entire > certificates from logs whilst still "proving" that those certificates are > "included". Relying parties have to trust the log to only "white out" > certs for good reasons. ISTM that this defeats most of the purpose of CT! > > From https://tools.ietf.org/html/rfc6962#section-1... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates." > > ISTM that supporting "white out" would turn that sentence into this... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, modifiable, trusted > logs of some issued certificates." > > That sounds not too dissimilar to the WebPKI minus CT! > Indeed. I think the takeaway from the proposed solution is that it undermines the goals of CT to provide the ability to later 'remove' certificates (by effectively inserting a later node in the tree that includes sufficient data to recreate the Merkle Tree, by providing its hash, while refusing to provide that entry to clients). This is the question of whether to solve this problem technologically - if it is even possible (and full disclosure, like Rob states, I believe this seriously undermines the security guarantees) - or whether through policy. The policy approach is simply to shut the log down, should it ever need to violate the append-only property, thereby avoiding any particular notion of additional trustworthiness. This then becomes an 'implementation guidance' aspect, as clients, monitor/auditors, and CAs must all be prepared to adjust to changes in trusted logs commiserate to their belief such a mechanism is necessary/appropriate. That is, if implementations do not believe there exists a need to 'remove' certificates, or are willing and able to tolerate the disappearance of a log, then no further action is necessary. --001a11411ca250e315054a1880b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling <rob.stradling@co= modo.com> wrote:
I think = the "white out" proposal that was discussed at the CT Policy Days= is likely to be far more controversial than the various redaction proposal= s.

"White out" proposes a mechanism for removing or omitting entire = certificates from logs whilst still "proving" that those certific= ates are "included".=C2=A0 Relying parties have to trust the log = to only "white out" certs for good reasons.=C2=A0 ISTM that this = defeats most of the purpose of CT!

>From https://tools.ietf.org/html/rfc6962#section-= 1...
=C2=A0 "Certificate transparency aims to mitigate the problem of misis= sued
=C2=A0 =C2=A0certificates by providing publicly auditable, append-only, unt= rusted
=C2=A0 =C2=A0logs of all issued certificates."

ISTM that supporting "white out" would turn that sentence into th= is...
=C2=A0 "Certificate transparency aims to mitigate the problem of misis= sued
=C2=A0 =C2=A0certificates by providing publicly auditable, modifiable, trus= ted
=C2=A0 =C2=A0logs of some issued certificates."

That sounds not too dissimilar to the WebPKI minus CT!

Indeed.

I think the takeaway from = the proposed solution is that it undermines the goals of CT to provide the = ability to later 'remove' certificates (by effectively inserting a = later node in the tree that includes sufficient data to recreate the Merkle= Tree, by providing its hash, while refusing to provide that entry to clien= ts).

This is the question of whether to solve this= problem technologically - if it is even possible (and full disclosure, lik= e Rob states, I believe this seriously undermines the security guarantees) = - or whether through policy. The policy approach is simply to shut the log = down, should it ever need to violate the append-only property, thereby avoi= ding any particular notion of additional trustworthiness.

This then becomes an 'implementation guidance' aspect, as c= lients, monitor/auditors, and CAs must all be prepared to adjust to changes= in trusted logs commiserate to their belief such a mechanism is necessary/= appropriate. That is, if implementations do not believe there exists a need= to 'remove' certificates, or are willing and able to tolerate the = disappearance of a log, then no further action is necessary.
--001a11411ca250e315054a1880b8-- From nobody Mon Mar 6 16:01:00 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 7A448129470 for ; Mon, 6 Mar 2017 16:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 G-KgPA1c1cok for ; Mon, 6 Mar 2017 16:00:58 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112CF1294C0 for ; Mon, 6 Mar 2017 16:00:58 -0800 (PST) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1488844857; bh=1DaLobxdpgPtyXJAR3EKnxWnGD8fwR74fSSAQn/1EDU=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=T3mGzbfw21Zc5RiSBBgcpzE9Pq5BptUraFMQ661Tw+mx/k2xwI05tfzV047yF0/E0 I1DnDVLFLZBbC+5sCp9JtaGMo/0NQl+kz3OqmQckPUhXV83TE8/qvmOUmTM2Griv02 CM1/WaXJTvJd0OOklxVxPZV5A3gELY5EP/KmzTDM= To: Ryan Sleevi , Rob Stradling Thread-Topic: [Trans] White out (was Re: Reviving Redaction) Thread-Index: AQHSltPdt8LSyfxwTEuy3FGv4xJY+6GIfE1w Date: Tue, 7 Mar 2017 00:00:55 +0000 Message-ID: <18fb569702ac45ec8eeea0185cdd36ab@EX2.corp.digicert.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01A7_01D2969B.37EBE730" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" , Ben Laurie , Peter Bowen Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 07 Mar 2017 00:00:59 -0000 ------=_NextPart_000_01A7_01D2969B.37EBE730 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01A8_01D2969B.37EBE730" ------=_NextPart_001_01A8_01D2969B.37EBE730 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Agreed, it=E2=80=99s more controversial, but whether a white out = mechanism undermines CT depends on whether a whited-out entry still = serves as a SCT. If a whited-out entry does not count towards a the log = requirements, then it=E2=80=99s the same as not logging the cert in the = first place. I=E2=80=99m not sure how that would work yet, but that was = a suggestion at the CT days. =20 Currently, the Chrome policy doesn=E2=80=99t permit quickly spinning up = new logs with omitted certificates. =20 =20 From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com]=20 Sent: Monday, March 6, 2017 4:46 PM To: Rob Stradling Cc: Jeremy Rowley ; Ben Laurie = ; trans@ietf.org; Peter Bowen Subject: Re: [Trans] White out (was Re: Reviving Redaction) =20 =20 =20 On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling > wrote: I think the "white out" proposal that was discussed at the CT Policy = Days is likely to be far more controversial than the various redaction = proposals. "White out" proposes a mechanism for removing or omitting entire = certificates from logs whilst still "proving" that those certificates = are "included". Relying parties have to trust the log to only "white = out" certs for good reasons. ISTM that this defeats most of the purpose = of CT! >From https://tools.ietf.org/html/rfc6962#section-1... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates." ISTM that supporting "white out" would turn that sentence into this... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, modifiable, trusted logs of some issued certificates." That sounds not too dissimilar to the WebPKI minus CT! =20 Indeed. =20 I think the takeaway from the proposed solution is that it undermines = the goals of CT to provide the ability to later 'remove' certificates = (by effectively inserting a later node in the tree that includes = sufficient data to recreate the Merkle Tree, by providing its hash, = while refusing to provide that entry to clients). =20 This is the question of whether to solve this problem technologically - = if it is even possible (and full disclosure, like Rob states, I believe = this seriously undermines the security guarantees) - or whether through = policy. The policy approach is simply to shut the log down, should it = ever need to violate the append-only property, thereby avoiding any = particular notion of additional trustworthiness. =20 This then becomes an 'implementation guidance' aspect, as clients, = monitor/auditors, and CAs must all be prepared to adjust to changes in = trusted logs commiserate to their belief such a mechanism is = necessary/appropriate. That is, if implementations do not believe there = exists a need to 'remove' certificates, or are willing and able to = tolerate the disappearance of a log, then no further action is = necessary. ------=_NextPart_001_01A8_01D2969B.37EBE730 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Agreed, = it=E2=80=99s more controversial, but whether a white out mechanism = undermines CT depends on whether a whited-out entry still serves as a = SCT. =C2=A0If a whited-out entry does not count towards a the log = requirements, then it=E2=80=99s the same as not logging the cert in the = first place. I=E2=80=99m not sure how that would work yet, but that was = a suggestion at the CT days.

 

Currently, = the Chrome policy doesn=E2=80=99t permit quickly spinning up new logs = with omitted certificates. =C2=A0

 

From:<= /b> = Ryan Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Monday, March = 6, 2017 4:46 PM
To: Rob Stradling = <rob.stradling@comodo.com>
Cc: Jeremy Rowley = <jeremy.rowley@digicert.com>; Ben Laurie <benl@google.com>; = trans@ietf.org; Peter Bowen <pzbowen@gmail.com>
Subject: = Re: [Trans] White out (was Re: Reviving = Redaction)

 

 

 

On Mon, = Mar 6, 2017 at 6:30 PM, Rob Stradling <rob.stradling@comodo.com> = wrote:

I think = the "white out" proposal that was discussed at the CT Policy = Days is likely to be far more controversial than the various redaction = proposals.

"White out" proposes a mechanism for = removing or omitting entire certificates from logs whilst still = "proving" that those certificates are = "included".  Relying parties have to trust the log to = only "white out" certs for good reasons.  ISTM that this = defeats most of the purpose of CT!

From https://tools.ietf.org/html/rfc6962#section-1...  "Certificate transparency aims to mitigate the problem of = misissued
   certificates by providing publicly auditable, = append-only, untrusted
   logs of all issued = certificates."

ISTM that supporting "white out" = would turn that sentence into this...
  "Certificate = transparency aims to mitigate the problem of misissued
  =  certificates by providing publicly auditable, modifiable, = trusted
   logs of some issued = certificates."

That sounds not too dissimilar to the WebPKI = minus CT!

 

Indeed.

 

I = think the takeaway from the proposed solution is that it undermines the = goals of CT to provide the ability to later 'remove' certificates (by = effectively inserting a later node in the tree that includes sufficient = data to recreate the Merkle Tree, by providing its hash, while refusing = to provide that entry to clients).

 

This is the question of whether to solve this problem = technologically - if it is even possible (and full disclosure, like Rob = states, I believe this seriously undermines the security guarantees) - = or whether through policy. The policy approach is simply to shut the log = down, should it ever need to violate the append-only property, thereby = avoiding any particular notion of additional = trustworthiness.

 

This then becomes an 'implementation guidance' aspect, = as clients, monitor/auditors, and CAs must all be prepared to adjust to = changes in trusted logs commiserate to their belief such a mechanism is = necessary/appropriate. That is, if implementations do not believe there = exists a need to 'remove' certificates, or are willing and able to = tolerate the disappearance of a log, then no further action is = necessary.

------=_NextPart_001_01A8_01D2969B.37EBE730-- ------=_NextPart_000_01A7_01D2969B.37EBE730 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA3MDAwMDU0WjAj BgkqhkiG9w0BCQQxFgQUR78yISxn2hRHbbJj0HXujkbDMS4wgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAIaRZIdQ+OPGBQaVKnefKA3FK/N4YsNSquJo1T+9 4a2J7zJBI22HVyNXp140+jwqqv1FgNy6OEfmiYjPyDubL2wVPHmQ4mKq3LxPx60Q8xW53KFBBxbJ 4E6SXbW4P2lOrXnZAV7KmCXzPr6OCAjcEoaseZeFmsMCdDEl9adg/hDFgNppSLgq7eHwe1Se8Lc6 yrd+TNCElSWSiy+IdyEdCfdSRqAggsgl3czPXUSfbUcX8RS5oRnabgSgpEPokmDyIutZqTHwnTSM U+6IPAURL5EMueKfjljTswVOE7anDuAyRZhxChCzJR2oEgIEfjmOsOsD0OZ1KKQykrVxFh1E8GQA AAAAAAA= ------=_NextPart_000_01A7_01D2969B.37EBE730-- From nobody Mon Mar 6 17:15:34 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FEB129632 for ; Mon, 6 Mar 2017 17:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf2ngTpr9NiY for ; Mon, 6 Mar 2017 17:15:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EBA12944D for ; Mon, 6 Mar 2017 17:15:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIK50069; Tue, 07 Mar 2017 01:15:29 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Mar 2017 01:15:27 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.53]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Tue, 7 Mar 2017 09:15:23 +0800 From: "Xialiang (Frank)" To: "trans@ietf.org" Thread-Topic: I-D Action: draft-zhang-trans-ct-binary-codes-04.txt Thread-Index: AQHSlpDwVqAOHctDCE2GCjbfp+OudKGIg2qA Date: Tue, 7 Mar 2017 01:15:22 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58BE09B1.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3b17c2842dcd8cc2c2ff944dd739a084 Archived-At: Subject: [Trans] Fwd: I-D Action: draft-zhang-trans-ct-binary-codes-04.txt 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, 07 Mar 2017 01:15:33 -0000 SGkgYWxsLA0KV2UndmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0 LiBUaGlzIGRyYWZ0IGlzIG1haW5seSBhYm91dCBob3cgdG8gZXh0ZW5kIHRoZSBDVCBwcm90b2Nv bCB0byBzdXBwb3J0IGxvZ2dpbmcgYmluYXJ5IGNvZGVzIHRvIGVuYWJsZSB0aGUgbW9uaXRvcmlu ZyBhbmQgYXVkaXRpbmcgb2YgaXQgYW5kIGl0cyBkaXN0cmlidXRpb24uDQoNCllvdXIgcmV2aWV3 cyBhbmQgY29tbWVudHMgYXJlIHdhcm1seSB3ZWxjb21lLg0KDQpCLlIuDQpGcmFuaw0KDQotLS0t LdPKvP7Urbz+LS0tLS0NCreivP7IyzogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNl LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQq3osvNyrG8 5DogMjAxN8TqM9TCNsjVIDIzOjQ3DQrK1bz+yMs6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0K1vfM 4jogSS1EIEFjdGlvbjogZHJhZnQtemhhbmctdHJhbnMtY3QtYmluYXJ5LWNvZGVzLTA0LnR4dA0K DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6 IENUIGZvciBCaW5hcnkgQ29kZXMNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTGlhbmcgWGlh DQogICAgICAgICAgICAgICAgICAgICAgICAgIERhY2hlbmcgWmhhbmcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgRGFuaWVsIEthaG4gR2lsbG1vcg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBCZWhjZXQgU2FyaWtheWENCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC16aGFuZy10cmFucy1j dC1iaW5hcnktY29kZXMtMDQudHh0DQoJUGFnZXMgICAgICAgICAgIDogMTINCglEYXRlICAgICAg ICAgICAgOiAyMDE3LTAzLTA2DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBhIHNvbHV0aW9uIGV4dGVuZGluZyB0aGUgQ2VydGlmaWNhdGUNCiAgIFRyYW5zcGFyZW5jeSBw cm90b2NvbCBbSS1ELmlldGYtdHJhbnMtcmZjNjk2Mi1iaXNdIGZvciB0cmFuc3BhcmVudGx5DQog ICBsb2dnaW5nIHRoZSBzb2Z0d2FyZSBiaW5hcnkgY29kZXMgKEJDKW9yIGl0cyBkaWdlc3Qgd2l0 aCB0aGVpcg0KICAgc2lnbmF0dXJlLCB0byBlbmFibGUgYW55b25lIHRvIG1vbml0b3IgYW5kIGF1 ZGl0IHRoZSBzb2Z0d2FyZQ0KICAgcHJvdmlkZXIgYWN0aXZpdHkgYW5kIG5vdGljZSB0aGUgZGlz dHJpYnV0aW9uIG9mIHN1c3BlY3Qgc29mdHdhcmUgYXMNCiAgIHdlbGwgYXMgdG8gYXVkaXQgdGhl IEJDIGxvZ3MgdGhlbXNlbHZlcy4gIFRoZSBzb2x1dGlvbiBpcyBjYWxsZWQNCiAgICJCaW5hcnkg VHJhbnNwYXJlbmN5IiBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtemhhbmctdHJhbnMtY3QtYmluYXJ5LWNvZGVzLw0KDQpUaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC16aGFuZy10cmFucy1jdC1iaW5hcnktY29kZXMtMDQNCg0KQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpoYW5nLXRyYW5zLWN0LWJpbmFyeS1jb2Rlcy0wNA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UN CkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sIG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo= From nobody Mon Mar 6 18:16: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 9394D129A8C for ; Mon, 6 Mar 2017 18:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ldsuYXHpd_eU for ; Mon, 6 Mar 2017 18:16:30 -0800 (PST) Received: from homiemail-a55.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 70BD91293DB for ; Mon, 6 Mar 2017 18:16:30 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 1A84268003C2E for ; Mon, 6 Mar 2017 18:16:30 -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=FP7syD7+x9HY2tNBDYDae9yX4Ks=; b= IfhVLmFeg/oVKy0vwp2bDcgIPCzBvatvfCm6wF9ac0jaRI9RjxkzcywLcZZHXBs1 JUaqsehSaE1ZVNPdFl+TYkc0cp1Alz9pQPj4dZxyrkcP2WUaOFgxPBPWzK7Bam2z i58Y+NeK7+n0QuRrfqNH1IKRVnBl9VB4ZXQ6ryP4gwc= Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id CFC1A68003C2B for ; Mon, 6 Mar 2017 18:16:29 -0800 (PST) Received: by mail-lf0-f53.google.com with SMTP id y193so80649831lfd.3 for ; Mon, 06 Mar 2017 18:16:29 -0800 (PST) X-Gm-Message-State: AMke39kG/nX6rkcYkfs7U/p3J0bkTCQ+3/wP3z5h16OiXgIiS0yhPIxwAGQ8YfPPeZFjCmBjej4IzKwViaR+0Q== X-Received: by 10.46.82.66 with SMTP id g63mr6217377ljb.113.1488852988163; Mon, 06 Mar 2017 18:16:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Mon, 6 Mar 2017 18:16:27 -0800 (PST) In-Reply-To: <18fb569702ac45ec8eeea0185cdd36ab@EX2.corp.digicert.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> <18fb569702ac45ec8eeea0185cdd36ab@EX2.corp.digicert.com> From: Ryan Sleevi Date: Mon, 6 Mar 2017 21:16:27 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Rowley Content-Type: multipart/alternative; boundary=001a113c35567b8041054a1a998d Archived-At: Cc: Ryan Sleevi , Ben Laurie , Rob Stradling , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 07 Mar 2017 02:16:31 -0000 --001a113c35567b8041054a1a998d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 6, 2017 at 7:00 PM, Jeremy Rowley wrote: > Currently, the Chrome policy doesn=E2=80=99t permit quickly spinning up n= ew logs > with omitted certificates. > That's correct, and as discussed, that's open to change to address various implementation concerns. Which is my point - that this isn't necessarily one which requires a technical solution or engineering, and is more an aspect of implementation and implementation guidance. Everything provided by RFC 6962 or RFC 6962-bis supports addressing this concern without any changes to either spec - provided that implementations (which believe such concerns are valid) can appropriately address them via other, provided-for means. I don't think we should expend energy on specifying that unless we have reason to believe that it's impossible to implement agility for logs IF such a scenario were to happen and be seen as valid. But there's no reason to overly complicate and undermine the security properties to do so. --001a113c35567b8041054a1a998d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 7:00 PM, Jeremy Rowley <jeremy.rowley@= digicert.com> wrote:

Currently, the Chrome policy doesn=E2=80=99t = permit quickly spinning up new logs with omitted certificates. =C2=A0


That's correct, and a= s discussed, that's open to change to address various implementation co= ncerns.

Which is my point - that this isn't ne= cessarily one which requires a technical solution or engineering, and is mo= re an aspect of implementation and implementation guidance. Everything prov= ided by RFC 6962 or RFC 6962-bis supports addressing this concern without a= ny changes to either spec - provided that implementations (which believe su= ch concerns are valid) can appropriately address them via other, provided-f= or means.

I don't think we should expend energ= y on specifying that unless we have reason to believe that it's impossi= ble to implement agility for logs IF such a scenario were to happen and be = seen as valid. But there's no reason to overly complicate and undermine= the security properties to do so.=C2=A0

--001a113c35567b8041054a1a998d-- From nobody Tue Mar 7 01:50:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E2A12945F for ; Tue, 7 Mar 2017 01:50:51 -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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoV5__gm9aBM for ; Tue, 7 Mar 2017 01:50:47 -0800 (PST) Received: from dwdccgokm1.dela.clif.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:400:430::d201:8a76]) (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 5F6E8129434 for ; Tue, 7 Mar 2017 01:50:47 -0800 (PST) Received: (korumail 8743 invoked from network); 7 Mar 2017 09:50:46 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 7 Mar 2017 09:50:46 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703070950420591; Tue, 07 Mar 2017 09:50:42 +0000 To: Jeremy Rowley References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> <18fb569702ac45ec8eeea0185cdd36ab@EX2.corp.digicert.com> From: Rob Stradling Message-ID: Date: Tue, 7 Mar 2017 09:50:42 +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: <18fb569702ac45ec8eeea0185cdd36ab@EX2.corp.digicert.com> X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ryan Sleevi , "trans@ietf.org" , Ben Laurie , Peter Bowen Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 07 Mar 2017 09:50:51 -0000 On 07/03/17 00:00, Jeremy Rowley wrote: > Agreed, it’s more controversial, but whether a white out mechanism > undermines CT depends on whether a whited-out entry still serves as a > SCT. If a whited-out entry does not count towards a the log > requirements, then it’s the same as not logging the cert in the first > place. I’m not sure how that would work yet, but that was a suggestion > at the CT days. I think the only way it could conceivably work (without undermining CT) is by introducing a revocation mechanism for SCTs and a revocation mechanism for inclusion proofs, both of which would need to be 100% reliable. Let's not go there. > Currently, the Chrome policy doesn’t permit quickly spinning up new logs > with omitted certificates. > > > > *From:*Ryan Sleevi [mailto:ryan-ietf@sleevi.com] > *Sent:* Monday, March 6, 2017 4:46 PM > *To:* Rob Stradling > *Cc:* Jeremy Rowley ; Ben Laurie > ; trans@ietf.org; Peter Bowen > *Subject:* Re: [Trans] White out (was Re: Reviving Redaction) > > > > > > > > On Mon, Mar 6, 2017 at 6:30 PM, Rob Stradling > wrote: > > I think the "white out" proposal that was discussed at the CT Policy > Days is likely to be far more controversial than the various > redaction proposals. > > "White out" proposes a mechanism for removing or omitting entire > certificates from logs whilst still "proving" that those > certificates are "included". Relying parties have to trust the log > to only "white out" certs for good reasons. ISTM that this defeats > most of the purpose of CT! > > From https://tools.ietf.org/html/rfc6962#section-1... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates." > > ISTM that supporting "white out" would turn that sentence into this... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, modifiable, trusted > logs of some issued certificates." > > That sounds not too dissimilar to the WebPKI minus CT! > > > > Indeed. > > > > I think the takeaway from the proposed solution is that it undermines > the goals of CT to provide the ability to later 'remove' certificates > (by effectively inserting a later node in the tree that includes > sufficient data to recreate the Merkle Tree, by providing its hash, > while refusing to provide that entry to clients). > > > > This is the question of whether to solve this problem technologically - > if it is even possible (and full disclosure, like Rob states, I believe > this seriously undermines the security guarantees) - or whether through > policy. The policy approach is simply to shut the log down, should it > ever need to violate the append-only property, thereby avoiding any > particular notion of additional trustworthiness. > > > > This then becomes an 'implementation guidance' aspect, as clients, > monitor/auditors, and CAs must all be prepared to adjust to changes in > trusted logs commiserate to their belief such a mechanism is > necessary/appropriate. That is, if implementations do not believe there > exists a need to 'remove' certificates, or are willing and able to > tolerate the disappearance of a log, then no further action is necessary. > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Mar 7 09:43:44 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 943441295BF for ; Tue, 7 Mar 2017 09:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXVZGoLnAcjM for ; Tue, 7 Mar 2017 09:43:41 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 0687312959B for ; Tue, 7 Mar 2017 09:43:41 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 72so13948510uaf.3 for ; Tue, 07 Mar 2017 09:43:40 -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=dZmJ5SOud62aA+7ykV8YWm0ylkYdxO6fEy3yB7tYz0U=; b=XJp/dSCZG+H/fn9dBMvt6FL3tgmzmbHBt0E8A46yzEgpe33kf4eMqTAWjmA7lRkGi7 cb7RlFAqqkVp+x5EuN44CxlUskqetvbSg37SjSU+BlSi/ai0MhnTSig7ELHEZokZQvIL XsUtjHMcTcsF71vu7RYd9kKFb69uueXooo8bwuAQ8t2LQWzyWDLcBQxDulh7zSmk78lQ GfAn+Q4Q/Fbi5ayK38rbszGeEW1UyNukRtq2j8lVwC9v+amC3ID0eLdOeaY93qy7YKNi 1nmTcN6qXCV5eaIFvgvdcQE2i/xdcMhyh5rRGKaC9DnF3VomFA1ZAurCL4f5NXCJbme+ maNQ== 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=dZmJ5SOud62aA+7ykV8YWm0ylkYdxO6fEy3yB7tYz0U=; b=QrlEgZqJxDgmxl4VSQm05R6mBO2xNClW9sVVG7emuC9AbVbCpbErOHH701EQPEDMwP mvp8xbxXZZ3ppBuzotK36+0Zzf8IPaofv3wfuDD8+G/DASqNk1Utd1KEDGBc4KmKRY6z 9bthbTL2OIcY1xwYRkzhIgZBUH8pr9JinfdLkpi/67mEIpNmRRARqtbPctwDuYOnYEA5 QWx6H+rEKzzZwgDBYsWGBAwcDYaMY0FDUnG32rTtl47sn3EgX+/fggA/+m/uHSImXhLv v6PR2RYwefqZO7oJlEHX15S6xdBEnrgzsInLFaQThu5f0dKM78oR3q557MbrG63clAGy J7ZA== X-Gm-Message-State: AMke39m72WKSjSVvyR1IwEqUZnWTPtHh2hbTeGdMziRtxS8jeiwIhzvTVfZiE/KlHyFw4BlekYpQDgPxsAcbo+C9 X-Received: by 10.31.195.193 with SMTP id t184mr930183vkf.7.1488908619983; Tue, 07 Mar 2017 09:43:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Tue, 7 Mar 2017 09:43:39 -0800 (PST) In-Reply-To: <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> From: Ben Laurie Date: Tue, 7 Mar 2017 17:43:39 +0000 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=001a114e72c266105d054a278d17 Archived-At: Cc: "trans@ietf.org" , Peter Bowen , Jeremy Rowley Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 07 Mar 2017 17:43:43 -0000 --001a114e72c266105d054a278d17 Content-Type: text/plain; charset=UTF-8 On 6 March 2017 at 23:30, Rob Stradling wrote: > I think the "white out" proposal that was discussed at the CT Policy Days > is likely to be far more controversial than the various redaction proposals. > > "White out" proposes a mechanism for removing or omitting entire > certificates from logs whilst still "proving" that those certificates are > "included". Relying parties have to trust the log to only "white out" > certs for good reasons. ISTM that this defeats most of the purpose of CT! > > From https://tools.ietf.org/html/rfc6962#section-1... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, append-only, untrusted > logs of all issued certificates." > > ISTM that supporting "white out" would turn that sentence into this... > "Certificate transparency aims to mitigate the problem of misissued > certificates by providing publicly auditable, modifiable, trusted > logs of some issued certificates." > > That sounds not too dissimilar to the WebPKI minus CT! > I think if this kind of thing is going to work, you have to also log the reason for removing the cert (e.g. link to court order :-). > > On 06/03/17 22:26, Jeremy Rowley wrote: > >> On the CT days, there was an emphasis on a distinction between white >> washing >> a cert (removing it from CT) and redaction. Is the white washing in scope >> for the Trans list and this discussion or should it be separate? >> >> I ask because two of the main arguments cited for redaction tend to be: >> 1) Network/New project mapping reveals >> 2) Inclusion if PII in logged certs >> >> If white washing address the second concern, a specification around that >> process could eliminate a good deal of the push for redaction. >> >> >> -----Original Message----- >> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling >> Sent: Monday, March 6, 2017 2:39 PM >> To: Ben Laurie >> Cc: trans@ietf.org; Peter Bowen >> Subject: Re: [Trans] Reviving Redaction >> >> On 06/03/17 21:22, Ben Laurie wrote: >> >>> I think you can waste a lot of brainpower on redaction, but really the >>> answer is: if you don't want to publish your names, then don't use a >>> mechanism that requires you to. >>> >> >> I agree that that's the ideal answer, but as we've seen, there is >> resistance >> to that answer from various participants in the CT ecosystem. >> >> There are alternatives: name-constrained sub-CAs. >>> >> >> We removed that option from 6962-bis. It's now in >> draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're >> unlikely to ever support it (at least in its current form). >> >> Private CAs. You can even have private CT to go along with them. >>> >> >> Private CAs don't suit every use case, AFAIK. >> >> Why mess up a protocol whose intent is to show everything? >>> >> >> Because Security and Useability aren't always in perfect harmony? >> >> Much as I'd love to stop wasting brainpower on redaction, I think it's a >> conversation that needs to continue for now (although not indefinitely!) >> >> On 6 March 2017 at 21:16, Rob Stradling wrote: >>> >>> On 06/03/17 06:06, Peter Bowen wrote: >>> >>> >>> 8) The only way to get the content of a full certificate is to >>> have a >>> full certificate. >>> >>> Rationale: An alternative option is to have some sort of escrow >>> >> key >> >>> that can "unlock" a precertificate. >>> >>> >>> In previous iterations of 6962-bis, we proposed a redaction >>> mechanism that envisaged replacing domains labels with ?s in >>> precertificates. That mechanism was deemed problematic by the Chrome >>> team precisely because "The only way to get the content of a full >>> certificate is to have a full certificate". >>> What recourse does a domain owner have when they discover a >>> precertificate for their domain space that they don't recognize? >>> How do they figure out whether the (pre)cert was misissued or >>> whether it was legitimately requested by a different team within >>> their organization? >>> >>> The redaction mechanism that's documented in >>> https://tools.ietf.org/html/draft-strad-trans-redaction-01# >>> section-3.3 >>> >>> >> >>> attempted to find a solution to this problem of recourse by swapping >>> ?s for a hash of the unredacted domain. However, this mechanism has >>> also been deemed problematic, because it could be trivial to >>> determine unredacted labels via dictionary attacks. >>> >>> I think a "sort of escrow key" may be the only viable way to >>> construct a redaction mechanism that is deemed non-problematic by >>> everyone. >>> >>> This quickly turns into 'where do we keep the escrow key?' and >>> 'who gets >>> to access the escrow key?'. If there is no such thing, then >>> these >>> questions don't exist. >>> >>> >>> I think these questions will need to be both asked and answered, >>> although I'd be delighted to be proved wrong. >>> >>> Do others agree that these are true and can be used as givens for >>> reviewing any proposed designs? >>> >>> >>> Your other points all LGTM. >>> >> > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > --001a114e72c266105d054a278d17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 March 2017 at 23:30, Rob Stradling <rob.stradling@comodo= .com> wrote:
I think the &q= uot;white out" proposal that was discussed at the CT Policy Days is li= kely to be far more controversial than the various redaction proposals.

"White out" proposes a mechanism for removing or omitting entire = certificates from logs whilst still "proving" that those certific= ates are "included".=C2=A0 Relying parties have to trust the log = to only "white out" certs for good reasons.=C2=A0 ISTM that this = defeats most of the purpose of CT!

>From https://tools.ietf.org/html/rfc6962#section-= 1...
=C2=A0 "Certificate transparency aims to mitigate the problem of misis= sued
=C2=A0 =C2=A0certificates by providing publicly auditable, append-only, unt= rusted
=C2=A0 =C2=A0logs of all issued certificates."

ISTM that supporting "white out" would turn that sentence into th= is...
=C2=A0 "Certificate transparency aims to mitigate the problem of misis= sued
=C2=A0 =C2=A0certificates by providing publicly auditable, modifiable, trus= ted
=C2=A0 =C2=A0logs of some issued certificates."

That sounds not too dissimilar to the WebPKI minus CT!

I think if this kind of thing is going to work, you have to= also log the reason for removing the cert (e.g. link to court order :-).
=C2=A0

On 06/03/17 22:26, Jeremy Rowley wrote:
On the CT days, there was an emphasis on a distinction between white washin= g
a cert (removing it from CT) and redaction. Is the white washing in scope for the Trans list and this discussion or should it be separate?

I ask because two of the main arguments cited for redaction tend to be:
1) Network/New project mapping reveals
2) Inclusion if PII in logged certs

If white washing address the second concern, a specification around that process could eliminate a good deal of the push for redaction.


-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling
Sent: Monday, March 6, 2017 2:39 PM
To: Ben Laurie <ben= l@google.com>
Cc: trans@ietf.org;= Peter Bowen <pzb= owen@gmail.com>
Subject: Re: [Trans] Reviving Redaction

On 06/03/17 21:22, Ben Laurie wrote:
I think you can waste a lot of brainpower on redaction, but really the
answer is: if you don't want to publish your names, then don't use = a
mechanism that requires you to.

I agree that that's the ideal answer, but as we've seen, there is r= esistance
to that answer from various participants in the CT ecosystem.

There are alternatives: name-constrained sub-CAs.

We removed that option from 6962-bis.=C2=A0 It's now in
draft-strad-trans-redaction, but IIRC the Chrome team hinted that they'= re
unlikely to ever support it (at least in its current form).

Private CAs. You can even have private CT to go along with them.

Private CAs don't suit every use case, AFAIK.

Why mess up a protocol whose intent is to show everything?

Because Security and Useability aren't always in perfect harmony?

Much as I'd love to stop wasting brainpower on redaction, I think it= 9;s a
conversation that needs to continue for now (although not indefinitely!)
On 6 March 2017 at 21:16, Rob Stradling wrote:

=C2=A0 =C2=A0 On 06/03/17 06:06, Peter Bowen wrote:
=C2=A0 =C2=A0 <snip>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 8) The only way to get the content of a full ce= rtificate is to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 full certificate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Rationale: An alternative option is to have som= e sort of escrow
key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that can "unlock" a precertificate.

=C2=A0 =C2=A0 In previous iterations of 6962-bis, we proposed a redaction =C2=A0 =C2=A0 mechanism that envisaged replacing domains labels with ?s in<= br> =C2=A0 =C2=A0 precertificates. That mechanism was deemed problematic by the= Chrome
=C2=A0 =C2=A0 team precisely because "The only way to get the content = of a full
=C2=A0 =C2=A0 certificate is to have a full certificate".
=C2=A0 =C2=A0 What recourse does a domain owner have when they discover a =C2=A0 =C2=A0 precertificate for their domain space that they don't rec= ognize?
=C2=A0 =C2=A0 How do they figure out whether the (pre)cert was misissued or=
=C2=A0 =C2=A0 whether it was legitimately requested by a different team wit= hin
=C2=A0 =C2=A0 their organization?

=C2=A0 =C2=A0 The redaction mechanism that's documented in
=C2=A0 =C2=A0 https://tools.ie= tf.org/html/draft-strad-trans-redaction-01#section-3.3

<https://tools.ietf.org/htm= l/draft-strad-trans-redaction-01#section-3.3>
=C2=A0 =C2=A0 attempted to find a solution to this problem of recourse by s= wapping
=C2=A0 =C2=A0 ?s for a hash of the unredacted domain.=C2=A0 However, this m= echanism has
=C2=A0 =C2=A0 also been deemed problematic, because it could be trivial to<= br> =C2=A0 =C2=A0 determine unredacted labels via dictionary attacks.

=C2=A0 =C2=A0 I think a "sort of escrow key" may be the only viab= le way to
=C2=A0 =C2=A0 construct a redaction mechanism that is deemed non-problemati= c by
=C2=A0 =C2=A0 everyone.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This quickly turns into 'where do we keep t= he escrow key?' and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 'who gets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to access the escrow key?'.=C2=A0 If there = is no such thing, then these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 questions don't exist.


=C2=A0 =C2=A0 I think these questions will need to be both asked and answer= ed,
=C2=A0 =C2=A0 although I'd be delighted to be proved wrong.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Do others agree that these are true and can be = used as givens for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reviewing any proposed designs?


=C2=A0 =C2=A0 Your other points all LGTM.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

--001a114e72c266105d054a278d17-- From nobody Tue Mar 7 09:44: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 241511295D5 for ; Tue, 7 Mar 2017 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS9U73NPdqBN for ; Tue, 7 Mar 2017 09:44:35 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 AADD31295D2 for ; Tue, 7 Mar 2017 09:44:35 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id u30so14767675uau.0 for ; Tue, 07 Mar 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=3LZIZadUouys3XXGvSkdp3M2EltX9GSgPIYkgSY4Kz4=; b=PQJ2TftXOg7MSzxzB1SbZrTZnV+JVVmrAso4XVl9NP218h2D7Fhbn9ER/mfE9c6KlL cvtwq1YLy9aKjJKjc82OdKFAw7z0cnVZz29DKIVBJv8AyMSs0vVVLea6Qs5h2TKzxHK0 Cq0H3/S36GhxA8UMub+AOuzgPlU980YHlG0aytZV6rGWfN4Gkg7Rx74XVTU3X7AHyACG 4C5nVex+mhHZR6n9b93+gkj9OZdFPRhTrMFJQkinKDTEXAqeljQkynYQIffo4amfgAnw N/7n+AUal3r/UyC/OH21dAkTYazjq+25NXB1+d5uyJ25k+UzFcxG9OIulye9eHyI34wY QBeQ== 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=3LZIZadUouys3XXGvSkdp3M2EltX9GSgPIYkgSY4Kz4=; b=abXH4vROdFrx0MeDk/zN27+pn/gJcV2BhhmTpU+NUTD01IAQ7ZwwYICaacT3P5rerZ UlBfW2fdyPJkFQdjevW9VaO0HdVslzjG4hYxrFns+SCjnWYWMiC9PtOtyR73jlswuQFs udN6HqD9MhJiusSCAkY760TXQzfvc28DQTNmTx70hIOqPAGyoOOI/qshy98/eRpkdpIL RHwLuo86FGbVtlMM8GVtDGL+5cYk6oXpMrgMMro6mGWu4YYtkYBnmppg/LWxL+CLO3MU /5Eeh6pVVbXI0uVdh0EYPSUGmQ/wLcOK6aNKhNN/VeNh6xMxPXZNabK9n7cEJaB/i4io 7Amw== X-Gm-Message-State: AMke39lIxQvRsgFqkRXZlIQY6tvVhOhhtC2zV7JbPN5uWzFhDTTm6aeYmfDhhDi9Yk5OZhFzNAZUv0nKuk1fHLjb X-Received: by 10.176.66.38 with SMTP id i35mr872011uai.90.1488908674544; Tue, 07 Mar 2017 09:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Tue, 7 Mar 2017 09:44:33 -0800 (PST) In-Reply-To: References: From: Ben Laurie Date: Tue, 7 Mar 2017 17:44:33 +0000 Message-ID: To: Ryan Sleevi Content-Type: multipart/alternative; boundary=001a114fa3b6a69827054a2790f2 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Reviving Redaction 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, 07 Mar 2017 17:44:37 -0000 --001a114fa3b6a69827054a2790f2 Content-Type: text/plain; charset=UTF-8 On 6 March 2017 at 21:36, Ryan Sleevi wrote: > > > On Mon, Mar 6, 2017 at 4:22 PM, Ben Laurie wrote: > >> I think you can waste a lot of brainpower on redaction, but really the >> answer is: if you don't want to publish your names, then don't use a >> mechanism that requires you to. There are alternatives: name-constrained >> sub-CAs. Private CAs. You can even have private CT to go along with them. >> Why mess up a protocol whose intent is to show everything? >> > > Ben: > > Name-constrained sub-CAs have not been accepted by Chrome as a redaction > mechanism. They were moved to the redaction spec precisely because they are > a variation of redaction. > Ah, good point. They're probably a good idea for private CAs, though. :-) --001a114fa3b6a69827054a2790f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 March 2017 at 21:36, Ryan Sleevi <ryan-ietf@sleevi.com>= wrote:


On Mo= n, Mar 6, 2017 at 4:22 PM, Ben Laurie <benl@google.com> wrote:=
I think you can waste a= lot of brainpower on redaction, but really the answer is: if you don't= want to publish your names, then don't use a mechanism that requires y= ou to. There are alternatives: name-constrained sub-CAs. Private CAs. You c= an even have private CT to go along with them. Why mess up a protocol whose= intent is to show everything?

Ben:

Name-constrained sub-CAs have not been accep= ted by Chrome as a redaction mechanism. They were moved to the redaction sp= ec precisely because they are a variation of redaction.

Ah, good point. They're probably a= good idea for private CAs, though. :-)
=C2=A0

--001a114fa3b6a69827054a2790f2-- From nobody Tue Mar 7 09:46:44 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 323F51295BF for ; Tue, 7 Mar 2017 09:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 1j3p975TAYZ6 for ; Tue, 7 Mar 2017 09:46:40 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EFF129527 for ; Tue, 7 Mar 2017 09:46:40 -0800 (PST) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1488908799; bh=9amGvYRhp7SWUXVo/QwP7fjMhflt2Bn8ngYsmn4brY0=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=m1x3a+7WloC5+tWfJxK3YDx0qxn50W6xoKgn5H1+QOmXljRkmv6oWV0WRmz7ppN+9 A0D5Gj8wsFVDdV9JtyoVCE4xkSbIJnCocCKYcPpXjcVgWS4mvawSosqw8Ptr6a+Vxn W0fNU61gx+XDpYe8++lvkSTxGEoN3983GPq90Qnw= To: Ben Laurie , Rob Stradling Thread-Topic: White out (was Re: [Trans] Reviving Redaction) Thread-Index: AQHSltGsYuwx53OkwUyiXJdzn1zaVqGKHGqA//+LAyA= Date: Tue, 7 Mar 2017 17:46:38 +0000 Message-ID: <49c85f38e8324e83980c9032fc1b4a2b@EX2.corp.digicert.com> References: <8acee1f6-2df5-af74-640f-2ed836a81d90@comodo.com> <288bad395a3f4e1eb011d250b186f58a@EX2.corp.digicert.com> <4575c710-9095-c0bb-27b1-bcf93a8a02ba@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_033E_01D29730.184BA240" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] White out (was Re: Reviving Redaction) 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, 07 Mar 2017 17:46:43 -0000 ------=_NextPart_000_033E_01D29730.184BA240 Content-Type: multipart/alternative; boundary="----=_NextPart_001_033F_01D29730.184BA240" ------=_NextPart_001_033F_01D29730.184BA240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I highly doubt there would be a court order. However, I think linking to the applicable cease and desist, take down request, privacy issue, etc. is reasonable. From: Ben Laurie [mailto:benl@google.com] Sent: Tuesday, March 7, 2017 10:44 AM To: Rob Stradling Cc: Jeremy Rowley ; trans@ietf.org; Peter Bowen Subject: Re: White out (was Re: [Trans] Reviving Redaction) On 6 March 2017 at 23:30, Rob Stradling > wrote: I think the "white out" proposal that was discussed at the CT Policy Days is likely to be far more controversial than the various redaction proposals. "White out" proposes a mechanism for removing or omitting entire certificates from logs whilst still "proving" that those certificates are "included". Relying parties have to trust the log to only "white out" certs for good reasons. ISTM that this defeats most of the purpose of CT! >From https://tools.ietf.org/html/rfc6962#section-1... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates." ISTM that supporting "white out" would turn that sentence into this... "Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, modifiable, trusted logs of some issued certificates." That sounds not too dissimilar to the WebPKI minus CT! I think if this kind of thing is going to work, you have to also log the reason for removing the cert (e.g. link to court order :-). On 06/03/17 22:26, Jeremy Rowley wrote: On the CT days, there was an emphasis on a distinction between white washing a cert (removing it from CT) and redaction. Is the white washing in scope for the Trans list and this discussion or should it be separate? I ask because two of the main arguments cited for redaction tend to be: 1) Network/New project mapping reveals 2) Inclusion if PII in logged certs If white washing address the second concern, a specification around that process could eliminate a good deal of the push for redaction. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org ] On Behalf Of Rob Stradling Sent: Monday, March 6, 2017 2:39 PM To: Ben Laurie > Cc: trans@ietf.org ; Peter Bowen > Subject: Re: [Trans] Reviving Redaction On 06/03/17 21:22, Ben Laurie wrote: I think you can waste a lot of brainpower on redaction, but really the answer is: if you don't want to publish your names, then don't use a mechanism that requires you to. I agree that that's the ideal answer, but as we've seen, there is resistance to that answer from various participants in the CT ecosystem. There are alternatives: name-constrained sub-CAs. We removed that option from 6962-bis. It's now in draft-strad-trans-redaction, but IIRC the Chrome team hinted that they're unlikely to ever support it (at least in its current form). Private CAs. You can even have private CT to go along with them. Private CAs don't suit every use case, AFAIK. Why mess up a protocol whose intent is to show everything? Because Security and Useability aren't always in perfect harmony? Much as I'd love to stop wasting brainpower on redaction, I think it's a conversation that needs to continue for now (although not indefinitely!) On 6 March 2017 at 21:16, Rob Stradling wrote: On 06/03/17 06:06, Peter Bowen wrote: 8) The only way to get the content of a full certificate is to have a full certificate. Rationale: An alternative option is to have some sort of escrow key that can "unlock" a precertificate. In previous iterations of 6962-bis, we proposed a redaction mechanism that envisaged replacing domains labels with ?s in precertificates. That mechanism was deemed problematic by the Chrome team precisely because "The only way to get the content of a full certificate is to have a full certificate". What recourse does a domain owner have when they discover a precertificate for their domain space that they don't recognize? How do they figure out whether the (pre)cert was misissued or whether it was legitimately requested by a different team within their organization? The redaction mechanism that's documented in https://tools.ietf.org/html/draft-strad-trans-redaction-01#section-3.3 attempted to find a solution to this problem of recourse by swapping ?s for a hash of the unredacted domain. However, this mechanism has also been deemed problematic, because it could be trivial to determine unredacted labels via dictionary attacks. I think a "sort of escrow key" may be the only viable way to construct a redaction mechanism that is deemed non-problematic by everyone. This quickly turns into 'where do we keep the escrow key?' and 'who gets to access the escrow key?'. If there is no such thing, then these questions don't exist. I think these questions will need to be both asked and answered, although I'd be delighted to be proved wrong. Do others agree that these are true and can be used as givens for reviewing any proposed designs? Your other points all LGTM. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ------=_NextPart_001_033F_01D29730.184BA240 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I highly = doubt there would be a court order. However, I think linking to the = applicable cease and desist, take down request, privacy issue, etc. is = reasonable.

 

From:<= /b> = Ben Laurie [mailto:benl@google.com]
Sent: Tuesday, March 7, = 2017 10:44 AM
To: Rob Stradling = <rob.stradling@comodo.com>
Cc: Jeremy Rowley = <jeremy.rowley@digicert.com>; trans@ietf.org; Peter Bowen = <pzbowen@gmail.com>
Subject: Re: White out (was Re: = [Trans] Reviving Redaction)

 

 

 

On 6 = March 2017 at 23:30, Rob Stradling <rob.stradling@comodo.com> = wrote:

I think = the "white out" proposal that was discussed at the CT Policy = Days is likely to be far more controversial than the various redaction = proposals.

"White out" proposes a mechanism for = removing or omitting entire certificates from logs whilst still = "proving" that those certificates are = "included".  Relying parties have to trust the log to = only "white out" certs for good reasons.  ISTM that this = defeats most of the purpose of CT!

From https://tools.ietf.org/html/rfc6962#section-1...  "Certificate transparency aims to mitigate the problem of = misissued
   certificates by providing publicly auditable, = append-only, untrusted
   logs of all issued = certificates."

ISTM that supporting "white out" = would turn that sentence into this...
  "Certificate = transparency aims to mitigate the problem of misissued
  =  certificates by providing publicly auditable, modifiable, = trusted
   logs of some issued = certificates."

That sounds not too dissimilar to the WebPKI = minus CT!

 

I = think if this kind of thing is going to work, you have to also log the = reason for removing the cert (e.g. link to court order = :-).

 


On = 06/03/17 22:26, Jeremy Rowley wrote:

On the CT = days, there was an emphasis on a distinction between white washing
a = cert (removing it from CT) and redaction. Is the white washing in = scope
for the Trans list and this discussion or should it be = separate?

I ask because two of the main arguments cited for = redaction tend to be:
1) Network/New project mapping reveals
2) = Inclusion if PII in logged certs

If white washing address the = second concern, a specification around that
process could eliminate a = good deal of the push for redaction.


-----Original = Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob = Stradling
Sent: Monday, March 6, 2017 2:39 PM
To: Ben Laurie = <benl@google.com>
Cc: trans@ietf.org; = Peter Bowen <pzbowen@gmail.com>
Subject: Re: [Trans] = Reviving Redaction

On 06/03/17 21:22, Ben Laurie = wrote:

I think = you can waste a lot of brainpower on redaction, but really the
answer = is: if you don't want to publish your names, then don't use = a
mechanism that requires you to.


I agree that that's = the ideal answer, but as we've seen, there is resistance
to that = answer from various participants in the CT = ecosystem.

There are = alternatives: name-constrained sub-CAs.


We removed that = option from 6962-bis.  It's now in
draft-strad-trans-redaction, = but IIRC the Chrome team hinted that they're
unlikely to ever support = it (at least in its current form).

Private = CAs. You can even have private CT to go along with = them.


Private CAs don't suit every use = case, AFAIK.

Why mess = up a protocol whose intent is to show = everything?


Because Security and Useability = aren't always in perfect harmony?

Much as I'd love to stop = wasting brainpower on redaction, I think it's a
conversation that = needs to continue for now (although not = indefinitely!)

On 6 = March 2017 at 21:16, Rob Stradling wrote:

    On = 06/03/17 06:06, Peter Bowen wrote:
    = <snip>

        8) The only way to get = the content of a full certificate is to
        = have a
        full certificate.

  =       Rationale: An alternative option is to have some = sort of escrow

key

        that can = "unlock" a precertificate.


    In = previous iterations of 6962-bis, we proposed a redaction
  =   mechanism that envisaged replacing domains labels with ?s = in
    precertificates. That mechanism was deemed = problematic by the Chrome
    team precisely because = "The only way to get the content of a full
    = certificate is to have a full certificate".
    What = recourse does a domain owner have when they discover a
    = precertificate for their domain space that they don't = recognize?
    How do they figure out whether the (pre)cert = was misissued or
    whether it was legitimately requested = by a different team within
    their = organization?

    The redaction mechanism that's = documented in
    https://tools.ietf.org/html/draft-strad-trans-redaction= -01#section-3.3

<https://tools.ietf.org/html/draft-strad-trans-redaction= -01#section-3.3>

  =   attempted to find a solution to this problem of recourse by = swapping
    ?s for a hash of the unredacted domain.  = However, this mechanism has
    also been deemed = problematic, because it could be trivial to
    determine = unredacted labels via dictionary attacks.

    I think a = "sort of escrow key" may be the only viable way to
  =   construct a redaction mechanism that is deemed non-problematic = by
    everyone.

        This = quickly turns into 'where do we keep the escrow key?' and
  =       'who gets
        to access = the escrow key?'.  If there is no such thing, then these
  =       questions don't exist.


    I = think these questions will need to be both asked and answered,
  =   although I'd be delighted to be proved wrong.

  =       Do others agree that these are true and can be used = as givens for
        reviewing any proposed = designs?


    Your other points all = LGTM.


--
Rob Stradling
Senior = Research & Development Scientist
COMODO - Creating Trust = Online

 

------=_NextPart_001_033F_01D29730.184BA240-- ------=_NextPart_000_033E_01D29730.184BA240 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA3MTc0NjM2WjAj BgkqhkiG9w0BCQQxFgQULlvCrmFCFtUWXk0vj3JD+fEweQ4wgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAKzEkIn2Xz3V6mI4WGOnKeQzPIQgC7zpHfEi8b1V hp4SFIwmmADyIgOJeUfKrfOk45tNPkIVIaobGLgKv9ysaLUrncXd2GzGomOmSRANKvDVo6xqIU9B XrZKHCWG/uGux/+aF6wIXm/MYij5YyHx/4uG8l0xMFvHNy4S9jlOsmcOj6Wx4QqrNEddBLtac66Y Vm7Fnj9c7mzB/81wQK4+3RH5Dq7J8ypKA8/mYocglasK4v8K6Iw74ISTQVE4tD7SD4+4d4opsPP2 GhxKe0C5WR8ynLNfG5eMi1cPBnKdrHZ4ozVw7xAZp570LQhjc6+8fx4BQSzQUKg8dMM9BgDiH2EA AAAAAAA= ------=_NextPart_000_033E_01D29730.184BA240-- From nobody Tue Mar 7 10:10:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B42129467 for ; Tue, 7 Mar 2017 10:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuvVc7qpSduH for ; Tue, 7 Mar 2017 10:10:22 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 51001129442 for ; Tue, 7 Mar 2017 10:10:22 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 72so15129284uaf.3 for ; Tue, 07 Mar 2017 10:10:22 -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=mRddUvcLFrBmVDxxpaOBjnu/c1xZsYw6TJhJ2wJS/fE=; b=rKqLZpcE1yXY4lLVgK/BSYa0HV73YQk6wpmRtXMAFT+NhcWUVrfC9awi/d0jz0glyn QNgOFrZcfHRKXlxz8cleXPnIm2hV3Mzhkray92v0xR6yDWn5kSQ6CEkglv6x95AnjtW1 +h8xiOeIpiqi3vnxUwzXzIkOMCJ6Q4ro/C+MUbagV46Poj9hCKWPncpfIs3rMsZjPmDF wsljeObtl8Yz7y94F6NLrZmvDyFkqsLStTwkP7QZZlJY49s4XQN3fYpvi23KrDdKssDv VOHIvh0Jid1OxvGJM3anIuG46l45rBplNspBZs3/M8BRyU47MvcrgPK8P/veTS3sQcSV FsqA== 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=mRddUvcLFrBmVDxxpaOBjnu/c1xZsYw6TJhJ2wJS/fE=; b=QynxiifmJMhT+yRscnq8KHBxdoiuOupRQdRMmy6dcEePl7+2z/3rww4pLNlMFVk033 iJZkKjgOJNwmy4ECDVub1QejZkD0YdyXoS86HL1KPqgOce1E14D/CkLF1pegaDNnTF/s 3fY6OAppcgZf+PhLKPPLLFXWW8eyJ6FvKPfVcljk3emrll9ABm45QBJ9djH3wKwfjIiB w4+/w4GssrtrPCBICxk9JGok5hJTclrU9hEpiDVAW0lMBcFSq8UGdUiSt7+r1wcrUkYo MYYvU70Wc0Kmc3opPuEL8/NvXuCtEBzo7OaLh/lx9bIwVvkz+8woAvy9tQ5s0VcXVOSc 5NwA== X-Gm-Message-State: AMke39nkwXpkYIOdqWxAmbSdTPBw7t2aMMy+o0RW3nYot2MAdKE8Ik026+ENaOxmQD/kNyUOlw4Be2erJiIq2/2g X-Received: by 10.31.235.6 with SMTP id j6mr885672vkh.75.1488910221071; Tue, 07 Mar 2017 10:10:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Tue, 7 Mar 2017 10:10:20 -0800 (PST) In-Reply-To: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name> References: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name> From: Ben Laurie Date: Tue, 7 Mar 2017 18:10:20 +0000 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=94eb2c0944d6d4cf27054a27eca2 Archived-At: Cc: Richard Barnes , Trans Subject: Re: [Trans] STH Discipline & Security Considerations 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, 07 Mar 2017 18:10:23 -0000 --94eb2c0944d6d4cf27054a27eca2 Content-Type: text/plain; charset=UTF-8 On 3 March 2017 at 19:09, Andrew Ayer wrote: > On Fri, 3 Mar 2017 13:24:51 -0500 > Richard Barnes wrote: > > - A field in an SCT that indicates the canonical STH for the > > certificate in question. Possibly a serial number in STH that SCTs > > could refer to. > > Is this necessary? Why not define the canonical STH as the first STH > issued after the SCT (based on timestamp)? > That doesn't work - the cert may not have been included in the log by then. That said, not sure how Richard's proposal works, either - in general, the front-end that returns the SCT cannot know when the cert will be included, and hence cannot predict the relevant STH. Not entirely sure I agree with the initial premise anyway. > > --94eb2c0944d6d4cf27054a27eca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 March 2017 at 19:09, Andrew Ayer <agwa@andrewayer.name>= wrote:
On Fri, 3= Mar 2017 13:24:51 -0500
Richard Barnes <rlb@ipv.sx> wrote:
&= gt; - A field in an SCT that indicates the canonical STH for the
> certificate in question.=C2=A0 Possibly a serial number in STH that SC= Ts
> could refer to.

Is this necessary?=C2=A0 Why not define the canonical STH as th= e first STH
issued after the SCT (based on timestamp)?

<= div>That doesn't work - the cert may not have been included in the log = by then.

That said, not sure how Richard's pro= posal works, either - in general, the front-end that returns the SCT cannot= know when the cert will be included, and hence cannot predict the relevant= STH.

Not entirely sure I agree with the initial p= remise anyway.

<= /div>
--94eb2c0944d6d4cf27054a27eca2-- From nobody Tue Mar 7 11:01:04 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 607F1127A91 for ; Tue, 7 Mar 2017 11:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOq6QkdyBGXR for ; Tue, 7 Mar 2017 11:01:02 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 24D6612948D for ; Tue, 7 Mar 2017 11:00:04 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id v203so12060884wmg.0 for ; Tue, 07 Mar 2017 11:00:04 -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=Fwvp1KNNTkLzmqm8j9wgu/KxxVRttmnO3EaSTTLyZes=; b=u/hDVMaMCALvc78Tt2HCO4pgEvMxlHQ87jQD9JRnfYUl7kBVCgGzLr4ONLmevxmIoT TWF6vwmeW7gJ+wGdRZmVx5FBFSOxjTlIdN40fbUrPDy6VxiHa8f//fg4WRrPNjuibn2K Em9zBKueXp2L88hZqTIr76QGu5JuNrn9MHiIxE0vrJpOHvwul6cCo3tLt87Vk06GAq1f s4sw7widCRYfVnTRupfSbX18q++OOeVw2kbpqzSe1MxlaYqU7UBYPv10cblcWSC9RUFN Y4dWvtf9u91mGJkVIMeH9uNaXEkZtB980xtawxwU3261N0DikgN0bK5ED7ILmG7XNk7U 5qTQ== 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=Fwvp1KNNTkLzmqm8j9wgu/KxxVRttmnO3EaSTTLyZes=; b=cPSIALFhKgDyp66K68VA5x9N1Q1NzTM0p/NIq3cYC6jtZsZHtUb8+tKkikHJEmjXHW RfKIeiCpYjBbUtv2sPFngujI5Z4SjURrK/zQ/arTddkaI8EGd9azIemcP6Cq/tvCF1fQ n8sa2o1Gp++JSDj0gt1LfdFVwW1gM3oy4mzXTAx1DrxTfF2OQXePG6Q3Z8zSPvPYxgMV 0uFOdcM8fBhR2pDlQbQZM1yxfjLF3WaCFixG3ATzUnscjQlHeBKyUF/uTHuJ7mx2ngLR bwy1CbwkKHp8x5E63QICwF2kiA3/LLTys2xx+i4k1E2mF1CyK2MLfEpv6DecD73bmbC6 PBWA== X-Gm-Message-State: AMke39lS2m/TG2eFH8BWlPu27vzzHE3tSHwYygqgqjOs57JoeW7BHZnokS15V4/d9rLHssfON+PPCxtPv5azJQ== X-Received: by 10.28.130.139 with SMTP id e133mr20341247wmd.133.1488913202300; Tue, 07 Mar 2017 11:00:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Tue, 7 Mar 2017 11:00:01 -0800 (PST) In-Reply-To: References: <20170303110950.b04152416b71a5873b74fa37@andrewayer.name> From: Richard Barnes Date: Tue, 7 Mar 2017 14:00:01 -0500 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a114433a68663ee054a289e71 Archived-At: Cc: Trans , Andrew Ayer Subject: Re: [Trans] STH Discipline & Security Considerations 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, 07 Mar 2017 19:01:03 -0000 --001a114433a68663ee054a289e71 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 1:10 PM, Ben Laurie wrote: > > > On 3 March 2017 at 19:09, Andrew Ayer wrote: > >> On Fri, 3 Mar 2017 13:24:51 -0500 >> Richard Barnes wrote: >> > - A field in an SCT that indicates the canonical STH for the >> > certificate in question. Possibly a serial number in STH that SCTs >> > could refer to. >> >> Is this necessary? Why not define the canonical STH as the first STH >> issued after the SCT (based on timestamp)? >> > > That doesn't work - the cert may not have been included in the log by then. > > That said, not sure how Richard's proposal works, either - in general, the > front-end that returns the SCT cannot know when the cert will be included, > and hence cannot predict the relevant STH. > Yes, this proposal would require that there be enough coordination between log ingress and storage that the front-end could know under which STH a cert would land. I realize that might not be the case now, but is it unachievable? --Richard > Not entirely sure I agree with the initial premise anyway. > >> >> --001a114433a68663ee054a289e71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 7, 2017 at 1:10 PM, Ben Laurie <benl@google.com> wrote:


On 3 March= 2017 at 19:09, Andrew Ayer <agwa@andrewayer.name> wrote:=
On Fri, 3 = Mar 2017 13:24:51 -0500
Richard Barnes <rlb@ipv.sx> wrote:
=
> - A field in an SCT that = indicates the canonical STH for the
> certificate in question.=C2=A0 Possibly a serial number in STH that SC= Ts
> could refer to.

Is this necessary?=C2=A0 Why not define the canonical STH as th= e first STH
issued after the SCT (based on timestamp)?

=
That doesn't work - the cert may not have been included in t= he log by then.

That said, not sure how Richard= 9;s proposal works, either - in general, the front-end that returns the SCT= cannot know when the cert will be included, and hence cannot predict the r= elevant STH.

Yes, t= his proposal would require that there be enough coordination between log in= gress and storage that the front-end could know under which STH a cert woul= d land.=C2=A0 I realize that might not be the case now, but is it unachieva= ble?=C2=A0
=C2=A0
--Richard

=

Not entirely sure I ag= ree with the initial premise anyway.

--001a114433a68663ee054a289e71-- From nobody Tue Mar 7 12:55: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 1A812129428 for ; Tue, 7 Mar 2017 12:55:34 -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 vJVKoFSivhSt for ; Tue, 7 Mar 2017 12:55:32 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 D17101293F5 for ; Tue, 7 Mar 2017 12:55:32 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id w189so5132436pfb.0 for ; Tue, 07 Mar 2017 12:55:32 -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=9NX/cCTlloM/vAobUkKEWJHiyq9fu0n5SEIFyZShx+E=; b=i+YP9OtapGJgFXSpJr3D58LV8gFJoFo7hzJ1Pi6ZdLlKhWN7lOIwjy9cgj7mlncHS9 Jzyo2kOBqdEOfyJASUlP8syVgieRQzuagB+M35s2i1fWu4sAgYnDJrz9iO2u9H6LhZ+S TetIh51bouEo3FqrZPcPrybcli4e8XKgYnWSwFySNGymlOiIkjGaEI/iri6hxMbvSjHz nKHFECchctvJDo8aW0NU4KZbe+djKs17LJAINOnEUFh4YUmYubACIc/V6aPKBQdObKmf ZIQ8NKwgM1AHXgfrcEkCIhkEfGhd4W/tGPtrP+FeBb3KBgUAJYgb6cnGVscQDDAym5Oc hONw== 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=9NX/cCTlloM/vAobUkKEWJHiyq9fu0n5SEIFyZShx+E=; b=mw1l/i8SMidDbKd+4r8G74kycvPCMP+GvP8FTkYExqXJaK0yCQUjex83bW20/eFdb6 NNj37C7FtU2f52u9FNfv1qPpgRZe3k6PUBqhwn8GIu1Fk2rIg4k6expizf0qp5YsXl2e 9er37sCbnkJ6MdkPlj2V+bOm/+K3OVIc2fLs74LXCkVttkm0XbcvsaARVeZtwbVCU0d7 +mqA9hILD6DPT603ILfKc95vMzxkH9TebjpZtty11klE7nYx7IlSgwJfZjJMmCorLCWK VOcmDBcAnPAFaLCb4raYyj0VlaJ5WwbuLZBXxeaGNUW6N8o5K79jBvHymN0EZxkmuuLd eDBQ== X-Gm-Message-State: AMke39mthlG49ok2L7leZYXiDCQuvo/wFbdbHAJjy5JFNRXFrsxE3AIRSCBYz2sFiIdkAA== X-Received: by 10.84.232.72 with SMTP id f8mr3163861pln.85.1488920131992; Tue, 07 Mar 2017 12:55:31 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([8.18.217.206]) by smtp.gmail.com with ESMTPSA id d10sm1525289pfl.59.2017.03.07.12.55.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 12:55:31 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: <58d1f8ee-8f23-360b-42f1-54f264239d11@gmail.com> Date: Tue, 7 Mar 2017 12:55:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gGf7346F65CQq8n4Xk6T6CLtKSAwKxgbs" Archived-At: Subject: [Trans] Upcoming meeting 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, 07 Mar 2017 20:55:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gGf7346F65CQq8n4Xk6T6CLtKSAwKxgbs Content-Type: multipart/mixed; boundary="9m2sKghIGDEAhcikfK7keN2BWhsvHrAIO"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <58d1f8ee-8f23-360b-42f1-54f264239d11@gmail.com> Subject: Upcoming meeting --9m2sKghIGDEAhcikfK7keN2BWhsvHrAIO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: We're starting to put together an agenda for the upcoming meeting. There are some obvious topics for which we're planning on allocating time: 1) the state of the discussion of obtaining proofs (the issues raised by Richard Barnes and EKR. Any updates on log extension performance numbers would be excellent, as well 2) name redaction 3) the binary blobs logging draft. We're giving Frank time on the agenda to discuss the draft but the primary use case seems to be software distribution (packages transparency, basically) and it looks like there's been some activity in this space outside of the IETF. If anyone could provide an update, we'd be grateful There's the recurring question of a client (fsvo "client") behavior draft and whether or not it's time for some work on that. There's been no publicly visible activity on DNSSEC but let us know if there's something that would benefit from face-to-face discussion. Please let us know if there are issues to add to the agenda. As always, we prefer to spend meeting time on topics which have had already had active discussion on the mailing list. Thanks, Melinda & Paul --9m2sKghIGDEAhcikfK7keN2BWhsvHrAIO-- --gGf7346F65CQq8n4Xk6T6CLtKSAwKxgbs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYvx5BAAoJELiGRpM6HoEuis8P/iBXlsCzWBdYURefG2NehpqG aptNyBffrkK3tG5nixtYGmvPj8N50nxHjnsqea9SexKaDztgN1r96cnJo+cSDOeL rJ1DTOZ6UAOb6WhTFLeSWAYoz5MIWkA/t2HwLTnyjMD5RhFySmqrzK7nJNZO4ogG g8AxH4IwqCHopoV9+6a56bRUdRfmg2gzY7Cm6IQPZ7jdd56nZs8PBz/NxuRwXsjW EZAsQSbj6oZA7G33oZVqfay9xcDlVeiveN9bxyttQbhfj5ME2i83OBonGgFbP2j7 f5gyKqBGQQ+z1GQjUEqIr1rhl37kNxMTH4bkui+y+nn1PHAuHIKllTx9qbZC+gKm YZXJARLB4Z8W3VoxBF+9Xr27laxrYaGxQrT6gOzOlv8DbMflwWuCOdMAR86sGMGV 1j81zCadxIUcIb21nB8ikwIISppIdPKKjXHy+CPd/ZrJIAc+aiY2G5ctx8fw1N5k rODASwKSL7pOQwi+WzXqi3X5taoinY8Yk0ZaF23Jz8nyORFZcmfp5SGADCrQlesN rFfUhMANUqpULk+jBLUbkrN2siz8g0CaYN6x67ItciZyNS8vG1M0aI1WWb9UOwQM zkQdCpPinE6hgCvN6Mqg4G+OZqvA7fTF8keXaBVX19vakHaKPXSZ/pcNx4nlGIo/ 7YfCuVziTWU6/+eU/cu2 =EKrn -----END PGP SIGNATURE----- --gGf7346F65CQq8n4Xk6T6CLtKSAwKxgbs-- From nobody Tue Mar 7 19:13: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 BA0F91288B8 for ; Tue, 7 Mar 2017 19:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM3y_DC9W8v4 for ; Tue, 7 Mar 2017 19:13:51 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7610124281 for ; Tue, 7 Mar 2017 19:13:51 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id DE10420051C23 for ; Tue, 7 Mar 2017 19:13: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=FN8r8POKErm1lQQ+NDPlTjNoB38=; b= MZyHhNmRAb8XCt+GIjQb8/M6Q0zHgH7Fg4X+vNJct3yEtmsUBqm7eRzHnd/60Qef PMjeWafk0FT6S2GEP+rOoV7omiaMd0r9qQ6GvjUK2PsOyImKJYOdX1WTAA3/wVZh 0ZrWXTHdureTFU5Ze8/agi2sa67KAVbUcApgc7TYy/U= Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id B14C520051C22 for ; Tue, 7 Mar 2017 19:13:50 -0800 (PST) Received: by mail-lf0-f46.google.com with SMTP id y193so9286270lfd.3 for ; Tue, 07 Mar 2017 19:13:50 -0800 (PST) X-Gm-Message-State: AMke39n4Ee8NNKdzSeysrya40pLLSFa1TKh5re8SBqQzUIEvGeSulegxbpjmrvkAHHn2FPe/QdadZs0A/PmQxQ== X-Received: by 10.25.0.207 with SMTP id 198mr1033655lfa.134.1488942828910; Tue, 07 Mar 2017 19:13:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Tue, 7 Mar 2017 19:13:48 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Tue, 7 Mar 2017 22:13:48 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a113c9f486887e2054a2f8477 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 08 Mar 2017 03:13:52 -0000 --001a113c9f486887e2054a2f8477 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen wrote: > 8) The only way to get the content of a full certificate is to have a > full certificate. > > Rationale: An alternative option is to have some sort of escrow key > that can "unlock" a precertificate. This quickly turns into 'where do > we keep the escrow key?' and 'who gets to access the escrow key?'. If > there is no such thing, then these questions don't exist. > Can you elaborate on how you derived this principle? I think Rob captured well, which is there's a tension here - particularly in the case when the domain holder signals that the CA misissued - as to how to assess the impact and/or take corrective measure. There's a blurry line here between what's technically required versus what is addressed by policy external to the technology. So I think it'd be useful to understand how this one was derived. --001a113c9f486887e2054a2f8477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen <pzbowen@gmail.com>= wrote:
8) The only way to get the= content of a full certificate is to have a
full certificate.

Rationale: An alternative option is to have some sort of escrow key
that can "unlock" a precertificate.=C2=A0 This quickly turns into= 'where do
we keep the escrow key?' and 'who gets to access the escrow key?= 9;.=C2=A0 If
there is no such thing, then these questions don't exist.

Can you elaborate on how you derived this principle?=

I think Rob captured well, which is there's a= tension here - particularly in the case when the domain holder signals tha= t the CA misissued - as to how to assess the impact and/or take corrective = measure. There's a blurry line here between what's technically requ= ired versus what is addressed by policy external to the technology. So I th= ink it'd be useful to understand how this one was derived.=C2=A0
<= /div>
--001a113c9f486887e2054a2f8477-- From nobody Tue Mar 7 19:36: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 202B1129418 for ; Tue, 7 Mar 2017 19:36:34 -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 CB_n1JkHG_lP for ; Tue, 7 Mar 2017 19:36:33 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 0B27A124281 for ; Tue, 7 Mar 2017 19:36:33 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id x37so23151849ota.2 for ; Tue, 07 Mar 2017 19:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TSnKIT+1rJ5iTYAoRZwdHr0hXs90xETZa367z3CgDVE=; b=Hm7yxkBPzSb+liRmpdvapPUv4w7KFa+lztws2ffpxTF/ijoF/VLModPHuiTA65oPDa cXqBFIiqqi2WCFAjDMjTf2VDHMmtfKeKNATRdpK3yd43ebXRU7uzOB7j2WxGZAoEJ7Qj 6UtGMBYxizb0XGFbgGEd+JrKU+YTTxxXuWNMJUJ2NbVGlCYMImSdmsDjeinv+CGpydq8 5jS9rVl1Om2rk+VJwd1Jex2kfCIf0rwQ07FZyXqK5BYQeqAaL9UyxmYlDSHqI6O/P1nO ICPsM233ntK39+YFjdvjmPdbrqGJAYKsK/Ef1LFmlBaR36LcGU7hV+qp0/BSkoMpj2sm hhSA== 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=TSnKIT+1rJ5iTYAoRZwdHr0hXs90xETZa367z3CgDVE=; b=jEJ6HFdKp8b8Gu9EyfiLJZO7rPfGdIUvosRvcNg4DA0IsgERtrlbdFu9eYlYgEOjVg Lt0Dm3LyyF/n09T8bri31Oku8Cz2T0aVo2Evb9i7lE0m+oWWeHpH7trR08cQF2WL31wk nmGwKkZpdnMinmCAQe8k4+aj7ON5HwnK/MU+FMXIIG0LoVBn6Udp5VvE8YJ9xtJdwsoe oDGfi2Hzt8tvbvCJF8I/SDisnX0aw0MmEcHslT0murgtKbXqYbPXuJ9kXbdae9F2CtK4 +2qLEvhSWpAC1JRvJIj5ajsev3AFvmgElcqmky78134hZBS1DF4NLECQOgDpXId0qtaa kqQg== X-Gm-Message-State: AMke39kB2opdVrIBpGCgyvGnC4IiUwsZ1MJnT4/Z7qgmgABf5JFpnHPH1BdeOf3M7wX8s0chhHH0loPb95pLfQ== X-Received: by 10.157.8.98 with SMTP id 89mr2448633oty.264.1488944192380; Tue, 07 Mar 2017 19:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Tue, 7 Mar 2017 19:36:31 -0800 (PST) In-Reply-To: References: From: Peter Bowen Date: Tue, 7 Mar 2017 19:36:31 -0800 Message-ID: To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 08 Mar 2017 03:36:34 -0000 On Tue, Mar 7, 2017 at 7:13 PM, Ryan Sleevi wrote: > > On Mon, Mar 6, 2017 at 1:06 AM, Peter Bowen wrote: >> >> 8) The only way to get the content of a full certificate is to have a >> full certificate. >> >> Rationale: An alternative option is to have some sort of escrow key >> that can "unlock" a precertificate. This quickly turns into 'where do >> we keep the escrow key?' and 'who gets to access the escrow key?'. If >> there is no such thing, then these questions don't exist. > > > Can you elaborate on how you derived this principle? > > I think Rob captured well, which is there's a tension here - particularly in > the case when the domain holder signals that the CA misissued - as to how to > assess the impact and/or take corrective measure. There's a blurry line here > between what's technically required versus what is addressed by policy > external to the technology. So I think it'd be useful to understand how this > one was derived. I think I might have phrased it poorly. It was not meant to be a policy principal, rather a technical one. What I was trying to say is that I don't think having an encrypted blob in the precertificate (i.e. publicly escrowed) that has unredacted names is a good path. I am not intending to rule out a policy that says the holder of the full certificate (i.e. the CA) must provide it to X upon Y. My focus was on the "reversibility" of the precertificate in cases where the precertificate does not contain all the data in the final certificate. Thanks, Peter From nobody Tue Mar 7 21:13: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 69656129409 for ; Tue, 7 Mar 2017 21:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHPVTuECzPMK for ; Tue, 7 Mar 2017 21:13:15 -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 72BA71279EB for ; Tue, 7 Mar 2017 21:13:15 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 37F30A003A1D for ; Tue, 7 Mar 2017 21:13:15 -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=rtSiz0Vq0KeW4YOgkNgGtxBAFGY=; b= fm2B1GkBWyfh3YcYiV8jHzmPmFgXSAfBsNFoewcwcyBbHy6Iodw3b04qNYCbIgY1 V223N9np6B9553xGximADoTx7rsMA4fjsIaDM2+n0z/GWLPNryYW+c8YvMk1M0wF cnY9ZimRjedtLlbObwq1MQfylObVwQ8LVBlutmxhEic= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 01542A00012B for ; Tue, 7 Mar 2017 21:13:14 -0800 (PST) Received: by mail-lf0-f49.google.com with SMTP id k202so9989493lfe.1 for ; Tue, 07 Mar 2017 21:13:14 -0800 (PST) X-Gm-Message-State: AMke39kiEEFfTSCMVOnZrVTjLreKIAg3m5I5SwCBALAZXxM6kHO+7NP5t0FO5gZPQZVox2r2hbMwcchL/RxAAA== X-Received: by 10.46.80.21 with SMTP id e21mr1335118ljb.29.1488949993322; Tue, 07 Mar 2017 21:13:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Tue, 7 Mar 2017 21:13:12 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Wed, 8 Mar 2017 00:13:12 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=f403045fbae670c4f1054a312f03 Archived-At: Cc: Ryan Sleevi , "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 08 Mar 2017 05:13:16 -0000 --f403045fbae670c4f1054a312f03 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 10:36 PM, Peter Bowen wrote: > I think I might have phrased it poorly. It was not meant to be a > policy principal, rather a technical one. What I was trying to say is > that I don't think having an encrypted blob in the precertificate > (i.e. publicly escrowed) that has unredacted names is a good path. > > I am not intending to rule out a policy that says the holder of the > full certificate (i.e. the CA) must provide it to X upon Y. My focus > was on the "reversibility" of the precertificate in cases where the > precertificate does not contain all the data in the final certificate. I think the question of whether or not a precertificate should be able to produce a full certificate is, in some ways, related to the policy discussions. That is, a technical solution is a means to circumvent the policy discussion, and a policy discussion is a means to circumvent a technical solution. I don't know that I can agree a priori that we should rule this out, if only because it implies a policy solution is viable, but we don't know that. As far as statements go, while there's an intuitive appeal about the first statement, it does seem to conflict with some degree of RFC 7719 - namely, it seems to introduce additional terms that may conflict with or overlap with the terminology there. In particular, the claim that the existence/non-existence of a registered domain as public information sits within that space of uncertainty as to whether you're describing something akin/similar to "public suffix", or something akin to the registry/registrant relationship. I highlight this because I think Statement 1 is similar to Statement 8. If we're describing the technical capabilities, and ignoring any policy concerns, then I think 7719 and Statement 1 are in some degree of conflict. If we're describing possible and/or desired outcomes, then I think Statement 1 is a reasonable statement. Put differently, I'm unclear if Statement 1 is "This is a thing that currently exists" or whether it's "This is a thing that (for policy reasons related to CT and its deployment in common browser clients for purposes of the WebPKI) should exist". If the former, it's hard to support. If the latter, I agree that it represents at least a minimum, both of goal and of what is, as you note, effectively practiced at the TLD zone level. But it's a policy statement :) --f403045fbae670c4f1054a312f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 7, 2017 at 10:36 PM, Peter Bowen <pzbowen@gmail.com>= ; wrote:
I think I might have phr= ased it poorly.=C2=A0 It was not meant to be a
policy principal, rather a technical one.=C2=A0 What I was trying to say is=
that I don't think having an encrypted blob in the precertificate
(i.e. publicly escrowed) that has unredacted names is a good path.

I am not intending to rule out a policy that says the holder of the
full certificate (i.e. the CA) must provide it to X upon Y.=C2=A0 My focus<= br> was on the "reversibility" of the precertificate in cases where t= he
precertificate does not contain all the data in the final certificate.

I think the question of whether or not a precer= tificate should be able to produce a full certificate is, in some ways, rel= ated to the policy discussions. That is, a technical solution is a means to= circumvent the policy discussion, and a policy discussion is a means to ci= rcumvent a technical solution. I don't know that I can agree a priori t= hat we should rule this out, if only because it implies a policy solution i= s viable, but we don't know that.

As far as st= atements go, while there's an intuitive appeal about the first statemen= t, it does seem to conflict with some degree of RFC 7719 - namely, it seems= to introduce additional terms that may conflict with or overlap with the t= erminology there. In particular, the claim that the existence/non-existence= of a registered domain as public information sits within that space of unc= ertainty as to whether you're describing something akin/similar to &quo= t;public suffix", or something akin to the registry/registrant relatio= nship.

I highlight this because I think Statement = 1 is similar to Statement 8. If we're describing the technical capabili= ties, and ignoring any policy concerns, then I think 7719 and Statement 1 a= re in some degree of conflict. If we're describing possible and/or desi= red outcomes, then I think Statement 1 is a reasonable statement. Put diffe= rently, I'm unclear if Statement 1 is "This is a thing that curren= tly exists" or whether it's "This is a thing that (for policy= reasons related to CT and its deployment in common browser clients for pur= poses of the WebPKI) should exist". If the former, it's hard to su= pport. If the latter, I agree that it represents at least a minimum, both o= f goal and of what is, as you note, effectively practiced at the TLD zone l= evel. But it's a policy statement :)
--f403045fbae670c4f1054a312f03-- From nobody Tue Mar 7 21:38: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 5456E126D73 for ; Tue, 7 Mar 2017 21:38:10 -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 Gkal_5U335Mi for ; Tue, 7 Mar 2017 21:38:09 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 136B0126B6D for ; Tue, 7 Mar 2017 21:38:09 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id o24so24102686otb.1 for ; Tue, 07 Mar 2017 21:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AzWEJVAzp8lW259db9uYelhG6Tb07e/7f6oQGaPLz1Y=; b=AVV6NEkOEWcN73U4zKfF0j7Xa6fDq5H8nNGmLWR5yr4QgdTLtm9wniTyawBlMQvWy5 sZ3fL2wUP2T80jjY8qoLm8m+Te9Fjce6trre5kRcF/uR9y+BbZET/CmtmUSQIs0QL++8 Lf1p8KOk9RiNipY0Wn9ctr76MJLimdEKclY9bqW6UM54RGbZ5BpyQCbY04WsHFznOfIo /CajCS0x/HS6kCO8AUmg9qbEvZSzClLOC45EWk3yZ7q4md59cT9FVH2bwQVYQzvSVFOL hTgWG/2Mv8elzhD7jscjaXYu5BLld3RvaBJNL5yBZvdQEhtsQxsmAOZzmUCPWNT7SQV6 3gEA== 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=AzWEJVAzp8lW259db9uYelhG6Tb07e/7f6oQGaPLz1Y=; b=gybIfUOZQ2PIWL2rkMSfa+wTJJcUhB1FMR8LmcfW9QDEPnpHb0kQb7BOS5+fMPowJL m796De2pjQFWE6QlupKwIQX4C/ZCXn3t51ROi0SCoDowAZqnRBQQ+/dKNwQgYPkIVSV5 vB91BQ/ksSACpLw8vM00p6o4lKwcUW1kBoL30dnq+9HDUsiYU/dp21sOn6ShNw+EkIVf vccTXgDy+1xAO27f2jx5QfQjj66JUEyNdWtw4qp67B3gz2ihErNn65xaFm0YWJlXYMv4 2Rmmx3lOYOZzxTpC5K3E7r/j7gFknUCNQ3tFbJfgI3Qm1fYfgZ6/6TXaMEju7ZjyixFh roqQ== X-Gm-Message-State: AMke39lizaQ2+2inovMPcW5fyttA3jxnQIcwcfvmmDfv8aAe7AnGGZ5SfJSGKJcQk+Bgb3sUNCGXjPRKPefmZQ== X-Received: by 10.157.15.161 with SMTP id d30mr2349774otd.221.1488951488405; Tue, 07 Mar 2017 21:38:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Tue, 7 Mar 2017 21:38:07 -0800 (PST) In-Reply-To: References: From: Peter Bowen Date: Tue, 7 Mar 2017 21:38:07 -0800 Message-ID: To: Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Reviving Redaction 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, 08 Mar 2017 05:38:10 -0000 On Tue, Mar 7, 2017 at 9:13 PM, Ryan Sleevi wrote: > > > On Tue, Mar 7, 2017 at 10:36 PM, Peter Bowen wrote: >> >> I think I might have phrased it poorly. It was not meant to be a >> policy principal, rather a technical one. What I was trying to say is >> that I don't think having an encrypted blob in the precertificate >> (i.e. publicly escrowed) that has unredacted names is a good path. >> >> I am not intending to rule out a policy that says the holder of the >> full certificate (i.e. the CA) must provide it to X upon Y. My focus >> was on the "reversibility" of the precertificate in cases where the >> precertificate does not contain all the data in the final certificate. > > > I think the question of whether or not a precertificate should be able to > produce a full certificate is, in some ways, related to the policy > discussions. That is, a technical solution is a means to circumvent the > policy discussion, and a policy discussion is a means to circumvent a > technical solution. I don't know that I can agree a priori that we should > rule this out, if only because it implies a policy solution is viable, but > we don't know that. > > As far as statements go, while there's an intuitive appeal about the first > statement, it does seem to conflict with some degree of RFC 7719 - namely, > it seems to introduce additional terms that may conflict with or overlap > with the terminology there. In particular, the claim that the > existence/non-existence of a registered domain as public information sits > within that space of uncertainty as to whether you're describing something > akin/similar to "public suffix", or something akin to the > registry/registrant relationship. > > I highlight this because I think Statement 1 is similar to Statement 8. If > we're describing the technical capabilities, and ignoring any policy > concerns, then I think 7719 and Statement 1 are in some degree of conflict. > If we're describing possible and/or desired outcomes, then I think Statement > 1 is a reasonable statement. Put differently, I'm unclear if Statement 1 is > "This is a thing that currently exists" or whether it's "This is a thing > that (for policy reasons related to CT and its deployment in common browser > clients for purposes of the WebPKI) should exist". If the former, it's hard > to support. If the latter, I agree that it represents at least a minimum, > both of goal and of what is, as you note, effectively practiced at the TLD > zone level. But it's a policy statement :) OK, rephrasing in RFC 7719 terms and focusing on the reality: For all TLDs which consist of three or more letters, except for mil, gov, and int, and for certain two letter TLDs, the existence of a domain name consisting of the label immediately below plus the label that is the TLD is public information. This is ICANN policy as it exists today. It is a fact independent of browsers or CT. Additionally certain two letter TLDs, such as us and se, have the same policy. I'm just asking for stipulation that due to the policies enforced by ICANN, it is not valid to say "the existence of companycorporationpromocode.com. is not public information". From nobody Tue Mar 7 22:34: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 64F1712945E for ; Tue, 7 Mar 2017 22:34:29 -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 jkxoJ1q6xp_A for ; Tue, 7 Mar 2017 22:34:28 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 4BD57129448 for ; Tue, 7 Mar 2017 22:34:28 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id 62so14273696oih.2 for ; Tue, 07 Mar 2017 22:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dUUXSSgw2dBE79IUpaNnu3HzX+IF8RJSXaxqY1ywhDc=; b=Q5t9m9EBkJ6dOkHple3nq1XJ0Z1fO1mIjhR7ZtUd+0zsE/4EFfuP+NDeKDiMSg3muk F5qyD+ryuFh2VYK3ayC1lL70Mh0bXPm4RlvNe3pB9sYZfihEPG7wlKWSIEKem+TNFxuj 1AKoJHwUua/OGhaGuZJLRiuMVmvQXZMo1Phnn2QAbs3Qqw9xHYYMBqXr7HGsW2GIg4jF b8EwPiE/u6mIXF55jlnS6TL6VGIMW6kKzh5k1xf9rru/twuaJRbUeGJwR3b22TXRQOQh UPBh3ZIHWoejqysK9MDLpsXkklBTni0cwEGcXiE0aBec9UzKbwCHNDF3v6by9XTbIPF+ klBw== 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=dUUXSSgw2dBE79IUpaNnu3HzX+IF8RJSXaxqY1ywhDc=; b=ZEpKmbFVzFKh7WG7NKeKE9V+2JzEfsk9rljoF9+d0ivEjBSCKHuduIFl/wuB6sJJ7u zPer15U3jPbJvY0bWdC5BM+wXDpnCvqpJes6bItdaxt8FSrHSml474/0rLSsyU3yWWCe SNfsqWC/NsIP/gjKZlOcEeUclEJz731w3TEwAVDijQkBmvLywRPbcI6kO/SmgD0A7WUL 3rVxL8eNu/rPsd1uIZcGn1XGEuU39zLMZS8V5PRiA+bcNVZ445qZ8Tvik6ghbG+yJwuR LrBhxs8F/LYGZoaow61fhIldTlwmBw4heL9DQmEpHiPNqnZv9lxuWtmjcnC+s2b5M8su oTiQ== X-Gm-Message-State: AMke39kKm0164Trba+9H5f/9o2MkN16i6Jbu6/roUw8i6wSpFAeM0pL2VXSW/JsKgGG8AfHOsImGH7gbvSw6FA== X-Received: by 10.202.241.70 with SMTP id p67mr2247173oih.67.1488954867345; Tue, 07 Mar 2017 22:34:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.116 with HTTP; Tue, 7 Mar 2017 22:34:26 -0800 (PST) From: Peter Bowen Date: Tue, 7 Mar 2017 22:34:26 -0800 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Non-redaction options 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, 08 Mar 2017 06:34:29 -0000 While I realize this WG is focused on the technical implementation of transparency, I think it is helpful to review what has been proposed or implemented by clients for transparency. As with my prior email, I think I have all these facts right, but I would appreciate feedback if I got them wrong. I've numbered them to help with replies but there is no meaning to the order. 1) At least one client has announced an intent to require certificates to be included in CT to be trusted, as the default state. Currently a subset of certificates have this requirement, but the intent from clients appears to be to set this as the default rule for all certificates at some point. 2) Clients have said they will exclude certificates that do not chain to roots included in the default trust list from this requirement. (It is a unclear what happens if a user adds a CA that is cross-signed by a public CA as a locally installed trust anchor.) 3) No client, as far as I know, allows scoping a trust anchor when it is added. Adding a local trust anchor trusts it for the entire DNS hierarchy. 4) All clients that allow adding local trust anchors give these anchors super powers, such as overriding public key pinning. There is no way to prevent a local trust anchor from having this power. 5) Some clients or client OSes make it extremely hard for users to add local trust anchors. 6) At least one client has proposed to have a client setting, available only via "enterprise policy" which allows excluding domain subtrees from the CT requirement. 7) Not all client software packages that have announced they are considering a CT-by-default rule have integration with common enterprise police management systems. 8) On Windows, many popular versions (such as Windows 10 Home) do not have policy support. 9) There is no ability to allow only certain policies to be set. If you enable a policy administrator access to set a domain whitelist they can also disable numerous security features and install browser extensions. Thanks, Peter From nobody Wed Mar 8 05:24:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E74129688 for ; Wed, 8 Mar 2017 05:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r2fkghwDhGE for ; Wed, 8 Mar 2017 05:24:19 -0800 (PST) Received: from homiemail-a24.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 DA58E12967A for ; Wed, 8 Mar 2017 05:24:19 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 38BBA70F6787 for ; Wed, 8 Mar 2017 05:24:19 -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=OUcGIbmFr9AGj0L+OQbv+BY3blY=; b= AJNbcD0OBOr0KonvqlZUbnUtjACf0WlOdDRs73Tb3zR7s1MnnsbIRV6OaUorWKY2 GGeGEQq8iSA2YjTRY8u1uz7var5kAoFy9J00EFSLb/j4BeMKy+VHk6D47rE+RjKJ Q5VRSKVGu8E+B0mvEh1Hz4lzkluny35IenHPZIeK5/I= Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 0330670F6785 for ; Wed, 8 Mar 2017 05:24:18 -0800 (PST) Received: by mail-lf0-f52.google.com with SMTP id k202so14413327lfe.1 for ; Wed, 08 Mar 2017 05:24:18 -0800 (PST) X-Gm-Message-State: AMke39kvzzRT5tp/qwrkktKje7fJsj83KaabZA4arl2rbhzpGGHpPpw9Vu2n0vPQw8HjkJjbnl5vkN9Zq6nlQA== X-Received: by 10.46.82.66 with SMTP id g63mr2088023ljb.113.1488979457134; Wed, 08 Mar 2017 05:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Wed, 8 Mar 2017 05:24:16 -0800 (PST) In-Reply-To: References: From: Ryan Sleevi Date: Wed, 8 Mar 2017 08:24:16 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a113c35569eda24054a380b0b Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Non-redaction options 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, 08 Mar 2017 13:24:21 -0000 --001a113c35569eda24054a380b0b Content-Type: text/plain; charset=UTF-8 On Wed, Mar 8, 2017 at 1:34 AM, Peter Bowen wrote: > While I realize this WG is focused on the technical implementation of > transparency, I think it is helpful to review what has been proposed > or implemented by clients for transparency. > > As with my prior email, I think I have all these facts right, but I > would appreciate feedback if I got them wrong. I've numbered them to > help with replies but there is no meaning to the order. > > 1) At least one client has announced an intent to require certificates > to be included in CT to be trusted, as the default state. > > Currently a subset of certificates have this requirement, but the > intent from clients appears to be to set this as the default rule for > all certificates at some point. > > 2) Clients have said they will exclude certificates that do not chain > to roots included in the default trust list from this requirement. > > (It is a unclear what happens if a user adds a CA that is cross-signed > by a public CA as a locally installed trust anchor.) > > 3) No client, as far as I know, allows scoping a trust anchor when it > is added. Adding a local trust anchor trusts it for the entire DNS > hierarchy. > > 4) All clients that allow adding local trust anchors give these > anchors super powers, such as overriding public key pinning. There is > no way to prevent a local trust anchor from having this power. > > 5) Some clients or client OSes make it extremely hard for users to add > local trust anchors. > > 6) At least one client has proposed to have a client setting, > available only via "enterprise policy" which allows excluding domain > subtrees from the CT requirement. > > 7) Not all client software packages that have announced they are > considering a CT-by-default rule have integration with common > enterprise police management systems. > > 8) On Windows, many popular versions (such as Windows 10 Home) do not > have policy support. > > 9) There is no ability to allow only certain policies to be set. If > you enable a policy administrator access to set a domain whitelist > they can also disable numerous security features and install browser > extensions. > Regardless of factual accuracy/inaccuracy, and despite the dangerous foray into policy here, I think many of the points, as posed, attempt to suggest a contradiction to / ignoring the Immutable Laws of Computer Security. That is, I would argue that 4, 5, 6, 7, 8, 9 are not relevant to the discussion when considering such basic statements Law #6 "Your computer is only as secure as the administrator is trustworthy" or Law #2 "If a bad guy can alter the operating system of your computer, it's not your computer anymore" Nor, for the most part, do I think they're relevant for/and or necessary for a discussion of redaction, beyond statement #1. --001a113c35569eda24054a380b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 8, 2017 at 1:34 AM, Peter Bowen <pzbowen@gmail.com>= wrote:
While I realize this WG is= focused on the technical implementation of
transparency, I think it is helpful to review what has been proposed
or implemented by clients for transparency.

As with my prior email, I think I have all these facts right, but I
would appreciate feedback if I got them wrong.=C2=A0 I've numbered them= to
help with replies but there is no meaning to the order.

1) At least one client has announced an intent to require certificates
to be included in CT to be trusted, as the default state.

Currently a subset of certificates have this requirement, but the
intent from clients appears to be to set this as the default rule for
all certificates at some point.

2) Clients have said they will exclude certificates that do not chain
to roots included in the default trust list from this requirement.

(It is a unclear what happens if a user adds a CA that is cross-signed
by a public CA as a locally installed trust anchor.)

3) No client, as far as I know, allows scoping a trust anchor when it
is added.=C2=A0 Adding a local trust anchor trusts it for the entire DNS hierarchy.

4) All clients that allow adding local trust anchors give these
anchors super powers, such as overriding public key pinning.=C2=A0 There is=
no way to prevent a local trust anchor from having this power.

5) Some clients or client OSes make it extremely hard for users to add
local trust anchors.

6) At least one client has proposed to have a client setting,
available only via "enterprise policy" which allows excluding dom= ain
subtrees from the CT requirement.

7) Not all client software packages that have announced they are
considering a CT-by-default rule have integration with common
enterprise police management systems.

8) On Windows, many popular versions (such as Windows 10 Home) do not
have policy support.

9) There is no ability to allow only certain policies to be set.=C2=A0 If you enable a policy administrator access to set a domain whitelist
they can also disable numerous security features and install browser
extensions.

Regardless of factual accur= acy/inaccuracy, and despite the dangerous foray into policy here, I think m= any of the points, as posed, attempt to suggest a contradiction to / ignori= ng the Immutable Laws of Computer Security.

That i= s, I would argue that =C2=A04, 5, 6, 7, 8, 9 are not relevant to the discus= sion when considering such basic statements Law #6 "Your computer is o= nly as secure as the administrator is trustworthy" or Law #2 "If = a bad guy can alter the operating system of your computer, it's not you= r computer anymore"

Nor, for the most part, d= o I think they're relevant for/and or necessary for a discussion of red= action, beyond statement #1.
--001a113c35569eda24054a380b0b-- From nobody Wed Mar 8 15:12: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 9C874129508 for ; Wed, 8 Mar 2017 15:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 qbCnnbKv9w4T for ; Wed, 8 Mar 2017 15:12:52 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2EF12950C for ; Wed, 8 Mar 2017 15:12:52 -0800 (PST) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1489014771; bh=lWhGcGCDjhTosW2wD0tqcZV29yOikI9j2ewzV9fGvyI=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=KNfx0lh+pSdUtGyXHT9wW7v3rHe6IGdU0uFMGds+PlOL8gTKbjybTGV+GENyCLjMv vhj72JUHilzY2rKTuKk1QVj7SOrMiLXq2W7AOkRmvsfMpnkHHJlmBBcAN7GeVQ5u3W eJ//5FQGfHtKweWG1U56QQaL6Tp2GOYntRoducgk= To: Ryan Sleevi , Peter Bowen Thread-Topic: [Trans] Non-redaction options Thread-Index: AQHSl9YN8NWPte5AjEGBUz5vPspyOaGLZD4AgAAuvXA= Date: Wed, 8 Mar 2017 23:12:50 +0000 Message-ID: <22a67f1ecf7e4ff68919e8bad8e206e8@EX2.corp.digicert.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_035E_01D29826.D4F59850" MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Non-redaction options 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, 08 Mar 2017 23:12:54 -0000 ------=_NextPart_000_035E_01D29826.D4F59850 Content-Type: multipart/alternative; boundary="----=_NextPart_001_035F_01D29826.D4F59850" ------=_NextPart_001_035F_01D29826.D4F59850 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Why wouldn=E2=80=99t the rest be relevant? Particularly, if one goal of = redaction is to remove private information from logs but the log = operator is not permitted to set policy to exclude certificates that = chain to an included root, then it seems very relevant to the redaction = discussion. =20 From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ryan Sleevi Sent: Wednesday, March 8, 2017 6:24 AM To: Peter Bowen Cc: trans@ietf.org Subject: Re: [Trans] Non-redaction options =20 =20 =20 On Wed, Mar 8, 2017 at 1:34 AM, Peter Bowen > wrote: While I realize this WG is focused on the technical implementation of transparency, I think it is helpful to review what has been proposed or implemented by clients for transparency. As with my prior email, I think I have all these facts right, but I would appreciate feedback if I got them wrong. I've numbered them to help with replies but there is no meaning to the order. 1) At least one client has announced an intent to require certificates to be included in CT to be trusted, as the default state. Currently a subset of certificates have this requirement, but the intent from clients appears to be to set this as the default rule for all certificates at some point. 2) Clients have said they will exclude certificates that do not chain to roots included in the default trust list from this requirement. (It is a unclear what happens if a user adds a CA that is cross-signed by a public CA as a locally installed trust anchor.) 3) No client, as far as I know, allows scoping a trust anchor when it is added. Adding a local trust anchor trusts it for the entire DNS hierarchy. 4) All clients that allow adding local trust anchors give these anchors super powers, such as overriding public key pinning. There is no way to prevent a local trust anchor from having this power. 5) Some clients or client OSes make it extremely hard for users to add local trust anchors. 6) At least one client has proposed to have a client setting, available only via "enterprise policy" which allows excluding domain subtrees from the CT requirement. 7) Not all client software packages that have announced they are considering a CT-by-default rule have integration with common enterprise police management systems. 8) On Windows, many popular versions (such as Windows 10 Home) do not have policy support. 9) There is no ability to allow only certain policies to be set. If you enable a policy administrator access to set a domain whitelist they can also disable numerous security features and install browser extensions. =20 Regardless of factual accuracy/inaccuracy, and despite the dangerous = foray into policy here, I think many of the points, as posed, attempt to = suggest a contradiction to / ignoring the Immutable Laws of Computer = Security. =20 That is, I would argue that 4, 5, 6, 7, 8, 9 are not relevant to the = discussion when considering such basic statements Law #6 "Your computer = is only as secure as the administrator is trustworthy" or Law #2 "If a = bad guy can alter the operating system of your computer, it's not your = computer anymore" =20 Nor, for the most part, do I think they're relevant for/and or necessary = for a discussion of redaction, beyond statement #1. ------=_NextPart_001_035F_01D29826.D4F59850 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Why = wouldn=E2=80=99t the rest be relevant? Particularly, if one goal of = redaction is to remove private information from logs but the log = operator is not permitted to set policy to exclude certificates that = chain to an included root, then it seems very relevant to the redaction = discussion.

 

From:<= /b> = Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ryan = Sleevi
Sent: Wednesday, March 8, 2017 6:24 AM
To: = Peter Bowen <pzbowen@gmail.com>
Cc: = trans@ietf.org
Subject: Re: [Trans] Non-redaction = options

 

 

 

On Wed, = Mar 8, 2017 at 1:34 AM, Peter Bowen <pzbowen@gmail.com> = wrote:

While I = realize this WG is focused on the technical implementation = of
transparency, I think it is helpful to review what has been = proposed
or implemented by clients for transparency.

As with = my prior email, I think I have all these facts right, but I
would = appreciate feedback if I got them wrong.  I've numbered them = to
help with replies but there is no meaning to the order.

1) = At least one client has announced an intent to require = certificates
to be included in CT to be trusted, as the default = state.

Currently a subset of certificates have this requirement, = but the
intent from clients appears to be to set this as the default = rule for
all certificates at some point.

2) Clients have said = they will exclude certificates that do not chain
to roots included in = the default trust list from this requirement.

(It is a unclear = what happens if a user adds a CA that is cross-signed
by a public CA = as a locally installed trust anchor.)

3) No client, as far as I = know, allows scoping a trust anchor when it
is added.  Adding a = local trust anchor trusts it for the entire DNS
hierarchy.

4) = All clients that allow adding local trust anchors give these
anchors = super powers, such as overriding public key pinning.  There = is
no way to prevent a local trust anchor from having this = power.

5) Some clients or client OSes make it extremely hard for = users to add
local trust anchors.

6) At least one client has = proposed to have a client setting,
available only via = "enterprise policy" which allows excluding domain
subtrees = from the CT requirement.

7) Not all client software packages that = have announced they are
considering a CT-by-default rule have = integration with common
enterprise police management = systems.

8) On Windows, many popular versions (such as Windows 10 = Home) do not
have policy support.

9) There is no ability to = allow only certain policies to be set.  If
you enable a policy = administrator access to set a domain whitelist
they can also disable = numerous security features and install = browser
extensions.

 

Regardless of factual accuracy/inaccuracy, and despite = the dangerous foray into policy here, I think many of the points, as = posed, attempt to suggest a contradiction to / ignoring the Immutable = Laws of Computer Security.

 

That is, I would argue that  4, 5, 6, 7, 8, 9 are = not relevant to the discussion when considering such basic statements = Law #6 "Your computer is only as secure as the administrator is = trustworthy" or Law #2 "If a bad guy can alter the operating = system of your computer, it's not your computer = anymore"

 

Nor, for the most part, do I think they're relevant = for/and or necessary for a discussion of redaction, beyond statement = #1.

------=_NextPart_001_035F_01D29826.D4F59850-- ------=_NextPart_000_035E_01D29826.D4F59850 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA4MjMxMjQ5WjAj BgkqhkiG9w0BCQQxFgQUC4nT508B9zCmn0vCAO6GZK8yEocwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAANny992Tae6EkrpOAdsnOo/2AFSNzYQmibXKIVB +A13HeiWviPtJ/IFiNE+RbkoiNsvIv3bxDoOCipjxDOkWe/z7XSfZ7YkEQb8XDgarVNyJZykBJ8C LDJirxbw9vSZjMLkTTZUYEaXKOe54IAIT1DlkJAbiMUWoEfBnCSM9ozWnEngnoGHAhPEuPi42Clf oIm1Yhed28B7iVjJiuYN0LYeTgXF986w2ZL1z/WFKwxTjXc17xWMJwEDcwakIf5eXW/V6whLBlAY vNSUPWDFY27+h51Q0iQjwvYCAs72h2D76xu/uGiTBorDzOtLIZfuM1dLN+KXUm0watpmgjP53YcA AAAAAAA= ------=_NextPart_000_035E_01D29826.D4F59850-- From nobody Thu Mar 9 12:44:49 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 04B9612951E for ; Thu, 9 Mar 2017 12:44: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 FE7oDvbBQ7op for ; Thu, 9 Mar 2017 12:44:46 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D925712896F for ; Thu, 9 Mar 2017 12:44:46 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 77so30313628pgc.1 for ; Thu, 09 Mar 2017 12:44:46 -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=blXq3BsGrdjgvqGTiRsMQoQYdgpjQ9ga1RW1Ut3UrgY=; b=c46ExrlXt7PBbTjjHigzrAxtQq+ACiuwF9vqMHmoArzQPcMZMo1XFOORLNP+n0JYnd TapQNrZtJPufbbTrCe9rajMoYJ3osmGEE5aa18owzH93X305YhGc9MavfhcfntyNn5TS JYj/U9vjPGL9PKqpnSNI0YOj2tHv/lV/EW1R3n2uw2LSy0EIgivMWQ2SKjmg+jy7vJcl rIl4zO3/jQUH2UyzMOR4we+qRCgeXQ7bxTF2a3Yp19Sn5/YE5qqLWkv2SwiA+LjJtwBh gmeintA5v8CVst6HeMlZZ/5ROCL67rRODoK8/R9UF79PKSz0d8iH3PUhkjidaSUke6ux kTQQ== 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=blXq3BsGrdjgvqGTiRsMQoQYdgpjQ9ga1RW1Ut3UrgY=; b=oswuyGEHDHr5nq5V5UARCbYYNQEEzhbKH+ZtVkQvJv6q4Q1jVbo6Zjbv7qzGlJQ/b7 c8WukZ5uh18FzJ+tGLUZH6XzWoA7Cxq3Mc8X8xUZp4+q/Q57XLMaeZfdsWTcFQOdoKl4 uaJn1x9UHD8DRbMnDZb9kdaxCr6uNu/M+N0f06gvtvh/8QSw+JmlASYbqSNQpmkZU7ZZ aky9c2sSDI53a5pWNaMH99G6dSmb0r8TTqqt/3rVESjbCycLL/PAgKHs+YD29T2iM6Y5 2R46aUOz3l3CCQHGh031sUn156KBZ3L5lhE7HY92wD0nnFWSGGZy0sJxKqGMFI4K5YLH fhuQ== X-Gm-Message-State: AMke39kWptTMu9r74sMHiW/MU4wKXmwet32HgYqhNirXh4lwOF8gJJM12jNg3QtqSIulhQ== X-Received: by 10.98.23.202 with SMTP id 193mr16444433pfx.141.1489092285832; Thu, 09 Mar 2017 12:44:45 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([8.18.217.206]) by smtp.gmail.com with ESMTPSA id v9sm14096082pfg.133.2017.03.09.12.44.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 12:44:45 -0800 (PST) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Thu, 9 Mar 2017 12:44:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q4hPf4tmTC5HV12L9xbA18sUHp4qtKiQN" Archived-At: Cc: Paul Wouters Subject: [Trans] Draft agenda 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, 09 Mar 2017 20:44:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q4hPf4tmTC5HV12L9xbA18sUHp4qtKiQN Content-Type: multipart/mixed; boundary="GlrJI6MEtsjQTwRfvhuCIBEdJ4OrKPq3s"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Cc: Paul Wouters Message-ID: Subject: Draft agenda --GlrJI6MEtsjQTwRfvhuCIBEdJ4OrKPq3s Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: This is a first poke at an agenda, with some open questions (for example, has there been any progress on a log monitoring API?). Please flag any problems, raise any questions, or suggest any additions. Thanks, Melinda =3D=3D=3D=3D=3D=3D=3D=3D trans session, ietf 98 13:00-14:30 Tuesday March 28, 2017 @ Room Studio 4 Agenda ------ administrivia (~5 minutes) blue sheets, minute taker, jabber scribe, agenda-bashing Note Well status update =2E charter unchanged =2E issue tracker (17 open tickets) =2E 6962-bis: WGLC completed - significant issue raised by Mozilla, nearing resolution =2E Redaction: Weak interest but we need a way forward =2E threat-analysis: stuck - additional author? =2E ct-gossip: through wglc =2E ct-dnssec: no update =2E ct-binaries: new drafts, apparently there's work being done on this problem outside the IETF 6962bis follow-up, obtaining proofs (Eran/Richard) Name redaction/privacy =2E use of VRFs for name redaction (Eran) =2E a privacy-preserving mechanism for obtaining and and reporting log misbehavior (Saba) binaries logging =2E draft-zhang-trans-ct-binary-codes-04 (Frank) =2E current work on this problem outside of the IETF (DKG) new work =2E Log Monitoring API Any other business? --GlrJI6MEtsjQTwRfvhuCIBEdJ4OrKPq3s-- --Q4hPf4tmTC5HV12L9xbA18sUHp4qtKiQN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYwb68AAoJELiGRpM6HoEuDg8QAInB6zXUBPYuANSkU+idFi1Y R+/vil4c9uN/Br7Ti0WtGktdJHu2o6B5PvoiVZzxg3jHs5aHcM8ah/f9CwEnSvNx AUWpBrtOqvJdad3uOlzFgxl29nD7DeOir2HxjGPR93Z8ZtmgPAY9QU+gKACkC7jX puJxfyDlWFAiLC2QKrUoJfnbPAe8aJlvfx+LPQCg/SztoGM0YeGIg2nmeMOUz/Sr 6uC3wR6MLm6Z04Z57g3kL25O7ayk4NcvbQRmViFBGI34t4caL5NPmEfF0kZ7qw+E 1euG5Hpjw8Lyc2dwlmNsauu9hs2oUMNXfNkAmoACXSWL3Y110WRpAmyc8nGJxk9P zhW5ZY/3evZ9wuF1P7X7vcsQlJTC+vOY7Flt/ir7CXvVBWUnWear/pUXtZVUEZml +ezvq05gADTWJHAx/DUQYkQTcTg5vN2cCuN/+z6WWMvh2hKilNjfaVVyQUTfc6YZ 08DEHQKyM4g0jRPrVcu4715TD3od3rEK7LtilzkrqkKYVoQo6TDqHrw5QxkzP0IB 4jRCMlWHTeO6QKdQgfBz20kPSnDpbrHF4T/QPqac7LKuINSCJjVIKUEj2Y0T+yEn oYN+/i+1TT4RhGbi7jGnxNTpcFbmib0fX2f1HKQVPv9VryE86pVqIf0GjQ9ODQ++ El1+khU/abfNTTkkA11A =E+qq -----END PGP SIGNATURE----- --Q4hPf4tmTC5HV12L9xbA18sUHp4qtKiQN-- From nobody Thu Mar 9 13:21: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 B8E50129410 for ; Thu, 9 Mar 2017 13:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 o5dkjwJd_TUJ for ; Thu, 9 Mar 2017 13:21:47 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C868129401 for ; Thu, 9 Mar 2017 13:21:47 -0800 (PST) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1489094420; bh=OqQ0+QoGi0Tk6sne/mf/RGrYwyIyHlpgv5pJV1ZZNm8=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=CHyOf7fBBzdXIpALAnS7FaQCep+5K5YqYz3jR1fWlpjolnF2L7gMI2IWQaZ9MMC6y 2Qb0ieMFpmOkTawz7oFeNnml/LuupjLrxAjSuZA5lWRS/4X4gFydl+x2KvdD9d/KlE 84p3ycu8kreIjCRUMW+NE26x62iqPMPuSO3uRevo= To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Draft agenda Thread-Index: AQHSmRYBLynsXD/QS02NFBvzrrMeBqGNA2NA Date: Thu, 9 Mar 2017 21:20:19 +0000 Message-ID: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05EA_01D298E0.47469530" MIME-Version: 1.0 Archived-At: Cc: Paul Wouters Subject: Re: [Trans] Draft agenda 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, 09 Mar 2017 21:21:48 -0000 ------=_NextPart_000_05EA_01D298E0.47469530 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I don't think there's weak interest in redaction. I think most people are stumped on how to move forward. Given the discussions on the Google CT policy list and CAB Form (and the current Symantec practice of redacting SAN information), it's a huge topic. The question is how do we progress towards consensus when there are such polar view points. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Thursday, March 9, 2017 1:45 PM To: trans@ietf.org Cc: Paul Wouters Subject: [Trans] Draft agenda Hi, all: This is a first poke at an agenda, with some open questions (for example, has there been any progress on a log monitoring API?). Please flag any problems, raise any questions, or suggest any additions. Thanks, Melinda ======== trans session, ietf 98 13:00-14:30 Tuesday March 28, 2017 @ Room Studio 4 Agenda ------ administrivia (~5 minutes) blue sheets, minute taker, jabber scribe, agenda-bashing Note Well status update . charter unchanged . issue tracker (17 open tickets) . 6962-bis: WGLC completed - significant issue raised by Mozilla, nearing resolution . Redaction: Weak interest but we need a way forward . threat-analysis: stuck - additional author? . ct-gossip: through wglc . ct-dnssec: no update . ct-binaries: new drafts, apparently there's work being done on this problem outside the IETF 6962bis follow-up, obtaining proofs (Eran/Richard) Name redaction/privacy . use of VRFs for name redaction (Eran) . a privacy-preserving mechanism for obtaining and and reporting log misbehavior (Saba) binaries logging . draft-zhang-trans-ct-binary-codes-04 (Frank) . current work on this problem outside of the IETF (DKG) new work . Log Monitoring API Any other business? ------=_NextPart_000_05EA_01D298E0.47469530 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA5MjEyMDE4WjAj BgkqhkiG9w0BCQQxFgQUyHmMvTPBgLovavUsKrQWnehPANwwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAF6hpO9ggHeC3/eSqEnz0GtSh8r9FAJCkL+ICaM7 2N4g+O4gn51DnThfLUuDjCkmfkHmJsbT0UV/1+tHUsBXdUP9wJ0YDwBUmje36xLezLIYSXlXHkpr Cn21OsCxmxyvptzHQDEe+/zdLrKvBqzgc6MT0BYi/LlzlU3W7n52DTMOM2pD0wN+NPC06yInkM10 7FV1ydzERoa0waaIJFIHB7dsVO6oh2QXPudLVHkX1+SiMmneoVZO2LzlJmMeknpms++a+dSde8Av oUjdQsqkdiL3c8iROonoD+wsogfZSETF4RWKkb9aZo8Vvsysu9utKJie8w2vmdW9MfXgAmbIQ18A AAAAAAA= ------=_NextPart_000_05EA_01D298E0.47469530-- From nobody Thu Mar 9 13:33:12 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 AF49D1294BD for ; Thu, 9 Mar 2017 13:33:11 -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, 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 4s42uxnZsVkx for ; Thu, 9 Mar 2017 13:33:10 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 6DE4312948D for ; Thu, 9 Mar 2017 13:33:10 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id g2so13429121pge.3 for ; Thu, 09 Mar 2017 13:33:10 -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=eT/KD/8zUQFweddQr5SoBtlGRY7tF9T3pv2eNNuWHek=; b=K4SYuatoRt2o918sTNCm0zF/OtZ3nw9i76eYqLzaqaxsfwyVni7tO1r/HiLQv7hJgv IbLyJLz5/ADAjYSr4OF10OypfgCAZO9uMgS/agY1chz0RKYUYAUmPSIiiLWQ4GRUYsLB F/iDVBAgN9dYdi5pgoOXnPTwXOjFypVYpsE03n429ENWi7ogc2IYDV01pSDhXyG/AIzu 8P123LYolEVpj6rGR/XSLx4isEbwWIl3vtCc1Nd0VK2JPJXNd8h5b7DY/PcihE4SiHC1 rVyT4Xwsn9QE4WHPZM9xB2z2M8ZSpHrlp/9MbTVvOByDUA2XcbnGCWFDMEeaO10WLve2 NNcA== 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=eT/KD/8zUQFweddQr5SoBtlGRY7tF9T3pv2eNNuWHek=; b=X9W4/8S+OoquuBz79HFLznYwEn/BYl5sds4HZ/giseMGM/Q2Tfhncseq9OWQrdXYmm pYgC1wYEYBFZKiVyorgRpJ02sGvxeIgiCW4pkv7s2cA9baZ4ZLDq9v8FMf2BluSpp44R am67aVe5JU6nkDUcJcELMxDohquFEsVMWH97I1/w5087icZHzzK7LScH8utZ/KNSCOEM Y0wOkdJ0oMX3C5nxg5yJX7LaJI9EMMde8m9Gr3X9+qB8wtmxDohvqz1w5qgf8Uj/IzIK zan0qgEOGeh66gNEInF42llBXKMwQZregl81Z9qdE8bRh1132+h0Y2mxRDFjU5SkGBwi gzCQ== X-Gm-Message-State: AMke39mzp0x/gHcL77wpaP+TNznOXpKeOuB38nv5KrBQ8EmHCMrm5xZ3Ovf31b/9Qj1msQ== X-Received: by 10.84.171.195 with SMTP id l61mr19786054plb.84.1489095189577; Thu, 09 Mar 2017 13:33:09 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([8.18.217.206]) by smtp.gmail.com with ESMTPSA id o26sm14371490pgd.25.2017.03.09.13.33.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 13:33:08 -0800 (PST) To: Jeremy Rowley , "trans@ietf.org" References: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> From: Melinda Shore Message-ID: <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> Date: Thu, 9 Mar 2017 13:33:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NunJXQhTf21LgWQxDWLTHbBJrxvIJi0nO" Archived-At: Cc: Paul Wouters Subject: Re: [Trans] Draft agenda 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, 09 Mar 2017 21:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NunJXQhTf21LgWQxDWLTHbBJrxvIJi0nO Content-Type: multipart/mixed; boundary="wcvQDA9wr2L8TBmuG2rnxttTHr6FXNrCf"; protected-headers="v1" From: Melinda Shore To: Jeremy Rowley , "trans@ietf.org" Cc: Paul Wouters Message-ID: <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> Subject: Re: [Trans] Draft agenda References: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> In-Reply-To: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> --wcvQDA9wr2L8TBmuG2rnxttTHr6FXNrCf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/9/17 1:20 PM, Jeremy Rowley wrote: > I don't think there's weak interest in redaction. I think most people a= re=20 > stumped on how to move forward. Given the discussions on the Google CT = policy=20 > list and CAB Form (and the current Symantec practice of redacting SAN=20 > information), it's a huge topic. The question is how do we progress tow= ards=20 > consensus when there are such polar view points. Fair enough. One problem has been that the proposals have been fairly unstable, in the sense that they change/develop fairly rapidly. One thing that would be helpful would be a summary of each proposal, with technical tradeoffs, that might be useful as a basis for discussion. Also, if someone else wants time on the agenda on this topic they should let us know. Melinda --wcvQDA9wr2L8TBmuG2rnxttTHr6FXNrCf-- --NunJXQhTf21LgWQxDWLTHbBJrxvIJi0nO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYwcoTAAoJELiGRpM6HoEuO08QAI7oGB7JctRZYMcI9j1DbAb2 JrT1QCvMeZQ5qirGOJnMf4Phx8Y7fIqaZfpx4HomdLLcCHcNcF0m9FP1/pYcZFFd pq/qu1V3F5EG308j9z6YL5bdLLPpWpoGT+EQR5F/3YfySwn+tAn2vRB3s9eMLfjj AFptrl3sRPpTWNL1Ir7rMcW6LReQMZBXqVLtBrtKK9cewH2ZLMDhJyYgaZV3L5b/ LNw+cIgEGbtpFErnMo3js1iATJnSDfDCnpBPfflFvaAnbPG5M6nNZGEzYjskWN0M F8tcOwAKEVCMsXK0tdOC/UfEi1dhsogeattxNVjiG0T9upPdLeBObG7dt20IWz5I vr72RqnmEJ9b/lsYeXxaxdki8PvgRGwit1FCubQSA2rjNhZaWy2n6Ly8/jXWKMV2 Bka+ekwojZJlG0wNUXTb99RIHc0AlADQ/ZrlOHGG9TEpW+dDVS5csyr075+IV00b y/FLfuABsCv2kQGVQZSeZO+hko5WcZ3BGG2pDYzBXy6twYTj+O3dSBYi/K2GUuNb JPJ42onzq/FTG/QNMFtWnKlCK5W0uI31KQyOy1+lwgY0L1CAHMTE+CKO1Tq9DsWJ EMUHdL6GRr/eYypu9Dog6Wnl/8X8Dl6L3LzcANox37dtBI7KexxFRa0z5dXKL5+u FN7oHe/5BRREkUCjfhPz =ZR6x -----END PGP SIGNATURE----- --NunJXQhTf21LgWQxDWLTHbBJrxvIJi0nO-- From nobody Thu Mar 9 13:45:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DECB1289C4 for ; Thu, 9 Mar 2017 13:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 KUBjFpqRcuVF for ; Thu, 9 Mar 2017 13:45:45 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DB21294C8 for ; Thu, 9 Mar 2017 13:45:41 -0800 (PST) From: Jeremy Rowley DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1489095941; bh=ef9hcz/ro/ZmQkhW4vVTV6Jrh4IPBnA4zEx+RhvQamY=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=cMIOQMGsUc2p8GVd4fDuNbCh2xXZ+BQw96O9U9Uof7e/0OO4kLCcqrK3ZXhisa/ff pqvi2cV0hbhk83JATstRLIp/rElHDoMmlTOvOHDCKPYhnrgGwC77QDBNFfsaLEPRf1 xDNtw39V1aLz+WLuybsjljHxzCyRxeM3qVvODsZ4= To: Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Draft agenda Thread-Index: AQHSmRYBLynsXD/QS02NFBvzrrMeBqGNA2NAgAB5RAD//42E0A== Date: Thu, 9 Mar 2017 21:45:39 +0000 Message-ID: References: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> In-Reply-To: <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_062C_01D298E3.D141E340" MIME-Version: 1.0 Archived-At: Cc: Paul Wouters Subject: Re: [Trans] Draft agenda 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, 09 Mar 2017 21:45:46 -0000 ------=_NextPart_000_062C_01D298E3.D141E340 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I could provide a summary of each proposal, but I'm probably not the best person to discuss the technical pros and cos of each proposal. I'd like time to discuss it on the agenda. -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com] Sent: Thursday, March 9, 2017 2:33 PM To: Jeremy Rowley ; trans@ietf.org Cc: Paul Wouters Subject: Re: [Trans] Draft agenda On 3/9/17 1:20 PM, Jeremy Rowley wrote: > I don't think there's weak interest in redaction. I think most people > are stumped on how to move forward. Given the discussions on the > Google CT policy list and CAB Form (and the current Symantec practice > of redacting SAN information), it's a huge topic. The question is how > do we progress towards consensus when there are such polar view points. Fair enough. One problem has been that the proposals have been fairly unstable, in the sense that they change/develop fairly rapidly. One thing that would be helpful would be a summary of each proposal, with technical tradeoffs, that might be useful as a basis for discussion. Also, if someone else wants time on the agenda on this topic they should let us know. Melinda ------=_NextPart_000_062C_01D298E3.D141E340 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA5MjE0NTM4WjAj BgkqhkiG9w0BCQQxFgQUlxp6HlzolT0IeXcU9QQdpheF74MwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBANmZp3JejKqfAG36t1BIpriglYJZYdz4Csetj//I hhylIY4jrDUhr1yygr5oxxqnZap7LXzSFVRxbL7Ykxxe06ArxoWLGxmOHoy5/vP00t/weOhmfUeQ Ef/J3ZbVqoVePX6+ihMwPSszzoteIZMQ+AYqJ1x5PQLg6mUetUI7nAeojKEZNjVGMslcKZQI+U3t v3YTq6Wy8qp/YSl3RHsClnVKOAT0VX1WrtlPAXtVygXJXADGkAreLZYCs6mqT4mpnmRwBxH6BDDi yDdjxtMdYrCnzStyrrW2YIxty4299aJSLmKK4eLi+G38H6Y3zChLaBtrOjQY8ItDTdFlGkpovasA AAAAAAA= ------=_NextPart_000_062C_01D298E3.D141E340-- From melinda.shore@gmail.com Thu Mar 9 13:50: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 C60FB12946C for ; Thu, 9 Mar 2017 13:50:22 -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 xyes4B8kal4s for ; Thu, 9 Mar 2017 13:50:21 -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 D48AB129457 for ; Thu, 9 Mar 2017 13:50:21 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id b129so30937272pgc.2 for ; Thu, 09 Mar 2017 13:50:21 -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=u7A/SjlmwosU/WUT8x9CYTacsLdLLPIIFfauLggi/1c=; b=Rvr80ZHnsJU6OWVtHPEUyqPyY5xoIrUApBc983u9JsCYjywDSXL24DEEnRVMF4TuZD X2QbZ9L6PcAS7VdHv9l85ZUDWvmnOPN6dPopYFiBjXu1EC2z9XAgmz53uHmYU1vI2i2e XEjWn5EPbMGhO3ZRuMHbS/6jbnUI6VvlKAZDbNuCz9q1YUhmlLOV11Ut2bPpm8Elunic mxnSp6ZmFE8GiIsFLCp7kt0zFo/lb63iIJA1H9iutgC08gLlwtefe14CFx7xYRBEWdJG 2ew2Bb4MVxboBWhRTtH6q+ntyfDqwF+87s/q6CwRrM/yLcwk8zo6SAy5PQAfMPXoGwfe w4lw== 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=u7A/SjlmwosU/WUT8x9CYTacsLdLLPIIFfauLggi/1c=; b=oh5xNlzKhDb95GB0wtC4mG7fUiqm+UdBLe1d44bIMZfPMyCNWOISHie2QUdQbOrZPz nvoXZwAblpaTpjtw+D0UY4E0Z7oTOWVMBjQmA7GKCUg+7Bi+rOvNbDylh6cPRfLTkotc VAcsROdY55KTtZREN6vEtur0zy1cvhQLijjZDeuVKfR5iA1tUY5Ro1N5ib+uy6PsM6fr 3woxxmn3KXICyQluzVeOYjaZdVNZG/k+sBAxbFaHj+OZuBhsHUKb7n5y0gDLAwusOwKe kZYe7t9BRaR2VpMRtDswKML+PHGVxJBsgQucYEWdTNWga41OOL4e9fwF99Wv43I0Joqm hptg== X-Gm-Message-State: AMke39nceMi7ooHWvzJb9XUuh2wV5Yr4Uswm8O5ZIGk9jSw2mWKvDiIQgPTO0rWI+uta/Q== X-Received: by 10.99.246.83 with SMTP id u19mr16144657pgj.205.1489096221030; Thu, 09 Mar 2017 13:50:21 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([8.18.217.206]) by smtp.gmail.com with ESMTPSA id m20sm14350390pgd.67.2017.03.09.13.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 13:50:20 -0800 (PST) To: Jeremy Rowley , "trans@ietf.org" References: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> From: Melinda Shore Message-ID: <12574b40-19fe-75a9-64c0-68aa34949367@gmail.com> Date: Thu, 9 Mar 2017 13:50:19 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1H3qxctBOuSqdXJIWHuwBTrn6SgauAwsw" Cc: Paul Wouters Subject: Re: [Trans] Draft agenda 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, 09 Mar 2017 21:50:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1H3qxctBOuSqdXJIWHuwBTrn6SgauAwsw Content-Type: multipart/mixed; boundary="M69AGhQUWmClFUkmAU3dmdnmCJ5DxNu4j"; protected-headers="v1" From: Melinda Shore To: Jeremy Rowley , "trans@ietf.org" Cc: Paul Wouters Message-ID: <12574b40-19fe-75a9-64c0-68aa34949367@gmail.com> Subject: Re: [Trans] Draft agenda References: <7a50186d80034c72a81aa59bac45586a@EX2.corp.digicert.com> <9b136218-7728-e61e-bfaf-0d913eb1a503@gmail.com> In-Reply-To: --M69AGhQUWmClFUkmAU3dmdnmCJ5DxNu4j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/9/17 1:45 PM, Jeremy Rowley wrote: > I could provide a summary of each proposal, but I'm probably not the be= st=20 > person to discuss the technical pros and cos of each proposal. I'd like= time=20 > to discuss it on the agenda. Thanks - we'll add you to the redaction discussion slot. Melinda --M69AGhQUWmClFUkmAU3dmdnmCJ5DxNu4j-- --1H3qxctBOuSqdXJIWHuwBTrn6SgauAwsw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYwc4bAAoJELiGRpM6HoEuTK4P+wZS04i+dCIclvtbY8g1bn08 x35kPFx6fglgnkkPOwGTCS/ok70YLBnqi/v6iKfDVI4DWziJ0AiMsTbP400Rx8QT wCOhNlggCr64eQLIi0iJOmCAQhkmLVBgb7r6u/AsNEu1z9LkndBH4CxzgBBpuiTb yATxhzLBobnxkiAZqA+6M4Pvd3T/2UUI+6m9o/kyezRg/PkJt9IVpkwM4S+qZHjA 4/xL2PCEpKp2KPM66TRTPXHMOfAj5DAv00K6E25mdCbk3HlijaiqT6n3EHBLgO4A aQ+4znahaJ6K28bcyRXRbLj2tTwmy8J2BTfmbAp+bx1XMwLWe2vlkIuWJoXMULoP OAHP8sEpz2l59G9CiIvxhrcV+yoB+pFbT9ww34tAQfqYSaVfRPnnxMUbx38pBcGt rAeDXlHTbxz2QlDmH+3p/NPDWmBvackU4JxfsUZgb5q9tLwz1A1YyDOZTVjXxx0C x61tjsLYSi1ZWdXIYUIO/ktZkPRNv+KIVMNae4gsDMvsqN+sIpUNWwP45IqNAfU6 VePuDJSZyhR6UOXSUrwSZtZcq9hhG+5zuDBGkz6J4cXwx53CcU8e79oNfQXqFjg5 xtwTX2s4rDyyLNMbmcOGWxxQbjpVqV6u21zBUeuqaeN/0bqC2XQfYccjJmdojt8o qEvdP54rKCwJ10KkvlI5 =JVlC -----END PGP SIGNATURE----- --1H3qxctBOuSqdXJIWHuwBTrn6SgauAwsw-- From nobody Thu Mar 9 14:07: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 D7559129588; Thu, 9 Mar 2017 14:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eheyJgeQA7P; Thu, 9 Mar 2017 14:07:04 -0800 (PST) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18131129490; Thu, 9 Mar 2017 14:07:04 -0800 (PST) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v29M73Tv063696; Thu, 9 Mar 2017 14:07:03 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v29M73oT056087; Thu, 9 Mar 2017 14:07:03 -0800 (PST) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org Date: Thu, 09 Mar 2017 14:07:03 -0800 Message-ID: <87a88uksu0.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Trans] Talk announcement: Internet-Level Consensus is Practical X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Mazieres expires 2017-06-07 PDT List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:07:05 -0000 I'll be giving the following 30-minute talk during the saag session at the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on Internet-level consensus that evening. Internet-Level Consensus is Practical David Mazi=C3=A8res Security Area Open Meeting Thursday March 30, 2017 15:20-17:20 Zurich D room =09=09=09=09=20=20=20 Consensus is the problem of agreeing on a valid input value among members of a distributed system. Internet-level consensus extends the concept to global agreement, despite the fact that the Internet has no meaningful notion of membership. This talk will report on the Stellar consensus protocol (SCP), an existence proof that secure consensus does not require well-defined membership. SCP's key idea is for individual participants to decide for themselves which other participants they cannot afford to diverge from. SCP guarantees agreement so long as there is transitive overlap in these dependencies. SCP is in production use by the Stellar payment network, but has broader potential applications ranging from secure package distribution to key management in end-to-end email encryption. From nobody Mon Mar 13 06:53:10 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 888EF129422 for ; Mon, 13 Mar 2017 06:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 181EnAka8veO for ; Mon, 13 Mar 2017 06:53:08 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 7451C1293D9 for ; Mon, 13 Mar 2017 06:53:08 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id v76so59109683ywg.0 for ; Mon, 13 Mar 2017 06:53:08 -0700 (PDT) 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=HIslQuIEBM7Amqe38UrKn7wueVgKBYF+svTmBBNTjgY=; b=M7+EMUzuv0UQ6oZT56VKYnBEQyjy5ONn/ydSE+3e5YZE4xS0bBXHl47LGF473Iyp/1 6k0deD/fPa4Idh9yGNcD44BHCaIXzDKeBuoLywk2qe1E4g5b/xVDRKwGe32yZds70VUa nS56wscVqUUKz5cijHwtdqHUMqDvlfnPbOXO8vrjj+Pq+aig0LeAw5BCIBTf89FWc/Nr FI8v1Yr1HcRzIHvfUetQ1qSeM+5XOzTGLNZT6xjXqE9BOSRT/TTQdLfMmvrRzPO47eB9 +2GCpKdxhBDMiF455Pj+QmhuPcbU8tt/d17XOm5EbJPSa4cnjrydQre+fy6ecjdLnxdy J0Dw== 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=HIslQuIEBM7Amqe38UrKn7wueVgKBYF+svTmBBNTjgY=; b=RTJ/UdW5LoveRYq50MUjdTwEVDlEixn9KHA3Tt8gJdlfC7TO5NPwQRqyH9ersbQErg ORagtoCcRndbMkYk70CEnC6I5yeGnp71wRK6V3IyWfa67NmiNPvH3a7aDyBLxVO/xg5I RPqjv5WdBsBLXNS2p2Fo03pb0fS8vgDAMWkyjqRsVFzSmon2oNAncxdtYx9yPQBZez4d jGBeGsi6LkBcuUGYIMxeT84DLmHsruyVBmJQ8dA8thg280XbNizdUkIf9HCW9c+6K7Y7 uWEkfpePz5uz9mZIkxewjLejJCiX9/rLXcZ/BTh5UDTWr8etADkRkDWaQFduuuwO3qF8 h2Tw== X-Gm-Message-State: AMke39kfTvN2DVyG4bAouYTYuAfspP28dYuhIx3r6MaNYHVpUGPkKrbw3G1M1lEFhaHAIYX1OByRM9cgtdazF2GO X-Received: by 10.129.107.196 with SMTP id g187mr17111683ywc.172.1489413187648; Mon, 13 Mar 2017 06:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.17.67 with HTTP; Mon, 13 Mar 2017 06:53:06 -0700 (PDT) In-Reply-To: <87r321ibrj.fsf@nordberg.se> References: <87r321ibrj.fsf@nordberg.se> From: Al Cutter Date: Mon, 13 Mar 2017 13:53:06 +0000 Message-ID: To: Linus Nordberg Content-Type: multipart/alternative; boundary=001a1147398ef9a650054a9d07e3 Archived-At: Cc: Ryan Sleevi , Richard Barnes , Zakir Durumeric , Trans , Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie 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, 13 Mar 2017 13:53:09 -0000 --001a1147398ef9a650054a9d07e3 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 13, 2017 at 12:47 PM, Linus Nordberg wrote: > Al Cutter wrote > Fri, 3 Mar 2017 10:19:19 +0000: > > > I think none of this dream world is in conflict with the current state of > > -bis, other than possibly that requirement to limit STH issuance to one > per > > hour. I understand why it got put in, but I do wonder if it really > belongs > > in the Gossip doc rather than -bis where it's potentially discouraging > This > > Sort of Thing. > > 6962bis doesn't say one hour. It says a log must stipulate its maximum > number of STHs per MMD in its metadata. > Yep, my mistake, sorry for the noise. > Since it's a requirement on logs, it should be in a document > standardising logs. > Standardising the knob makes sense, I just didn't like the idea of standardising the values I can dial in here (and I now know they aren't, thanks!) --001a1147398ef9a650054a9d07e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 13, 2017 at 12:47 PM, Linus Nordberg <= linus@sunet.se><= /span> wrote:
Al Cutter <al@google.com> wrote
Fri, 3 Mar 2017 10:19:19 +0000:

> I think none of this dream world is in conflict with the current state= of
> -bis, other than possibly that requirement to limit STH issuance to on= e per
> hour. I understand why it got put in, but I do wonder if it really bel= ongs
> in the Gossip doc rather than -bis where it's potentially discoura= ging This
> Sort of Thing.

6962bis doesn't say one hour. It says a log must stipulate its m= aximum
number of STHs per MMD in its metadata.

Yep, my mistake, sorry for the noise.


Since it's a requirement on logs, it should be in a document
standardising logs.

Standardising the k= nob makes sense, I just didn't like the idea of standardising the value= s I can dial in here (and I now know they aren't, thanks!)
= =C2=A0

--001a1147398ef9a650054a9d07e3-- From linus@sunet.se Mon Mar 13 05:47: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 148201295C6 for ; Mon, 13 Mar 2017 05:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcYDzMuQyPYn for ; Mon, 13 Mar 2017 05:47:55 -0700 (PDT) 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 2C5FF1295CC for ; Mon, 13 Mar 2017 05:47:54 -0700 (PDT) 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 v2DCliKS020827 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Mar 2017 13:47:45 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2DClelN014774 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Mar 2017 12:47:43 GMT From: Linus Nordberg To: Al Cutter Organization: Sunet References: Date: Mon, 13 Mar 2017 13:47:44 +0100 In-Reply-To: (Al Cutter's message of "Fri, 3 Mar 2017 10:19:19 +0000") Message-ID: <87r321ibrj.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; 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: 0aSToLJvp - 2f7638bc948f - 20170313 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: X-Mailman-Approved-At: Mon, 13 Mar 2017 09:04:55 -0700 Cc: Ryan Sleevi , Richard Barnes , Zakir Durumeric , trans@ietf.org, Nick Sullivan Subject: Re: [Trans] Experiment report: The MMD is a lie 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, 13 Mar 2017 12:49:33 -0000 Al Cutter wrote Fri, 3 Mar 2017 10:19:19 +0000: > I think none of this dream world is in conflict with the current state of > -bis, other than possibly that requirement to limit STH issuance to one per > hour. I understand why it got put in, but I do wonder if it really belongs > in the Gossip doc rather than -bis where it's potentially discouraging This > Sort of Thing. 6962bis doesn't say one hour. It says a log must stipulate its maximum number of STHs per MMD in its metadata. Since it's a requirement on logs, it should be in a document standardising logs. From nobody Wed Mar 15 12:58: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 BCBFB1316A7 for ; Wed, 15 Mar 2017 12:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eymk0RCy2DC8 for ; Wed, 15 Mar 2017 12:58:43 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 C77A1131804 for ; Wed, 15 Mar 2017 12:58:43 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id BB9B9A8A1121 for ; Wed, 15 Mar 2017 19:58:39 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 7DA5A1FE07E5; Wed, 15 Mar 2017 20:58:39 +0100 (CET) Date: Wed, 15 Mar 2017 20:58:39 +0100 From: Kurt Roeckx To: trans@ietf.org Message-ID: <20170315195838.iypfur5rg4bgysq6@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:58:46 -0000 The -04 draft currently has URLs like this in it: https:///.well-known/ct-gossip/v1/sct-feedback But the it's indicating that it's about rfc6962-bis, which changed things to /v2 URLs. Is the v1 about the gossip protocol version only, or are the URLs supposed to be v2? Kurt From nobody Wed Mar 15 13:29: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 C839A13181F for ; Wed, 15 Mar 2017 13:29:35 -0700 (PDT) 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 DhQ5Of2Gra0a for ; Wed, 15 Mar 2017 13:29:34 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 6C9001317F9 for ; Wed, 15 Mar 2017 13:29:34 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id n21so22352882qta.1 for ; Wed, 15 Mar 2017 13:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/4YKntAzZ1j3ZXfl70MVlMbIft2Fn0TslAx3S47dJBs=; b=kmNej+riGX6zB1XWSKpP3/n9p+ymZ+yqQBEUAcXiCWmdjjLMg+12x+sCY8QUA8JhGG m8JMqrZepLEEH8lRpF0U6Jq5yE0UAPSNqQ7mlVQ9dK7iPIFK5cTyAHvhH7jSI4SM7xXq GIBTPobQSDzxEG+8mk1BUlPr11jziyUoTGhEnB1gfaA/m1LcrmQWmXndzr9fDJw26uuJ TqeKqvlGOn6OmkPfm/j/B7dxrM4arNBwly4HqIvllKIkvLpCvl9QEZYCrJjhLo5/sKip 8DkAPx7E7SoiFVelIFGLx1q4s+Or1AbAOpSnwgE8wJ3FlznETMbfAwZ6XGjgyN6bAWDo DqqQ== 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=/4YKntAzZ1j3ZXfl70MVlMbIft2Fn0TslAx3S47dJBs=; b=XV3VD5SM8BlXrEIXIU/ELNTNVwLfsE2MhW/YUIGPu8Hql5q+W7JBr4yfmKXdmbqVbN kfNVdG0WoyF9m5eWymua4RrjhL8pDKvygOJtVb99hD3n6Ljb4NjKVUoH6ErAT+WHlazI SnJfcsUxtpm+HSOZD3J/CkifYFUbE19LbcDqTBgwHc/MtrBUgcQxKIpRopv4TbkqfXgq VVq8aPBICmiOT74MnwAhXUqDdPHHEng1p/iyr0tJiTmnZ3c0kZYJSqPTsk0cQchiq+bl TzgPw3L3s8Fjp/VpvKSPSU4t5jC34hDcgzbl1j6YtO/Tv+/TeOgufebOMVZfp9+7fG7b dVCA== X-Gm-Message-State: AFeK/H1Y2oqfkYTEyx85X7V+MwuEkTkz5IxvrydKUBqA8iTvyy+1Wrkh1tLd991hyrcdQUyVxWEx72p1CWfaaw== X-Received: by 10.237.41.100 with SMTP id s91mr5199324qtd.143.1489609773519; Wed, 15 Mar 2017 13:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 15 Mar 2017 13:29:33 -0700 (PDT) From: Martin Thomson Date: Thu, 16 Mar 2017 07:29:33 +1100 Message-ID: To: trans@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:29:36 -0000 I am not following this work, but this and the original RFC 6962 both run afoul of the (good) guidance in RFC 7320. Has the working group solicited feedback from the HTTP community on the use of HTTP in this protocol? From nobody Wed Mar 15 13:44:57 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 700D31315A7 for ; Wed, 15 Mar 2017 13:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RCw6jxLhdkE for ; Wed, 15 Mar 2017 13:44:52 -0700 (PDT) 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 93F7B131836 for ; Wed, 15 Mar 2017 13:44:50 -0700 (PDT) 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 v2FKikO6025408 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Mar 2017 21:44:46 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2FKie5O008667 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Mar 2017 20:44:45 GMT From: Linus Nordberg To: Kurt Roeckx Cc: trans@ietf.org Organization: Sunet References: <20170315195838.iypfur5rg4bgysq6@roeckx.be> Date: Wed, 15 Mar 2017 21:44:46 +0100 In-Reply-To: <20170315195838.iypfur5rg4bgysq6@roeckx.be> (Kurt Roeckx's message of "Wed, 15 Mar 2017 20:58:39 +0100") Message-ID: <87varauv5t.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; 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: 0aSUkIKWu - ac6e07162348 - 20170315 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:44:55 -0000 Kurt Roeckx wrote Wed, 15 Mar 2017 20:58:39 +0100: > The -04 draft currently has URLs like this in it: > https:///.well-known/ct-gossip/v1/sct-feedback > > But the it's indicating that it's about rfc6962-bis, which changed > things to /v2 URLs. Is the v1 about the gossip protocol > version only, or are the URLs supposed to be v2? The version number in the gossip well-known URL's indicates the version of the gossip protocol. The gossip protocol should work for both CT v1 and CT v2. If it doesn't, we should fix that. If that's not possible, let's define a gossip protocol version two. From nobody Wed Mar 15 13:46:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62E2131837 for ; Wed, 15 Mar 2017 13:46:51 -0700 (PDT) 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 dIwnG69v0job for ; Wed, 15 Mar 2017 13:46:50 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 478CE131828 for ; Wed, 15 Mar 2017 13:46:50 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id b129so14284642pgc.2 for ; Wed, 15 Mar 2017 13:46:50 -0700 (PDT) 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=fF541DCOnSaQliBB2UA7gLM2C/Siu2fNMqA54QhZyLE=; b=ba+BAPGrIH8UPaP9sTAmJE7CtYE9y3RohJnVbW3M5GfdMHIBV2kHskCNmQGnEXQepz MVRWVPT+myFO6ATX8s6y+nxXia8ZI/hI5Is+NcouEJaa99omB9X+iexPQ0W3I4Xd+kNR KnFZgPE+zbbXXrtxTu4Zs3ek8rHJYz4ugwmzX7RjKzxhWzlnBTsn4B/1TPsxsMC2G1C7 KHEzanquMrSerIHdK+eyE7MLRp6cTroPQ6w8KAjWGOV/MyvR7c2GWp5vWt1aHUeJhhOR G2YfAA5AzHwbAffjXCNoAVmBZ+NUcnx+jXldbiJXuvo+PhaaehjEmKYmqY22nDlb4dKB d04g== 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=fF541DCOnSaQliBB2UA7gLM2C/Siu2fNMqA54QhZyLE=; b=iVfWq8z0Ic6hK+o7tkW+m3FAlVdjEM3b4JOxyx+4huTJp9eLAr6mlMzpX/WCvEn/s9 P6PnNozPrFWt7lP3Da9I2HwYB09tJz11/8zrhYpJyNg32q5Y7OjmUWObhhcCW2wdgN3P pCP+lBqVg5paQOYW79HQCNV++Fts+ZP3FPE7ifWS7o1dtJ3qj57SFOlz2B8e/CkzaE62 Y9A6DVTRjbTw3NAOt8UUQMJo3P9Sk9wT+k1ymfX5BBd646BkJYkkP16cWPn2WnX8q+Xj Z2jqT3DuW9Es0bciCmwBkLUnueiGllBqvtQXi7I7X6gGNneOylCJJW5/hSyiMQArhFXX gqog== X-Gm-Message-State: AFeK/H2IPe8tLjRI0sJwcPOOfwl8KfPVrtzVooQh2P4YFC2f3nQ876XyU0cv65Z+Ae+VAQ== X-Received: by 10.84.169.227 with SMTP id h90mr7123268plb.155.1489610809168; Wed, 15 Mar 2017 13:46:49 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-74-184-radius.dynamic.acsalaska.net. [216.67.74.184]) by smtp.gmail.com with ESMTPSA id v186sm5993449pgv.44.2017.03.15.13.46.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 13:46:48 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> Date: Wed, 15 Mar 2017 12:46:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5NGPkHP09WeQg1HsepsBWOFiItUKJuOPH" Archived-At: Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:46:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5NGPkHP09WeQg1HsepsBWOFiItUKJuOPH Content-Type: multipart/mixed; boundary="rMHJ9DujxTMHGeA2pqpqkNkmje7I57l9g"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 References: In-Reply-To: --rMHJ9DujxTMHGeA2pqpqkNkmje7I57l9g Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/15/17 12:29 PM, Martin Thomson wrote: > I am not following this work, but this and the original RFC 6962 both > run afoul of the (good) guidance in RFC 7320. >=20 > Has the working group solicited feedback from the HTTP community on > the use of HTTP in this protocol? No, we haven't. For what it's worth, 6962 reflects implementation and deployment prior to CT having been brought to the IETF for standardization, so any concerns regarding URL syntax or HTTP transport in the work being done by this working group are necessarily limited to the -bis and related documents. To be honest, I'm personally not convinced of the applicability of 7320 in this case but if there's a specific problem it does need to be discussed. Melinda --rMHJ9DujxTMHGeA2pqpqkNkmje7I57l9g-- --5NGPkHP09WeQg1HsepsBWOFiItUKJuOPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYyag2AAoJELiGRpM6HoEu9XUP+wax9xWc47yHc6vq/YLoyTnG sDlpvvMIp35oK3CiHD9hAfMzjSG3uWJALrlAMJsvnDsjyz+d77C0WVcnLTaPhieD 24ZJWWnsIqYN9A7/QmpMNPlH+KHct4oRvd06Fwgv5LoOcHAmlcaHjbxb9OMw5IAQ /ePoalkOhQYDmudmbsOOGDzBR3Ny87r4CzI1Y+g5wo1Otm56hBZf3AlT1BaDAygn OcJqzGc/Br3XldjgwB7QxhXzlpDKBtNS3Z5xGu89MT1vFxZPuS1/2U6JncBAVWYZ febFIpuMa5XSXrFativoTSF3v5+q778Fc99wXjaaI0glBK6zE+2ID1gngHL0WgIr C9dyYYU/Fms9axVr03S+NslGIz0ah5npPKp0OaGtxVxCRMLm+5zEXF4JQo+gEsM0 JbrEukJI4dyW5wmPRfcZ/K5zzmNvfJCJw2RvMctliuIrSBzofdNP3CLOJjq/1xnN ukJMeyZzopN0ebtzdglmNrfOf4QclNJUXOOktiqYoNIEGnh7ousCHk23gIL753hj dTW2Qs0RoG4F72+/6DBmGmRZS3zM7tSyKd8p00F19uASoMXeDrlIjMI6SyP7WfPa 5OUiOl/ouxHzuTCuA7KbETEYqBlC/d0qXn6Nxap1KBjetY2NPCWwF//ucBFr44cf p39IeqYrn0UFgp1MFkJJ =PHPa -----END PGP SIGNATURE----- --5NGPkHP09WeQg1HsepsBWOFiItUKJuOPH-- From nobody Wed Mar 15 14:48: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 3E127129C03 for ; Wed, 15 Mar 2017 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYy8gnUKXx_e for ; Wed, 15 Mar 2017 14:48:36 -0700 (PDT) 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 70C2F129C26 for ; Wed, 15 Mar 2017 14:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1489614512; bh=WNr9JhG1q25/cuQPjIPHJxv9JFWDzBRWn40Xk8iKg9Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=iiEmgoTPzisAnfbFdIP8McP6lu2AWqUnX8fkZsF4+gHLhEtaESHnUSldXdK3uRlb2 09aXMSm6Vwj1+j/5sReanUP6u+UXjN2GGZYiSTcf0mXU705rfRxLQakKveR6syV7et W9Zg0AfSVsWRoZAG6L6gLOPoretagwMqIU7983fynjdKqPHQg8x6htENChj6mHB9ZW nm8wJpnnwqMtcmHzoti6fttqtWl8d/OYvfC/eGlnUTRCqypn+A2IsrUIlba2uhcSDY 6od1MKMkRsgaVQmuAOlnWl2i7s8yiJ2aYn0If7sG4sQDO1IJ3q+/4FkxPfrNItn4X4 n6rDTwzDqYwSQ== Date: Wed, 15 Mar 2017 14:48:32 -0700 From: Andrew Ayer To: Linus Nordberg Cc: Kurt Roeckx , trans@ietf.org Message-Id: <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> In-Reply-To: <87varauv5t.fsf@nordberg.se> References: <20170315195838.iypfur5rg4bgysq6@roeckx.be> <87varauv5t.fsf@nordberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:48:37 -0000 On Wed, 15 Mar 2017 21:44:46 +0100 Linus Nordberg wrote: > The gossip protocol should work for both CT v1 and CT v2. If it > doesn't, we should fix that. If that's not possible, let's define a > gossip protocol version two. The sth-pollination protocol defined in draft-ietf-trans-gossip-04 could work with v1 STHs, but section 8.2.4 says it contains an array of v2 STHs: "sths - an array of 0 or more fresh SignedTreeHeads as defined in [RFC-6962-BIS-09] Section 3.6.1." For this reason, I've been implementing draft-ietf-trans-gossip-00, which uses v1 STHs and uses the URL .well-known/ct/v1/sth-pollination. Should I be using the URL defined in -04 instead? Incidentally, -04 is not entirely clear how STHs are represented. RFC6962-bis no longer defines a JSON representation for STHs. Instead STHs are returned in JSON responses as base64-encoded SignedTreeHeads. Does this mean that the sth-pollination protocol should use a JSON array of strings, possibly mixed with JSON objects for v1 STHs? Regards, Andrew From nobody Wed Mar 15 14:58:49 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 00DF2129C1E for ; Wed, 15 Mar 2017 14:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkmN9pLSei9C for ; Wed, 15 Mar 2017 14:58:43 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 A355C129C31 for ; Wed, 15 Mar 2017 14:58:35 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 1588EA8A4351; Wed, 15 Mar 2017 21:58:34 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D90DE1FE07E5; Wed, 15 Mar 2017 22:58:33 +0100 (CET) Date: Wed, 15 Mar 2017 22:58:33 +0100 From: Kurt Roeckx To: Andrew Ayer Cc: Linus Nordberg , trans@ietf.org Message-ID: <20170315215833.ig3ctnt3p7ukgc6f@roeckx.be> References: <20170315195838.iypfur5rg4bgysq6@roeckx.be> <87varauv5t.fsf@nordberg.se> <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 21:58:48 -0000 On Wed, Mar 15, 2017 at 02:48:32PM -0700, Andrew Ayer wrote: > On Wed, 15 Mar 2017 21:44:46 +0100 > Linus Nordberg wrote: > > > The gossip protocol should work for both CT v1 and CT v2. If it > > doesn't, we should fix that. If that's not possible, let's define a > > gossip protocol version two. > > The sth-pollination protocol defined in draft-ietf-trans-gossip-04 > could work with v1 STHs, but section 8.2.4 says it contains an > array of v2 STHs: > > "sths - an array of 0 or more fresh SignedTreeHeads as defined in > [RFC-6962-BIS-09] Section 3.6.1." > > For this reason, I've been implementing draft-ietf-trans-gossip-00, > which uses v1 STHs and uses the URL .well-known/ct/v1/sth-pollination. That one also has an sth_version as one of the fields, so I assume it works for both versions. But if I look at other things, it's not obvious to me if it works or not. Kurt From nobody Wed Mar 15 15:34:10 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 E2FE3129C49 for ; Wed, 15 Mar 2017 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay2KTuzddD2n for ; Wed, 15 Mar 2017 15:34:08 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 5F726129C31 for ; Wed, 15 Mar 2017 15:34:01 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u132so21952319wmg.0 for ; Wed, 15 Mar 2017 15:34:01 -0700 (PDT) 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; bh=x2bgwUZr4TmksArZ8Vkm6Jh2ZIjD+91p0K7ypD5HHso=; b=rYgmksKz+dvRRY9Zls5nyYBz+4Ela0VPET7x+u3kAvwelgmI+eaeKMfkHOgnXdbdYc 8PvqojrWduf8+k9uqKT4oMyEiKvI/rulxguYQDwLVtzi24Dnt2iyBCHISf/BY1NknO9L j4pmTIivhTwX6xqJXsMhSpkT6HzebJ4rUA80evxv5NuXo3jxM4Z9q5oNL5p7S8WfjpyM CWixcL3O1p6lFV52u6OtvZcBExWoo3v9LV5tQb+Yc5hEs4F9coTQrHyjbSBz8c5v84Rs CTy8lDRWhIAxguCPkTaYTQesgMYej66HXlgXSG/75BMknDihqZ6pNgyWeAfwWLjIlziz jqNA== 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=x2bgwUZr4TmksArZ8Vkm6Jh2ZIjD+91p0K7ypD5HHso=; b=IjoR7IL62zkR+CXjnuAwxu5xSZXuCjJ4sXlwTLxHWlcNi3tLZUQc/6ha1tYIRcIqmS F6zJWjBvYAat8A5xngIraWDQAIt94CfKGnoguPNSLSfUqMphFFK6/0vv8bx4rsNlsKyA ZxGNLmGwsbEemPkQARHCG/F50t71rwQaFm1dsJq539OEu7kM5kt48LXBFsxYW3MPXKMP jQQ+PG72bE7xAeXFxJf+ZVnFp/ATvWfYSu46tYI8SH+7W/coOI6qo2Ko5gz2cAmob8q8 vQ6bKtrXUnk5Ie52VzEvJ1iUySQ2QH4tUoumrKefDMAJYUR4rl3O3w0QgzDeF2mfZC5F W57g== X-Gm-Message-State: AFeK/H0A06FS51n7njGjAXJ/QpzHrwsEgqrvxcblYzg2+ISPYZcuN67zzhaNhtX3Zdoj5FdsBaiienhUml3c6Q== X-Received: by 10.28.93.68 with SMTP id r65mr6757862wmb.133.1489617239479; Wed, 15 Mar 2017 15:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Wed, 15 Mar 2017 15:33:58 -0700 (PDT) Received: by 10.28.31.2 with HTTP; Wed, 15 Mar 2017 15:33:58 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 15 Mar 2017 18:33:58 -0400 Message-ID: To: Trans Content-Type: multipart/alternative; boundary=001a11467a9a6953eb054acc8a2f Archived-At: Subject: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:34:10 -0000 --001a11467a9a6953eb054acc8a2f Content-Type: text/plain; charset=UTF-8 Hey all, I just submitted a whole crop of new issues (>10% of all WG issues to date!) on 6962-bis: https://trac.ietf.org/trac/trans/report/1 While these issues are numerous and some of them are non-trivial, none of them are fundamental and I think most of them are pretty clearly justified. So hopefully it will be easy to make progress here. I'd like to call out a few as especially critical, which basically encode the objections EKR and I have been raising lately: https://trac.ietf.org/trac/trans/ticket/162 https://trac.ietf.org/trac/trans/ticket/163 I will be off next week, but glad to meet up with folks at the IETF to triage / fix issues. --Richard --001a11467a9a6953eb054acc8a2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all,

I j= ust submitted a whole crop of new issues (>10% of all WG issues to date!= ) on 6962-bis:


Wh= ile these issues are numerous and some of them are non-trivial, none of the= m are fundamental and I think most of them are pretty clearly justified.=C2= =A0 So hopefully it will be easy to make progress here. =C2=A0

I'd like to call out a few as es= pecially critical, which basically encode the objections EKR and I have bee= n raising lately:



--001a11467a9a6953eb054acc8a2f-- From nobody Wed Mar 15 18:46: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 74D2313013D for ; Wed, 15 Mar 2017 18:46:15 -0700 (PDT) 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 cp-hHuk9dnZx for ; Wed, 15 Mar 2017 18:46:14 -0700 (PDT) Received: from homiemail-a98.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 AB6D612F24E for ; Wed, 15 Mar 2017 18:46:14 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 4006060002A3B for ; Wed, 15 Mar 2017 18:46:14 -0700 (PDT) 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=wT0lid97TZm5Qcoyf6D8MZv8Dlw=; b= Qb92kDGLzCBshLJ5ksxGnItZbtiomK9XN2j6F2E7hTTPdbhJFJlGpqxs8EeaY/Eu 2vdT+aYsPdGb5ntaXb+WYSiRudmlwy8WLAISZKyYiN4Dy/650K/gXgjH7LpF2Qiv bbaGL/wATLNFjXYHVXJYmCZJ1wsqm6Z1uWRygTNXABY= Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 0C07D60002A38 for ; Wed, 15 Mar 2017 18:46:14 -0700 (PDT) Received: by mail-lf0-f42.google.com with SMTP id y193so14160703lfd.3 for ; Wed, 15 Mar 2017 18:46:13 -0700 (PDT) X-Gm-Message-State: AFeK/H22KXjjO3eFYosCWqX8enTBot4LYLNBZ59G2wwUAVNiuGKl9G+iOMo3p7pr9d1TR8i+iHNTk+J4s2jwqw== X-Received: by 10.46.22.85 with SMTP id 21mr2093545ljw.113.1489628772211; Wed, 15 Mar 2017 18:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Wed, 15 Mar 2017 18:46:11 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Wed, 15 Mar 2017 21:46:11 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Cc: Trans Content-Type: multipart/alternative; boundary=f403045fc1a0d0a4a0054acf392c Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 01:46:15 -0000 --f403045fc1a0d0a4a0054acf392c Content-Type: text/plain; charset=UTF-8 That's a whole lot of issues, and some of them questionably justified. It also seems non-ideal to suggest that these issues be closed without discussion on the list, as that's not very transparent. Given WGLC has completed, and it seems some of them fundamentally redefine the protocol or implementation, do you have a suggested priority of issues to discuss, from those you view as most clearly justified to least clearly justified? --f403045fc1a0d0a4a0054acf392c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's a whole lot of issue= s, and some of them questionably justified. It also seems non-ideal to sugg= est that these issues be closed without discussion on the list, as that'= ;s not very transparent.

Given WGLC has completed, and it seems some of them fund= amentally redefine the protocol or implementation, do you have a suggested = priority of issues to discuss, from those you view as most clearly justifie= d to least clearly justified?
--f403045fc1a0d0a4a0054acf392c-- From nobody Wed Mar 15 19:28:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1529612F24E for ; Wed, 15 Mar 2017 19:28:51 -0700 (PDT) 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 T8L7nKQ5mE5x for ; Wed, 15 Mar 2017 19:28:49 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 5A52A129C68 for ; Wed, 15 Mar 2017 19:28:49 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u132so24397046wmg.0 for ; Wed, 15 Mar 2017 19:28:49 -0700 (PDT) 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=j8VbbV0s8AEi+4NAazA4cdvNAQUa4iJK4KMFt1b1JCs=; b=Frf+TUJqIAoUqPhsXQFuHG7VVFDJwNGqJCzpAtHXm/fS898RbGkLeS2A4buwdlCTzZ z1XOPQLNZYHgKNorkGSUff5yjgO8DoYnyDwEKk7JZS4JiTNC2YGovs/1n44n6yzaCUR8 YnM+w83ESaziaEODiNEZQ7mmNXZMAeT43JU8aZGIjXnSnopKcqiUkJbpOoDS/uwmmQVf iUwTppt3p5Ut9PRmZ/ajYUpRzO8sxVcfzw5gjek11FhbRt9Y63t0KPFzHpdEVVQBu0Ey B1WPum4vYsB/aLK0RufO7/L1U/6qMZXRGgGrctBFp5gdJUpNSlLh3aSrWk8fvf5uXvYQ T8NA== 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=j8VbbV0s8AEi+4NAazA4cdvNAQUa4iJK4KMFt1b1JCs=; b=tuJughzWA9OmUJg5eB+zUcLgNd+jSW+/IHZE7NOgb4MbSgnYYKclsV0Wf4j/hvGP5f dovKss5IIVp7A/NN+qvcuBzWZSCpN2DYevZcRkvT09l+LWiaksEWDB6C/N2VpHcGkDlA W0dqmZzGup73s9oo009k8WCrq4jTbv+cvDEqmu2NfJnMHjI4losFK0z/NK2jqvrh5mjO /CmDkkj0ru57i8Xzt+7QXbhJgNtGELBgnFXT8JbCHwW3lbpQGLjNI241M6484YTj7K9G trK3ONHk8kfScWdZD/5ZEN6bqKd/9VURARQCm/VfbneeyAwAzZdO1PCDkw4mM085cq4P mUag== X-Gm-Message-State: AFeK/H0T+XVE7uxVsAcUOnSIcdiUy3el2EbXQFfAxAybo9B57Ihg3gNS56mrJSLe0PMn3kZ+KZ8RYcwIBbOM0Q== X-Received: by 10.28.156.69 with SMTP id f66mr21249842wme.56.1489631327665; Wed, 15 Mar 2017 19:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Wed, 15 Mar 2017 19:28:47 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 15 Mar 2017 22:28:47 -0400 Message-ID: To: Ryan Sleevi Cc: Trans Content-Type: multipart/alternative; boundary=001a114b7e2a21d2c2054acfd27f Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:28:51 -0000 --001a114b7e2a21d2c2054acfd27f Content-Type: text/plain; charset=UTF-8 On Wed, Mar 15, 2017 at 9:46 PM, Ryan Sleevi wrote: > That's a whole lot of issues, and some of them questionably justified. It > also seems non-ideal to suggest that these issues be closed without > discussion on the list, as that's not very transparent. > I certainly didn't mean to imply that these would be closed without discussion. The idea of meeting up was just to get concrete proposals in front of the WG faster. > Given WGLC has completed, and it seems some of them fundamentally redefine > the protocol or implementation, do you have a suggested priority of issues > to discuss, from those you view as most clearly justified to least clearly > justified? > I think you're over-stating the impacts here. The overall shape of the protocol is untouched by these proposals, and many of them are just cleanup for a document that's made it through 25 revisions. But I'm happy to provide some taxonomy / plan of attack. I'll send something around tomorrow. --Richard --001a114b7e2a21d2c2054acfd27f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 15, 2017 at 9:46 PM, Ryan Sleevi <ryan-ietf@sleevi.com<= /a>> wrote:
That's a whole lot of issues, and some of them= questionably justified. It also seems non-ideal to suggest that these issu= es be closed without discussion on the list, as that's not very transpa= rent.


--001a114b7e2a21d2c2054acfd27f-- From nobody Wed Mar 15 19:39: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 270AE12F257 for ; Wed, 15 Mar 2017 19:39:51 -0700 (PDT) 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 X2i4n3LHatf1 for ; Wed, 15 Mar 2017 19:39:49 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::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 B8C1112F24E for ; Wed, 15 Mar 2017 19:39:49 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id n190so17801719pga.0 for ; Wed, 15 Mar 2017 19:39:49 -0700 (PDT) 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=kxZVg3NZh8huyyFM5SHdNRqQbfip1plhqgdUzdthbEU=; b=ne+i2gCtxAU6Is3kvnrf6cw/qbj8bwNuIPSHjNAGHwGyxTTcyDMLKX1itOhOP7NHDH c5cc61lgBYlkkFWu0P41qAfJ/B4roblyy/r9DacJFNMt0hARpqE/DdTIlhn/FDhoTpP8 vj4sIm5WFBJ6CuS2pkAbiO1Do87pUhktRsGhc3pDO7GJFFAn0H0HNCA1J/5PWKU/1tyA nd1yFfoOp0fd77O49RTN2Jt8lRSn/P1jM8IRvMdjTqvrPFo8SXAOsmEBywUnLXHM4Qiu P5JPVKIUl/fFseYiiBc0/hdd5E0XwtuVgdAAyc9J3OCEP31H5lyy9E79xHAuJB+v0Ka1 sptA== 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=kxZVg3NZh8huyyFM5SHdNRqQbfip1plhqgdUzdthbEU=; b=UXYjh6ilF/Q9rjjNzw0doGoU3GkHnyeV+CHomXLDoyL4z3dA4NB+jqAAAzV6YXrGTt pPAc+AM3KtT+YWb6eSrO9qWwWTziWnXB8/PwSfsGwo5IWDi60QC+bmZafeiPqi5GZzS/ c7vCIYZU72sx9mLfALVDKOAj3Zu5y+yuJN7zwUgymoZsOFuLd1lia4c0Dgvd7cO13cyQ tqn9PyhSwytjzhqNiMUhz3MBaMdW3oAO1VJfPk4GgrbtBd3LvNlIoEK6RisPtJz9Bdeg Bj1Dnmpb/eCAJtK9g7gjJfZzvgCHVxeQn1ipEa25nCoc2Jbee9dvkIgUd0aI+odHb1ys G4QA== X-Gm-Message-State: AFeK/H1BbuVRuzl/xnMZsZ+golvNj7YSyIu4/j2dKjiqE/7m2SEbqH7nBSG0PTM0wZaVKw== X-Received: by 10.84.232.72 with SMTP id f8mr8872859pln.85.1489631988668; Wed, 15 Mar 2017 19:39:48 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-74-184-radius.dynamic.acsalaska.net. [216.67.74.184]) by smtp.gmail.com with ESMTPSA id z68sm6678881pgz.11.2017.03.15.19.39.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 19:39:47 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: Date: Wed, 15 Mar 2017 18:39:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G18Aqiaq2K4OsvtkbJJhlAEk1HFKUBT3p" Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:39:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G18Aqiaq2K4OsvtkbJJhlAEk1HFKUBT3p Content-Type: multipart/mixed; boundary="A9j4p3eqogKa4A6vpRqGhSNDm8OWwvceD"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: Subject: Re: [Trans] Fresh issues! References: In-Reply-To: --A9j4p3eqogKa4A6vpRqGhSNDm8OWwvceD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I appreciate that there's going to be a lot of concern about a big pile of issues being opened up at this stage in the process. Nothing is going to be closed without working group discussion (which means on the mailing list, not just in a meeting) unless it's truly trivial - something on the scale of misplaced punctuation. I'm going to go through the new issues tonight and make sure that we've got a handle on how to get these whacked down in a timely way. We should probably figure on having a side meeting at some point during the week - we'll try to track down a room once we've got some idea of when and how many people. Melinda --A9j4p3eqogKa4A6vpRqGhSNDm8OWwvceD-- --G18Aqiaq2K4OsvtkbJJhlAEk1HFKUBT3p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYyfryAAoJELiGRpM6HoEuvPMQAJQNe/T5hiFKv23dUYFCmc4m QRSyLYoBFHEPYNLOy+gQDZ+wdlic03tNPKk5i2bMA7jKDZ73zarxATfV0ghqjhJb sE3on9b3AVMDFiTgDKwtDMK50WJS18MnvCrsPO9pH3htjb2etwPMDk26B/9OdBe8 8TFEkUNAFJdUFpT/LYDKjKTLwnp2G4Wq22De9enVugVvPH2iiDr7uEs1NNkTKFcy ZIkXyfPaGxd0vpLeSPf2y2QWmLSdV79qlgdbLYhUi45iNErreFxSRET23J2coarw UbmHTkvHyRwaOn0QvBPT9ABiaXzGWERU1t+0QN6QxpQi9aik16e74guYJe4hUuJG bd9uTYoIkdRe3+whaI8zKeqrIexS7pMQi4qgsN8LMas1RQV6HLopE3C57s8zB2ja 8rBv45VbxnPPt3ko1628aQsNIFsex20L+OjA5UsobsIZoaRAP6gh4Wr8ZgGH9mlP 70oR3zfJxcRDDWPnSmoHhW/ZA/fFI+ymPSgkS0hKBrafrh8QNLwV2YFn9q9D0GXF 9HKF4vphy3AK7gC+OraCYZKzhZMJ2cEHdWNOAcMBcueV7QR39r49rm9q/hmBhJqD P3wQAtUCRuz/iAs7Ysr2IAxwUn5z/MXGcWAGuCcgfFdqomXlQB52QKQSOyACUAz2 8tCduyMEqyw7RZ7t2g1J =fUtO -----END PGP SIGNATURE----- --G18Aqiaq2K4OsvtkbJJhlAEk1HFKUBT3p-- From nobody Wed Mar 15 19:48: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 F1EA912F257 for ; Wed, 15 Mar 2017 19:48:46 -0700 (PDT) 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 k2S6NNxGtk_h for ; Wed, 15 Mar 2017 19:48:45 -0700 (PDT) Received: from homiemail-a103.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 DB467129C68 for ; Wed, 15 Mar 2017 19:48:43 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 77BE630002B25 for ; Wed, 15 Mar 2017 19:48:43 -0700 (PDT) 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=7ZYQ6QA6lLNQ0go52GXsPvRYkL8=; b= gWVT2cZkLxUMo+VU/3bXru2Z3cfAKJN1xvwEt5QhfJXx+ekkYFONOcViBiGYBogM 44RIvsMjpyOm88E7UyzcxElR0zgZUtzec9GBFa29kYZogJG40Ba2yXQgpnxG1Nh6 qLnIUZPQhE5ksSoy3YQCKOQMEfhsrd8A/froX2y2/s8= 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-a103.g.dreamhost.com (Postfix) with ESMTPSA id 4AD6A30002B21 for ; Wed, 15 Mar 2017 19:48:43 -0700 (PDT) Received: by mail-lf0-f47.google.com with SMTP id z15so14558314lfd.1 for ; Wed, 15 Mar 2017 19:48:43 -0700 (PDT) X-Gm-Message-State: AFeK/H3IUPXr9gX4AiDwyDnfrmbLdd2B3cbePmdi/hmTfqwFH2or6oJ7U+wABnySgx9sbRN82PEpnX+3erChTw== X-Received: by 10.46.9.75 with SMTP id 72mr2144928ljj.10.1489632521607; Wed, 15 Mar 2017 19:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Wed, 15 Mar 2017 19:48:40 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Wed, 15 Mar 2017 22:48:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Cc: Ryan Sleevi , Trans Content-Type: multipart/alternative; boundary=001a114b10364be16f054ad019d2 Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 02:48:47 -0000 --001a114b10364be16f054ad019d2 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 15, 2017 at 10:28 PM, Richard Barnes wrote: > I think you're over-stating the impacts here. The overall shape of the > protocol is untouched by these proposals, and many of them are just cleanup > for a document that's made it through 25 revisions. > https://trac.ietf.org/trac/trans/ticket/162 https://trac.ietf.org/trac/trans/ticket/170 https://trac.ietf.org/trac/trans/ticket/171 https://trac.ietf.org/trac/trans/ticket/174 https://trac.ietf.org/trac/trans/ticket/176 https://trac.ietf.org/trac/trans/ticket/185 Are all pretty substantially impacting changes. That's just a few I looked through of which meaningfully change how either a client or server is designed and implemented. I'll use https://trac.ietf.org/trac/trans/ticket/185 as an example, which I suspect is something you'd consider trivial (but I may have read wrong). As a client, this forces an additional indirection through a URL lookup service to take advantage of this. It further forces the need for policy regarding how such URLs are constructed and advertised - because as we all know, despite (or because of, depending on your view) RFC 3986, URLs are far messier in the real world, and untangling that mess just shifts the problem to policy. It touches on operational issues, such as whether or not this remains static for the duration of the log or variable. I wasn't trying to suggest we shouldn't discuss these, just that I can see a number of them are, from a client implementor hat, pretty significant, and some of them are pretty underjustified or undesirable (e.g. https://trac.ietf.org/trac/trans/ticket/171 ). I'll save the substantive comments for the individual discussions, and greatly appreciate the view to highlight what you believe are most to least pressing matters to resolve :) --001a114b10364be16f054ad019d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 15, 2017 at 10:28 PM, Richard Barnes <= rlb@ipv.sx> w= rote:
I think you're over-stating the impacts here.=C2=A0 The overall= shape of the protocol is untouched by these proposals, and many of them ar= e just cleanup for a document that's made it through 25 revisions.


Are all pretty substanti= ally impacting changes. That's just a few I looked through of which mea= ningfully change how either a client or server is designed and implemented.=

I'll use=C2=A0https://trac.ietf.org/trac/trans/ticket/185 as= an example, which I suspect is something you'd consider trivial (but I= may have read wrong). As a client, this forces an additional indirection t= hrough a URL lookup service to take advantage of this. It further forces th= e need for policy regarding how such URLs are constructed and advertised - = because as we all know, despite (or because of, depending on your view) RFC= 3986, URLs are far messier in the real world, and untangling that mess jus= t shifts the problem to policy. It touches on operational issues, such as w= hether or not this remains static for the duration of the log or variable.<= /div>

I wasn't trying to suggest we shouldn't di= scuss these, just that I can see a number of them are, from a client implem= entor hat, pretty significant, and some of them are pretty underjustified o= r undesirable (e.g.=C2=A0https://trac.ietf.org/trac/trans/ticket/171 ).

I'll save the substantive comments for the individual discussion= s, and greatly appreciate the view to highlight what you believe are most t= o least pressing matters to resolve :)
--001a114b10364be16f054ad019d2-- From nobody Thu Mar 16 04:00: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 F3320127A90 for ; Thu, 16 Mar 2017 04:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMjlvzegkOZI for ; Thu, 16 Mar 2017 04:00:43 -0700 (PDT) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (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 E7419127977 for ; Thu, 16 Mar 2017 04:00:41 -0700 (PDT) Received: (korumail 16282 invoked from network); 16 Mar 2017 11:00:39 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 16 Mar 2017 11:00:39 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703161100391558; Thu, 16 Mar 2017 11:00:39 +0000 To: Melinda Shore , trans@ietf.org References: From: Rob Stradling Message-ID: Date: Thu, 16 Mar 2017 11:00:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:00:52 -0000 Melinda, You'll recall that (a few months ago) both Eran and I promised that we would make no further changes to 6962-bis. But if you'd like me to resume co-authoring duties, I'd be happy to do so. On 16/03/17 02:39, Melinda Shore wrote: > I appreciate that there's going to be a lot of concern > about a big pile of issues being opened up at this stage > in the process. Nothing is going to be closed without > working group discussion (which means on the mailing list, > not just in a meeting) unless it's truly trivial - > something on the scale of misplaced punctuation. I'm > going to go through the new issues tonight and make sure > that we've got a handle on how to get these whacked down > in a timely way. We should probably figure on having > a side meeting at some point during the week - we'll try > to track down a room once we've got some idea of when > and how many people. > > Melinda -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Mar 16 05:26:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F04129456 for ; Thu, 16 Mar 2017 05:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfv8dSEZl4tZ for ; Thu, 16 Mar 2017 05:26:48 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 A3CD1127201 for ; Thu, 16 Mar 2017 05:26:48 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id g138so40656295itb.0 for ; Thu, 16 Mar 2017 05:26:48 -0700 (PDT) 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=wHmW8C3fm9gepaHgmbyL3Ta4Ek5gN6gIy1qYH+FY3Os=; b=R2Ex/QLC+DA9rPFwXUSMoQUWAdfudSaxh7+AHowM7PlBZEhjb9owsvAfE50GYUzW9D YBMs3hsWJMGMQ8/JCyeI0ROPzB05GV8egYYfLFw+w+ypKuA90V8Y6OmnY5AZ6BhMq8Xs DEXj6/46yKtJMGBVFSBY3TVUPiZqZNy3n+tmMqxc+vS2XFFjyPo97CdENbTkk84GAqsn 42D0c/6FcnnDJ4TrDqn9PuUl//eP5RpRY61Lj0Bv4S5/3iGvIlrvrV8rMGwugGjf3sFM dsuAX+5nLK1Obt4UCU8L9S6Y+VZ/OobfomFPX7zzrsO6aEyr4h2ae25PSpZSmwb3UauK h10A== 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=wHmW8C3fm9gepaHgmbyL3Ta4Ek5gN6gIy1qYH+FY3Os=; b=HZ+ZCuH/1c9Efx+UlAgdkpFXClCUYTz4ySw6JL3e0OayTd9jywMeZJkYMsvUJXkL3h /spX76cFd7yGA+joXLhq2VqdZ/ZL8M/v1NV8TNjUKScv2w2hlt74A73WG+osMsS9taMD 1utuLj+pKK/OAFmFcA3kLhoTz1+6ThWnoeOfPM/EdDyOK+iLvWRp4Qhr2ckvK/ARaqpu uVSYCzbYjbBwJJsTufsRSlWDNKhYz98hb+4ZZ6si/ewHdUuK+7zj5+pjGs+Y2wysRw7u /rj8pbaLJwKNofALQiW5WaudQHOkFwaExGgVxA5fEwa97zqHQWcpvfSzKuWCOX9sxtnF K+gQ== X-Gm-Message-State: AFeK/H2Bi0i8cbhaAKORGGbfcltXdyKgOJXhH9EDBzkzFWNDUCJCftUwhyA/JERmQz4Lol6PeoOmMpIH6YZAtgnM X-Received: by 10.36.124.85 with SMTP id a82mr11190840itd.90.1489667207906; Thu, 16 Mar 2017 05:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Thu, 16 Mar 2017 05:26:17 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Thu, 16 Mar 2017 12:26:17 +0000 Message-ID: To: Rob Stradling Cc: Melinda Shore , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a114aa74ac33e46054ad82cc1 Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:26:51 -0000 --001a114aa74ac33e46054ad82cc1 Content-Type: text/plain; charset=UTF-8 Same here - I also think that going over the issues Richard has filed to determine which ones can be addressed in a timely way, without significantly changing fundamental aspects of 6962-bis. On Thu, Mar 16, 2017 at 11:00 AM, Rob Stradling wrote: > Melinda, > > You'll recall that (a few months ago) both Eran and I promised that we > would make no further changes to 6962-bis. But if you'd like me to resume > co-authoring duties, I'd be happy to do so. > > > On 16/03/17 02:39, Melinda Shore wrote: > >> I appreciate that there's going to be a lot of concern >> about a big pile of issues being opened up at this stage >> in the process. Nothing is going to be closed without >> working group discussion (which means on the mailing list, >> not just in a meeting) unless it's truly trivial - >> something on the scale of misplaced punctuation. I'm >> going to go through the new issues tonight and make sure >> that we've got a handle on how to get these whacked down >> in a timely way. We should probably figure on having >> a side meeting at some point during the week - we'll try >> to track down a room once we've got some idea of when >> and how many people. >> >> Melinda >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114aa74ac33e46054ad82cc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Same here - I also think that going over the issues Richar= d has filed to determine which ones can be addressed in a timely way, witho= ut significantly changing fundamental aspects of 6962-bis.


On Thu, Mar 1= 6, 2017 at 11:00 AM, Rob Stradling <rob.stradling@comodo.com>= ; wrote:
Melinda,

You'll recall that (a few months ago) both Eran and I promised that we = would make no further changes to 6962-bis.=C2=A0 But if you'd like me t= o resume co-authoring duties, I'd be happy to do so.


On 16/03/17 02:39, Melinda Shore wrote:
I appreciate that there's going to be a lot of concern
about a big pile of issues being opened up at this stage
in the process.=C2=A0 Nothing is going to be closed without
working group discussion (which means on the mailing list,
not just in a meeting) unless it's truly trivial -
something on the scale of misplaced punctuation.=C2=A0 I'm
going to go through the new issues tonight and make sure
that we've got a handle on how to get these whacked down
in a timely way.=C2=A0 We should probably figure on having
a side meeting at some point during the week - we'll try
to track down a room once we've got some idea of when
and how many people.

Melinda

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

--001a114aa74ac33e46054ad82cc1-- From nobody Thu Mar 16 05:45: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 E5956129483 for ; Thu, 16 Mar 2017 05:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otlE_VBS39zt for ; Thu, 16 Mar 2017 05:45:34 -0700 (PDT) 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 750B7129464 for ; Thu, 16 Mar 2017 05:45:34 -0700 (PDT) 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 v2GCjRRi032392 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 13:45:27 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2GCjLrm015130 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 12:45:25 GMT From: Linus Nordberg To: Andrew Ayer Cc: trans@ietf.org, Kurt Roeckx Organization: Sunet References: <20170315195838.iypfur5rg4bgysq6@roeckx.be> <87varauv5t.fsf@nordberg.se> <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> Date: Thu, 16 Mar 2017 13:45:28 +0100 In-Reply-To: <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> (Andrew Ayer's message of "Wed, 15 Mar 2017 14:48:32 -0700") Message-ID: <87h92ts847.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; 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: 0aSUAJrVV - beab26ae7fc2 - 20170316 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:45:37 -0000 Andrew Ayer wrote Wed, 15 Mar 2017 14:48:32 -0700: > On Wed, 15 Mar 2017 21:44:46 +0100 > Linus Nordberg wrote: > >> The gossip protocol should work for both CT v1 and CT v2. If it >> doesn't, we should fix that. If that's not possible, let's define a >> gossip protocol version two. > > The sth-pollination protocol defined in draft-ietf-trans-gossip-04 > could work with v1 STHs, but section 8.2.4 says it contains an > array of v2 STHs: > > "sths - an array of 0 or more fresh SignedTreeHeads as defined in > [RFC-6962-BIS-09] Section 3.6.1." Hmm. It seems like CT v1 has been ignored in the transition to 6962-bis. > For this reason, I've been implementing draft-ietf-trans-gossip-00, > which uses v1 STHs and uses the URL .well-known/ct/v1/sth-pollination. > > Should I be using the URL defined in -04 instead? > > Incidentally, -04 is not entirely clear how STHs are represented. > RFC6962-bis no longer defines a JSON representation for STHs. Instead > STHs are returned in JSON responses as base64-encoded SignedTreeHeads. > Does this mean that the sth-pollination protocol should use a JSON > array of strings, possibly mixed with JSON objects for v1 STHs? I don't know right now. Suggestions welcome! Well, I guess your question is a suggestion. Analysis welcome, as well as proposed text of course. :) Also, very happy to see implementation under way! From nobody Thu Mar 16 08:48: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 043DE12965D for ; Thu, 16 Mar 2017 08:48:31 -0700 (PDT) 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 7R4QK2kfCX5u for ; Thu, 16 Mar 2017 08:48:29 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 9C822129654 for ; Thu, 16 Mar 2017 08:48:29 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id x63so20760772pfx.2 for ; Thu, 16 Mar 2017 08:48:29 -0700 (PDT) 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=UE1hYjpEYiXmeFTdXh1FtPkqZwx2uay7hpNxCwS8vHQ=; b=F2s8GDqbe7pWaulTuyJ73kU6olTaxVI2eMogK/IrFFC2rXY31xBXctTfBm1yAELsSD b/1VQfkvJnBut19cgAKboTwAfG/GyCmbBUsIyaEPIs9suL6fZftR6O2+49xqbjVegKaI DMO90yQC+O4vpye2A8pvzK2Vcwa5fxRnuWx6kaml6A3v42X3rlB70GPhr3GYBrUT+7Zr Umg3P+t8oMNxgaNNZ+/L9zKknQR6P+Iz/raNWNP3ZtJ2lBlD7h1G/yr1B9Ovr5rKETlf rz3umm8g+038vK30o8j/7+o7dqVSNnW4Clstaggpwgrm/b/CTYfSzuZUTE1j01TWo8e6 3wYg== 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=UE1hYjpEYiXmeFTdXh1FtPkqZwx2uay7hpNxCwS8vHQ=; b=exV/dL+TlO0nGqscm51ko3y7g8LBlyw2812jIZG8yxfp8tBTXnMaV0YDzsaqVBtBsJ XEd+hIfM0BkYVNSnbb17vyev83wCkIc22KKjaoTwmzfV3a0+8T8BjFm7VHby9BnfcGqC gCx7zQJfqKgAHL6+Vr9lCyyNQKTO358hLKmPfRCOkq5MyYPS+yRoLXbXKsytn/FA+faV tcd/KjFfPYrNptyEI8DDd4hhTzQMElG65j1wu9CLGkdCzxNvVQ3DI/oeL/CzXI/Z6pAC v5hUqkC7jJFHxYvUaUp+l2VY+U63gsQYOgj6+wMy8ktIJAXURe0ZOrPWUbkih2d51jZB /nJg== X-Gm-Message-State: AFeK/H1LWQ9yXaWUkNxJxTC4QBV2eSlyNVnsxIN/ADgmETlaJw6hrhrLVP9v6T6OIwdZYA== X-Received: by 10.99.229.5 with SMTP id r5mr10861389pgh.206.1489679308925; Thu, 16 Mar 2017 08:48:28 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (69-161-6-5-radius.dynamic.acsalaska.net. [69.161.6.5]) by smtp.gmail.com with ESMTPSA id q23sm11408144pfg.63.2017.03.16.08.48.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 08:48:28 -0700 (PDT) To: Eran Messeri , Rob Stradling References: Cc: "trans@ietf.org" From: Melinda Shore Message-ID: <57a78abf-a309-9fd1-dc2f-dca46eefb6fc@gmail.com> Date: Thu, 16 Mar 2017 07:48:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d9d16v0HX4gvKmx1Q02RgjUNmU7U1XQbp" Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:48:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d9d16v0HX4gvKmx1Q02RgjUNmU7U1XQbp Content-Type: multipart/mixed; boundary="RFbEJXmSoW8P3mIxxQCPrA4TxIJh4ehS2"; protected-headers="v1" From: Melinda Shore To: Eran Messeri , Rob Stradling Cc: "trans@ietf.org" Message-ID: <57a78abf-a309-9fd1-dc2f-dca46eefb6fc@gmail.com> Subject: Re: [Trans] Fresh issues! References: In-Reply-To: --RFbEJXmSoW8P3mIxxQCPrA4TxIJh4ehS2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/16/17 4:26 AM, Eran Messeri wrote: > Same here - I also think that going over the issues Richard has filed t= o > determine which ones can be addressed in a timely way, without > significantly changing fundamental aspects of 6962-bis. >=20 > On Thu, Mar 16, 2017 at 11:00 AM, Rob Stradling > > wrote: >=20 > You'll recall that (a few months ago) both Eran and I promised that= > we would make no further changes to 6962-bis. But if you'd like me= > to resume co-authoring duties, I'd be happy to do so. Excellent - thanks to you both. I think it would also be helpful to identify which of the new issues can be addressed in a new document and which require changes to the -bis draft. Melinda --RFbEJXmSoW8P3mIxxQCPrA4TxIJh4ehS2-- --d9d16v0HX4gvKmx1Q02RgjUNmU7U1XQbp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYyrPKAAoJELiGRpM6HoEuZ6YP/ReCMjm74/CXk9rpd1GCumqi Ey+hngluKa5a5J8A0nWtWCu/WHDSfiH/6xbsrkI0Q13wDXLgjJS0Q2hwm7NOBvQA e67iZQj3TU98RoR5IIKFWPBe0QR7C7b4sP4z2N69OVOa3npFPXAW0ChNTNW76pMt XC4RDMjQ+7lL5c01uX7MqJX5wEijsXT9XCx6yU3rHsowXQgI4i0RVo8d+MR0NWSw Fk7ybTBwuopjlRjwlFZxpAQSwYXMGMsRs6pf5Rnpz5nU+TPQU0y8D/AAGS0eCHlm Emq4g7vb8Vvaseb4XS5Jz31VNlaYi7jgJdEbsMXhwUfgjZFCV55G5O6iVBl7aFTJ YZ65XVnjU5Us2Sj9vU0CCD63k0OSEnvtxPYy1xJOgPjhchGgqlHy4ES50ZUy7cKr swEfEKaLQfWmuFlowJgfr3GozzWwx9kkQrJ6vvm3Rntl+Y15+iAH0bbgjqNHSoZH 85HpYf5gsf+3ovGK//wzz96WzVJmCh2DwiRdsrY6IkC3bYDCotJajCMUWioOZZj3 Ec8fTIyHLoJ7L+ZWLYhiaAgYvMKq41wgCA3/77LEkU6+q906pkdwFGvrqUp0FyZh D+EdXYuDCvsr+KtO/CijWb3/GYNKkfxWqvhfM08rMuuYcs8PdRND1Y3SlcC2zxe1 sx81Qo1Djc3UwrEQ86g3 =BY4p -----END PGP SIGNATURE----- --d9d16v0HX4gvKmx1Q02RgjUNmU7U1XQbp-- From nobody Thu Mar 16 08:55: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 69EDD129646 for ; Thu, 16 Mar 2017 08:55:06 -0700 (PDT) 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 LPT7AnbTqVl4 for ; Thu, 16 Mar 2017 08:55:04 -0700 (PDT) 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 ABE43124234 for ; Thu, 16 Mar 2017 08:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1489679704; bh=056ZYin9P14eztwVoFE27OGlCOxXqNB0DEQfYwtOSj8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Vo6B+OBmSXnmmkIzkln3eNdQArBX/SdSeNrDl4WmVCivB5R88Kyag+OKRaP2o2U2g iRBCCW+Hh3zFX9p0mwfFnKH121sX8mfyig0dqHepg5Jou0iiakN+0/9nS7L07zPcSx 0WU4Lx+P9mb8RoKg4YMG56HLSd4FUN6RE5zQr50Ho5LCYhHBqE0f0KWEsKLlSgYbaf Ym2GqlTrZt8wY/vexHkQVYpbZKXDbfJlcSgoMtoOEQoWkahl5NvGaXJFv9f7RaKZXD cmYKBrLYuZoiN9DaFCLK4P3Cngs7ANtOujMKEszZY3uYx6iGYGSsJewJatzjlNmks5 uBRRx0Di9jCAg== Date: Thu, 16 Mar 2017 08:55:03 -0700 From: Andrew Ayer To: Linus Nordberg Cc: trans@ietf.org Message-Id: <20170316085503.3bab89dca9c1d97d77c4ded1@andrewayer.name> In-Reply-To: <87h92ts847.fsf@nordberg.se> References: <20170315195838.iypfur5rg4bgysq6@roeckx.be> <87varauv5t.fsf@nordberg.se> <20170315144832.8dd517ff9b5010035a17fe49@andrewayer.name> <87h92ts847.fsf@nordberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Gossip URL version X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 15:55:06 -0000 On Thu, 16 Mar 2017 13:45:28 +0100 Linus Nordberg wrote: > Andrew Ayer wrote > Wed, 15 Mar 2017 14:48:32 -0700: > > > On Wed, 15 Mar 2017 21:44:46 +0100 > > Linus Nordberg wrote: > > > >> The gossip protocol should work for both CT v1 and CT v2. If it > >> doesn't, we should fix that. If that's not possible, let's define a > >> gossip protocol version two. > > > > The sth-pollination protocol defined in draft-ietf-trans-gossip-04 > > could work with v1 STHs, but section 8.2.4 says it contains an > > array of v2 STHs: > > > > "sths - an array of 0 or more fresh SignedTreeHeads as defined in > > [RFC-6962-BIS-09] Section 3.6.1." > > Hmm. It seems like CT v1 has been ignored in the transition to > 6962-bis. It seems very desirable to add explicit CT v1 support, as it will probably be quite a while before CT v2 fully replaces CT v1, and there is a need for gossip in the v1 ecosystem in the meantime. I don't think the changes would be significant, and I'd be willing to make a pass through the draft to add text where necessary. However, the gossip draft has already completed WGLC. What kind of changes can be made at this point? > > For this reason, I've been implementing draft-ietf-trans-gossip-00, > > which uses v1 STHs and uses the > > URL .well-known/ct/v1/sth-pollination. > > > > Should I be using the URL defined in -04 instead? > > > > Incidentally, -04 is not entirely clear how STHs are represented. > > RFC6962-bis no longer defines a JSON representation for STHs. > > Instead STHs are returned in JSON responses as base64-encoded > > SignedTreeHeads. Does this mean that the sth-pollination protocol > > should use a JSON array of strings, possibly mixed with JSON > > objects for v1 STHs? > > I don't know right now. Suggestions welcome! Well, I guess your > question is a suggestion. Analysis welcome, as well as proposed text > of course. :) Yes, you can take my question as a suggestion. The advantage is that it avoids creating redundant formats for STHs and allows code reuse for parsing STHs. The disadvantage is that mixing objects and strings in the same array might make parsing the JSON awkward with some libraries/languages. > Also, very happy to see implementation under way! I should have a report to make to trans soon :-) Regards, Andrew From nobody Thu Mar 16 10:09: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 284AC120227 for ; Thu, 16 Mar 2017 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui4rnFPsffFH for ; Thu, 16 Mar 2017 10:09:48 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 B5E721296B8 for ; Thu, 16 Mar 2017 10:09:46 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id x37so63239267ota.2 for ; Thu, 16 Mar 2017 10:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pKfzFGc73+FDBPVqfB0+Kljwt/FBpW43w7JIm1K3UnE=; b=aBWqahm1dspHskx6WmdeOj4xBHV64y8lbVyZhZxQABWXILOAwL0ZViDCNSZ48PeWKN W2eum2erpq23W321K8O3J/b/LD/c63+AAAUiqoR+yCBdRIAv9habVKKnaXgDLZIqNN1h +Ej3ac/q8nBV7Xy1ZTCi1ihgWs5C6XXKjheVWAiVHsOoiJsc872LGipl6aILO3cnPmnI BnqrGK96bInG/0ypAUFIX1jm/fXQNG1nEzGSHQ4KGtTMhMVuzq7tjKYXcj6EtEYUNcDD zLvGxIwrwk4gPsBHbHaL9ObhUnafIM1kT3F+0YIEnuiouFT31J1+NG078aaq3K+mmMbC hjdA== 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=pKfzFGc73+FDBPVqfB0+Kljwt/FBpW43w7JIm1K3UnE=; b=KnWe4WacPXwqjWGPoU58AnXq5oFdyrPRT+1Hu7WJZaxRaVr8PCLiHN7IAQyhGWlPE5 z9AiH9hyhy6yET3UtPwG+9XZUIIYekU5/pebJXiY5kAT9+SjUqz7HZ9E92FqaHXMEeR7 1mUD5HamXeSoHNhd1vIxL3FWwFnkQTtap7nt2fKM1RrLdDfCjG08Jb25kh1pHZunmVA3 f8msbEcE7utX1dxCRdK22Pn9NLPAn86SlIMOj+icc1+A6B4r6CPGdP5idyt4b2Juti0C 7nyIw7Abr7HdLqfOfjkaIwaK732f4+HgPkXLA5WRIxNN19e3ILyoqQYHyh8BQ3iHZJpp neRg== X-Gm-Message-State: AFeK/H0oMvkVY4QzNpc1j9bfyKlgYnD6saCRylNJeZWJTtf20MqAbkzaKCgxK8nbRIoIjCk8wEIR+wCVrgJC30v6 X-Received: by 10.157.11.229 with SMTP id 92mr4947740oth.85.1489684185705; Thu, 16 Mar 2017 10:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Thu, 16 Mar 2017 10:09:44 -0700 (PDT) From: Wei Chuang Date: Thu, 16 Mar 2017 10:09:44 -0700 Message-ID: To: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1142ef02bd25cf054adc202a" Archived-At: Subject: [Trans] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:09:50 -0000 --001a1142ef02bd25cf054adc202a Content-Type: multipart/alternative; boundary=001a1142ef02b80dbe054adc20f6 --001a1142ef02b80dbe054adc20f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi folks, I saw there was significant interest in exploring CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec was created. It seems to have quieted down since. I believe the motivation is still there which is to prevent a parent zone from potentially misbehaving and spoofing the child zone. Is there still interest in this? From the list archives, I can't see what the issues were though I'm guessing one of them was respecifying the DS resource record to use a SCT which might have caused compatibility concerns. (But please correct me if I'm wrong) Other than that, the draft seems pretty reasonable. Were there other concerns? thanks, -Wei --001a1142ef02b80dbe054adc20f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi folks,

I saw there was significant interest in exploring CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec was created.  It seems to have quieted down since.  I believe the motivation is still there which is to prevent a parent zone from potentially misbehaving and spoofing the child zone.  Is there still interest in this?  From the list archives, I can't see what the issues were though I'm guessing one of them was respecifying the DS resource record to use a SCT which might have caused compatibility concerns.  (But please correct me if I'm wrong)  Other than that, the draft seems pretty reasonable.  Were there other concerns?

thanks,
-Wei  
--001a1142ef02b80dbe054adc20f6-- --001a1142ef02bd25cf054adc202a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDkMu8j/55wvvscg3Tg3Cwg rHV7mIJ/SWzSivNj6RvI2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTYxNzA5NDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA2tTj0ncb7wAx1o5/lbe45u9tP1W9aJfupS6iIgaq hPYCqgGts7fZkHG8y1EGlnK6wEYL9mr1/34R7VHz5fVSZcrY1M4blWHnKJMen5CGgwKyknky07he 42gCECBGWE6i4/nWfwWfvJtSzi/OU9nYorfC8ORzCsKxdJL5TSqRMmWwq4zgjnzTRI28IeufZhp9 8s5o9d79z4K4fTICohfsmDu1CRMPIONN+03wr/W72U60A1ZE0P+F8tR+CfMrDPHwvWVl/V0nzkof BgxG8ZbmypDoA88USTjHYcHeC4P9rGLfUCyYT4XSDNZMN3zjDReLodkKiK8RXc9PA18cx5yhgA== --001a1142ef02bd25cf054adc202a-- From nobody Thu Mar 16 10:25:15 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 218121296C4; Thu, 16 Mar 2017 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 l7dJX4f7OcmW; Thu, 16 Mar 2017 10:25:12 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 865FF127843; Thu, 16 Mar 2017 10:25:12 -0700 (PDT) Received: from [10.32.60.31] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2GHP2ro022144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Mar 2017 10:25:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.31] From: "Paul Hoffman" To: "Wei Chuang" Cc: trans@ietf.org, dane@ietf.org Date: Thu, 16 Mar 2017 10:25:08 -0700 Message-ID: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:25:14 -0000 On 16 Mar 2017, at 10:09, Wei Chuang wrote: > I saw there was significant interest > in > exploring > CT for DNSSEC back in 2014 of which a draft > draft-zhang-trans-ct-dnssec > was > created. > It seems to have quieted down since. I believe the motivation is > still > there which is to prevent a parent zone from potentially misbehaving > and > spoofing the child zone. Is there still interest in this? From the > list > archives, I can't see what the issues were though I'm guessing one of > them > was respecifying the DS resource record to use a SCT which might have > caused compatibility concerns. (But please correct me if I'm wrong) > Other > than that, the draft seems pretty reasonable. Were there other > concerns? There were two separate issues that got conflated at the time: - Seeing evidence that a parent had spoofed DNSSEC keys for a child. A transcript of the DS records in the parent is sufficient as long as the child doesn't have relying parties create islands of trust (which is relatively rare these days). - Seeing evidence that a parent had spoofed any resource records for a child. A transcript of the NS records in the parents is a good start, although what is really needed is a transcript of everything that is seen for the child. In both cases, having transcripts from various DNS looking glasses around the Internet would give greater assurance of the integrity of the transcript. --Paul Hoffman From nobody Thu Mar 16 15:59:09 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 4E3DD129B52 for ; Thu, 16 Mar 2017 15:58:59 -0700 (PDT) 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 IqX8Psm8uzgu for ; Thu, 16 Mar 2017 15:58:54 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 2E946129B4B for ; Thu, 16 Mar 2017 15:58:54 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id g10so41673129wrg.2 for ; Thu, 16 Mar 2017 15:58:54 -0700 (PDT) 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=Gb+qLP4k180zWDfniAy3eXfJ2/jeiSIaloB/9EcOIjU=; b=TdBOFuAkWOZwwjei/YZc5/XPi8HoOIbD3SkeaFbs3rON6PpaXkwQQX2m33Rq2iRaZ4 S+zjSja7Ot3PUmc8mG/vvrESkaJyj0uFOq0q2RJpa/mhd9IA0+I/bW8saG6QOnMl9MLv BPD2LSsFYeFWR/qV/+nBFCGKkZU52xKwffxK5pvslrZ9QKz19drbYImTVOPLQnpicqMv lEcNGuyXJTJPa2bHbdyPza0kPmEL3PCRKJAw8bBKgteZdxY/EBP8NMms5Yw3uz6m54ne i01EspS/692KogzLouaN49JCC+pHErMAb/HBVVwE5xP8VRi9Gky5hDw6QRVYoMzSGsZe Dv2A== 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=Gb+qLP4k180zWDfniAy3eXfJ2/jeiSIaloB/9EcOIjU=; b=HCC8hvHtRvRhXx3nc1Q4yJqSyYPm36pg8LcykUOb7eEGjzAkAaeemdfs1ICHJNISAj TYR605X60J4Aewu0gKGPlZNkJpIzvio3qy6iwyXEdKAaT3w/s+zrmozj1/QGR4vdJtho wtV9KpXDtwR4jSn79bWLkjeG8FZg0FjJmh5U3OiTSpHpcA8qGfbHQ6hPmc+khUDCwryl mCtA+mtBFlL1vN00xpUeMCFLZSat24uV2BDGdYjjbAmnJTNC2BeNnFHBVrBl0m/dMIET F/MyM3hgXPV2He4bTvhSAefeA1PGoeS+7GAiVE//ZP9Aw/RRzWumfH6D96WGGh7H2GPD zOQQ== X-Gm-Message-State: AFeK/H1UalUwd0+qbFdv2mlqgTAxHwmNNiGI3dq4mUjC9FTPLZ/jHd4BKqBCiVcukuxKBm+oQRzL7hoUM0h/bA== X-Received: by 10.223.162.130 with SMTP id s2mr11152328wra.149.1489705132068; Thu, 16 Mar 2017 15:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.2 with HTTP; Thu, 16 Mar 2017 15:58:51 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 16 Mar 2017 18:58:51 -0400 Message-ID: To: Ryan Sleevi Cc: Trans Content-Type: multipart/alternative; boundary=f403045ea68837a4f5054ae1014c Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 22:58:59 -0000 --f403045ea68837a4f5054ae1014c Content-Type: text/plain; charset=UTF-8 Alright, here's some taxonomy: https://docs.google.com/spreadsheets/d/1TS8fgwLrW2js1Q4genXRSzEOOCihw9rJPNq5Zc7a4To/edit?usp=sharing I've binned the issues into a few classes: Editorial, Architecture, Data Model, HTTP API, and TLS Connections. I've filled in estimates of priorities (personal) and effort (in units of code, spec text, WG time). I've also highlighted exactly what the impact would be on any current implementations of 6962-bis as it is. I think this primarily serves to illustrate that the impacts are localized, e.g., to the parsing of specific objects, as opposed to changing the overall pattern of behavior of any of the participants in the protocol. The largest impacts are adding an HTTP request, to fetch an STH or a URL directory. As far as plan of attack, I might propose a two-part plan: 1. The editors and I go ahead and write up PRs for the editorial and data model issues, since these should either be non-controversial or pretty straightforward to come to resolution on. These also constitute the largest text changes, so they'll be good to get out of the way. 2. We discuss the remainder at the IETF meeting and try to agree on direction, then create PRs as necessary to make things concrete and get toward consensus. Melinda: With regard to your questions about what of this needs to be in -bis and what could move to a client behaviors document: If we're going to have a client behavior document, I would propose we delete Section 8.2 entirely in favor of that document (and probably the remainder of Section 8 as well). That section doesn't add much beyond saying "use the mechanisms defined above", and that would resolve the CONN issues in my batch. On Wed, Mar 15, 2017 at 10:48 PM, Ryan Sleevi wrote: > > > On Wed, Mar 15, 2017 at 10:28 PM, Richard Barnes wrote: > >> I think you're over-stating the impacts here. The overall shape of the >> protocol is untouched by these proposals, and many of them are just cleanup >> for a document that's made it through 25 revisions. >> > > https://trac.ietf.org/trac/trans/ticket/162 > https://trac.ietf.org/trac/trans/ticket/170 > https://trac.ietf.org/trac/trans/ticket/171 > https://trac.ietf.org/trac/trans/ticket/174 > https://trac.ietf.org/trac/trans/ticket/176 > https://trac.ietf.org/trac/trans/ticket/185 > > Are all pretty substantially impacting changes. That's just a few I looked > through of which meaningfully change how either a client or server is > designed and implemented. > > I'll use https://trac.ietf.org/trac/trans/ticket/185 as an example, which > I suspect is something you'd consider trivial (but I may have read wrong). > As a client, this forces an additional indirection through a URL lookup > service to take advantage of this. It further forces the need for policy > regarding how such URLs are constructed and advertised - because as we all > know, despite (or because of, depending on your view) RFC 3986, URLs are > far messier in the real world, and untangling that mess just shifts the > problem to policy. It touches on operational issues, such as whether or not > this remains static for the duration of the log or variable. > > I wasn't trying to suggest we shouldn't discuss these, just that I can see > a number of them are, from a client implementor hat, pretty significant, > and some of them are pretty underjustified or undesirable (e.g. > https://trac.ietf.org/trac/trans/ticket/171 ). > > I'll save the substantive comments for the individual discussions, and > greatly appreciate the view to highlight what you believe are most to least > pressing matters to resolve :) > --f403045ea68837a4f5054ae1014c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've binned the issues into a few classes: Edit= orial, Architecture, Data Model, HTTP API, and TLS Connections.=C2=A0 I= 9;ve filled in estimates of priorities (personal) and effort (in units of c= ode, spec text, WG time).

I've also highlighted exactly what the= impact would be on any current implementations of 6962-bis as it is.=C2=A0= I think this primarily serves to illustrate that the impacts are localized= , e.g., to the parsing of specific objects, as opposed to changing the over= all pattern of behavior of any of the participants in the protocol.=C2=A0 T= he largest impacts are adding an HTTP request, to fetch an STH or a URL dir= ectory.

As far as plan of attack, I might propose a two-= part plan:

1. The editors and I go ahead and write up PRs= for the editorial and data model issues, since these should either be non-= controversial or pretty straightforward to come to resolution on.=C2=A0 The= se also constitute the largest text changes, so they'll be good to get = out of the way.

2. We discuss the remainder at the IETF m= eeting and try to agree on direction, then create PRs as necessary to make = things concrete and get toward consensus.

Meli= nda: With regard to your questions about what of this needs to be in -bis and what could move to a client behaviors document: If we're goin= g to have a client behavior document, I would propose we delete Section=20 8.2 entirely in favor of that document (and probably the remainder of=20 Section 8 as well).=C2=A0 That section doesn't add much beyond saying &= quot;use=20 the mechanisms defined above", and that would resolve the CONN issues = in my batch.


On Wed, Mar 15, 2017 at 10:48 PM, Ryan Slee= vi <ryan-ietf@sleevi.com> wrote:


On Wed, Mar 15, 2017 at 10:28 PM, Richard Ba= rnes <= rlb@ipv.sx> wrote:
I think you're= over-stating the impacts here.=C2=A0 The overall shape of the protocol is = untouched by these proposals, and many of them are just cleanup for a docum= ent that's made it through 25 revisions.
=

Are all pretty substantially impacting changes. That'= ;s just a few I looked through of which meaningfully change how either a cl= ient or server is designed and implemented.

I'= ll use=C2=A0https://trac.ietf.org/trac/trans/ticket/185 as an exam= ple, which I suspect is something you'd consider trivial (but I may hav= e read wrong). As a client, this forces an additional indirection through a= URL lookup service to take advantage of this. It further forces the need f= or policy regarding how such URLs are constructed and advertised - because = as we all know, despite (or because of, depending on your view) RFC 3986, U= RLs are far messier in the real world, and untangling that mess just shifts= the problem to policy. It touches on operational issues, such as whether o= r not this remains static for the duration of the log or variable.

I wasn't trying to suggest we shouldn't discuss th= ese, just that I can see a number of them are, from a client implementor ha= t, pretty significant, and some of them are pretty underjustified or undesi= rable (e.g.=C2=A0https://trac.ietf.org/trac/trans/ticket/171 ).

I'll save the substantive comments for the indivi= dual discussions, and greatly appreciate the view to highlight what you bel= ieve are most to least pressing matters to resolve :)

--f403045ea68837a4f5054ae1014c-- From nobody Fri Mar 17 01:54:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC7126BF6; Fri, 17 Mar 2017 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk5aqApHS75Q; Fri, 17 Mar 2017 01:54:47 -0700 (PDT) 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 7F791126B72; Fri, 17 Mar 2017 01:54:46 -0700 (PDT) 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 v2H8sgWZ010061 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 09:54:43 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2H8sdei000524 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 08:54:42 GMT From: Linus Nordberg To: Wei Chuang Cc: trans@ietf.org, dane@ietf.org Organization: Sunet References: Date: Fri, 17 Mar 2017 09:54:46 +0100 In-Reply-To: (Wei Chuang's message of "Thu, 16 Mar 2017 10:09:44 -0700") Message-ID: <878to4qo4p.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; 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: 0aSUUSGCU - 86c8624a5734 - 20170317 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [Trans] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 08:54:51 -0000 Wei Chuang wrote Thu, 16 Mar 2017 10:09:44 -0700: > spoofing the child zone. Is there still interest in this? From the list > archives, I can't see what the issues were though I'm guessing one of them > was respecifying the DS resource record to use a SCT which might have > caused compatibility concerns. (But please correct me if I'm wrong) Other > than that, the draft seems pretty reasonable. Were there other concerns? I'm still interested in logging things DNSSEC. The test log set up at the IETF Berlin hackathon [0] is still running [1]. We lack a client for submission. Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized in [2]. [0] https://lists.sunet.se/pipermail/dnssec-transparency/2016-July/000049.html [1] curl -A "" -x socks4a://127.0.0.1:9050/ -s http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp --8<---------------cut here---------------start------------->8--- { "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=", "timestamp" : 1489739801931, "tree_size" : 1, "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I=" } --8<---------------cut here---------------end--------------->8--- [2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnssec.md;hb=refs/heads/dnssec2 From nobody Fri Mar 17 09:31: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 F21281294F9 for ; Fri, 17 Mar 2017 09:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw9JyUlv2CMR for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB1B1294E8 for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id o24so96723640otb.1 for ; Fri, 17 Mar 2017 09:31:46 -0700 (PDT) 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=fwjvvHkkfDEL6fzbQprx/HD9ekRNpt6e+q/sOvL2Z+M=; b=UiHk7RLxicx8hhLZU7KYWE97UYoP0fX4zFlrth+gkDAGsIX3eRHZomqb5j4OlVVwsA X1X+C+juXqcDHcHhffyOfo79wozb7FzynZTLvBk+fbgn4xr181a2BIdQW011oW05jtuO erK3BLCjKKOSJ5xNqUdNuiQWLFn6gdlN1oTlAWIxCnKN1eyVE1yZBGRG7bmyM4epKDre +ZhOWg1b/wBl5AilgiJ08EMPilhCYbKiyLS4i9kz9oqdAX+wkKiXe0ywo4+1q6cvZ6jt W06OjnbGz/kTxkNjEc37jZseoxd4+FJ2WB0z9LZEejkjsZlUweCpBCV3N9Jm4RmoGDQA DdRw== 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=fwjvvHkkfDEL6fzbQprx/HD9ekRNpt6e+q/sOvL2Z+M=; b=OrqrZmo19z4uEQ+VOqoIYhzzbqOsda2KSw7CbOh4pb0iKYt/rwI+d6ZpI0JWrT+4yI pcFx/N//lisjQzulnLCeAtbKUxlYFMY5RjBvfF/O1C1y5FwvYoLgJSPJCztiz4znEMtD cazWHJni87GEPKzJpRZ2xAtZvq7WLucsqWAKxwb1VL/PAfWWDNgcsK1/wZK8TNNDpMrV Gi1zXEPbLNYgx1P6O2RXyrKiD0DUi1BoCyge59hmhMkuqE3Unt1j4uRY+bNQ0TsgExUB 5V6OW7deeINPTBUR5GSe87UG9WJ7m2bPKwNnXKcfPq7sp3PS4I2andPQuX4g89u21K0U J24w== X-Gm-Message-State: AFeK/H35oD8tF+0gLn3mx5tgX10RzXwdc6aBdL+DwdtYjlqz7fL4+GrcCnieJZo4CZFuX1WRQ4/C0oPGt3OEEXMY X-Received: by 10.202.178.138 with SMTP id b132mr8568195oif.101.1489768305631; Fri, 17 Mar 2017 09:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Fri, 17 Mar 2017 09:31:44 -0700 (PDT) In-Reply-To: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> From: Wei Chuang Date: Fri, 17 Mar 2017 09:31:44 -0700 Message-ID: To: Paul Hoffman Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ce0b0acbcb1054aefb685" Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:31:50 -0000 --001a113ce0b0acbcb1054aefb685 Content-Type: multipart/alternative; boundary=001a113ce0b0a8053e054aefb630 --001a113ce0b0a8053e054aefb630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman wrote: > On 16 Mar 2017, at 10:09, Wei Chuang wrote: > > I saw there was significant interest >> in exploring >> CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec >> was created. >> It seems to have quieted down since. I believe the motivation is still >> there which is to prevent a parent zone from potentially misbehaving and >> spoofing the child zone. Is there still interest in this? From the list >> archives, I can't see what the issues were though I'm guessing one of them >> was respecifying the DS resource record to use a SCT which might have >> caused compatibility concerns. (But please correct me if I'm wrong) >> Other >> than that, the draft seems pretty reasonable. Were there other concerns? >> > > There were two separate issues that got conflated at the time: > > - Seeing evidence that a parent had spoofed DNSSEC keys for a child. A > transcript of the DS records in the parent is sufficient as long as the > child doesn't have relying parties create islands of trust (which is > relatively rare these days). > > - Seeing evidence that a parent had spoofed any resource records for a > child. A transcript of the NS records in the parents is a good start, > although what is really needed is a transcript of everything that is seen > for the child. > Is this because you're worried about the parent removing evidence of DNSSEC for the child in the spoofing scenario? If the parent tries to spoof with DNSSEC for the child I would assume that seeing the DS SCT's in the log, that is sufficient to find evidence of spoofing. That said I think it could be helpful to log NS as well for forensics. One issue with logging all records seen is if webmail providers publish SMIMEA there will be a potentially overwhelming number of records logged, and a very large change rate. Another issue is privacy of such records. > > In both cases, having transcripts from various DNS looking glasses around > the Internet would give greater assurance of the integrity of the > transcript. I agree that would a good idea. -Wei > > --Paul Hoffman > --001a113ce0b0a8053e054aefb630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 16 Mar 2017, at 10:09, Wei Chuang wrote:

I saw there was significant interest
 <http://blog.huque.com/2014/07/dnssec-key-transparency.html> in exploring
CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec
 <https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03> was created.
It seems to have quieted down since.  I believe the motivation is still
there which is to prevent a parent zone from potentially misbehaving and
spoofing the child zone.  Is there still interest in this?  From the list
archives, I can't see what the issues were though I'm guessing one of them
was respecifying the DS resource record to use a SCT which might have
caused compatibility concerns.  (But please correct me if I'm wrong)  Other
than that, the draft seems pretty reasonable.  Were there other concerns?

There were two separate issues that got conflated at the time:

- Seeing evidence that a parent had spoofed DNSSEC keys for a child. A transcript of the DS records in the parent is sufficient as long as the child doesn't have relying parties create islands of trust (which is relatively rare these days).

- Seeing evidence that a parent had spoofed any resource records for a child. A transcript of the NS records in the parents is a good start, although what is really needed is a transcript of everything that is seen for the child.

Is this because you're worried about the parent removing evidence of DNSSEC for the child in the spoofing scenario?  If the parent tries to spoof with DNSSEC for the child I would assume that seeing the DS SCT's in the log, that is sufficient to find evidence of spoofing.  That said I think it could be helpful to log NS as well for forensics.

One issue with logging all records seen is if webmail providers publish SMIMEA there will be a potentially overwhelming number of records logged, and a very large change rate.  Another issue is privacy of such records.  
 

In both cases, having transcripts from various DNS looking glasses around the Internet would give greater assurance of the integrity of the transcript.

I agree that would a good idea.
 
-Wei



--Paul Hoffman

--001a113ce0b0a8053e054aefb630-- --001a113ce0b0acbcb1054aefb685 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAR4jYbMMMNkJ0KKA3HhKv9 D6jGyy8v2ZdiaZ+HCxikIzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTcxNjMxNDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAA4ESZh7svAIaNM/tDxaWIkS1XRKIFPE6Q0QpwxKT PAB+akDdlBgJ30qSCuzZEN6UXxh3HEJqHBCn+Ny5lJdCBHYkqNRNx13SMVjSTo742+CwY4DVifjR U6icUuYvVHUf8DNhxAUOdff4ksZBOokFPFdc+vudRzmdPmlbaqx6PceIwEV0dSLEjDdBDGSLDdg5 9KOHcuiaPUEeNp0xFRWdErDOsYz/OB7NhZjxz5zAN3l1lEiEyx8jhZXHIkBMLXhTYLhSDl6VJhEC ILLOpAbQbP9Hi/YyrdN087Qs9BMhscXTBfh9xTf5ykBKgqZb98T/PEM5eDzAtpa5WmWkwDPUWw== --001a113ce0b0acbcb1054aefb685-- From nobody Fri Mar 17 09:34: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 DF9151294E2 for ; Fri, 17 Mar 2017 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 rXRqSQ8pqiJk for ; Fri, 17 Mar 2017 09:34:41 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 CFC6D1294F8 for ; Fri, 17 Mar 2017 09:34:40 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id o24so96820313otb.1 for ; Fri, 17 Mar 2017 09:34:40 -0700 (PDT) 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=6HA8uKY9qojrfSosrIf6DO1LFxwMhGyUExOrzcEqC5k=; b=eL1wtoEwEFoe95Yk2ZUaEtSmtP5kUcYpISlAXkuJKksoUz0XPc1smhcCLLVbdRoeFK NI1/XbpFB8M+5ygLjyNeofDEwhZEJed/IAewfD4WAjN43h0uiXK6P8HXCrK4Ys+EkOz8 DuB+PQT5qgDuhjyZu+TsFmoF8knIO/VrYd+zdBI35/zJ0QJ0cihiel/GBOrV+xQw6wHH KT0fwvFqWRyVJJC8U1rG+6zF3Zbh/PV72cXVeKVsHUXRlqvQ2XeyHDepU9lQ04frbPOG 0UfamrF2FlBf+adT5tfVVFylHwV/citr5XlmIP+zxHL0dsgOW6xxmt+og3xe8+OdLkEk jDiQ== 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=6HA8uKY9qojrfSosrIf6DO1LFxwMhGyUExOrzcEqC5k=; b=LnMKoz4I9c8rqwSRkc677JT2vZnDcglUgQwWen+7zXXiCv8FEfBmeNRrDCMT1WwLgB F4487eUSe52RMmmNmjrqq15HAelecKjGROW3eAzjSTLLfo6iKtmvyIMY6Ls/GbYC0+nB Odlp5wrcEtlkbKxw/dMsnma+54rmSnh7ZK4UJrHMpaDVeOZXjfrOvFLt5QeCekZyQZdv /k7NjhWADBp7VbtqZk7HBGhQrynaKyji1s1NzDOGov7h8IFFj4tTlLbkMbPbwbL1VQdy ZxdYIQ81OwbYulWT/3qx1XLxrJnGAExDZ+go1JAZFu9IqF8dNdCEBlMm5UemkXoEQXSI ATDA== X-Gm-Message-State: AFeK/H07+k8roqQFnfNLW94VQCRk95BblBbRAi0P7Z2zsTHI/18dgmu2Ty/O0344ETE75bUGv9FoVE2iZVvDSqJN X-Received: by 10.202.0.141 with SMTP id 135mr7488750oia.166.1489768479990; Fri, 17 Mar 2017 09:34:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Fri, 17 Mar 2017 09:34:39 -0700 (PDT) In-Reply-To: <878to4qo4p.fsf@nordberg.se> References: <878to4qo4p.fsf@nordberg.se> From: Wei Chuang Date: Fri, 17 Mar 2017 09:34:39 -0700 Message-ID: To: Linus Nordberg Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1137a09a116d4a054aefc1d5" Archived-At: Subject: Re: [Trans] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 16:34:43 -0000 --001a1137a09a116d4a054aefc1d5 Content-Type: multipart/alternative; boundary=001a1137a09a0cc16d054aefc120 --001a1137a09a0cc16d054aefc120 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 1:54 AM, Linus Nordberg wrote: > Wei Chuang wrote > Thu, 16 Mar 2017 10:09:44 -0700: > > > spoofing the child zone. Is there still interest in this? From the list > > archives, I can't see what the issues were though I'm guessing one of > them > > was respecifying the DS resource record to use a SCT which might have > > caused compatibility concerns. (But please correct me if I'm wrong) > Other > > than that, the draft seems pretty reasonable. Were there other concerns? > > I'm still interested in logging things DNSSEC. The test log set up at > the IETF Berlin hackathon [0] is still running [1]. Oh cool. Taking a look. Did things just pause due to benign neglect? -Wei > We lack a client for > submission. > Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized > in [2]. > > [0] https://lists.sunet.se/pipermail/dnssec-transparency/ > 2016-July/000049.html > [1] curl -A "" -x socks4a://127.0.0.1:9050/ -s > http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp > --8<---------------cut here---------------start------------->8--- > { > "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY > 3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=", > "timestamp" : 1489739801931, > "tree_size" : 1, > "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I=" > } > --8<---------------cut here---------------end--------------->8--- > [2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_ > plain;f=README-dnssec.md;hb=refs/heads/dnssec2 > --001a1137a09a0cc16d054aefc120 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 1:54 AM, Linus Nordberg <linus@sunet.se> wrote:
Wei Chuang <weihaw@google.com> wrote
Thu, 16 Mar 2017 10:09:44 -0700:

> spoofing the child zone.  Is there still interest in this?  From the list
> archives, I can't see what the issues were though I'm guessing one of them
> was respecifying the DS resource record to use a SCT which might have
> caused compatibility concerns.  (But please correct me if I'm wrong)  Other
> than that, the draft seems pretty reasonable.  Were there other concerns?

I'm still interested in logging things DNSSEC. The test log set up at
the IETF Berlin hackathon [0] is still running [1].

Oh cool.  Taking a look.  

Did things just pause due to benign neglect?  

-Wei
 
We lack a client for
submission. 

Protocol deviations from draft-zhang-trans-ct-dnssec-03 are summarized
in [2].

[0] https://lists.sunet.se/pipermail/dnssec-transparency/2016-July/000049.html
[1] curl -A "" -x socks4a://127.0.0.1:9050/ -s http://teowuafdvio2mip5.onion/dt/v1/get-sth | json_pp
--8<---------------cut here---------------start------------->8---
{
   "tree_head_signature" : "BAMARjBEAiA48+vqfg2O3ZbVYvlMxof2dzLwJ09gPtdY3FGtq1LbaAIgXWD4qfCOh38JzCz52E1B1cdkI+8+gHitA1DNMC4Zl2g=",
   "timestamp" : 1489739801931,
   "tree_size" : 1,
   "sha256_root_hash" : "OQFz17e1piHRfRRsAG3QkweRuq/jyrjViq+vZbkyY+I="
}
--8<---------------cut here---------------end--------------->8---
[2] https://git.nordu.net/?p=user/linus/catlfish.git;a=blob_plain;f=README-dnssec.md;hb=refs/heads/dnssec2

--001a1137a09a0cc16d054aefc120-- --001a1137a09a116d4a054aefc1d5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDUIlITEsRov5vDDLGs/myh 8/zkNApTXGMOu23FppAVXjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTcxNjM0NDBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAqfIflXrjEHNg44Sd7jDQ0gNFClq51akofvM/S4nr dDc+yJ8cOPqRUd9ItfTs2MiFaAiriCw+c5ImCqZZbk0ngp1DUGoSDWeA/Wx2hUZYufJTgp43c+Dz o/ukkQtFzIgKvYSjQDz3t9dht34c9zH4iGPwlMisBgXEGTx6lMAHUlm9vN3dil+kLhRBZ17CxBM/ cTeOfuTGvlsR9LkJYsTcaZ2CAtwwgltJvMqCl65tUrnWdkQYccMkL7VQkGqYA8+ZHdfjOGcDbBP2 VDgSkg11B5hqt7oxJ4Q1kFa/N4UBdL7btRrPHoB/GCTiJzMxEUKZF5tDspYUBKodxTYpxETghg== --001a1137a09a116d4a054aefc1d5-- From nobody Fri Mar 17 11:20: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 112D312706D; Fri, 17 Mar 2017 11:20:12 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM9WpxKhWnHW; Fri, 17 Mar 2017 11:20:10 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5E979124D68; Fri, 17 Mar 2017 11:20:10 -0700 (PDT) Received: from [10.32.60.17] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2HIK0uI006297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Mar 2017 11:20:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.17] From: "Paul Hoffman" To: "Wei Chuang" Cc: trans@ietf.org, dane@ietf.org Date: Fri, 17 Mar 2017 11:20:06 -0700 Message-ID: In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:20:12 -0000 On 17 Mar 2017, at 9:31, Wei Chuang wrote: > On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman > wrote: > >> On 16 Mar 2017, at 10:09, Wei Chuang wrote: >> >> I saw there was significant interest >>> in >>> exploring >>> CT for DNSSEC back in 2014 of which a draft >>> draft-zhang-trans-ct-dnssec >>> was >>> created. >>> It seems to have quieted down since. I believe the motivation is >>> still >>> there which is to prevent a parent zone from potentially misbehaving >>> and >>> spoofing the child zone. Is there still interest in this? From the >>> list >>> archives, I can't see what the issues were though I'm guessing one >>> of them >>> was respecifying the DS resource record to use a SCT which might >>> have >>> caused compatibility concerns. (But please correct me if I'm wrong) >>> Other >>> than that, the draft seems pretty reasonable. Were there other >>> concerns? >>> >> >> There were two separate issues that got conflated at the time: >> >> - Seeing evidence that a parent had spoofed DNSSEC keys for a child. >> A >> transcript of the DS records in the parent is sufficient as long as >> the >> child doesn't have relying parties create islands of trust (which is >> relatively rare these days). >> >> - Seeing evidence that a parent had spoofed any resource records for >> a >> child. A transcript of the NS records in the parents is a good start, >> although what is really needed is a transcript of everything that is >> seen >> for the child. >> > > Is this because you're worried about the parent removing evidence of > DNSSEC > for the child in the spoofing scenario? No, this is because the parent can spoof any data for the child. It is unrelated to DNSSEC. > If the parent tries to spoof with > DNSSEC for the child I would assume that seeing the DS SCT's in the > log, > that is sufficient to find evidence of spoofing. That said I think it > could be helpful to log NS as well for forensics. Transcripts are useful even when the logged data is not cryptographic. > One issue with logging all records seen is if webmail providers > publish > SMIMEA there will be a potentially overwhelming number of records > logged, > and a very large change rate. Don't log what you can't log due to scale. > Another issue is privacy of such records. Sure, but there are unpredictable privacy issues with lots of DNS record data. It's not possible for us to predict what will and will not be considered private information now or in the future for anyone other than ourselves. >> In both cases, having transcripts from various DNS looking glasses >> around >> the Internet would give greater assurance of the integrity of the >> transcript. > > > I agree that would a good idea. --Paul Hoffman From nobody Fri Mar 17 11:46: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 BB546129406; Fri, 17 Mar 2017 11:46:33 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsbjOFX-7Ugw; Fri, 17 Mar 2017 11:46:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B217128AB0; Fri, 17 Mar 2017 11:46:32 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 516B17A32F1; Fri, 17 Mar 2017 18:46:31 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 17 Mar 2017 14:46:28 -0400 Cc: IETF DANE Mailinglist Content-Transfer-Encoding: quoted-printable Message-Id: <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 18:46:34 -0000 > On Mar 17, 2017, at 2:20 PM, Paul Hoffman = wrote: >=20 >> Is this because you're worried about the parent removing evidence of = DNSSEC >> for the child in the spoofing scenario? >=20 > No, this is because the parent can spoof any data for the child. It is = unrelated to DNSSEC. With qname minimization, the parent will first need to deny an NS RRset for the child, and those DOE records are better candidates for logging than routine non-NS queries. So logging can be limited to NS/DS queries, but that still leaves us with the problem of how to avoid logging non-existence of NS/DS for all the sundry leaf nodes. The public suffix list might be a useful resource here... --=20 Viktor. From nobody Fri Mar 17 12:20: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 9ACE7129401 for ; Fri, 17 Mar 2017 12:20:52 -0700 (PDT) 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, 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 FhHTfGt_IXU2 for ; Fri, 17 Mar 2017 12:20:50 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 6564C128AB0 for ; Fri, 17 Mar 2017 12:20:50 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id o126so41448513pfb.3 for ; Fri, 17 Mar 2017 12:20:50 -0700 (PDT) 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=S8clYcG7F07bXAukI+Z62dZBvN7u+vV7sBGojMnzZJQ=; b=HjNrQZXVONSjB65HrkuyX6u6JM69wU/tVSJYGeCiakza84ygMb3cri6tVAVtFD9bDt mGmS3rn4cDV4nf8eUFfJrfMoSt7rg42lMIDcdesXASMz7AQYOS7eukI2MIpQl4Vu76E7 phKUTFPXauKROw9d70+SfBGBWrwqnF0gAu8bXEdHW0xMwZW/AHEeDHbYAnTrn6V2dmP6 G0Lz8jyAp2igNEeDRoTfpgn0T3zGEU74UeH/D0ICnKHLXbUgm08d3II0qR0DeHx4f9Y+ qXVgcyaD6zW5g+ObdkOqUMBiEO/iORXE1B0ggO+dopMvuhus8Zsh3GVikJCX0fOf0jjm KVEQ== 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=S8clYcG7F07bXAukI+Z62dZBvN7u+vV7sBGojMnzZJQ=; b=rPj6gduVDfWPVkzNd1ux96QBz4MwlO/l77Ihn6PXZ/hNJv09viWN0g76kOH2aMjj4D yNSYzdFNcU3a+QVUovduDfqVgCvFNvUfFLN4vAccOvkGGSVhmTvbBi6JBbGknNrK9Ba2 t4JVzL/xorMQ0KxrsFvuYjFlsWCcvyeFfAU77zpC6qtOhT9qDcQh+WGgMlWOvASGYRio Mdo7B+MRp3QuqZfhPeKtRjO1NZgJ3fg5D8s51JA+Rn7OZ2+l+FMILF3uTN/pqAciZnfw dh271xKtk7t9UN00JdPwBPqT2cL0SshWkX1rg9HcSdkTfoA4mz/vZjmzOno3GbKsVfdU FOSA== X-Gm-Message-State: AFeK/H30mrEamdPwpDq64gpLXCBxG2EcTeqx4jNnaY2aKADsaI3K76WASPQkbxTJzgNyQQ== X-Received: by 10.98.252.211 with SMTP id e202mr18792869pfh.118.1489778449404; Fri, 17 Mar 2017 12:20:49 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-123-15-radius.dynamic.acsalaska.net. [216.67.123.15]) by smtp.gmail.com with ESMTPSA id t70sm18078535pfe.64.2017.03.17.12.20.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 12:20:48 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: <5b559a18-853a-b5d3-2500-0ceb720cbc6a@gmail.com> Date: Fri, 17 Mar 2017 11:20:45 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aNfEdReC009VWB1vFqng1vmOFbP46udVt" Archived-At: Subject: Re: [Trans] Fresh issues! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:20:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aNfEdReC009VWB1vFqng1vmOFbP46udVt Content-Type: multipart/mixed; boundary="hb5ViUpwxta2E3E3stNq5UgRLrQcLHDvL"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <5b559a18-853a-b5d3-2500-0ceb720cbc6a@gmail.com> Subject: Re: [Trans] Fresh issues! References: In-Reply-To: --hb5ViUpwxta2E3E3stNq5UgRLrQcLHDvL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/16/17 2:58 PM, Richard Barnes wrote: > Melinda: With regard to your questions about what of this needs to be i= n > -bis and what could move to a client behaviors document: If we're going= > to have a client behavior document, I would propose we delete Section > 8.2 entirely in favor of that document (and probably the remainder of > Section 8 as well). That section doesn't add much beyond saying "use > the mechanisms defined above", and that would resolve the CONN issues i= n > my batch. Okay, we'll try to get a sense of how much agreement there would be to doing so. The two-part bottleneck on any of this is whether or not there's consensus that we need a client behavior draft and whether or not we've got editors who are on top of client issues. Also, to reiterate a general principle in this working group, our expectation is that 6962-bis does not have to be complete but it does have to be correct. Melinda --hb5ViUpwxta2E3E3stNq5UgRLrQcLHDvL-- --aNfEdReC009VWB1vFqng1vmOFbP46udVt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYzDcOAAoJELiGRpM6HoEuFqYP/jUemd4Yg13J+IJaAZ+nQgSH O4S7j0oCbb3XELsejnqoHObZ04T4+0ZECiPUOvFRn4YNC9/H1t20NF4c5c9tUnZr /NMADZjB2wTPVkfLqsF4/Fn2WornFyyv/vkDdtRFcJgVfLcCwjvUCi9luQLBaJ85 vvoTdOh418hY3dJLI2W6aO5a74AaNHbTxdjc59ZxgJ2QXNd7h/0xji4PyPV3sUke x9RtG9KTFcwsjHWTTmOfJFfRYhextiicWb+EwqSC3Gq62DDTPZCpi3ypMD/1oA2Q FD6yr5fstXN5NR56vhzY87s8CXXs6QVgK3peUtZIPpm+JHfaWMZMnMoHyV/Ro6Vw Rj95ElQJ7AVPGhABhZKwQbjxO5Ha9Fau96xs7DKW2AduXdrl6PmPSKI92HYOE/CP iUzFZ4U0s99BTcqglS0WevbE09PI2W7ATXRdJmys6VJOwZeVBDgBXPylaTQ57Dek T/iLHJgqUSpzWhOoiYJmRSSe+RY+6qcKBzWk4Jg7xysJslzWtjxYMtkExPHVU8kf 0USj4urHMjhrwyWHfAcosY40JU1C3bFBpdLI/acm8VSPlsyKxJjiWFAv0mvRgove BUQFYc6rB1aPBz0D3SkyrxuISGnqxXTd8HXIdXZB5Dk6Rs9WK2koKiOhrhxAfehe v/haXhchmAkxlgOjbMQu =Liq6 -----END PGP SIGNATURE----- --aNfEdReC009VWB1vFqng1vmOFbP46udVt-- From nobody Sat Mar 18 15:36: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 79816129447 for ; Sat, 18 Mar 2017 15:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPhtNnzF-gwe for ; Sat, 18 Mar 2017 15:36:16 -0700 (PDT) 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 E3DAF126B7F for ; Sat, 18 Mar 2017 15:36:14 -0700 (PDT) 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 v2IMaA5Y013908 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Mar 2017 23:36:10 +0100 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8::129]) (authenticated bits=0) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id v2IMa5jf020542 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Mar 2017 22:36:10 GMT From: Linus Nordberg To: Wei Chuang Cc: trans@ietf.org Organization: Sunet References: <878to4qo4p.fsf@nordberg.se> Date: Sat, 18 Mar 2017 23:36:15 +0100 In-Reply-To: (Wei Chuang's message of "Fri, 17 Mar 2017 09:34:39 -0700") Message-ID: <87efxumcv4.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 X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-nordu-net:default, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=2001:6b0:8::129; 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: 0aSVyAaJ1 - fd5fe1cd8569 - 20170318 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 2001:6b0:8::129 is neither permitted nor denied by domain linus@sunet.se) receiver=e-mailfilter02.sunet.se; client-ip=2001:6b0:8::129; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: Re: [Trans] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 18 Mar 2017 22:36:19 -0000 Wei Chuang wrote Fri, 17 Mar 2017 09:34:39 -0700: > Did things just pause due to benign neglect? After consulting the database on the matter of what "benign neglect" means I think that I'll have to answer no. There was a lunch meeting in Yokohama where a number of people expressed interest in an experiment with logging DS records in the root and one or two more TLD's. A log was implemented [0] with great support from Willem Toorop of getdns. A standalone client was developed but never got published. What's lacking for the experiment is a client and a couple of operators of if. [0] https://git.nordu.net/?p=user/linus/catlfish.git;a=tree;h=refs/heads/dnssec2;hb=refs/heads/dnssec2 From nobody Mon Mar 20 07:51: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 334AD127058 for ; Mon, 20 Mar 2017 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUVBxCOuphQq for ; Mon, 20 Mar 2017 07:51:44 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 28D7312947B for ; Mon, 20 Mar 2017 07:51:43 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y18so36484548itc.0 for ; Mon, 20 Mar 2017 07:51:43 -0700 (PDT) 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=o6Qr/1x7p6JMxFvmKIvAxPiN7MaWPTISnk1wYPhw/jc=; b=t4sUm5X6b5x6c1h4lvLU5tuHO/RIffOjX3sgwR91PKX8AA9O33MnwiTHn548r5+8bc uAVYU+lFqUHO9fZ7/VJ4HkQQmzL/lQXiRMZJNSc2Lbcqzy2iaOejJGnfA7vvg3AZSPgo ZWoJ4ViTXzjIjlAMVTPffC6W409JeBEt0aWGK/61ous8PSHS3++Ym4LB75b1K2Hlwogq 7iT+zOKFBDp6ZMm5t7HErA/g8T1BED5OwIDqTlElMX9NwizxEMR61Cl+i+VTl6wcIAGN Vk0Ndr17MgYas7Xsmcw3RAEms9pUOnh3pYSQ1MsM20ySyPYeddqSoiWqB7Z2gFJ5Spsb 926g== 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=o6Qr/1x7p6JMxFvmKIvAxPiN7MaWPTISnk1wYPhw/jc=; b=NNtGwU1YeN+8sPiX4eiIZcqXOGO1jjO3qSDCYofzAFUJp/010+hJTt5CvC2BBHnH+N 1BVA7oxBX1+b0JMbH9PpqTvXbu6VFArPgTs9s0xb49Gz3RKkJ/4XiZ0CgO3j+Wn2pODw O8YUWU3tRCjHS0u3U6lJZUN4+8oa/V7NrIXdY+GIygJ4YRTYJUS6/7AbjhR7DD8oeNf7 f2YIPxYq30mqucJSzybPLcpmv6OVc6tkoc/TL8iPtq0Ye00t5W/D/8LrHA9Eba0976WM iICqae+iNKgsdHNTu/R97x6dd8HRLGVuAlRcLW57/WU9DCO55viQpopAOUZom6sWKvZu Oo3g== X-Gm-Message-State: AFeK/H0DJAEnX1z8OHatITpmdctL8RxeHFmaZs0hLTilo2tca7/zc9Y5dIdpV1COmH0nnl0f7GW9Q7Y6zb0uuKMN X-Received: by 10.107.85.2 with SMTP id j2mr32639714iob.165.1490021459535; Mon, 20 Mar 2017 07:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Mon, 20 Mar 2017 07:50:29 -0700 (PDT) In-Reply-To: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> References: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> From: Eran Messeri Date: Mon, 20 Mar 2017 14:50:29 +0000 Message-ID: To: Melinda Shore Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1c5f80ce6c4b054b2aa795 Archived-At: Subject: Re: [Trans] RFC 7320 and draft-ietf-trans-rfc6962-bis-24 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 14:51:46 -0000 --94eb2c1c5f80ce6c4b054b2aa795 Content-Type: text/plain; charset=UTF-8 FYI this has been documented in https://trac.ietf.org/trac/trans/ticket/185. On Wed, Mar 15, 2017 at 8:46 PM, Melinda Shore wrote: > On 3/15/17 12:29 PM, Martin Thomson wrote: > > I am not following this work, but this and the original RFC 6962 both > > run afoul of the (good) guidance in RFC 7320. > > > > Has the working group solicited feedback from the HTTP community on > > the use of HTTP in this protocol? > > No, we haven't. > > For what it's worth, 6962 reflects implementation and > deployment prior to CT having been brought to the IETF > for standardization, so any concerns regarding URL > syntax or HTTP transport in the work being done by this > working group are necessarily limited to the -bis and > related documents. > > To be honest, I'm personally not convinced of the applicability > of 7320 in this case but if there's a specific problem it does > need to be discussed. > > Melinda > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c1c5f80ce6c4b054b2aa795 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI this has been documented in=C2=A0https://trac.ietf.org/trac/trans/ticket/= 185.

On = Wed, Mar 15, 2017 at 8:46 PM, Melinda Shore <melinda.shore@gmail.c= om> wrote:
On 3/15/17 12:29 PM, Martin Thomson wrote:
> I am not following this work, but this and the original RFC 6962 both<= br> > run afoul of the (good) guidance in RFC 7320.
>
> Has the working group solicited feedback from the HTTP community on > the use of HTTP in this protocol?

No, we haven't.

For what it's worth, 6962 reflects implementation and
deployment prior to CT having been brought to the IETF
for standardization, so any concerns regarding URL
syntax or HTTP transport in the work being done by this
working group are necessarily limited to the -bis and
related documents.

To be honest, I'm personally not convinced of the applicability
of 7320 in this case but if there's a specific problem it does
need to be discussed.

Melinda


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


--94eb2c1c5f80ce6c4b054b2aa795-- From nobody Mon Mar 20 15:38: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 7E7CD129406 for ; Mon, 20 Mar 2017 15:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgR1rAqhuEbP for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F591293FF for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id a12so72128226ota.0 for ; Mon, 20 Mar 2017 15:38:50 -0700 (PDT) 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=vav3XesZgE+3rd2Dz9pviQASIH/bUQ+0McfTx3Zv7sw=; b=W7KUmOuaGAs4VEUS5JXmhRXY0xTaIY9NpZ07BZwDN7A0NWjRa+sk7oNGq8kMm0ZmQj 0Ey07tQS1XLTTEOvlJI5Zh4oS0sAvU2w/5Al4Oe2IFeScJbSNktt0TbKJaPopsAxwJUx MKoabJMWicKy25KYJmwOVCQ0tvtt44U4GiDhN/26hIvxnX50jAp5Om/DYMnz/dIIFlgJ rR9b7UzDoLgVpQyBAKB9s1eYBPIW4UfieQKcpSeX3ET+kql7fB/vgXQAbSntVFQrWocT 7LmJ6Zt83qgwJQWv25msO2jKvGFRaFA9+CobzR1MM6QfYjUYHaVUKYQy77Kbxbogt5p8 +6dw== 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=vav3XesZgE+3rd2Dz9pviQASIH/bUQ+0McfTx3Zv7sw=; b=axB9x+1cbTKaQBIg9qemUIG5DtXzmLLqpZ1QouL839d9u33vQ01mZDMEsLzOyhCDVT AMsT18eTEVa6b/akGEdo87Ak/a9l08GgbIVvNlYAi6RDkfOH7BSDqpetnZwPt+RxHEkk ZksDItGQ+kM0XqkHRdDAaRtMgV/l1BTak93mePq5J2KPGL9fPaD/XU5STnotTF/VBdW4 zC/rVPpXxejTbX7/S/ohKZQsN/2wZetcHFZbt0iPMYEVxPFH66AEJitH0mdcmFCuovWq xh7fvdv4S58hwvq8CiV4SCrvx5udWP3vQ/ytOnN9+DolqDhh3CjkX4mfhgVEYTGuLyDb ttmg== X-Gm-Message-State: AFeK/H3y07MkexYbCp0cN6Ni0Nmc/G0agWblWnOVgmkQx5lM3fxoCyeWXKQK+pY/LKcfkPliqxvUDdYY4vgGhfLX X-Received: by 10.157.56.61 with SMTP id i58mr14948959otc.247.1490049529815; Mon, 20 Mar 2017 15:38:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Mon, 20 Mar 2017 15:38:49 -0700 (PDT) In-Reply-To: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> From: Wei Chuang Date: Mon, 20 Mar 2017 15:38:49 -0700 Message-ID: To: Paul Hoffman Cc: trans@ietf.org, dane@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113be8f6f08801054b313015" Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 22:38:52 -0000 --001a113be8f6f08801054b313015 Content-Type: multipart/alternative; boundary=001a113be8f6ec7bb7054b313032 --001a113be8f6ec7bb7054b313032 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 11:20 AM, Paul Hoffman wrote: > On 17 Mar 2017, at 9:31, Wei Chuang wrote: > One issue with logging all records seen is if webmail providers publish >> SMIMEA there will be a potentially overwhelming number of records logged, >> and a very large change rate. >> > > Don't log what you can't log due to scale. Just a note of caution: Sometimes that might be hard to determine a priori deployment, and then the cause of cessation of logging might be inadvertently interpreted as malicious. It might be best to statically define which records are expected to be logged. > > Another issue is privacy of such records. >> > > Sure, but there are unpredictable privacy issues with lots of DNS record > data. It's not possible for us to predict what will and will not be > considered private information now or in the future for anyone other than > ourselves. Logging may defeat the privacy mechanism that SMIMEA and OPENPGPKEY naming scheme uses to prevent bulk disclosure of keys i.e. sec 7.4 in RFC7929. Much depends on the log implementation though. -Wei --001a113be8f6ec7bb7054b313032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 11:20 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 17 Mar 2017, at 9:31, Wei Chuang wrote:
One issue with logging all records seen is if webmail providers publish
SMIMEA there will be a potentially overwhelming number of records logged,
and a very large change rate.

 Don't log what you can't log due to scale.

Just a note of caution: Sometimes that might be hard to determine a priori deployment, and then the cause of cessation of logging might be inadvertently interpreted as malicious.  It might be best to statically define which records are expected to be logged.
 

Another issue is privacy of such records.

 Sure, but there are unpredictable privacy issues with lots of DNS record data. It's not possible for us to predict what will and will not be considered private information now or in the future for anyone other than ourselves.

Logging may defeat the privacy mechanism that SMIMEA and OPENPGPKEY naming scheme uses to prevent bulk disclosure of keys i.e. sec 7.4 in RFC7929.  Much depends on the log implementation though.

-Wei
 
--001a113be8f6ec7bb7054b313032-- --001a113be8f6f08801054b313015 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCpyfftbQhDa4oWWIvlnGt4 6KSQXqnbCjUmo/smSFGhsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjAyMjM4NTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQDDR9oXjtB7E/h2Ow1b9jrqocC3T+s4XpiWv+DqK ZAe1zDyqDeJTiNtGFyWOLuzXfSpsLlDKVS96k02pNs7CVkoQjwEMK+RcfLcFFXVIr9Pbva68I996 PJJ0a0RhRozCvlfmwwsOVZa5VIg+ZK+PpNVPymgxAWy33hvrOKkrC/96UCpvdx0iHQA7Kil7iKz8 9vqvaqBsmQQDrq/LwCGRfm6kPruwHuZKD31LsTHxnqfvnrKPVHpNBNcD0abP9dyBiIjbgdS2MzYw b3TwV6DCd76/LM0e35AdhHy84nRPBDtBBoPsHodLLpg+JG1BuCVfvOmOnUODCccLDXeW4Jmt+w== --001a113be8f6f08801054b313015-- From nobody Mon Mar 20 15:43: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 121761270AC for ; Mon, 20 Mar 2017 15:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msLKbAiObP2O for ; Mon, 20 Mar 2017 15:43:24 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFD01293FF for ; Mon, 20 Mar 2017 15:43:22 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id o24so141487757otb.1 for ; Mon, 20 Mar 2017 15:43:22 -0700 (PDT) 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=CO9gwViy4FGBFaS9nBgde26mTFXdve3d2ywBfYMtItU=; b=fHelsQj+Nl8QeHZN6Tp6WxYj6f/bigxorrIcqyt5kPqjObo04//oW4dvrmmvqHtXL1 X2uu1B5Pgn3L8uiv27wUn99Ee2SiVwmsSuh8w/fnPuznrWT24R3HbJjaeTdlKlYpv1LF 3SMKuJQSYw85y85+MjmfiPriWICt6wpkIgPDss2JaeQAud/6pqaf+e7gVa7MZIHUXrPR bRKKOJ/phuEcfsAa0bbT/e0MZuFuOd6zKdB+Cc9KdvXVrUeVQUZ5vOfq3dMaiRXfh9MF OxF7WHbEVOEfllGVw46pqvUHD6/pvCd/LjndUchUCKdIWXqC4mnpnpEiDcWIfGH78eVT QbOQ== 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=CO9gwViy4FGBFaS9nBgde26mTFXdve3d2ywBfYMtItU=; b=KTIxb6OVLv8+suh6lfaWy6ctuCldkWVynul5aj1IEOcAR7zkwEUwTNQetRMNEdufz8 uifz/aeVEjs2QMH925OrQ76vOnIekOo3c8WwSL7tZJWwuT2PPYEJp1aXBM9H9TZPWbuE YMFWw/W64OWRPVs93lKFRZdMlqarY2mmXFOr9W2/PZrQnR9yHcrccoUdk/q9vCbR5KxA x04qNUjyaEGrQyqjkUvDZHU1ylKw4uHel2J8lggl66jgLEYwgZlxQ3rPVaOb0szw/EmC hf8NfAS/w6ceoKxi7O+0Lhysk+0hLvt9CyaoSIR/zzhUM0x0yTPYJVHnZCLbATuMl4Tg 0QWA== X-Gm-Message-State: AFeK/H3xuwi1mZ5q92YX3U1jKwUgNa6kek+hXdtGmn1XAbi6BrUmIOBzs+RezKHqNjlYCKKPECHpZW9eCAG91OrO X-Received: by 10.157.15.147 with SMTP id d19mr14923765otd.233.1490049801694; Mon, 20 Mar 2017 15:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Mon, 20 Mar 2017 15:43:20 -0700 (PDT) In-Reply-To: <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> From: Wei Chuang Date: Mon, 20 Mar 2017 15:43:20 -0700 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113d196a24725e054b314145" Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 22:43:26 -0000 --001a113d196a24725e054b314145 Content-Type: multipart/alternative; boundary=001a113d196a20fbbc054b3141b5 --001a113d196a20fbbc054b3141b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Mar 17, 2017 at 11:46 AM, Viktor Dukhovni wrote: > > > On Mar 17, 2017, at 2:20 PM, Paul Hoffman wrote: > > > >> Is this because you're worried about the parent removing evidence of > DNSSEC > >> for the child in the spoofing scenario? > > > > No, this is because the parent can spoof any data for the child. It is > unrelated to DNSSEC. > > With qname minimization, the parent will first need to deny an NS > RRset for the child, and those DOE records are better candidates > for logging than routine non-NS queries. Can you expand on how the the DOE record (which I assumes means denial-of-existance) could work with an adversarial parent? The only approach I can think of is some sort of UI support which isn't very compelling. (Perhaps monitors but alas I not really up-to-date where things are at with monitors and gossip) > So logging can be limited > to NS/DS queries, but that still leaves us with the problem of how > to avoid logging non-existence of NS/DS for all the sundry leaf > nodes. The public suffix list might be a useful resource here... > I agree. -Wei > > -- > Viktor. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113d196a20fbbc054b3141b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Fri, Mar 17, 2017 at 11:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Mar 17, 2017, at 2:20 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
>> Is this because you're worried about the parent removing evidence of DNSSEC
>> for the child in the spoofing scenario?
>
> No, this is because the parent can spoof any data for the child. It is unrelated to DNSSEC.

With qname minimization, the parent will first need to deny an NS
RRset for the child, and those DOE records are better candidates
for logging than routine non-NS queries.

Can you expand on how the the DOE record (which I assumes means denial-of-existance) could work with an
adversarial parent?

The only approach I can think of is some sort of UI support which isn't very compelling.  (Perhaps monitors
but alas I not really up-to-date where things are at with monitors and gossip)
 
  So logging can be limited
to NS/DS queries, but that still leaves us with the problem of how
to avoid logging non-existence of NS/DS for all the sundry leaf
nodes. The public suffix list might be a useful resource here...

I agree.

-Wei
 

--
        Viktor.

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

--001a113d196a20fbbc054b3141b5-- --001a113d196a24725e054b314145 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBiv5w2bo+hjqTbVErfHTBD L6oUGk4Vdrf5IU1TX3QKvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjAyMjQzMjFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAPKCh3tsXo5rD3qcz3t2NSEeQldXvGiHBiSQsGWmS PfbdzpKoao2B5BxLf2cXih71G7v09xg8Ai4iaGc4E9cIkb/AHVj5DOsVYFadBea2HRuw/WVAAeQ+ bdzhzkbygvNTy1TxP0UpKHmlwXbEmTJ2Sd92rjdt1y7neT1Dbm9xXRF/jYUA/R5Rc1h/bFd/Fpzb naIAvBCoEcSKpoVRnxmpxHJAPKVuJgPPodxvJXIv2RwW4ODjoITOkPflNjFWU62Pbh6GotIJIla6 D2C9aWjofzgqjRPhPZHn8e5sV8xYohAFyxRWmrgi7ad26GT5marjTW8AHMB1euvpBBFP/1TXRw== --001a113d196a24725e054b314145-- From nobody Mon Mar 20 16:01: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 80387127077; Mon, 20 Mar 2017 16:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wXIy7ARaWSY9; Mon, 20 Mar 2017 16:00:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40F6126D85; Mon, 20 Mar 2017 16:00:58 -0700 (PDT) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id BD8047A32F1; Mon, 20 Mar 2017 23:00:57 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 20 Mar 2017 19:00:56 -0400 Cc: IETF DANE Mailinglist Content-Transfer-Encoding: 7bit Message-Id: <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 23:01:00 -0000 > On Mar 20, 2017, at 6:43 PM, Wei Chuang wrote: > >>> No, this is because the parent can spoof any data for the child. >>> It is unrelated to DNSSEC. >> >> With qname minimization, the parent will first need to deny an NS >> RRset for the child, and those DOE records are better candidates >> for logging than routine non-NS queries. > > Can you expand on how the the DOE record (which I assumes means > denial-of-existence) could work with an adversarial parent? Yes, DOE is denial of existence. When the child sends NS queries as part of qname minimization a negative response (no NS records) will include signed NSEC(3) records to that effect, signed by the parent zone. These are candidates for logging. An insecure positive response will include NSEC(3) records proving the non-existence of the DS RRset (possibly via the opt-out flag). These can also be logged. A secure positive response, can also be logged, and the follow-up query for any associated DS records will again either yields an answer that can be logged, or DOE that can be logged. The key question is how to avoid logging ridiculous volumes of data that can DoS any log service and also disclose too much. Hence the suggestion to consider using the PSL as a cut-off mechanism. One would also not log NXDOMAIN responses to NS, which might allow parent domains to lie about non-existence, but is surely necessary to guard against filling logs with junk. There are likely many issues this fails to consider, but I think that's a reasonable starting point to explore further. -- Viktor. From nobody Tue Mar 21 08:02: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 AC7051299ED for ; Tue, 21 Mar 2017 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 fr-uFuFu08RW for ; Tue, 21 Mar 2017 08:02:54 -0700 (PDT) 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 0AD971299D6 for ; Tue, 21 Mar 2017 08:02:54 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vnbf42mXRz3JZ; Tue, 21 Mar 2017 16:02:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490108572; bh=WTq3yXzH756+iJQMdnN0Xxnq1t6Kg8/i5gQtAm8X0pI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ahIhvvlVNQkUmTPYi/IQzsNG5vbLvaFmNXUXkcqkyWEcXh6tJtrFc3Fh9kpks9yLv xK2VGnCtl7gUnfhk7AJ0BbMrS4IkB7u/XGU2bDEzwNfQC8iNQyFCeFyfahfpcqnB6M OU5QuCA5LjYD4/hWPSu++ozc6PIZWFsg61uqDZ6g= 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 cM3JIfnmHjjw; Tue, 21 Mar 2017 16:02:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 21 Mar 2017 16:02:46 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F1495353868; Tue, 21 Mar 2017 11:02:45 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F1495353868 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E96134073521; Tue, 21 Mar 2017 11:02:45 -0400 (EDT) Date: Tue, 21 Mar 2017 11:02:45 -0400 (EDT) From: Paul Wouters To: Wei Chuang cc: Linus Nordberg , Trans In-Reply-To: Message-ID: References: <878to4qo4p.fsf@nordberg.se> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Trans] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 15:02:56 -0000 On Fri, 17 Mar 2017, Wei Chuang wrote: > Did things just pause due to benign neglect?   Yes Paul From nobody Wed Mar 22 12:31: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 54E6C129BCF for ; Wed, 22 Mar 2017 12:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Zop6CGXGDm for ; Wed, 22 Mar 2017 12:31:50 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (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 3F793126BF6 for ; Wed, 22 Mar 2017 12:31:50 -0700 (PDT) Received: from asbsmtmtaapi01.symc.symantec.com (asb1-f5-symc-ext-prd-snat7.net.symantec.com [10.90.75.7]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 3A.1F.37454.521D2D85; Wed, 22 Mar 2017 19:31:49 +0000 (GMT) X-AuditID: 0a5af81a-8fa559a00000924e-8a-58d2d12576cd Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat3.net.symantec.com [10.90.75.3]) by asbsmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 05.59.04315.321D2D85; Wed, 22 Mar 2017 19:31:49 +0000 (GMT) Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 22 Mar 2017 12:31:46 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.128.7) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 22 Mar 2017 12:31:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yUQX4RGyuCXve1yvL/yk60n+r2XChyKu5eSGnULY0G4=; b=Xs5PAPujLn/fT1W2pFUUrGycc4roWl1vdxTU4GZ9gNiqWXEARBrCl1AVoy6Mdicctfx1P8smWxiNm2EQ5zyyuQwalT7LJhgYOhAJ9N2UuYmPwFEPXwGoKO0n7aUGd9wLR5FI8GiC4x+9UvX2Relwpqf3U2f89nVL42ehvxEYm2w= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0900.namprd16.prod.outlook.com (10.165.81.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 19:31:44 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0977.020; Wed, 22 Mar 2017 19:31:43 +0000 From: Tarah Wheeler To: "trans@ietf.org" Thread-Topic: Proposal to modularize pre certificate transformation Thread-Index: AQHSo0LvLcFxGd4fV0CeqEQxJK1Smg== Date: Wed, 22 Mar 2017 19:31:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [155.64.38.27] x-microsoft-exchange-diagnostics: 1; BN3PR16MB0900; 7:4uw9QsVKfns4tJPj3ZqCcF16cCTvIgQOUr+pDprS/mg41l72Ua80LdOMxfWRLqzs9SgYSVhtex4QNMGEZ4UWbRBvGMvtlg5RRtGkN6CXBoQZzebBMnT3JKQfDItcZ2RA5fazDb+4MmmHi6OEBcQPWxMAWEbuJvc6w24ZSy7wb8fPPd27vievEst+oeuS7ogoNAwaHAmS8f5n1cPHEq1eQsS0+yPaefkhT8x2ML28y6hISoM6UtCfB3n5E8tzJI6nDJ+qt2S0eQFOCcgbN9IjbXYVt/vOGHQZMbA3uqFqpWjeUkPtAcVIkO2O+ZCqPn9ZqylhkMSDli5sYK0ndhrlhg== x-ms-office365-filtering-correlation-id: f6ffefca-1734-4610-2567-08d4715a1288 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BN3PR16MB0900; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(164924216521020); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR16MB0900; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0900; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(40134004)(85714005)(110136004)(54356999)(189998001)(38730400002)(7736002)(6116002)(102836003)(3846002)(122556002)(6486002)(575784001)(606005)(77096006)(6436002)(99936001)(6916009)(3280700002)(2900100001)(551944002)(7906003)(6506006)(733005)(2906002)(86362001)(66066001)(5640700003)(1730700003)(50986999)(5890100001)(81166006)(53936002)(6306002)(10290500002)(236005)(83506001)(2501003)(19618635001)(861006)(36756003)(99286003)(3660700001)(5660300001)(6512007)(8936002)(80792005)(54896002)(54556002)(4001350100001)(8676002)(25786009)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR16MB0900; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_D4F8495D4F2Dtarahwheelersymanteccom_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 19:31:43.5648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0900 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnk+LIzCtJLcpLzFFi42LhivJm11W9eCnC4NtsCYu1jy+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr48rlbawFW/4zViw/ENfA+P4BYxcjJ4eEgInEhS/vmbsYuTiE BD4ySpzqeMcCk5i3YBYrROIbo8TTzp+MEM5RIOfpGqjMS0aJ9v0nWUAcFoFOZokDHy9ADZvG JHG06SRU2TFGiZdP1jF1MXJwsAkYSHy8EQWyRERAVeLz/RYmEFtYwE5i2Y5t7BBxZ4nGFysZ IWw9icO3J4PFWYDqr/atAYvzCphJzDv/GizOKCAm8f3UGrA5zALiEreezGeCeEJE4uHF02wQ tqjEy8f/WEFsUaCZ+/59ZQO5jVGgm1Fi65790ODQkTh7/QmUrSBxc2YL2DcSAj3MEh+mLWYE eUBCwFfi2T5eiJoYiY8bDzND2NkS255/hYZerMT0e9NZIXqXMkmsPfUGaqiMxO0ZHVCJ56wS B3ZNZ5rAqDMLyeUQdrnEq9UzWGaBfSoocXLmExaIeLTE+UlrGSFsHYkFuz+xQdjaEssWvmaG sc8ceAw1x0Ni/49GVkw13hJb+s+xQ9gOEhO6vwHN5AKygTE1s38aVLORxI5HX6AWK0pM6X7I voCRbxWjQmJxUnFuSX5pSWJBqoGRXnFlbjKISAQmzGS95PzcTYzgpPlDagfjkzs+hxgFOBiV eHhVj16KEGJNLAOqPMSoAjTy0YbVFxilWPLy81KVRHhzzwCleVMSK6tSi/Lji0pzUosPMUpz sCiJ807MuRAhJJCeWJKanZpakFoEk2Xi4JRqYORbN49X5L0ng+ScpYdeTONtVnq0R84hb/8C OzE3+UsT1wdVJ1kxTZq8v0u88Piv5szynWK2N4yUCl35Tx5cd3qSj/zkd+s+s/icLck3fXa3 QKzsxfpkRsdXlwqCj3lwaEyL62+N/dUX+0Bz5yr3TeXX384TieaX1O6czvJnZpfkmugD1j5H TyuxFGckGmoxFxUnAgC43EYBogMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfUhTURjGObv3btdLy9vy49UM/EDQMp0hYlAiRDFRIYRiaJk3vaToTDaz rH80xNJFmoVTCZtohqWZpiJ96FC0ZpofaZkflTnbTKHWUpNM23ZvEPTP5fc+73Pec55zD4lJ jIQ7mZqRxSozmHRvIYVTcVHYHt+RUbl0YFoQ1jg3gkcgWW3tmuAIiqP2J7PpqdmsMig8kUoZ e91OZLZuovN3dQm56OtHVIQcSKBDoEpbSRQhipTQKwjmC9cQV/Rai/kGvrOA4HKXHrcVOF2I gc48jHGdMgH0XtLztj4EC4YHgiJEkkJaCuaJONsmTrQvWD7kC2y8nQ6Huo52EacfhDxTPeI4 EHqmbth13Oofv9Zg18V0KFQNLdp1RLvAan+DfQ5Gu8Kk4baAC+EEsyMvhRw7w8LcBmFjZ+vM zo1loe1siFYjaHvaxacOgMG3Bp494V1Fvj0N0Fcx+FZWg2wBgI6Bz51iznMczM09GMdp0G5c xjk+AZr3GoJbe0cAjf1L/FAPmCq/wjeMBOgea/j47jAzVog49gDT9DOiBPlV/pOI43Pw5X45 Xmm/gW2grzDgnB4PQ6WNiOMA0D75LuR4N9RVL2J/eUA3x8+RQdfPPOJ/TxS0Fr8ScRwBJeoV 60zKytY/WFFcxi/eCx2ffvAbe8FN9axIi7beQ56M6pRKkaXIYpjMVGlwoCpHkWT7MNZ3mRSY dEbRguwv85dLB9KtR3cjmkTeW8Ty56NyCcFkW53daAeJe7uKJ4Jb5BL6NJPFprFsJqs8qTyb zqq6kYB0cM9FtW5psrWmA0svtI5NOfFRg9FeLtLJhwV4glloerRanqxsS9msvhV0yKSrx4W5 TTK5/3qNus7f4oSuL6pmxi2M42HKk74Y6Re77BMSltTZp9FZRH5i/fJR0XAzuBn2xVzwhdDE N78LCMojttTHpy3vWGzkSudiUPmgeadR642rUpjgXZhSxfwBcQRHmXoDAAA= X-CFilter-Loop: ASB01 Archived-At: Subject: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 19:31:53 -0000 --_004_D4F8495D4F2Dtarahwheelersymanteccom_ Content-Type: multipart/alternative; boundary="_000_D4F8495D4F2Dtarahwheelersymanteccom_" --_000_D4F8495D4F2Dtarahwheelersymanteccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter Bowen and I have been collaborating on a possible solution for certif= icate privacy. Thoughts? ++++++++++ Precertificate Transformation Extension Many of the concerns around certificate privacy (the ability to privatize s= ome certificate fields) are due to fears that multiple final certs could be= generated for the same precertificate. This solution uses a random key in = the final certificate which can be matched against the hashed redacted info= rmation in the precertificate to demonstrate that the precertificate was un= ique. The precert contains a hash of the original information; without the = key in the full certificate, the hash is not transformable, and if the key = works to transform the hash (as a one way function), the pre certificate ca= n be proven to have been the correct one issued for the full cert. This sol= ves the difficult problem of ensuring that a given precert is the one that = was indeed issued for the full certificate. In order to give domain registrants options for what domain name labels are= disclosed in precertificates, we propose a new certificate extension: Prec= ertifcate Transformation. This extension is found in both the final certif= icate and in the precertificate. The extension specifies a transformation = algorithm, genneral parameters for the algorithm, and a count of disclosed = component per subject alternative name. There are two transformation algorithms initially defined. The basic algor= ithm is as described in 6962 and 6962bis. It has no parameters and the san= DisclosedComponents component is not used. This algorithm is the default. The second is the partialhm256 algorithm. This extends the basic algorithm= by including transformation of the subjectAlternativeName extension. The = Parms is a 128-bit value that is used as K for a HMAC (cf RFC 2104) that us= es H =3D SHA256. For each entry in the subjectAlternativeName extension, a= n entry in the sanPartialComponents sequence must exist. Matching is done = by order. Let the disclosed components count for the entry in question be = N. If N is -1, then the SAN entry is unmodified. If it is greater than or= equal to zero, then the following transformations occur: (1) If the GeneralName type is not dNSName or iPAddress, the result is unde= fined and an error must be thrown (2) If the GeneralName type is dNSName, then the entry is replaced with an = otherName entry of type id-ct-partialGN-dNSName with a value created by cop= ying the N labels closest to the root to the new name and prepending them w= ith a value created by taking the remaining labels and calculating the HMAC= -SHA256 value and hex encoding it and prepending '#'. Note that a '*.' pre= fix on a name is not considered a label; it must be copied to the output as= is. For example, if the input is "*.beta.group.secret.demo.test" with key 0x4fa= 1cb4ce23db6e45caf727b0b1d85ed and the number of disclosed labels is 2, then= the resulting name is "*.#4d240f70beb97f4c402984e94ac6e1c8351c89ff13e8a94d= abfbc474ded4d3d4.demo.test" (3) If the GeneralName type is iPAddress, then the entry is replaced with a= n otherName entry of type id-ct-partialGN-iPAddress. The value is a IA5Str= ing in the format + "|" + . For the hashed part, the ad= dress first is converted to a text string. The format is dotted decimal, w= ith no leading zeroes, for IPv4 addresses and is as described in Section 4 = of RFC 5952 for IPv6 addresses (section 5 is not used in this case). The H= MAC-SHA256 value is calculated of this string as in (2) and is the= hex encoding of the result. Partial is formed by setting the bits other t= han N most significant bits to zero and the converting to string as describ= ed above. For example, if the input is "198.51.100.47" with key 0x4fa1cb4ce23db6e45ca= f727b0b1d85ed and the number of disclosed labels is 27, then the resulting = name is "198.51.100.32|8e38c51f339de29c05e543a099ba76468367043d5bc167c801ae= 0330a648925d". In the precertificate the transformation parameter is set to a zero length = bit string. If the subject contains a commonName type attribute and the value of the co= mmonName attribute value matches a dNSName in the SAN and the precertificat= e contains a partialGN otherName in place of that entry, then the commonNam= e attribute is replaced with a id-ct-partialGN-replacedCN type attribute wi= th the value being the otherName value. This algorithm provides the recipient of a full certificate the ability to = deterministically create the precertificate. It also ensures that the prec= ertificate can only reasonably match one full certificate. id-ct-precertificateTransformation ID ::=3D {1 3 187 97 1} id-ct-partialGN ID ::=3D {1 3 187 97 10} id-ct-partialGN-dNSName ID ::=3D {id-ct-redactedGN 2} # type IA5String id-ct-partialGN-iPAddress ID ::=3D {id-ct-redactedGN 7} # type IA5String id-ct-partialGN-replacedCN ID ::=3D {id-ct-redactedGN 127} # type IA5String id-ct-taAlgorithm ::=3D {1 3 187 97 20} id-ct-taAlgorithm-basic ::=3D {id-ct-taAlgorithm 1} id-ct-taAlgorithm-partialhm256 ::=3D {id-ct-taAlgorithm 2} precertificateTransformation EXTENSION ::=3D { SYNTAX PrecertificateTransformation IDENTIFIED BY id-ct-precertificateTransformation } PrecertificateTransformation ::=3D SEQUENCE { transformationAlgorithm TransformationAlgorithm DEFAULT id-ct-taAlgorthim= -basic, transformationParms TransformationParms BIT STRING OPTIONAL, sanPartialCount SEQUENCE SIZE (1..MAX) OF NamePartialCount OPTIONAL } TransformationAlgorithm ::=3D OBJECT IDENTIFIER TransformationParms ::=3D ANY NamePartialCount ::=3D INTEGER (-1..127) DEFAULT -1 -- Tarah M. Wheeler Principal Security Advocate and Sr Director of Engineering - Website Securi= ty - Delivering Confidence for Customers and Consumers by Securing Websites and = Applications Symantec Corporation www.symantec.com ________________________________ (206) 276-4920 tarah@symantec.com ________________________________ [cid:4524896B-C0DD-4A56-BA9D-E836A716603F] ________________________________ This message (including any attachments) is intended only for the use of th= e individual or entity to which it is addressed and may contain information= that is non-public, proprietary, privileged, confidential, and exempt from= disclosure under applicable law or may constitute as attorney work product= . If you are not the intended recipient, you are hereby notified that any u= se, dissemination, distribution, or copying of this communication is strict= ly prohibited. If you have received this communication in error, notify us = immediately by telephone and (i) destroy this message if a facsimile or (ii= ) delete this message immediately if this is an electronic communication. --_000_D4F8495D4F2Dtarahwheelersymanteccom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Peter Bowen and I have been collaborating on a possible solution for c= ertificate privacy. Thoughts?

++++++++++

Precertificate Transformation Extension

 

Many of the concerns around certificate privacy (the ability to privatize s= ome certificate fields) are due to fears that multiple final certs could be= generated for the same precertificate. This solution uses a random key in = the final certificate which can be matched against the hashed redacted information in the precertificate t= o demonstrate that the precertificate was unique. The precert contains a hash of the original= information; without the key in the full certificate, the hash is not transformable, and if the key works to transf= orm the hash (as a one way function), the pre certificate can be proven to = have been the correct one issued for the full cert. This solves the di= fficult problem of ensuring that a given precert is the one that was indeed issued for the full certificate. <= /span>


In order to give domain registrants options for what domain name labels are= disclosed in precertificates, we propose a new certificate extension: Prec= ertifcate Transformation.  This extension is found in both the final c= ertificate and in the precertificate.  The extension specifies a transformation algorithm, genneral parameters fo= r the algorithm, and a count of disclosed component per subject alternative= name.

 

There are two transformation algorithms initially defined.  The basic = algorithm is as described in 6962 and 6962bis.  It has no parameters a= nd the sanDisclosedComponents component is not used. This algorithm is the = default. 

 

The second is the partialhm256 algorithm.  This extends the basic algo= rithm by including transformation of the subjectAlternativeName extension.&= nbsp; The Parms is a 128-bit value that is used as K for a HMAC (cf RFC 210= 4) that uses H =3D SHA256.  For each entry in the subjectAlternativeName extension, an entry in the sanPartialComponents= sequence must exist.  Matching is done by order.  Let the disclo= sed components count for the entry in question be N.  If N is -1, then= the SAN entry is unmodified.  If it is greater than or equal to zero, then the following transformations occur:

(1) If the GeneralName type is not dNSName or iPAddress, the result is unde= fined and an error must be thrown

(2) If the GeneralName type is dNSName, then the entry is replaced with an = otherName entry of type id-ct-partialGN-dNSName with a value created by cop= ying the N labels closest to the root to the new name and prepending them w= ith a value created by taking the remaining labels and calculating the HMAC-SHA256 value and hex encoding it= and prepending '#'.  Note that a '*.' prefix on a name is not conside= red a label; it must be copied to the output as is.

 

For example, if the input is "*.beta.group.secret.demo.test" with= key 0x4fa1cb4ce23db6e45caf727b0b1d85ed and the number of disclosed labels = is 2, then the resulting name is "*.#4d240f70beb97f4c402984e94ac6e1c83= 51c89ff13e8a94dabfbc474ded4d3d4.demo.test"

 

(3) If the GeneralName type is iPAddress, then the entry is replaced with a= n otherName entry of type id-ct-partialGN-iPAddress.  The value is a I= A5String in the format <partial> + "|" + <hashed= >.   For the hashed part, the address first is converted to a = text string.  The format is dotted decimal, with no leading zeroes, for IP= v4 addresses and is as described in Section 4 of RFC 5952 for IPv6 addresse= s (section 5 is not used in this case).  The HMAC-SHA256 value is calc= ulated of this string as in (2) and <hashed> is the hex encoding of the result.  Partial is formed by setting the = bits other than N most significant bits to zero and the converting to strin= g as described above.

 

For example, if the input is "198.51.100.47" with key 0x4fa1cb4ce= 23db6e45caf727b0b1d85ed and the number of disclosed labels is 27, then the = resulting name is "198.51.100.32|8e38c51f339de29c05e543a099ba764683670= 43d5bc167c801ae0330a648925d".

 

In the precertificate the transformation parameter is set to a zero length = bit string.

 

If the subject contains a commonName type attribute and the value of the co= mmonName attribute value matches a dNSName in the SAN and the precertificat= e contains a partialGN otherName in place of that entry, then the commonNam= e attribute is replaced with a id-ct-partialGN-replacedCN type attribute with the value being the otherName value.

 

This algorithm provides the recipient of a full certificate the ability to = deterministically create the precertificate.  It also ensures that the= precertificate can only reasonably match one full certificate.

 

id-ct-precertificateTransformation ID ::=3D {1 3 187 97 1}

id-ct-partialGN ID ::=3D {1 3 187 97 10}

id-ct-partialGN-dNSName ID ::=3D {id-ct-redactedGN 2} # type IA5String

id-ct-partialGN-iPAddress ID ::=3D {id-ct-redactedGN 7} # type IA5String

id-ct-partialGN-replacedCN ID ::=3D {id-ct-redactedGN 127} # type IA5String=

id-ct-taAlgorithm ::=3D {1 3 187 97 20}

id-ct-taAlgorithm-basic ::=3D {id-ct-taAlgorithm 1}

id-ct-taAlgorithm-partialhm256 ::=3D {id-ct-taAlgorithm 2}

 

precertificateTransformation EXTENSION ::=3D {

  SYNTAX PrecertificateTransformation

  IDENTIFIED BY id-ct-precertificateTransformation

}

 

PrecertificateTransformation ::=3D SEQUENCE {

  transformationAlgorithm TransformationAlgorithm DEFAULT id-ct-taAlgo= rthim-basic,

  transformationParms TransformationParms BIT STRING OPTIONAL,

  sanPartialCount SEQUENCE SIZE (1..MAX) OF NamePartialCount OPTIONAL<= /p>

}

 

TransformationAlgorithm ::=3D OBJECT IDENTIFIER

 

TransformationParms ::=3D ANY

 

NamePartialCount ::=3D INTEGER (-1..127) DEFAULT -1

 





-- 

Tarah M. Wheeler


Princip= al Security Advocate and Sr Director of Engineering - Website Security - =

Delivering Confidence for C= ustomers and Consumers by Securing Websites and Applications

Symantec Corporation

www.symantec.com

________________________________

(206) 276-4920=
tarah@symantec.co= m 

________________________________=

________________________________

This message (including= any attachments) is inte= nded only for the use of the individual or entity to which it is addres= sed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applic= able law or may constitute as attorney work product. If you are not the int= ended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strict= ly prohibited. If you have received this communication in error, notify us = immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if thi= s is an electronic communication.
--_000_D4F8495D4F2Dtarahwheelersymanteccom_-- --_004_D4F8495D4F2Dtarahwheelersymanteccom_ Content-Type: image/png; name="7EDF6DD6-B748-44E0-A644-5EEFE097D244[9].png" Content-Description: 7EDF6DD6-B748-44E0-A644-5EEFE097D244[9].png Content-Disposition: inline; filename="7EDF6DD6-B748-44E0-A644-5EEFE097D244[9].png"; size=5688; creation-date="Wed, 22 Mar 2017 19:31:43 GMT"; modification-date="Wed, 22 Mar 2017 19:31:43 GMT" Content-ID: <4524896B-C0DD-4A56-BA9D-E836A716603F> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAI4AAAAnCAYAAADZ7nAuAAAD8GlDQ1BJQ0MgUHJvZmlsZQAAOI2N Vd1v21QUP4lvXKQWP6Cxjg4Vi69VU1u5GxqtxgZJk6XpQhq5zdgqpMl1bhpT1za2021Vn/YCbwz4 A4CyBx6QeEIaDMT2su0BtElTQRXVJKQ9dNpAaJP2gqpwrq9Tu13GuJGvfznndz7v0TVAx1ea45hJ GWDe8l01n5GPn5iWO1YhCc9BJ/RAp6Z7TrpcLgIuxoVH1sNfIcHeNwfa6/9zdVappwMknkJsVz19 HvFpgJSpO64PIN5G+fAp30Hc8TziHS4miFhheJbjLMMzHB8POFPqKGKWi6TXtSriJcT9MzH5bAzz HIK1I08t6hq6zHpRdu2aYdJYuk9Q/881bzZa8Xrx6fLmJo/iu4/VXnfH1BB/rmu5ScQvI77m+Bkm fxXxvcZcJY14L0DymZp7pML5yTcW61PvIN6JuGr4halQvmjNlCa4bXJ5zj6qhpxrujeKPYMXEd+q 00KR5yNAlWZzrF+Ie+uNsdC/MO4tTOZafhbroyXuR3Df08bLiHsQf+ja6gTPWVimZl7l/oUrjl8O cxDWLbNU5D6JRL2gxkDu16fGuC054OMhclsyXTOOFEL+kmMGs4i5kfNuQ62EnBuam8tzP+Q+tSqh z9SuqpZlvR1EfBiOJTSgYMMM7jpYsAEyqJCHDL4dcFFTAwNMlFDUUpQYiadhDmXteeWAw3HEmA2s 15k1RmnP4RHuhBybdBOF7MfnICmSQ2SYjIBM3iRvkcMki9IRcnDTthyLz2Ld2fTzPjTQK+Mdg8y5 nkZfFO+se9LQr3/09xZr+5GcaSufeAfAww60mAPx+q8u/bAr8rFCLrx7s+vqEkw8qb+p26n11Aru q6m1iJH6PbWGv1VIY25mkNE8PkaQhxfLIF7DZXx80HD/A3l2jLclYs061xNpWCfoB6WHJTjbH0mV 35Q/lRXlC+W8cndbl9t2SfhU+Fb4UfhO+F74GWThknBZ+Em4InwjXIyd1ePnY/Psg3pb1TJNu15T MKWMtFt6ScpKL0ivSMXIn9QtDUlj0h7U7N48t3i8eC0GnMC91dX2sTivgloDTgUVeEGHLTizbf5D a9JLhkhh29QOs1luMcScmBXTIIt7xRFxSBxnuJWfuAd1I7jntkyd/pgKaIwVr3MgmDo2q8x6IdB5 QH162mcX7ajtnHGN2bov71OU1+U0fqqoXLD0wX5ZM005UHmySz3qLtDqILDvIL+iH6jB9y2x83ok 898GOPQX3lk3Itl0A+BrD6D7tUjWh3fis58BXDigN9yF8M5PJH4B8Gr79/F/XRm8m241mw/wvur4 BGDj42bzn+Vmc+NL9L8GcMn8F1kAcXgSteGGAAASA0lEQVR4Ae2bCZgV1ZXHb1W93oAGRECUIBE/ QR3oBRgNoGExBBcQIgSDigxRoxM/SUaDOpkYJTEx7qiYmDFOEo0axUR0mCBLsyiKAgIqJmACRMGg yCoN3XS/VzW/f726r+s13S0YEEje4fv3ufecc/dzz71Vr3CCIDA5ys3A/s6Au78FDpp9RdlDwZyy Nw9a/bmKD+gMHBaO4zjOlTc8srGFY8zDB3R0ucoO2gwkDlrNn1AxzoKfmBGgAAxd/k7VFuO5uYjz CfN2uKidQ3HHwWcKEgnTp23LxLwdu/zaqj3+yKCitB/XrdOcs1YMOlwmJ9ePxmfg74s4U0d7pt2S PFNwrGPya5Km9+tJ04Qn4jA6GhVpji/Mc595dlKXZGV16urBE9fMNW5ynpNw8xrvak5zOM3AfkWc jdN7N2uXlzzdOMEXPM8tx0k68UzWEV/AAYMtQeC+77j+264JlhjHeckMWvF+fLA4zr+T7wfu8Fxn waRLO0yY/OxHV2/ekVyMv02I2+bSh/cM7JPjVE0v61hQ6FzhGOdC4sVJToHjGZ+B+biNnuYFG0s8 AkoyMH4y2IKDzfBrzc8TZ69YqGnAcXrAxoIzwZNgNHgFPI/jhDakc3QEzEDTjjOJ+NGn7HInz/ku 6CyHCFJAjtIE6SwKD6U8Yk9tUO2Y4LHRP3hv6tQFWy9ClQQfgM+BTeBBnOY9eI6OoBlo1HEqZ5W2 L/LcKZ7nfFXjIYI0OKzw2Uga1A1ZuAWuWfxWpTnnxjW7tu5MNcdyA3gC6GjqlnMaZuEIpIYdZ3bP 4wIveNrJc/sFNX5WhJGjODqOBDzFr+G8YvXdPNc1CWREJMHnKHPzXfObF7aYaQt3mN5di8ytj39o dlXrjAvpXf4OpOi6KJ9jR9AMcKmtRzN6tkslgqlentvX35NZ5NDIzePQSd9f3uTYmsmRtcRzg83J pPwvVewl3ZNTQfAl13P6EGmKd+32zZJVu83cFTvN0a0SJiVn4i7UpjixnQvxKCqV8+ToCJyB7Igz f2AiVbP9116Re1HcaVwCiQnvK/4iP+Xf5tXkVZihS3c3Nt7amd1L8wry/uPKu9Z/ZeqL21tu25nK mCaIVMse6rqpx4kFXzQD31idUTSR4FLdGnUzsAsP3dGEaU71Gc1AluOkZpVe5uV7v4hfgN3QawgW qeB2d3vtbearKyv3pW8s9liKPsBB1qqkS6GZcEF7c839G8wt4zqYiV87hgeu4DnjtR5lBszTZXkv onw7hOPBueAYoPvRTrAFLAHPgVdxpBp4jj7jGcg4zq7nexxT1CyxyE04J9iLcHSfSXIsTTRfWj55 X/vGol+C7STQRWXat06YM0tamB4nFJmJF7Y3zQp52kLOK8PhBYOXPS+bOFG+hPxvgB7fGyM53BAc Z25jBv9IcuZkAOM5D+j+8HPGvRZ+yEhvX0IqKPIu5l6ScRoJeZNrkjXB5P10mhMoei8InUb1bNqe rNxRmdrz7ZHtQqcheoWP6wkTXGde7531tpgJ0pH0MxB3mvfI63es9cCSjrnlNvNPwPX+6zvgetD5 UI83fTmecVKByWt+cfhCL+oRkcf4tf7y7dVVP2iLjAUdB+sOnsbbdVQ0RjehUJE4Lf39pM8vLi5O XB/UasPwQMYlm0t0X7OTN9HGLAyF6T+nwfpG+V3wb4HpQHcqOdWJYAx4nX5sg/+zkMZtqe7SaCWf MU87jteyu+cFp2oxLSnlBs6dbc9ftROnkd03gBb0m+Tvgf+IhauGZwj5F8joJV+cVpEZV5zvVAe1 qTGO53aydyi3wEn41eY8wl7cceITpDvMI7HKdMf5EOhtc0i0yU8eJj/K6vK8KUpbvS7WR0WyWvhG IHtM0/2nDo+8jsdOQPpl6MLFQaeIqOgn3XqwXAXhWYRdMYJu4Fig3SHbP2KadYeL6tN8JtGpP9qU KlsKtOHWIg+/EkCux5IC0AqoXkuFqIrIYLrXGrRHfgrQmP8G1IdKeINEPar/ZHA8UF83gD9RJqvf yLIJA5OaXXZrML88gIcI5pKeVbYumN2rlfQCNBRo4ZQRHgPNYnpNvu4rVi+uRRhmbVJzyiYHL/as a4c2k7PKXqb68K4VtXNprI63SR9lyzfE0etY2w4UfWaBvLgd+QcinfQPAzmIjr61QJPVC1QARTT1 uQo8A7RY/cECYHXivwOto77i82EUvg/+V6CydvxaLDl4/3r9uQWZFlT1yCk13j+BGqCyKjcVaOHl UC8BbRY5sq17M2nVsRIUR32RI90CtPBySNlqY6vusfE+2DTyYeA1oMhu61b7C8H5wLO29XnoFKnZ pcuCirTTyHmixX1iL2NjrqKy+ACeIB86D3wQkJfaDoi/Fq8jObNkmD+v3PfnRA5aIWct3xjM69XW 2lFGC2knUXXMB0NAxkmtrTg0Etg2NQEnWj1pHW3LY3odceXAj2TT4B9FaVuH5VqwjxvRTYrabo5+ cSM2tp4t6EtifdJDhnRydrVv7erzO9C1AHKQ+jqbl4PIufKB1sLKG+JX2z5Efb8EezlWQ7aS/RmE ThkvZ9PaMZBTqje9dUQ512i3ZxGFHkKg3WVJC/ETwl0Cfh1Q1LEkJ7rNZsSTvnmH364+TkdgScI+ N6+pqe2gXERa6KdtBt4fzACvUe4u0BcohFvSAmuXieQoA8NU+o+OF4Vh0VYgW/VVzi8aDtqCReBe oMmydAYJu+M15jVWAR9FF/KZDznqryL5WviD4FqgRd8JRG3AlWEq/cfOdCuyal95Rer7wXpg6QIS cojvgruAnMSSbecaBOrD14HWQrQH3AS02eRMlm6mz5oPHY0nwuTABcpD68CPwI/BUqD5uZHx2TGQ rUfyIHtEWR4eWxXl10hXHxRvCVR5uOpwOcj/AA3AysSfBJkjKKznufLjaOPDIIw0RLZ0lKuseaGk Z7wdymkxG9uNmkBNdHdbhvR/A9v2kzH5v8XkFZJDfYDqsPZ3ki6MdF+LyTV53wcFke7imG4b6Y6R XEfKKNBGeQvyPwG2DYV+N7K/JybfRPr8WJmxMZ0c/aSozEmk7XGpOk+LldHix9fjFzFdC3R/AbYf V0T13RSTKSKyGJkricoMANlrFxubbMOIk7V/KRES9w6bjHMKfUx+ItBxIvLAeKDdbkmeeiu26nAd uX6DddYZpFMU20xqNLgUaNJ1d7CkiDEMzGDn9IyEz8K1c0V9kMu5Rf3SLPw7PZa2STn947SnkC3a mGbhX8meQqcdLNLRYknjKFQG/TbwDNhKu83BKeB8VNrVltqTUL/r0yrKaRNY2kDCjkP3Hzunlls7 3WcsfY7Ev0QZzXc4TvogR60kL6eydJrkZAZYAXwuditsXmXAfJC9dtYg4qHjYKIdWEfpt8Wt6wTZ Keqch+SpbGlW7lfYvJ0lIVOTSB3NVDMJWX3SWx27OJkilK8BjyHoD74ItIPXAEuasDuZCE3wK+Dd SNEJXhZNUO9Ipt06P0rXZypvKZwPm4Hnx9L1dZlB0FYJuBtbObkW4TkwCljSXah+eekoFj7RWbu4 jerPtGENGuAnILNHjtTfo84KeEXEz5QwIs2ZjsjjrQC+Kpbe52TY0SDw39CPj3EK/KBHPN9A+i5k 8uj6pIj00/pC5T3X7cpLxRaB3VPpUFeZX+W835C9ZDiPD5aC/yR7OnhY8og0Kaei2wGfGck0koGg I+gWyfRksTJKH1DG4lxNhS+Ca0EZkLNpPOuBpX1xAGu7v7wNBRQBReK9wCAwIOLHwS0prUgZ3xCN 32NsqQZ4GD6JXtP4TKJ35gVgLTHACc7YOb1b2+Khq3Vs7EUs1ptM2v+iGFNPORVdg16M/dn6JMP+ pKE96PjOX8yIZdvr1dFglnq3UMf3UA4FxwJFi87gDfAMuBxoTDqiNgAb0mdQNjuqovw7qZa+lFPH vcBGrdmktWmWgBFgCjjYpDuKHFNOoy15O1gNmN296CMkOoIFS3K8/abQcVK1wR/wFEKcLon0gl8m 3YTboVlR4XBqfKSJWn+J7kJgO6nFkWxvqijp4rjecINTZogjMXD8WXa7SM5iaDf0BwtYbHuPksqS 2rLtSWYnYRHptaAr0M4PxwZPAoXuA00a62BgnUZH8yj6rIircewRP0hkY7aq/zPQUWyPw5X04Qkp GiL6pem28yST0obsPkkWLkDe+oQaW+roQywoXFr+OIF7fSXf5zRRyXx0L8f0WrzXYvlMMuW7E518 t62PU4p0jeLTjZpUMvVCxiiduAT2B/ACYxwDPg90AddinAzTEXmM8pAW6a9K0H9N3nSlIfV5YJhK P2oqAhwMshFNdctRqpSgnwWwT7UgKt8Aqd6w7kjHXTFD75PSvFu6gfa72QzpruB+oEitedICzLV6 +EB0l4Bw8WG9wONA0bRRSu/KbyytdWaVP8ZqnhG5jdEPkfzo2bWZ8W9nJi5Ti/VrQaRwPQ75VaA1 uA+ZdngWpeaUjnQ97+v6mjBD+r5nT2pe3qKRy82X01Lq0vHzQ6B+aeEFhVc9sah9OcxRwNI0Etpx lv6PxLdA6GiRUI/hu6zBAeTadPF7kxzl9/RzDVx3r57gQJHmYBuwx8pttKPjuiMYA+4EmiuNuwQs RK/jW09jciKVq0HGx3fh74yPkteadQFycp0q+ikJFr4JL4br6VARVZtzLNDGULozdUwJIw4Z8/Fu frzck3pLX/lZ0kLzY+d4f3bZzVZWn1PJOnADuBL8sb4+OavXINf1fkqfeGGW1qp//F6V4r/I3G1u vjnmTeEj74NYfRCrR9FDg1e0iTuNotJ1tBnVSo7vc0C8D9LJLk4asz3GxOsGnH0EakKb0kk/A8wH Ii2aFlOO2xNsBHIiUX6ahX9t28rYY86q1Te7Jpn2GaKc5nfWCK65uAycDfRWehb8+8Ae7W1JnwX6 ADmNaD0I+4H9h6SvAH8DIsllK8hpROqn0goE2rBdwM/AAyAzgab1iOXb+S3pFnr9FAub0HKES6LI k3Bu9ivKOlXtSf5X83NXfqCC+0LUN95L8LbXddpkLsQU5MgyqerUo97gN+bE62FAVeR/jKc/Ch8F tHO7gfZAg1Pbq4AijX4SsRNFNgzDuymrS3KPUJBevFejtGXbSShUa6FTQLvIkl66LYgyujtVWgVc u146OZPke2hf7Y0mfSPQIh4H1McKMBmcAr4DVNZukNWkXwIiRYW446v9eUB9U5SMtz+J/B4wHBwP 9DQkxwyjKX3RvC0jPx6Ugg5gB1gH5gN9wyNnDon0XOwHkpkA+oHOQPUrgmtdpmCj/ujonS0ObQKK cum3g0pY4kfH+xLNvAl+3UflFMRQR0vSf4eL8wNuIvFbM2DpZlsmi0/tW2SO3n1mKuV82/PMOZpn e6+RnSIaTrSaL336m7Pekuc3SXRa4Va7TzuxmsGEE9VYIeyvRXd3pNdb5IvitugZTWZXS6XH/XDx 9lGn8ioip8sQZdXPQqA+7rYK5Nq5GXvyGocgysiVibUftoEo0zfpRdgUwQRFAn0NkNUPZLJpDlNf akGDNsgzhL1s1X85dyV1qu4mKXytnGWxqG9RsLvqaafAHRrgPOGMRgb6Rkf7je90CHvOIoa9MuBM T/lOTcL1j8XsVP7TXl9suvP/sFx+l8KkrvbIabamksE5eUNWLK7TfPoUg1Y4PQ9o0L3AVaBllD+X SZhJOkcHeAb2dhw1MLNvmyBR9Ws5j+F/OkQPQpmm+QCLQ06bAtKHWXIO5SXnmx77vU2oj/7ov8rw vc+7qdrk5Ykhb2YdUXG7/U3jODqW5ITaNXF6iMw3taXjwlz6wMyADZnZtQ15ZatT5V3I/5m6VydN /MIsQz1x6X9BCHoLrKXxiS463nSXiS+VnExOw0/jL9dWJ4cdSKeJOt0WrjuBSFHnA3AHuDbnNMzC QaKGI06ssVRF+Qh29U2ux5OCrgd8G5H9CUbMOEqGdyJFH8CT2RYcaYpbW3CPOefV+EV074KfQhId VSUU1eVZjrMGh9nwKarKFdmPGfhEx1Fdm58/ufiowqILuNKN4zet3rwoLNbVLH7plZ2Lr4TOQkTi 32py0/hB/BEzeLlu6jn6B5qBfXKc+HhrZpV2T+R5Xw5S/le4CP8r0YXvVTIW73C0zfBNanqiRbPF 5vQDH2EyLeUSh3QG9ttxDmlvc40fNjPw/yo9MJdW/21oAAAAAElFTkSuQmCC --_004_D4F8495D4F2Dtarahwheelersymanteccom_-- From nobody Wed Mar 22 12:50: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 9685D129C0C for ; Wed, 22 Mar 2017 12:50:14 -0700 (PDT) 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 VSm7tdKnC9wJ for ; Wed, 22 Mar 2017 12:50:13 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 46575129C11 for ; Wed, 22 Mar 2017 12:50:13 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id o126so96067614pfb.3 for ; Wed, 22 Mar 2017 12:50:13 -0700 (PDT) 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=xzU3I1IGigrigG7y0LOqTxpsEO4qztFWKGOvW88yozQ=; b=Eiry1KgL9+8a5CN1JquPtIfO6IeEB7PSIwrVC+SdA00kPDxzOALn1xYUYzf6l1ulip iAc9E2sxnMeDyzu6Ijx3t/WXedJ/F5AYajc2qin0G9gwbKJGfHpQD1ZARUZTrTY7TOHy T3legoXFa6fa60eYd7uYGdJA4waWe2iNtyRp7nTnn0KxhJJS+gb2TYlwAF/NqaQfFtth XUjEW/fp1+8Aq7k+hQcyZT68gidXM9eTb9QQVrLhyp4aU4iCrkWaP/NfJN2KbonBYiAu R4SYajvozJe3zB2QuaCM83MgEs3VKSh2fmgW/QnQuE1bbSCfUZZTwnD/DWbY/qPZ2XPm WKdw== 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=xzU3I1IGigrigG7y0LOqTxpsEO4qztFWKGOvW88yozQ=; b=qZexSveLHSbiiEYFE1KRrFPzhhsHJJpHtGgYG8+YXpmS13MS9dVho9AhrKAz9ft5Mn IBz0yPlysgA/m6GoB0cMYu3fkUJPXe7gVBWypwz1Q1VAnyT7/6bzLRsTrLcHPooXjjs4 v62SBjjfLHB0MhoLvhvDcvW3EU3W6/Gv+vOtv/lIJ6ssrOs0j7Xq/OKrhGDBjep4MxX5 VVgv/r2eOeANpDEs/DFlvLdHWhgl3j4KcVRhWYZkiyiVpYHgRPYK0oBz9qy7X58AXFud gnjfxas1iEPYTDiOO8nLzZ6cG9aCHLdO0g8zFZYEZoQK3A9lH+L2rWFKsn1XgZUWifMH wf7g== X-Gm-Message-State: AFeK/H3V92kUHAgAqW/FpMP4lpOyNpYto+ovLRLE1JhqvoipyX5w4nkeW+mADimu8LOuLQ== X-Received: by 10.84.177.36 with SMTP id w33mr56898296plb.105.1490212212327; Wed, 22 Mar 2017 12:50:12 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (66-230-100-107-radius.dynamic.acsalaska.net. [66.230.100.107]) by smtp.gmail.com with ESMTPSA id t70sm5530851pfe.64.2017.03.22.12.50.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 12:50:11 -0700 (PDT) To: trans@ietf.org References: From: Melinda Shore Message-ID: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> Date: Wed, 22 Mar 2017 11:50:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DdKRO8XVXkfhDMusHOx3k8gCcLHeNFTV3" Archived-At: Subject: Re: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 19:50:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DdKRO8XVXkfhDMusHOx3k8gCcLHeNFTV3 Content-Type: multipart/mixed; boundary="hR8Qv05fRPF8b44RX9xH8iD4H74pwOuap"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> Subject: Re: [Trans] Proposal to modularize pre certificate transformation References: In-Reply-To: --hR8Qv05fRPF8b44RX9xH8iD4H74pwOuap Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/22/17 11:31 AM, Tarah Wheeler wrote: > Peter Bowen and I have been collaborating on a possible solution for > certificate privacy. Thoughts? We've allocated time on Tuesday to a discussion of redaction and privacy-preserving logging mechanisms. Will either you or Peter be there to discuss this proposal? Thanks, Melinda --hR8Qv05fRPF8b44RX9xH8iD4H74pwOuap-- --DdKRO8XVXkfhDMusHOx3k8gCcLHeNFTV3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0tVxAAoJELiGRpM6HoEuX9MP/RU0G3N8yRK49pAm6ta7FRkQ uaOZtgTGjeqeP0xpuBO96K+VD4oWGqV2DSXM74ShZ3Z+iQBRKpWhjN9Yx54oP3y6 C4s8IoFxCzEyYm+eTJdDbsT5NSVVftO3IKUkKUBiK93vbKczsb4Z4p/8jfLK7uN1 zoKXCuvyvgDe0LeJzw8rQ37x9DF3m1kDBRXxabgAakNjTHbYN36WXHcyYyJK2k8v CLyy4mEI8UuJHzB3t6+dirzu/pIeRpqEyLIkVgFd86ThU9n0hvT1UBtkQba52+56 DG4ZVmngQ0UfZ+xkCeOHtqOea+xfK041THXO5kE3o9B9ac5GFb4NYAaj3xgKFCqk qAjj90X2DTICgvwZLHujRPUQoaUoMY3W7izAkKBHv/jTI04MZwaNMFWgxjOm5rX+ eSUtsYPZF6ohxBCFiQg/+mM5UuDGn5xWRvGFr/Rc12tRP+W8eq1zSKDOePva4YoX F0MjXa/E40gl8iQcRPk3ics0n9onC64hvF0/973SqRZeH7o3kdmj7HfunbIk16VA HE7CXyBGhSBo4KXHgI6uT2CwGZPDEig4BUpS2iDi3PJKdCSYsgutD78MaFwS2OTJ 773GCYQd9yCk9MAwIHLpClW0nLcJjzjJqCbGxdeG2pKuCxgP4kMgW4DKX0Uv5PO0 KXZkClEaQbgZcQ6OSa8C =g4mb -----END PGP SIGNATURE----- --DdKRO8XVXkfhDMusHOx3k8gCcLHeNFTV3-- From nobody Wed Mar 22 13:45:03 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 773E8128BB7 for ; Wed, 22 Mar 2017 13:45:01 -0700 (PDT) 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 TOeXkKYv6jSs for ; Wed, 22 Mar 2017 13:45:00 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 3A07A12778D for ; Wed, 22 Mar 2017 13:45:00 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id o24so175484775otb.1 for ; Wed, 22 Mar 2017 13:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A3X95nYIgTRDm81L12je9W0kUCUi32d9EuFTNXAwLRw=; b=lgM8T8dhD0CiA5jVUNLumY7QSK1sTejcwQEUQ20o5vRO1A0A+KFY5SY51b3q64jjr9 WlvmS2HgyDszed6qrYW/WGENG5H2V9HoWuBJxdrXzn3be7mUBfLqviddqqyRmYTDvLA/ jknsFnW57DyUX0y+ci1dXYtkztCOccZJC6j/6cdlIIscfcelB80nTri2XSbwoT71uket feiJI+pjL+MFeGe0enVZBbAa41/MaUjG6Ae2TFONAptgNS9iEkc97OAD0wJsb81+j2pK fOCWmPHaYK9b2Qrj/Ny6H9jZZIAzenCT1RkCPDMkmwEcdwtUDOT533mkpz1FtKqprvvn oEQg== 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=A3X95nYIgTRDm81L12je9W0kUCUi32d9EuFTNXAwLRw=; b=bBfdtR0jVjqHJqW2Gf8rIA1MTQQbBlSMtwZbzVVgmIAkuDWL1WpHzmN57BkmLvSYAv ckjBDCpvba6A7O9Mss4J1EXWZ5KBxy+6WxvltpFLVJM4KrGFymvCbnxhBi8XwWBJJpyf RidDQ+wwFnUaI8xMVtSdSsUOwkaFEVGW/GEfFvjkqY/EnEkhJSICu8qzEyNNhkGYniO2 D13ubKqVZ5tbHgjATaYJ08KzJt+gj1jIGoi0cgOULLuCLk6azac82/0bAXsEE4gaOsae 3r/30BM1O1bWLbGUyuC6mfKoVi/y0R6ICavsUsjR5jvxnZAVKbPP02W7wCMhwEdcy0Mm ca5w== X-Gm-Message-State: AFeK/H0xu1EeuOax1bYsQAVSlU6DRobN19fqK0LfK+oMyAssjQKjHxBx8j6acnIJAgBhLkoKM/Uy866E6xYe8g== X-Received: by 10.157.15.161 with SMTP id d30mr22403717otd.221.1490215499654; Wed, 22 Mar 2017 13:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Wed, 22 Mar 2017 13:44:59 -0700 (PDT) In-Reply-To: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> References: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> From: Peter Bowen Date: Wed, 22 Mar 2017 13:44:59 -0700 Message-ID: To: Melinda Shore Cc: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:45:01 -0000 On Wed, Mar 22, 2017 at 12:50 PM, Melinda Shore wrote: > On 3/22/17 11:31 AM, Tarah Wheeler wrote: >> Peter Bowen and I have been collaborating on a possible solution for >> certificate privacy. Thoughts? > > We've allocated time on Tuesday to a discussion of redaction > and privacy-preserving logging mechanisms. Will either you or > Peter be there to discuss this proposal? I cannot make it to the meeting in person due to a family commitment but can likely join remotely. We know this is after the deadline for submittals, hence the rather quick note rather than proposed changes to a draft. From nobody Wed Mar 22 14:14:13 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14302128C83 for ; Wed, 22 Mar 2017 14:14:11 -0700 (PDT) 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 l70dlLGQlCGB for ; Wed, 22 Mar 2017 14:14:09 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 783E812778D for ; Wed, 22 Mar 2017 14:14:09 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id g2so112373103pge.3 for ; Wed, 22 Mar 2017 14:14:09 -0700 (PDT) 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=U/A4Y4aPQVasc4D/JOUKBbNXnXdOiEsa1UX3zhkKC+Y=; b=nqzDC92QKCsvqRmEhc6ocSG8VDV56If1U+UL9uC82dXZx4pnFc6ohZ48GJrv2dt85b dVGrw5A1zW20Qc8B8vcQnYhimS0ZxnQWmVz9cFTGvdNoi74I2SwQnfaOeiN/Mh/JDMCL P7CogHGh3pEma/FPvPJhudcznjeJyhIz72iSHB+e9vELauXJE4VG438rG+fkX8aj+ZQq b5YYCFwqviMKkXj8dBy5HUrooeyZWkliu1rIq76t07KkHSa7Ctf9sDUG1A8rpN4QDVEC 4Q8NRmRdyAEZEEbxGCI1WOvEIRkEUhj0tu2XaM68+9Gs0Sb8uSvvDZqUTFP7mPDu4AYc ZNRQ== 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=U/A4Y4aPQVasc4D/JOUKBbNXnXdOiEsa1UX3zhkKC+Y=; b=qXhpYwmTXGegV2Ra+S+oNreUe1blfFUyXQRScezUsS8B2distSyJrILkOEvIwJABz6 +h5aX74+MGgGGLE6T8nzaqlIfMPKsrZGWkgARXbyiEM2xZIINd1GTH3V5c0Mcz0z0W2t ot03rBexEV+YHgJWTcQNFTiAViQbQFp/ETuMcVF1Iw9vFyrvaXHfeT3OI9Wrt/hOQNLQ ECr3Pbb1vm98389vKd/Bb4D9TE5zrGAddwy6F9SHE0te07KDovTHGsyR1sLGIq8kmMqW tfosoo5wfDMK2gzhjvx/GHLbCuU0kRLCMKD1vZ6eA0oIK9HXzrNPMNTTqXuawbHXL/JG qXfg== X-Gm-Message-State: AFeK/H1QXPSxX8P7JDTLFq0aete1J9FpUe59WCaGXv+l4ukWW3weytEkzE1DBxEdJ+D5+A== X-Received: by 10.99.101.199 with SMTP id z190mr45030597pgb.219.1490217248837; Wed, 22 Mar 2017 14:14:08 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (66-230-100-107-radius.dynamic.acsalaska.net. [66.230.100.107]) by smtp.gmail.com with ESMTPSA id t133sm5743591pgc.24.2017.03.22.14.14.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 14:14:08 -0700 (PDT) To: Peter Bowen References: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> Cc: "trans@ietf.org" From: Melinda Shore Message-ID: <7f604a5a-e0d1-11de-2e78-701dd96beaff@gmail.com> Date: Wed, 22 Mar 2017 13:14:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6GSqXoLWqIBb6ngmoAQU6d4uIDA26cnrW" Archived-At: Subject: Re: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 21:14:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6GSqXoLWqIBb6ngmoAQU6d4uIDA26cnrW Content-Type: multipart/mixed; boundary="VFK1n30NsgQkmRiD0WgI6VX3Q76oPSd5h"; protected-headers="v1" From: Melinda Shore To: Peter Bowen Cc: "trans@ietf.org" Message-ID: <7f604a5a-e0d1-11de-2e78-701dd96beaff@gmail.com> Subject: Re: [Trans] Proposal to modularize pre certificate transformation References: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> In-Reply-To: --VFK1n30NsgQkmRiD0WgI6VX3Q76oPSd5h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/22/17 12:44 PM, Peter Bowen wrote: > I cannot make it to the meeting in person due to a family commitment > but can likely join remotely. We know this is after the deadline for > submittals, hence the rather quick note rather than proposed changes > to a draft. Remote participation is fine - I'd just like to make sure that we've got a handle on which proposals are out there during the discussion. Melinda --VFK1n30NsgQkmRiD0WgI6VX3Q76oPSd5h-- --6GSqXoLWqIBb6ngmoAQU6d4uIDA26cnrW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY0ukdAAoJELiGRpM6HoEuNuAQAKIbZwdJ7/b8mMc332wEgXh4 gU9QVyrzony1rAPQhWRK4mk1KJLkZP2MrKtAFXQg7T2XkHrcy3h6axe12m/onkim PKBkhfzpeSift8Ih3SbxL2mD826KPy2fdx/EDeRW9kdIim3+k/cgb+1YxDV8zb4Z mFkSfTvjNlL6xh238Ji0PWCit6eyAYaM6FkpRRMIciwB1SlIrTR3ywaGxOKA3j8u 8RYr72gl1yuCOhAfcldBaOhfty6xeg00Qg3IEKIPvtmqVZ+VF1IYBBhpcjx8FAyW 2MbqWsGBsmifz7k2K7+kD7I7j3yV2BVRD7Uj2qUxSII+tVFbKv/Evug1Uj1y9lHs l16r05UZzWd9MvPHrZqEXK9fGQrsQ1/ML0EhvhPHF2mUH2Liw0xPEGu9B1iHwAc9 UtTjMCn5XlTxIShuG1L9ieFcG+xYk2Ljy5VCfPOclCwZYD5nxV4XRWj97hvLLKCR sPCjAcuN3IFBruAHI2gcdhCDkyx9ptw2KN/5RsmcGa3IBbUrIKqFJ8gB/e/j1oiV mAOTOs90Plknc3plLHeETIuWe/qbAiykYsUfqgsyUPj2xsfN543a3U+4Ni1G/yZU hOZ/rNQmamtQ9l+naSFHtiQxE/JvSBi7c3nXiC3cheyTCQVRZVuqSlwO2c5OublF AUNcRhKW5PEtmK+M56zi =LG77 -----END PGP SIGNATURE----- --6GSqXoLWqIBb6ngmoAQU6d4uIDA26cnrW-- From nobody Wed Mar 22 14:41:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677641294A8 for ; Wed, 22 Mar 2017 14:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3HbTVh4G7RY for ; Wed, 22 Mar 2017 14:41:20 -0700 (PDT) Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (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 63A9A1293D6 for ; Wed, 22 Mar 2017 14:41:20 -0700 (PDT) Received: from tussmtmtaapi01.symc.symantec.com (tus3-f5-symc-ext-prd-snat7.net.symantec.com [10.44.130.7]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 3B.38.30096.F7FE2D85; Wed, 22 Mar 2017 21:41:19 +0000 (GMT) X-AuditID: 0a2c7e31-bbf679a000007590-50-58d2ef7f9bc1 Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat10.net.symantec.com [10.44.130.10]) by tussmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 4D.00.61790.F7FE2D85; Wed, 22 Mar 2017 21:41:19 +0000 (GMT) Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 22 Mar 2017 14:41:17 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.128.3) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 22 Mar 2017 14:41:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X3Iso6vrI8Ul0We7w6gzCan42CH88K8gc6O5Yw6zKR8=; b=t4qOQ8KPFRUttQ29rGwSY+wpZO4KKhYWuSk483mtWcaiJinNUiCKN6rrz3AH6Wmk/j4IhkwKBLlR5ZHFfroOIclnuSbQ/L6NdG/dI8qKP0FV8I87PEudMEeDuhddDOJ5c9qHbMm3ugvUBMf7HXu5Jd3CIDnyL7/PyCxSy079u4w= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0898.namprd16.prod.outlook.com (10.165.81.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 21:41:15 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0977.020; Wed, 22 Mar 2017 21:41:15 +0000 From: Tarah Wheeler To: Melinda Shore CC: Peter Bowen , "trans@ietf.org" Thread-Topic: [EXT] Re: [Trans] Proposal to modularize pre certificate transformation Thread-Index: AQHSo0LvLcFxGd4fV0CeqEQxJK1SmqGhXBbWgAAHdBM= Date: Wed, 22 Mar 2017 21:41:15 +0000 Message-ID: <96545CD3-C98E-4AA8-8534-302DAC2561FE@symantec.com> References: <0d59f95a-1323-6c60-7a36-87a173022312@gmail.com> , <7f604a5a-e0d1-11de-2e78-701dd96beaff@gmail.com> In-Reply-To: <7f604a5a-e0d1-11de-2e78-701dd96beaff@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2600:1004:b040:dcce:f86e:c4c7:ee9a:a5c7] x-microsoft-exchange-diagnostics: 1; BN3PR16MB0898; 7:atmDTIZhZzQfZpSDuH/5TTp/L0lSYcsXijFSIvRhnLELu+nKY0dUULJsRd/ecKJa7fwA+uHZOsAJx/1487PwVfjzIYtJP7O93EKxa8mS6gG+0Weltv3OXDF1mjYUpP9WhuH27zyuXdEurxaarESd1dt0z48uF76ZohMSB0VI9v0EGOcJXuGQ/FaZYj7XP5ksqT7zMQi4thCUcgoKYsMrnfhq+kLZy6m9TUhKLjffKwIDF7yWWOrm5phbcdPAhs3TZmLnfieMrltfvOijr7jDeT6RSq+aTfYn6zPI9iheYmXakt1T8A4x8VgcGpCxZjnN/OJlWorWep4xFadIMKsUdw== x-ms-office365-filtering-correlation-id: f8797437-5327-4220-7a0e-08d4716c2ae9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BN3PR16MB0898; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR16MB0898; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0898; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(93886004)(10290500002)(6486002)(110136004)(77096006)(5660300001)(83716003)(82746002)(38730400002)(39060400002)(6506006)(6436002)(4326008)(122556002)(3660700001)(36756003)(3280700002)(305945005)(229853002)(6116002)(102836003)(7736002)(53546009)(50986999)(8676002)(81166006)(6916009)(86362001)(33656002)(2906002)(80792005)(6512007)(8936002)(76176999)(99286003)(6246003)(54906002)(2950100002)(6306002)(54356999)(53936002)(2900100001)(189998001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR16MB0898; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 21:41:15.3971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0898 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsXCpdPErlv//lKEwZYHxhZtbbNYLP4/eMli sfbxRRYHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2Pva6WCbewVLSumMzYwNrN1MXJy SAiYSFy7fYe9i5GLQ0jgE6PEjw8nmWESqxtnsUEkfjJKnN31jAXCOcoo8fLVH6jMS0aJt1da wPpZBDqZJY7N6Icqm8Yk8eDJIqiyY4wSk5afAHI4ONgEDCQ+3ogCWSIioC2x/W4DC4jNLOAm MWVhIztIibBAmMTm614QJeESC+5MZYawrSTW9HeClbMIqEo8O7cG7AleAXuJiV/XQ+19yCjx Ye9xVpAEp4CtxLTtt8EaGAXEJL6fWsMEsUtc4taT+UwQjwpILNlzHuppUYmXj/+xggxiFOhl lFgy9TsrREJH4uz1J4wQtrVE1/f3zCBFEgI9zBLblj5hh0j4Slze2QZlx0hsXjgHqiFbYvG7 dywwzS/P7WaFaJ7FJPFw30qWCYz6s5BcBWHrSCzY/YkNwtaWWLbwNfMssFcFJU7OfMKygJFl FaNCSWlxcW5JfmlJYkGqgaFecWVuMohIBCaWZL3k/NxNjODkUme4g/HRBp9DjAIcjEo8vL73 LkUIsSaWAVUeYpTgYFYS4c09AxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO25NzIUJIID2xJDU7 NbUgtQgmy8TBKdXAqL4udZcV227NRYbSb/pvXVIqk1q+cabLcdu2skjnOWE+XJ+CBB6f3h6U 9u3+k9try+V+TubSl90R0HNbadX8hOu/yhuSzELvtB1PD5mhcM3yteWep68Y+BmVDQrENhwN Uo2eZSe1p/ZI9H+fwJ+XlWtjugNudX+f9ONwwNYVBWa7dzp/9q/MVGIpzkg01GIuKk4EAMmy ywgqAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsXCpdPEpVv//lKEwZx+RYu2tlksFv8fvGSx WPv4IosDs8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH3tVLBNvaKlhXTGRsYm9m6GDk5 JARMJFY3zgKyuTiEBH4ySpzd9YwFwjnKKPHy1R+ozEtGibdXWthBHBaBTmaJYzP6ocqmMUk8 eLIIquwYo8Sk5SeAHA4ONgEDiY83okCWiAhoS2y/28ACYjMLuElMWdjIDlIiLBAmsfm6F0RJ uMSCO1OZIWwriTX9nWDlLAKqEs/OrQG7lVfAXmLi1/VQex8ySnzYe5wVJMEpYCsxbfttsAZG ATGJ76fWMEHsEpe49WQ+E8SjAhJL9pxnhrBFJV4+/scKMohRoJdRYsnU76wQCR2Js9efMELY 1hJd398zgxRJCPQwS2xb+oQdIuErcXlnG5QdI7F54RyohmyJxe/escA0vzy3mxWieRaTxMN9 K6ESMhK3Z3RAJdawSvyd8o1xAqP2LCTnQtg6Egt2f2KDsLUlli18zTwLHAaCEidnPmFZwMiy ilGhpLS4OLcktyQxsSDTwFCvuDI3GUQkAhNLsl5yfu4mRnBycZbYwbjvj88hRgEORiUe3oia SxFCrIllQJWHGKU5WJTEeT8bbooQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLgimD3t4oas GgbeMP9EIwmDEBe7SKs7ouvnhUfkMKdU5Kss7l08NdvFQvPEV9Zdux8VGvh2nV/CfstcmaMn q/z85rbGWYaHVl83LTrCe4Ht8ZbyRdY8Iqs3/pV4upz9lKYVj86/K+HdcuEaAU/dM+b8vcQy 49KnthszhAvqDEJjVFZ+etjyXYmlOCPRUIu5qDgRAAsU9zMPAwAA X-CFilter-Loop: TUS02 Archived-At: Subject: Re: [Trans] [EXT] Re: Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 21:41:22 -0000 Thanks, Melinda--unfortunately I won't be there in person but if I'm not on= a plane I will be remotely participating as well.=20 Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec tarah@symantec.com > On Mar 22, 2017, at 5:14 PM, Melinda Shore wrot= e: >=20 >> On 3/22/17 12:44 PM, Peter Bowen wrote: >> I cannot make it to the meeting in person due to a family commitment >> but can likely join remotely. We know this is after the deadline for >> submittals, hence the rather quick note rather than proposed changes >> to a draft. >=20 > Remote participation is fine - I'd just like to make > sure that we've got a handle on which proposals are > out there during the discussion. >=20 > Melinda >=20 >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Thu Mar 23 07:07:24 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90D129739 for ; Thu, 23 Mar 2017 07:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 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=-2.796, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stevematsumoto.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 nFem-Wd2U6Yd for ; Thu, 23 Mar 2017 07:07:21 -0700 (PDT) Received: from homiemail-a46.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1D21296D8 for ; Thu, 23 Mar 2017 07:07:21 -0700 (PDT) Received: from homiemail-a46.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a46.g.dreamhost.com (Postfix) with ESMTP id 8E8B86A21 for ; Thu, 23 Mar 2017 07:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=stevematsumoto.net; h=to :from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=stevematsumoto.net; bh=mpoQZIT2A/y 6cLuelwaRH4/wH/A=; b=oR797OMHMVfAmJBqUEnwLsFA6JT+yETGeeJq+NSwIsz UHBxCeUMfKc6G/3QToKPANRzJW2u6iRNMib7xwA4zmhNa8s3yNKqGTQjvdsaUat/ O1WFZ87n7dl4/reax4S8PlnM7zmcKIWa0mpp6cIRx/+n5iqHjquXgWL5b+C5NjhI = Received: from syclone-2.local (c-67-186-43-183.hsd1.pa.comcast.net [67.186.43.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: steve@stevematsumoto.net) by homiemail-a46.g.dreamhost.com (Postfix) with ESMTPSA id 4BC036A20 for ; Thu, 23 Mar 2017 07:07:20 -0700 (PDT) To: "trans@ietf.org" From: Steve Matsumoto Message-ID: Date: Thu, 23 Mar 2017 10:07:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] CT Log Costs and Incentives X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 14:07:22 -0000 Hi everyone, I've been thinking lately about the incentives that certificate logs have for operating, and would like to start a discussion centered around the costs and incentives for certificate log operators. It seems to me that CT relies on the altruism of log operators. As far as I know, logs don't receive any sort of compensation for operating, and of the current known and included logs listed on the CT site [1], 4 are run by Google and 5 are run by CAs (Symantec, WoSign/StartSSL, and CNNIC) that had some sort of security incident in the past and had to implement CT as a result [2-4]. So besides the fact that CT will be required in October, what incentives are there to run a certificate log? Are there any plans to add incentives for logs to operate? Complementary to the above question is whether or not the incentives that log operators have outweigh the cost of running a log. I estimate that the storage cost of the certificate entries for the largest log (Google Pilot) is on the order of several hundred gigabytes, and that the cost of reliability, staff, etc. is quite expensive. But if there are any log operators who can comment more on this, that would be great. Moreover, as far as I know, CT also relies on the altruism of log monitors. Logs currently don't offer a way to retrieve entries by domain name, so it's difficult for a domain to query the logs for its own certificates (some of which may be rogue). Moreover, proving that a certificate is not in a log requires checking the entire tree. Therefore, CT needs monitors who periodically retrieve all newly-logged certificates and check for suspicious certificates, and it's not entirely clear how monitors decide whether a certificate is suspicious. What are the incentives for these monitors? Given that the number of logs is small and will probably be limited by Google (partially because monitoring becomes difficult otherwise), are there any plans to incentivize the "best" logs, i.e., those that keep the most certificates or have the highest uptime? Is incentivizing logs in this way something that we should do? I'd be very interested in getting feedback from everyone, particularly log operators and monitors, about this. -Steve [1] https://www.certificate-transparency.org/known-logs [2] https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html [3] https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html [4] https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html From nobody Thu Mar 23 09:57: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 CF3C3129A57 for ; Thu, 23 Mar 2017 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKfen3eSGiJR for ; Thu, 23 Mar 2017 09:57:55 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (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 938F5129A5B for ; Thu, 23 Mar 2017 09:57:55 -0700 (PDT) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat6.net.symantec.com [10.90.75.6]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id BC.49.37454.29EF3D85; Thu, 23 Mar 2017 16:57:54 +0000 (GMT) X-AuditID: 0a5af81a-8fa559a00000924e-b3-58d3fe92f876 Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat6.net.symantec.com [10.90.75.6]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 02.23.09705.29EF3D85; Thu, 23 Mar 2017 16:57:54 +0000 (GMT) Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 23 Mar 2017 09:57:52 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.128.5) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 23 Mar 2017 09:57:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=69HWckkr2H910BqUvGVUo/uRX7X7lrIGPLv9rFnetr8=; b=aqDREmuSWSNF1t3YZuXvC7+De6OPibGb2o1PE3J6Goyw2mtWFcOckiqJZ9HDRfoW2JeXZ77g/0Bm78iqd3FhkIe/D8Rc4Ok9d5MxmsLUEjpvtzwM+80EHryWkbQ/ypMjpRU512giigbiV9LgMRcveeVOYO51pQYmoF7DZi5pWGA= Received: from BN3PR16MB0899.namprd16.prod.outlook.com (10.165.81.153) by BN3PR16MB0898.namprd16.prod.outlook.com (10.165.81.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 16:57:51 +0000 Received: from BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) by BN3PR16MB0899.namprd16.prod.outlook.com ([10.165.81.153]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 16:57:50 +0000 From: Tarah Wheeler To: Steve Matsumoto , "trans@ietf.org" Thread-Topic: [EXT] [Trans] CT Log Costs and Incentives Thread-Index: AQHSo97ZnoxmhgFOfkyq20FZ4OfU4KGiYmiA Date: Thu, 23 Mar 2017 16:57:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 authentication-results: stevematsumoto.net; dkim=none (message not signed) header.d=none;stevematsumoto.net; dmarc=none action=none header.from=symantec.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [155.64.138.28] x-microsoft-exchange-diagnostics: 1; BN3PR16MB0898; 7:FnwpAhRRzFicfjmJjlaI6TTbZfFmp7RE+l3oZVOd2j/F9jEGvB+SusVS6qrSUQy9SZtKIW9DzUqLDjedBnsO98toninzk7OhsJ45R+Etmzjj7vuBHHiSYHwT8JidVTx0fSnrGJbX1HM5a/IL0WtOH+WUpsUpH0hfoA6DdOOHK16dpVbeFrP2K0jYf0hGruu540vR74xM9UOEbiOBL6IhrLTrLsefzxqJ8KzihcMGq5pEE+OP+YYorKYAx7DuV8TfJ/AhmLlUlR9AI4VuHz/JoamFBzL6ULtUobYkcEsKgHR7/pyv5LVARxCXslDjHNVOncBNeJfHhCVYY06IF83AeA== x-ms-office365-filtering-correlation-id: 78de0ba5-536c-49d8-e566-08d4720dbdb4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:BN3PR16MB0898; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR16MB0898; BCL:0; PCL:0; RULEID:; SRVR:BN3PR16MB0898; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(53754006)(377454003)(24454002)(2501003)(6512007)(6306002)(99286003)(66066001)(81166006)(86362001)(53936002)(575784001)(53546009)(83506001)(3660700001)(2906002)(5660300001)(3280700002)(2900100001)(8676002)(8936002)(6436002)(6506006)(76176999)(305945005)(38730400002)(36756003)(189998001)(7736002)(50986999)(10290500002)(6246003)(54356999)(122556002)(80792005)(3846002)(77096006)(6486002)(229853002)(102836003)(6116002)(25786009)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR16MB0898; H:BN3PR16MB0899.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <535912BD622B4D48BAA4412EFC2378A6@namprd16.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 16:57:50.6140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR16MB0898 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69W3er0dPSPK4P6Wr04rJNLP0QUkJiaRhKNMyo67yk+co2 XfYlrS86DbQXq813l2QopEOxdAuWWWlRpjgVUURFdPRBS00saXdXoy8Pv3P+5/+ccx4empRa BDI6LcvA6rKYDLlQTIkTY4RH728MalSud4rwAWchCm+ZHqBOEdFW6xoRvWZpIi8QieKTKWxG Wh6rOxZxTZz65ueSIMdy+OZKVfW2AvT6gAmJaMChYG+wCUxITEvxIoIHU/WCLeFOywTJC6sI 1l11Qj7oRVBkb0B8MI/ge+mst4zCxSSsjFVSvFJBgPnDKPnPs3G326PQtBCrYHEkkUMfnADO 9jiu3258AuYalhDHPjgM+lfNBM8hMHSny8sUVkCbo5LgrBJPfef4RS4txWegwlTtHVuEo6Cw lWskohHeA6t9zV4rif1gbKaG4FfDYO3+QvLsC/PTG16vLw4Gx8ayd0uE6xAslJRtvoUSPrtm ENcXcCDY+/O5GsClJBTcW9y86DzMtU9QPCeBra4S8ZwOPeVzFO+Ngd4eHe81E1DjdlBlSGX+ bz6elVDbtSTkORoqapo280HQWOcmOZbgXfDx6QxViwQvUACjT9ZnGrJzDUwOqwoJ1udnarmD 8XwYbbA2O7MNeb/ML1knmhmPdSJMI/kOycKfQY1UwOR5Kp0IaFLuI5l2e1KSFCb/FqvLvqrL zWD1TrSXpuR+kvKMrxopvs4Y2HSWzWF1WypBi2QFaOcrd1G1zGi4pLZ1WGsDR0KrjM/V54ZN WqY4SKjRDuFnzTaF0qdj6lNr5FTbqiZh3+MJhdHxxKT+bbVb/OOaA2Lbw9ZZ4od2MsroKnkU IRipOu1Qvne+HU7uuxE5u99N+48yltuT2haLOP5yV/zZ7d/qlx8ePJ505VBjJX4pp/SpjPoI qdMzfwFkGQNDLgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsXCFeXNpjvp3+UIgz9zxS0uHmpktFj7+CKL A5PHkiU/mTx+zl7JHMAUxWWTkpqTWZZapG+XwJWx/8sn1oLZmhXf5s5jb2DcpdLFyMkhIWAi 0bT2HnMXIxeHkMB3Ronf1xeyQTjHGCU69i5mhHBeMkq87XkKVsYi0Mks8e3WHBaIzDQmiVkn bjLD9fxr3gOU4eBgEzCQ+HgjCsQUEQiWOLTVH2SfsICZxPPFnxhBbBEBc4nT32cxQdhGElea doPZLAKqEpv2zWECaeUFqt9xJxQkLCTgKjGtax4riM0p4CbRuBFkEScHo4CYxPdTa8BamQXE JW49mc8E8ZqAxJI955khbFGJl4//gfWKCuhJ7Pv3FexLRoGFjBKvuiewQhTpSJy9/oQRZK+E gKLE3tOVIDUSAj3MEg29H6EG+Uo833qPBcKOkdi8cA4jhJ0tcWTicxaIXm+JY0eKIHpnMUnM f70PKi4j8eOYAUT8K4tEy6sDrBMYdWYhuRvC1pFYsPsTG4TtITFt/kqouLbEsoWvmUFsXgFB iZMzn7AsYGRdxaiQWJxUnFuSW5KYWJBpYKRXXJmbDCISgeklWS85P3cTIzjF/BbfwXjuj88h RgEORiUe3ojPlyOEWBPLgCoPMUpzsCiJ894w3BQhJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gVHFge9Ah6Kwl7n2JtfyDyvCa3p4vnk57PLczzObg9WQMS1RMNQ5MKBrWduhwn18E7JPPFx0 z/jO7zOP+JJ720qzJl44k/zW7d6fJx9erZ0hIzRxuyRH+QapaWmvjN6cC3K8EvreSFTm664H kbssHsh8/PLq8/37iSqfll4uuaF24qSphhnvZS4lluKMREMt5qLiRABvApSiEgMAAA== X-CFilter-Loop: ASB02 Archived-At: Subject: Re: [Trans] [EXT] CT Log Costs and Incentives X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:57:58 -0000 What are the financial incentives of the non-opaque log operators? I mistrust altruism as regards incentive for long-term stability. Is log operation a loss leader for orgs that provide other, more profitable services? --=20 Tarah M. Wheeler On 3/23/17, 10:07 AM, "Trans on behalf of Steve Matsumoto" wrote: >Hi everyone, > >I've been thinking lately about the incentives that certificate logs >have for operating, and would like to start a discussion centered around >the costs and incentives for certificate log operators. > >It seems to me that CT relies on the altruism of log operators. As far >as I know, logs don't receive any sort of compensation for operating, >and of the current known and included logs listed on the CT site [1], 4 >are run by Google and 5 are run by CAs (Symantec, WoSign/StartSSL, and >CNNIC) that had some sort of security incident in the past and had to >implement CT as a result [2-4]. So besides the fact that CT will be >required in October, what incentives are there to run a certificate log? >Are there any plans to add incentives for logs to operate? > >Complementary to the above question is whether or not the incentives >that log operators have outweigh the cost of running a log. I estimate >that the storage cost of the certificate entries for the largest log >(Google Pilot) is on the order of several hundred gigabytes, and that >the cost of reliability, staff, etc. is quite expensive. But if there >are any log operators who can comment more on this, that would be great. > >Moreover, as far as I know, CT also relies on the altruism of log >monitors. Logs currently don't offer a way to retrieve entries by domain >name, so it's difficult for a domain to query the logs for its own >certificates (some of which may be rogue). Moreover, proving that a >certificate is not in a log requires checking the entire tree. >Therefore, CT needs monitors who periodically retrieve all newly-logged >certificates and check for suspicious certificates, and it's not >entirely clear how monitors decide whether a certificate is suspicious. >What are the incentives for these monitors? > >Given that the number of logs is small and will probably be limited by >Google (partially because monitoring becomes difficult otherwise), are >there any plans to incentivize the "best" logs, i.e., those that keep >the most certificates or have the highest uptime? Is incentivizing logs >in this way something that we should do? > >I'd be very interested in getting feedback from everyone, particularly >log operators and monitors, about this. > >-Steve > >[1]=20 >https://clicktime.symantec.com/a/1/59oePpKbG62hyNDvpJjPTDfulpqyjTGck38AfdP >V-S4=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6 >LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy >dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP >XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8 >p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fwww.certificate-transpa= re >ncy.org%2Fknown-logs >[2] >https://clicktime.symantec.com/a/1/mw81gxILG0yv90ZXFS1qixOhC68j21cVWOlygtZ >HNc8=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6 >LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy >dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP >XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8 >p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >F2015%2F03%2Fmaintaining-digital-certificate-security.html >[3] >https://clicktime.symantec.com/a/1/L7ETjKNjE6aJIg2kJxMA-ySmW4-RcYG3BFCECcQ >T--k=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6 >LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy >dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP >XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8 >p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >F2015%2F10%2Fsustaining-digital-certificate-security.html >[4] >https://clicktime.symantec.com/a/1/TgVn9TlunMWDKiq9pWSvDsi2V-ip6xtqx8yPiWe >0ZuM=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6 >LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy >dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP >XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8 >p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >F2016%2F10%2Fdistrusting-wosign-and-startcom.html > >_______________________________________________ >Trans mailing list >Trans@ietf.org >https://www.ietf.org/mailman/listinfo/trans From nobody Thu Mar 23 13:33:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636C129C0C for ; Thu, 23 Mar 2017 13:33:22 -0700 (PDT) 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 dyU0OdAmchc4 for ; Thu, 23 Mar 2017 13:33:21 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 3000113164C for ; Thu, 23 Mar 2017 13:33:21 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id p189so87414935pfp.1 for ; Thu, 23 Mar 2017 13:33:21 -0700 (PDT) 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=TA4C1rRDoYqRAsVRlZZUTTdUGlFzmLDu7x41En7/5vM=; b=sCU/5Pti0Kq2VoXauTlCsd+gJqNpgKFetWMphZHD6CXypfugyipCoCLjbmPA9xlfDi ogz8yQfbbbviD3KCShTOcMxMroshKcB8PS6suooURlMW3AFGytOPcKF6D2IFJaiv0EE1 MfGg2soOU8ID1QaLIw45Sdw46mMtEcUwB/s5kT0N0+tnSUSlS4L/BnAQ9mWCt+jh8gTM 9KqzQSYmbKvomsL5rZUSEBit+ErpiwJ17v5B3OjQ4gZ8ZCR6GhIE2Dfim/Ya6UCfBMGc huak+pOqIi5xOI0eTpx5L2A9gXdwSaNCe8cDFds3psfklCg3J4mndar8ufxPHXmrnO1U PvkA== 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=TA4C1rRDoYqRAsVRlZZUTTdUGlFzmLDu7x41En7/5vM=; b=ZSb4CAQSzGIp8pH2L4qHaEur9KZj8PrZSvPCTtdkOPzCMrfK+ZTO1Us3dOtZIVrLSb cfHutcy2uEfsbfeQI/Lom2ICqbV0O0jtp2CSurfNdblWb/G8UyixYRLxWdpYeJ1j/x0b 6hvcvIRI4Z+lvMaIwrOEzTAnUWA9aw4oc9A4W0UMPCPQyHSjBuA7CoZYcvI3zvwEAdrg dF4DVTMQJdztxtQxDh7W+bNU/J9RgWFKx7dT5XUI9xmrJiZ3M/9NwUclXtYtnqWRSiZ+ aXsndpMbQKbMMItLXN5Ga9WvhbYN+62Yavsnq/WD+9C4ncyqvZPjn34uYK+XiTBsYDz5 G/kw== X-Gm-Message-State: AFeK/H0CB9ejC0umxmR5I8zRdC5ii4R6rLs1NswA3vcsnK+F5g/p14/ttVMAMxHQR3dajQ== X-Received: by 10.99.211.69 with SMTP id u5mr4930148pgi.82.1490301200244; Thu, 23 Mar 2017 13:33:20 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (74-124-98-225-radius.dynamic.acsalaska.net. [74.124.98.225]) by smtp.gmail.com with ESMTPSA id g5sm130643pfe.12.2017.03.23.13.33.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 13:33:19 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <716e13d7-680e-ee3f-1a78-89c3c2af6547@gmail.com> Date: Thu, 23 Mar 2017 12:33:17 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A0KMWp6ILAqwdRlSJ4WWMUKTBW0lX6VVC" Archived-At: Subject: [Trans] Slides! X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 20:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A0KMWp6ILAqwdRlSJ4WWMUKTBW0lX6VVC Content-Type: multipart/mixed; boundary="sMUdVV4NXpj93NG8CEP0XrBNvuCErblWr"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <716e13d7-680e-ee3f-1a78-89c3c2af6547@gmail.com> Subject: Slides! --sMUdVV4NXpj93NG8CEP0XrBNvuCErblWr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you've got a spot on the trans agenda and will be using slides, please get those to me for uploading. You can update them later to add or change material but getting them uploaded now will be a big help to meeting participants. Many thanks, Melinda --sMUdVV4NXpj93NG8CEP0XrBNvuCErblWr-- --A0KMWp6ILAqwdRlSJ4WWMUKTBW0lX6VVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY1DENAAoJELiGRpM6HoEu0mMQAKvvwpBdaHQaj/+a4WoCHe+G ksvZhyECfO9QhvMwoGH7n6itZ6D2xCdwZ+TXKnBf7kG/IENh11Sk2C9kHgvV0zga Kuh1kjdNZ5BlOHvmMpYi35qJMzcbbPYNBRL2M1AMA97Xmeg8RADSkfqiX8BMelzw 1cMXuv0SFzNoUJrIiyV4RVKGnlXBY9FbJdmnBnsTp+06aPV7B/2Rfe6tD7NCozUW sdob3tSGA5sKgeYIqzpJGTNS7ateQxDNhMLSNrpcrdIX0T1bRqiohysIlHAbt/1Q IkGmuoSkPrjNf/TBwzaESOnBpHRtHozS2hf5jCB/33tPqp1rcTLG96OEO+C4Kwui csBXYYJRg11uOorbTpG6tBvAcxSRTbWJPVVDLDWFHk7uXkUn2rGbpvlfriKJ9wY1 1vfiyLa/yrUAcnVIUPVp0f1ZCGXi8H+jA0mDBiUrqKCGNQSmDk7NmCjcjkqQIgO8 sTR8O9RYJVuJe8yrAa1kCB0jO18BGvnpeK9R/6lxXQQ4/ygLSRPB2BC0s79+fd5E qUfIMC679kO777woi+PuWJXFEsJ2ReigvzgSbhwcrPUywsO8s5IW0N8RTenmLv4N NAXLJtR2j24yDm0de5wyIFApWC4in7VhHBbgov+7gT/PSBF1UiuoSiRTkANIOYNf B+oXhpuIxMw3UpnaLKKD =76ZH -----END PGP SIGNATURE----- --A0KMWp6ILAqwdRlSJ4WWMUKTBW0lX6VVC-- From nobody Thu Mar 23 17:52: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 33504129BAD for ; Thu, 23 Mar 2017 17:52:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 AfTOSyaw5Pov for ; Thu, 23 Mar 2017 17:52:29 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 6C42C124B0A for ; Thu, 23 Mar 2017 17:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490316749; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Mfa2kic2IAuba3UNnzS95xLnfEncF7shKDE5h/YBPOs=; b=gFmzt9UPpApDVuu+gtA1GDYo/zxqabnz6n47cdFYwcL2/OFG2jHlW3w+ftzR8TFA sa+JHoFvbeWgaRX1TreDu+9c7K9z7jJALud7L+C5MzGeIKuIytB8S4fNRX03Oq3q 8H5ESU/A662FOCOpY5TdsCKjG3X6erKjVUYgE/TgVePX2tBoSlLKeskL3QvjNlDX hf5GUccmP2ScvkQfm0kLxaU5frZVQwUQ8CYeBU90RycOe+k9B+pmTqMxjg3VKBIw mIsHeKjYEpZj2+2WLZ6XrWRoDhyzGJwsNOnyNOpk9PLy48mwyfcZDMlf+nAyVYB8 lQfNY8QgBTU/44tuufGiGg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 3B.72.25383.CCD64D85; Thu, 23 Mar 2017 17:52:29 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-fa-58d46dcd76bc Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id 2F.4F.03007.CCD64D85; Thu, 23 Mar 2017 17:52:28 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_phaH/owmZA+Fqzde7QOuCw)" Received: from [17.153.46.23] (unknown [17.153.46.23]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONA00F7ENRG3W60@nwk-mmpp-sz10.apple.com>; Thu, 23 Mar 2017 17:52:28 -0700 (PDT) Sender: devon.obrien@apple.com From: Devon O'Brien Message-id: Date: Thu, 23 Mar 2017 17:52:27 -0700 In-reply-to: Cc: Steve Matsumoto , "trans@ietf.org" To: Tarah Wheeler References: X-Mailer: Apple Mail (2.3271) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FAYrns290qEwb7/rBYXDzUyWrzed5/N Yu3jiywOzB5Llvxk8vg5eyWzx47zU5gDmKO4bFJSczLLUov07RK4Mras/s1asOsrY8WKKeeY GhjfXmfsYuTgkBAwkdi/pb6LkYtDSGAvo8TtSXOZuxg5weIb5zWygthCAocYJY6/TAOxeQUE JX5MvscCYjMLhEnca/zJAtHczySxpXc5WEJYQE5i1dmHYDabgI7Ejdvz2SGabSQ6n/9khKgx l/j0ZTGYzSKgKjF17ns2kIM4geJPT3CBmMwCwRL352SDVIgI6ElcW3KRHSQsJFAk8eeXKcSV shLb781ghLBPsEn0dIpMYBSaheTQWUgOnQU2VF1iypRciLC2xJN3F1ghbDWJhb8XMSGLL2Bk W8UolJuYmaObmWeil1hQkJOql5yfu4kRFBnT7YR2MJ5aZXWIUYCDUYmHN6LmUoQQa2JZcWXu IUZpDhYlcV5tkcsRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgNdZdrb9c6UZna5+JbKn5O s/3IJ/up718mXp27WXKl88ltT5aEFRh1nOLgXrfif6xwYtmhvO1hij1eCxo5t8/zDJo5w7O1 XSE7rjHCxdHDW3z9qVNTnf1Ns6/PfPVB+ebnCBsDJgHeMGnxVV3yyVuPeSzzSbJc7LFR4iFz TvLH/Z/3z/ifYKnEUpyRaKjFXFScCAAdtxrNbQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUi2FBcpXsm90qEwbV7FhYXDzUyWrzed5/N Yu3jiywOzB5Llvxk8vg5eyWzx47zU5gDmKO4bFJSczLLUov07RK4Mras/s1asOsrY8WKKeeY GhjfXmfsYuTkkBAwkdg4r5EVxBYSOMQocfxlGojNKyAo8WPyPRYQm1kgTOJe408gmwuopp9J YkvvcrCEsICcxKqzD8FsNgEdiRu357NDNNtIdD7/yQhRYy7x6ctiMJtFQFVi6tz3bF2MHByc QPGnJ7hATGaBYIn7c7JBKkQE9CSuLbnIDhIWEiiS+PPLFOJKWYnt92YwTmDkn4XkuFlIjpsF NkhdYsqUXIiwtsSTdxdYIWw1iYW/FzEhiy9gZFvFKFCUmpNYaaKXWFCQk6qXnJ+7iREczIXh Oxj/LbM6xCjAwajEwxtRcylCiDWxrLgyFxhAHMxKIrw3sq5ECPGmJFZWpRblxxeV5qQWH2Kc yAj04URmKdHkfGCs5ZXEG5qYGJgYG5sZG5ubmNNSWEmct+sL0JEC6YklqdmpqQWpRTBHMXFw SjUw2i3uWOjMs+7JBpufe44JiK/s8LKf3L1pwRKvna7XMn2iDTY+cWywVPOq+7fzmfbSNyd6 Le92/D8+a6vBrtRqvYsS4au4znOek/Y5fKD32rcV+/viPGfsMNI9US037fDfyc+MOcOu1cu9 yms6tnrVS7eFX9aL/YhRmuNUZhQmIFRZkX765aZbU5RYijMSDbWYi4oTAZko9/zZAgAA Archived-At: Subject: Re: [Trans] [EXT] CT Log Costs and Incentives X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 00:52:32 -0000 --Boundary_(ID_phaH/owmZA+Fqzde7QOuCw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable While there might or might not be a direct financial incentive for log = operation, there are stakeholders in the CT ecosystem with very = compelling indirect incentives. As Chrome has demonstrated, User Agents have the strongest incentive. = They represent their users=E2=80=99 interest in a secure browsing = experience, and detecting and responding to mis-issuances within the = WebPKI solidifies that promise to their users. In most, but not all = cases, User Agents tend to also have the financial and infrastructural = resources in place to operate a high assurance log. Similarly, entities = like certain government agencies could also step up in this area since = they operate on a similar mandate. To a lesser extent, large PKIs have an incentive to run logs as well. = Given certificate logging requirements, it makes sense that a massive = PKI would rather deploy and depend upon their own CT log rather than = depend on what=E2=80=99s turned out to be a more tumultuous log = ecosystem than expected. As Steve pointed out, relying on the altruism = of a log operator can be a hard business case to make. Beyond either of these two cases, log operators can charge back = infrastructure costs to CAs submitting to the log. These can be = volume-based fees designed to allow scalability or allow for periodic = renegotiation. Personally, I like this model the least since it offers = the weakest commitment to CAs and UAs for continued operation. As has been discussed on a few occasions over the past few years, many = players in the CT ecosystem don=E2=80=99t see the need for more than = 10-20 logs to exist in total. This threshold can feasibly be met by the = above cases without requiring logs to operate as a token of goodwill. - Devon > On Mar 23, 2017, at 09:57, Tarah Wheeler = wrote: >=20 > What are the financial incentives of the non-opaque log operators? I > mistrust altruism as regards incentive for long-term stability. Is log > operation a loss leader for orgs that provide other, more profitable > services? >=20 >=20 > --=20 > Tarah M. Wheeler >=20 >=20 >=20 >=20 >=20 > On 3/23/17, 10:07 AM, "Trans on behalf of Steve Matsumoto" > on behalf of = steve@stevematsumoto.net > wrote: >=20 >> Hi everyone, >>=20 >> I've been thinking lately about the incentives that certificate logs >> have for operating, and would like to start a discussion centered = around >> the costs and incentives for certificate log operators. >>=20 >> It seems to me that CT relies on the altruism of log operators. As = far >> as I know, logs don't receive any sort of compensation for operating, >> and of the current known and included logs listed on the CT site [1], = 4 >> are run by Google and 5 are run by CAs (Symantec, WoSign/StartSSL, = and >> CNNIC) that had some sort of security incident in the past and had to >> implement CT as a result [2-4]. So besides the fact that CT will be >> required in October, what incentives are there to run a certificate = log? >> Are there any plans to add incentives for logs to operate? >>=20 >> Complementary to the above question is whether or not the incentives >> that log operators have outweigh the cost of running a log. I = estimate >> that the storage cost of the certificate entries for the largest log >> (Google Pilot) is on the order of several hundred gigabytes, and that >> the cost of reliability, staff, etc. is quite expensive. But if there >> are any log operators who can comment more on this, that would be = great. >>=20 >> Moreover, as far as I know, CT also relies on the altruism of log >> monitors. Logs currently don't offer a way to retrieve entries by = domain >> name, so it's difficult for a domain to query the logs for its own >> certificates (some of which may be rogue). Moreover, proving that a >> certificate is not in a log requires checking the entire tree. >> Therefore, CT needs monitors who periodically retrieve all = newly-logged >> certificates and check for suspicious certificates, and it's not >> entirely clear how monitors decide whether a certificate is = suspicious. >> What are the incentives for these monitors? >>=20 >> Given that the number of logs is small and will probably be limited = by >> Google (partially because monitoring becomes difficult otherwise), = are >> there any plans to incentivize the "best" logs, i.e., those that keep >> the most certificates or have the highest uptime? Is incentivizing = logs >> in this way something that we should do? >>=20 >> I'd be very interested in getting feedback from everyone, = particularly >> log operators and monitors, about this. >>=20 >> -Steve >>=20 >> [1]=20 >> = https://clicktime.symantec.com/a/1/59oePpKbG62hyNDvpJjPTDfulpqyjTGck38AfdP= = >> = V-S4=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >> = Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6= >> = LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy= >> = dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP= >> = XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8= >> = p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fwww.certificate-transpa= re >> ncy.org %2Fknown-logs >> [2] >> = https://clicktime.symantec.com/a/1/mw81gxILG0yv90ZXFS1qixOhC68j21cVWOlygtZ= = >> = HNc8=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >> = Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6= >> = LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy= >> = dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP= >> = XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8= >> = p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >> F2015%2F03%2Fmaintaining-digital-certificate-security.html >> [3] >> = https://clicktime.symantec.com/a/1/L7ETjKNjE6aJIg2kJxMA-ySmW4-RcYG3BFCECcQ= = >> = T--k=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >> = Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6= >> = LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy= >> = dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP= >> = XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8= >> = p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >> F2015%2F10%2Fsustaining-digital-certificate-security.html >> [4] >> = https://clicktime.symantec.com/a/1/TgVn9TlunMWDKiq9pWSvDsi2V-ip6xtqx8yPiWe= = >> = 0ZuM=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-= UKNt >> = Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6= >> = LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy= >> = dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP= >> = XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8= >> = p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com= %2 >> F2016%2F10%2Fdistrusting-wosign-and-startcom.html >>=20 >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans = >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans = --Boundary_(ID_phaH/owmZA+Fqzde7QOuCw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable While there might or might not be a direct financial = incentive for log operation, there are stakeholders in the CT ecosystem = with very compelling indirect incentives.

As Chrome has demonstrated, User Agents = have the strongest incentive. They represent their users=E2=80=99 = interest in a secure browsing experience, and detecting and responding = to mis-issuances within the WebPKI solidifies that promise to their = users. In most, but not all cases, User Agents tend to also have the = financial and infrastructural resources in place to operate a high = assurance log. Similarly, entities like certain government agencies = could also step up in this area since they operate on a similar = mandate.

To a = lesser extent, large PKIs have an incentive to run logs as well. Given = certificate logging requirements, it makes sense that a massive PKI = would rather deploy and depend upon their own CT log rather than depend = on what=E2=80=99s turned out to be a more tumultuous log ecosystem than = expected. As Steve pointed out, relying on the altruism of a log = operator can be a hard business case to make.

Beyond either of these two cases, log = operators can charge back infrastructure costs to CAs submitting to the = log. These can be volume-based fees designed to allow scalability or = allow for periodic renegotiation. Personally, I like this model the = least since it offers the weakest commitment to CAs and UAs for = continued operation.

As has been discussed on a few occasions over the past few = years, many players in the CT ecosystem don=E2=80=99t see the need for = more than 10-20 logs to exist in total. This threshold can feasibly be = met by the above cases without requiring logs to operate as a token of = goodwill.

- = Devon

On Mar 23, 2017, at 09:57, Tarah Wheeler <Tarah_Wheeler@symantec.com> wrote:

What are the financial = incentives of the non-opaque log operators? I
mistrust altruism as regards incentive for = long-term stability. Is log
operation a loss leader for orgs = that provide other, more profitable
services?
-- 
Tarah M. Wheeler

On 3/23/17, 10:07 AM, "Trans on behalf of Steve = Matsumoto"
<trans-bounces@ietf.org on behalf of steve@stevematsumoto.net> wrote:

Hi everyone,
I've been thinking lately about the incentives that = certificate logs
have for operating, and would like to = start a discussion centered around
the costs and = incentives for certificate log operators.

It = seems to me that CT relies on the altruism of log operators. As far
as I know, logs don't receive any sort of compensation for = operating,
and of the current known and included logs = listed on the CT site [1], 4
are run by Google and 5 are = run by CAs (Symantec, WoSign/StartSSL, and
CNNIC) that had = some sort of security incident in the past and had to
implement CT as a result [2-4]. So besides the fact that CT = will be
required in October, what incentives are there to = run a certificate log?
Are there any plans to add = incentives for logs to operate?

Complementary= to the above question is whether or not the incentives
that= log operators have outweigh the cost of running a log. I estimate
that the storage cost of the certificate entries for the = largest log
(Google Pilot) is on the order of several = hundred gigabytes, and that
the cost of reliability, = staff, etc. is quite expensive. But if there
are any log = operators who can comment more on this, that would be great.

Moreover, as far as I know, CT also relies on = the altruism of log
monitors. Logs currently don't offer a = way to retrieve entries by domain
name, so it's difficult = for a domain to query the logs for its own
certificates = (some of which may be rogue). Moreover, proving that a
certificate is not in a log requires checking the entire = tree.
Therefore, CT needs monitors who periodically = retrieve all newly-logged
certificates and check for = suspicious certificates, and it's not
entirely clear how = monitors decide whether a certificate is suspicious.
What = are the incentives for these monitors?

Given = that the number of logs is small and will probably be limited by
Google (partially because monitoring becomes difficult = otherwise), are
there any plans to incentivize the "best" = logs, i.e., those that keep
the most certificates or have = the highest uptime? Is incentivizing logs
in this way = something that we should do?

I'd be very = interested in getting feedback from everyone, particularly
log operators and monitors, about this.

-Steve

[1] 
https://clicktime.symantec.com/a/1/59oePpKbG62hyNDvpJjPTDfulpqy= jTGck38AfdP
V-S4=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9= IvfgPMVtpK-UKNt
Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ= 5xLjGfHLMj6
LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEa= i3x8ytUDPBy
dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5M= qM5ZYk3EqhP
XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9Rt= cflWCpFBjX8
p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fwww.cert= ificate-transpare
ncy.org%2Fknown-logs
[2]
https://clicktime.symantec.com/a/1/mw81gxILG0yv90ZXFS1qixOhC68j= 21cVWOlygtZ
HNc8=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9= IvfgPMVtpK-UKNt
Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ= 5xLjGfHLMj6
LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEa= i3x8ytUDPBy
dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5M= qM5ZYk3EqhP
XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9Rt= cflWCpFBjX8
p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com%2
F2015%2F03%2Fmaintaining-digital-certificate-security.html
[3]
https://clicktime.symantec.com/a/1/L7ETjKNjE6aJIg2kJxMA-ySmW4-R= cYG3BFCECcQ
T--k=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9= IvfgPMVtpK-UKNt
Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ= 5xLjGfHLMj6
LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEa= i3x8ytUDPBy
dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5M= qM5ZYk3EqhP
XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9Rt= cflWCpFBjX8
p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com%2
F2015%2F10%2Fsustaining-digital-certificate-security.html
[4]
https://clicktime.symantec.com/a/1/TgVn9TlunMWDKiq9pWSvDsi2V-ip= 6xtqx8yPiWe
0ZuM=3D?d=3DCAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9= IvfgPMVtpK-UKNt
Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ= 5xLjGfHLMj6
LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEa= i3x8ytUDPBy
dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5M= qM5ZYk3EqhP
XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9Rt= cflWCpFBjX8
p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=3Dhttps%3A%2F%2Fsecurity.googleblog.com%2
F2016%2F10%2Fdistrusting-wosign-and-startcom.html

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

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

= --Boundary_(ID_phaH/owmZA+Fqzde7QOuCw)-- From nobody Sat Mar 25 15:39:26 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 F200E127337 for ; Sat, 25 Mar 2017 15:39:24 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=office365stanford.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oRrYg6vvxfA for ; Sat, 25 Mar 2017 15:39:22 -0700 (PDT) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (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 DC3431277BB for ; Sat, 25 Mar 2017 15:39:22 -0700 (PDT) Received: from pps.filterd (m0102886.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2PMcoTK009961 for ; Sat, 25 Mar 2017 15:39:20 -0700 Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 29dpqb91bg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 25 Mar 2017 15:39:20 -0700 Received: from pps.filterd (m0102883.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2PMTFPm031962 for ; Sat, 25 Mar 2017 15:39:19 -0700 Received: from codegreen8.stanford.edu (codegreen8.stanford.edu [171.67.224.10]) by mx0a-00000d03.pphosted.com with ESMTP id 29dq12ugmb-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 25 Mar 2017 15:39:19 -0700 Received: from codegreen8.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen8.stanford.edu (Postfix) with ESMTP id E308E47 for ; Sat, 25 Mar 2017 15:39:18 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0081.outbound.protection.outlook.com [207.46.163.81]) by codegreen8.stanford.edu (Postfix) with ESMTP id 74AA947 for ; Sat, 25 Mar 2017 15:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=office365stanford.onmicrosoft.com; s=selector1-stanford-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N7bqbbun0S4BlfCEpVntQLaicjbYDZxmcIzHh8mtReA=; b=KKjnUbXPiE7c+LpYg0L2A3A7efJWhUIJtvy0lfuFqROYMn1XyW9E7ISmXC219SE6Y/6zFAVTP7FBg88Znk26rojjUKiOm/I5GLXFrmW2A0DzSZmX7Jzhol9rsIj7tnA51EM24Qqp67ZwgpuoUb5BBBldluPIDQuSQ0vvA/zS+98= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2862.namprd02.prod.outlook.com (10.175.50.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sat, 25 Mar 2017 22:39:16 +0000 Received: from MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) by MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) with mapi id 15.01.0991.018; Sat, 25 Mar 2017 22:39:16 +0000 From: Saba Eskandarian To: "trans@ietf.org" Thread-Topic: Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvg== Date: Sat, 25 Mar 2017 22:39:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [40.77.16.207] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2862; 7:RuEM+lemHGZdX863/GvD4EmZXrXH6uTBEoI5N/j6d6uPpOqFHc6IQLo7P085oxjUhKCX9kkIpD0wLAEOLB0deqEtR+8FeZYEu2W5iBPZ2JYV2z1C8pr1UlzAjViQcoRAsfOvKBToHs6k84UXBHgO8CftSElp3yP0BbVlx6+dtEP9L19CZJnGkUSd56y4JYxv1BKd23RF4MNiThaFiqnkxsaHHP1sN9BahU/H7O3vKaACcTXoESjtk6MOfBDa04G7+VZ9KDAdykzgmZaJfgUMpOhxuu7wlczoheO/mXAwCkH59Kuus/mqk7qC2uc1H/xECYXXUsjk1nnb5NXATshXmQ== x-ms-office365-filtering-correlation-id: 14a24800-bf81-4a49-573d-08d473cfc51f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR02MB2862; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127643986962959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:MWHPR02MB2862; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2862; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39830400002)(8676002)(102836003)(6116002)(1730700003)(3846002)(25786009)(2906002)(86362001)(6916009)(88552002)(81166006)(77096006)(53936002)(74316002)(7736002)(5640700003)(7696004)(6436002)(38730400002)(110136004)(33656002)(189998001)(66066001)(75432002)(6506006)(99286003)(55016002)(122556002)(3280700002)(5660300001)(54896002)(6306002)(54356999)(2501003)(9686003)(50986999)(305945005)(8936002)(2351001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR02MB2862; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB2861B9B66FE5AE28613ECFB5C3310MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2017 22:39:16.7569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2862 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-25_18:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-25_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703250210 Archived-At: Subject: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 25 Mar 2017 22:39:25 -0000 --_000_MWHPR02MB2861B9B66FE5AE28613ECFB5C3310MWHPR02MB2861namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago). My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209 Thanks and looking forward to meeting you all next week! ~saba --_000_MWHPR02MB2861B9B66FE5AE28613ECFB5C3310MWHPR02MB2861namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!

~saba

--_000_MWHPR02MB2861B9B66FE5AE28613ECFB5C3310MWHPR02MB2861namp_-- From nobody Sun Mar 26 09:46:26 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 27C2112957F for ; Sun, 26 Mar 2017 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIapqk3OpSbx for ; Sun, 26 Mar 2017 09:46:23 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAA01293DF for ; Sun, 26 Mar 2017 09:46:23 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id s68so30037541vke.3 for ; Sun, 26 Mar 2017 09:46:23 -0700 (PDT) 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=vUGSYX1V244thdRn81tDwgUiaZ+vNEarYtc8SvH34oM=; b=pmslIcK6JZb1tOsUmrP/zh5uP5cVSanzjStxCBlUqK2Y37zxiyT+Zb6h94TNyYfdnQ IGCNd/MGpKOPuPolvycFFl7MZUvOCTQQIAv/rVHqdi2y1CGh9DvdgZdquYT/EiEahIO2 3wgkY6gQqCsjyY/D1nwqEfzT0HocdL8FNNmtw3W7f4xMtI4Z8oshpKOonKPzSBwltSCk ++mA6fmQbJNj0ruBnn+l0IUccSBwPyM6cAeTClNsQKzSjnKVA/8S6+w9CBate5vuxbOQ 8VdAmZjelxsoR8O+R9KAbyXrYtjDbv1eAFASB0kVGXCFGi91ivIAAQBanFoyqF1+4F9R r4Dw== 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=vUGSYX1V244thdRn81tDwgUiaZ+vNEarYtc8SvH34oM=; b=kxu10250g47/KyPBLuHQBoBWfzAxFoqcJlHs4NXElmj6CffhROH2nXM7eImdMl4gtr tD6ybdvnOiBc9WgfHjYf+CEm64wrEdoX6OleP4iS9Eg3wZIQDn2dW1djjQGitPyehd7f cUX96l56YHlcckJ5PnKsjp8h6APZbCO1LYN4EcvyVgd+OiQEVg+b3rlaOs2//9jGVoJt I+8stvG4L8mHTe9elTxIs5Rzi45yIFG0EkeFfaRd+oGEJiPJzC5RPnCrrl63cNS/MxLg I8qLzp50xs4u0/TjHdGTBF/DYXg9fGOZp+H0TrdQ02A9Fz3ms/irH4HGon1S6OeLss5f Va7g== X-Gm-Message-State: AFeK/H1e/O4SQ1m30BUs62sfxsLVNzoQs83RkmuG3bRRaWII7YSoxigpg9scK/YoS9InIq452/tm0oXcAUlKA+Ye X-Received: by 10.159.59.9 with SMTP id i9mr8815973uah.6.1490546782291; Sun, 26 Mar 2017 09:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Sun, 26 Mar 2017 09:46:21 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Sun, 26 Mar 2017 17:46:21 +0100 Message-ID: To: Saba Eskandarian Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=f403043c51d07b5566054ba4f776 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 26 Mar 2017 16:46:25 -0000 --f403043c51d07b5566054ba4f776 Content-Type: text/plain; charset=UTF-8 On 25 March 2017 at 22:39, Saba Eskandarian wrote: > Hello, > > I'm on the agenda for Tuesday's meeting to share a privacy-preserving > proof of sct exclusion from a log (I think Eran alluded to this work in a > message a while ago). > > My posted slides will not include many words, so I wanted to share a link > to the preprint of our academic paper on the subject in case anyone wants > to read the details there. The paper is targeted at a somewhat different > audience, but it can be found here: https://arxiv.org/abs/1703.02209 > > Thanks and looking forward to meeting you all next week! > Cool, but I immediately see a problem - you require logs to be in timestamp order, but they aren't. I can't immediately think of a way to get that property without also considerably increasing time to inclusion in the log. That seems undesirable - in fact, we're trying to go the other way, i.e. reduce time to inclusion, in general. Also, engineering reality doesn't change, so increasing time to inclusion is also likely to increase MMD. Secondly, its interesting, but doesn't seem particularly useful: when an SCT corresponds to a cert that has not been included, you want to reveal the cert, not hide it. What you want to hide is who is revealing it. ~saba > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --f403043c51d07b5566054ba4f776 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.edu&g= t; wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preservi= ng proof of sct exclusion from a log (I think Eran alluded to this work in = a message a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arx= iv.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require= logs to be in timestamp order, but they aren't. I can't immediatel= y think of a way to get that property without also considerably increasing = time to inclusion in the log.

That seems undesirab= le - in fact, we're trying to go the other way, i.e. reduce time to inc= lusion, in general.

Also, engineering reality does= n't change, so increasing time to inclusion is also likely to increase = MMD.

Secondly, its interesting, but doesn't se= em particularly useful: when an SCT corresponds to a cert that has not been= included, you want to reveal the cert, not hide it. What you want to hide = is who is revealing it.

=

~saba


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


--f403043c51d07b5566054ba4f776-- From nobody Sun Mar 26 21:17: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 D7F9C1276AF for ; Sun, 26 Mar 2017 21:17:14 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=office365stanford.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmFpF0r7gboV for ; Sun, 26 Mar 2017 21:17:12 -0700 (PDT) Received: from mx0a-00000d04.pphosted.com (mx0a-00000d04.pphosted.com [148.163.149.245]) (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 B4656126D85 for ; Sun, 26 Mar 2017 21:17:11 -0700 (PDT) Received: from pps.filterd (m0102889.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2R4DMAM009103; Sun, 26 Mar 2017 21:17:09 -0700 Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 29dnv3b4fb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Mar 2017 21:17:08 -0700 Received: from pps.filterd (m0102883.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2R4FXUR012997; Sun, 26 Mar 2017 21:17:07 -0700 Received: from codegreen6.stanford.edu (codegreen6.stanford.edu [171.67.224.8]) by mx0a-00000d03.pphosted.com with ESMTP id 29dq1324r4-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Sun, 26 Mar 2017 21:17:07 -0700 Received: from codegreen6.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen6.stanford.edu (Postfix) with ESMTP id 2157146; Sun, 26 Mar 2017 21:17:07 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0016.outbound.protection.outlook.com [216.32.180.16]) by codegreen6.stanford.edu (Postfix) with ESMTP id B5F8B54; Sun, 26 Mar 2017 21:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=office365stanford.onmicrosoft.com; s=selector1-stanford-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N7M2N4a+/m1rNAv2uSKejeIBrOb/OCn6UKhEQMIDbv8=; b=pjozuwYRPTn3/SpLJnnnDOmqo2F9yIi/b2S+4uit7HLliAqzRFv6ZqvT+EbsOIdEXDWlDqM5026zsoZrCDuG7esbLYZGw6T3NdA31p0HE3D/rLNVPA/85VslwpLo+KcixB2/jFZENMV0FmB4jYtfosQMqVQYHAXPLeTsKODZdT8= Received: from MWHPR02MB2861.namprd02.prod.outlook.com (10.175.50.136) by MWHPR02MB2862.namprd02.prod.outlook.com (10.175.50.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Mon, 27 Mar 2017 04:16:53 +0000 Received: from MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) by MWHPR02MB2861.namprd02.prod.outlook.com ([10.175.50.136]) with mapi id 15.01.0991.020; Mon, 27 Mar 2017 04:16:53 +0000 From: Saba Eskandarian To: Ben Laurie CC: "trans@ietf.org" Thread-Topic: [Trans] Privacy-preserving proof of sct exclusion Thread-Index: AQHSpbii8uKV+c47g06WvQijP+zFvqGnVY2AgAC8Fco= Date: Mon, 27 Mar 2017 04:16:52 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stanford.edu; x-originating-ip: [2601:647:5400:6400::91e4] x-microsoft-exchange-diagnostics: 1; MWHPR02MB2862; 7:GxWQ1TEJ9qGogalBEggj799vifB16YboigktmxGCXWPKQLYuBo+Qu0FnBhgNIRR1BZ5IsdcWSDZLM7/iFEmH76XgdsO8nClYIRQmOQ2y/Vs0lEe1b3kzNsbjKP2Fp13/ur5qqJDQEiTG7ntTRwhxPaX163nX1X1CyMu8R/5y3LoLGT+JaGCbC2z6enjiFh/7tGeHCPXv5swWkKGUJujtaVMSX4zGHxF2zEjZSzE9/Yqm2AF3lJUlibPoWF6dgpFZtfd0t43962FCeA2YfO+Ah+L0tWNd7D0tepOdtMxOIZrrpGfYy7Jug0qfjty8uaREFyDKI8N+jHDjcKMLnkxaWw== x-ms-office365-filtering-correlation-id: c25ea912-3961-497c-1677-08d474c81936 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR02MB2862; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127643986962959)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:MWHPR02MB2862; BCL:0; PCL:0; RULEID:; SRVR:MWHPR02MB2862; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(24454002)(51914003)(377454003)(189998001)(99286003)(55016002)(7906003)(606005)(88552002)(6436002)(2906002)(54896002)(6116002)(86362001)(3280700002)(19627405001)(102836003)(9686003)(53936002)(6306002)(77096006)(33656002)(6506006)(3660700001)(229853002)(236005)(25786009)(53546009)(81166006)(38730400002)(110136004)(54356999)(4326008)(76176999)(122556002)(50986999)(75432002)(2900100001)(8936002)(7736002)(6606003)(6916009)(2950100002)(74316002)(6246003)(5660300001)(8676002)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR02MB2862; H:MWHPR02MB2861.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR02MB28614CE50312B5F12ABEB91EC3330MWHPR02MB2861namp_" MIME-Version: 1.0 X-OriginatorOrg: stanford.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 04:16:52.8436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 396573cb-f378-4b68-9bc8-15755c0c51f3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2862 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_04:, , signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270035 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 04:17:15 -0000 --_000_MWHPR02MB28614CE50312B5F12ABEB91EC3330MWHPR02MB2861namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the prompt feedback! I'll make sure to address these comments in= my talk, and I'm looking forward to discussing design options in person. I= suspect that the flexibility of the tools and techniques we use as well as= the associated engineering and privacy tradeoffs will make for an interest= ing discussion. Thanks, ~saba ________________________________ From: Ben Laurie Sent: Sunday, March 26, 2017 9:46:21 AM To: Saba Eskandarian Cc: trans@ietf.org Subject: Re: [Trans] Privacy-preserving proof of sct exclusion On 25 March 2017 at 22:39, Saba Eskandarian > wrote: Hello, I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago). My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxiv.org/abs/1703.02209 Thanks and looking forward to meeting you all next week! Cool, but I immediately see a problem - you require logs to be in timestamp= order, but they aren't. I can't immediately think of a way to get that pro= perty without also considerably increasing time to inclusion in the log. That seems undesirable - in fact, we're trying to go the other way, i.e. re= duce time to inclusion, in general. Also, engineering reality doesn't change, so increasing time to inclusion i= s also likely to increase MMD. Secondly, its interesting, but doesn't seem particularly useful: when an SC= T corresponds to a cert that has not been included, you want to reveal the = cert, not hide it. What you want to hide is who is revealing it. ~saba _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_MWHPR02MB28614CE50312B5F12ABEB91EC3330MWHPR02MB2861namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the prompt feedback! I'll make sure to address these comments in my talk, and I'm looking forwa= rd to discussing design options in person. I suspect that the flexibility o= f the tools and techniques we use as well as the associated engineering and privacy tradeoffs will make for a= n interesting discussion.


Thanks,

~saba

From: Ben Laurie <benl@g= oogle.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.org
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
 


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preserving proof= of sct exclusion from a log (I think Eran alluded to this work in a messag= e a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to get tha= t property without also considerably increasing time to inclusion in the lo= g.

That seems undesirable - in fact, we're trying to go the other way, i.= e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to inclus= ion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: when = an SCT corresponds to a cert that has not been included, you want to reveal= the cert, not hide it. What you want to hide is who is revealing it.

~saba


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


--_000_MWHPR02MB28614CE50312B5F12ABEB91EC3330MWHPR02MB2861namp_-- From nobody Mon Mar 27 02:48: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 B227D1294C2 for ; Mon, 27 Mar 2017 02:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH20MhpC1BqE for ; Mon, 27 Mar 2017 02:48:13 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 4D63B1294B8 for ; Mon, 27 Mar 2017 02:48:13 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id z204so45109667vkd.1 for ; Mon, 27 Mar 2017 02:48:13 -0700 (PDT) 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=VjjkOEAUtS6j9MUOWdw3ng3Y3ZBUKKdz3Z/TgAzJxiY=; b=BHvFdocaJZ73D+TYakKot3he54fy+GSH/Ial/i/YHEfMAPfssZbqE26aC+ZJFP0jWN GCw35k2BDD4R12WYvt4ufMSDyXvY1a+RuTCMcWscG9MJkYWvZOaaKeWR6WGFYI1Jg0vK BfYCCTsUmy/NZYHH1z2O0izyTOkI/ef7DJzivK/FPVhwwRHWdUXw1aEVxtJ2YSI1jQWG RYIjxCyWt4NxwZUdBLS7lzfYYgAfYb1D69dTyubxxwDQLaAxwbUGori75Og4pBTDe8Cd OtRxRteTknH847Gw4kg99ZWWt+LrE97Vo0YpEkx6CboSweM7nRmVWUsAA4QpRS22/6pu Uo7g== 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=VjjkOEAUtS6j9MUOWdw3ng3Y3ZBUKKdz3Z/TgAzJxiY=; b=WIR7zSFQzg9XBV3pdu1I8HyITY7VJyKX00XGWqEVNfD/idlDSLWp33Gk2f3EX6bSyQ ZtNs8EH6Lq37nWeqx7vecHbkVNVLCujG3roo7163QwnWMahmWtw7cOiw2/+8/HDiGQAb Q9BXvGvD+wXstOkw85WEONA0jpTB77gffhZab62jVAQq7OLi9ae8YBJorJJvXbmulu1V WzWaWTDpsLFGuO5xMJBokutXrWUJkexqinbDNNdM6piDFCmFGptTxajAacWHkgLg9+lx 7G7hwboGmlJNI4sHpjJIa167QPbV+ENOXzIOYcAK3p1b0o92Bp6b8ZKcCi7Z9LoMfNkv enxw== X-Gm-Message-State: AFeK/H13zrpey87iTW7ZD63RozzKqzfp/t4IJtUKYyNStwNP4nHp1opb0V9RnY4acFih+BEfUbOS/ySfOO4Wi/+Z X-Received: by 10.176.82.92 with SMTP id j28mr4629886uaa.130.1490608092064; Mon, 27 Mar 2017 02:48:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Mon, 27 Mar 2017 02:48:11 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Mon, 27 Mar 2017 10:48:11 +0100 Message-ID: To: Saba Eskandarian Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c191e48d41a45054bb33db6 Archived-At: Subject: Re: [Trans] Privacy-preserving proof of sct exclusion X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 09:48:15 -0000 --94eb2c191e48d41a45054bb33db6 Content-Type: text/plain; charset=UTF-8 On 27 March 2017 at 05:16, Saba Eskandarian wrote: > Thanks for the prompt feedback! I'll make sure to address these comments > in my talk, and I'm looking forward to discussing design options in person. > I suspect that the flexibility of the tools and techniques we use as well > as the associated engineering and privacy tradeoffs will make for an > interesting discussion. > Afraid I won't be there, but looking forward to hearing more. > > Thanks, > > ~saba > ------------------------------ > *From:* Ben Laurie > *Sent:* Sunday, March 26, 2017 9:46:21 AM > *To:* Saba Eskandarian > *Cc:* trans@ietf.org > *Subject:* Re: [Trans] Privacy-preserving proof of sct exclusion > > > > On 25 March 2017 at 22:39, Saba Eskandarian wrote: > >> Hello, >> >> I'm on the agenda for Tuesday's meeting to share a privacy-preserving >> proof of sct exclusion from a log (I think Eran alluded to this work in a >> message a while ago). >> >> My posted slides will not include many words, so I wanted to share a link >> to the preprint of our academic paper on the subject in case anyone wants >> to read the details there. The paper is targeted at a somewhat different >> audience, but it can be found here: https://arxiv.org/abs/1703.02209 >> >> Thanks and looking forward to meeting you all next week! >> > > Cool, but I immediately see a problem - you require logs to be in > timestamp order, but they aren't. I can't immediately think of a way to get > that property without also considerably increasing time to inclusion in the > log. > > That seems undesirable - in fact, we're trying to go the other way, i.e. > reduce time to inclusion, in general. > > Also, engineering reality doesn't change, so increasing time to inclusion > is also likely to increase MMD. > > Secondly, its interesting, but doesn't seem particularly useful: when an > SCT corresponds to a cert that has not been included, you want to reveal > the cert, not hide it. What you want to hide is who is revealing it. > > ~saba >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --94eb2c191e48d41a45054bb33db6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 March 2017 at 05:16, Saba Eskandarian <sabae@stanford.edu&g= t; wrote:

Thanks for the prompt=C2=A0feedback!=C2=A0I'll make sure to address these comments in my talk, and I'm looki= ng forward to discussing design options in person. I suspect that the flexi= bility of the=C2=A0tools and techniques we use as well as the=C2=A0associated engineering and privacy tradeoffs=C2=A0will make for a= n interesting discussion.

Afraid I won't be there, but looking forward to hearing mor= e.
=C2=A0


Thanks,

~saba

From:= Ben Laurie <benl@g= oogle.com>
Sent: Sunday, March 26, 2017 9:46:21 AM
To: Saba Eskandarian
Cc: trans@ietf.o= rg
Subject: Re: [Trans] Privacy-preserving proof of sct exclusion
=C2=A0


On 25 March 2017 at 22:39, Saba Eskandarian <sabae@stanford.= edu> wrote:

Hello,

I'm on the agenda for Tuesday's meeting to share a privacy-preservi= ng proof of sct exclusion from a log (I think Eran alluded to this work in = a message a while ago).

My posted slides will not include many words, so I wanted to share a link t= o the preprint of our academic paper on the subject in case anyone wants to= read the details there. The paper is targeted at a somewhat different audi= ence, but it can be found here: https://arxi= v.org/abs/1703.02209

Thanks and looking forward to meeting you all next week!


Cool, but I immediately see a problem - you require logs to be in time= stamp order, but they aren't. I can't immediately think of a way to= get that property without also considerably increasing time to inclusion i= n the log.

That seems undesirable - in fact, we're trying to go the other way= , i.e. reduce time to inclusion, in general.

Also, engineering reality doesn't change, so increasing time to in= clusion is also likely to increase MMD.

Secondly, its interesting, but doesn't seem particularly useful: w= hen an SCT corresponds to a cert that has not been included, you want to re= veal the cert, not hide it. What you want to hide is who is revealing it.

~saba


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



--94eb2c191e48d41a45054bb33db6-- From nobody Mon Mar 27 15:39:13 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2764412966F for ; Mon, 27 Mar 2017 15:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpg7YkiQOzs2 for ; Mon, 27 Mar 2017 15:39:09 -0700 (PDT) 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 98399126BFD for ; Mon, 27 Mar 2017 15:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1490654348; bh=DPmkXQDWDU/aCpZ4frImUQAbn1vb2QGWoEsYOqntUrM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=nD+n7co93qRxUtV0gLzX3uID0KeosiD6mKj7iBGfnLD9AUmHkmybwgYL7q8wc8rZs y+QJh79If0yUuHUKMKSDpuSiYfECaBfAAoD+QQcK96y5YWcHfKEL8MAqT0whvXSctT ImD5zPcJx1UmTe1fOvP1EO/CnaN796k9qLLZ2g+BHi1MCNNmq1OF896dH66JADwoeh FInm19qKavayWUjfOFBJVcaDpZeeEPvDwLOgFPrHW+MG+AzrYsvUC3D15q/+a81koS ZVeDBy4lQwLipXljM8AD/XI4Nvl1KQ3k3zNOUkfnyAtFgGzXXy/X9DWUIRtP9vMR1V YVi52eqn+IxnA== Date: Mon, 27 Mar 2017 15:39:07 -0700 From: Andrew Ayer To: Tarah Wheeler Cc: "trans@ietf.org" Message-Id: <20170327153907.435444debbebff6d9a08f95b@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] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 22:39:11 -0000 On Wed, 22 Mar 2017 19:31:43 +0000 Tarah Wheeler wrote: > Peter Bowen and I have been collaborating on a possible solution for > certificate privacy. Thoughts? Hi Tarah and Peter, Your proposal is very similar to the original redaction mechanism that existed in draft-ietf-trans-rfc6962-bis-16, the main differences being your proposal also supports IP address redaction and solves the multiple-certs-per-precert problem. Like the original redaction mechanism, your proposal imposes a high complexity cost on TLS clients by forcing them to do a lot of decoding and re-encoding of a certificate in order to reconstruct the pre-certificate. This problem was discussed here: https://mailarchive.ietf.org/arch/msg/trans/WU_XveDh0GmyyiQbmqEr1SVuC84 https://mailarchive.ietf.org/arch/msg/trans/eOHPqmAskBXMrGzSJAFzT9dzwOQ It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in draft-strad-trans-redaction-00), described here: https://mailarchive.ietf.org/arch/msg/trans/gGWZhqCXG0wlkktB_d0a2fPM4VU I think that any new redaction proposal should address the problem of client complexity at least as well as draft-strad-trans-redaction-00 does. Regards, Andrew From nobody Mon Mar 27 16:11: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 E4E651296C9 for ; Mon, 27 Mar 2017 16:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRwvXx0Di8tS for ; Mon, 27 Mar 2017 16:11:45 -0700 (PDT) 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 4F52E1296BF for ; Mon, 27 Mar 2017 16:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1490656304; bh=3USB7OYodXW88vGbM2IIcQR+Pbk0i+WDqTDd8auGyls=; h=Date:From:To:Subject; b=ClII7lD4++T13GDymWxy8CgZYr59+N3+i6hR7345KVsNZhYAmhUac2ZMVcNEfsGSh QkQ9/I84kkx65uuHUrdexMhDP8baM2AwAZfDwRThdQGpvc99BO5GKkwfxSIASIiCNp Z7HNZ9/by8TKqzBSddef1vy1pJxP4bZ6ZVNbSp8Yo9GJh9zvC2G21MasWo3R2nHmd/ MK0+EfhLBEcPpcerTPVtV567mX6e+j2y7aIgqiRYUC9TgLWclqRjBvJq8qFBeme1bN M9hl4b2eGNVUM+nkecA2D4dgCxX12IE/loP43tYwV5szv424JomvH/5zMlIOlkbiIM f+Wpad/nW4+mw== Date: Mon, 27 Mar 2017 16:11:44 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20170327161144.23c6b7a5a73ce65dad1cfc36@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] STH Pollination Implementations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 27 Mar 2017 23:11:47 -0000 First, Graham Edgecombe and I have set up public sth-pollination endpoints as defined in draft-ietf-trans-gossip-00: https://certspotter.com/.well-known/ct/v1/sth-pollination https://ct.grahamedgecombe.com/.well-known/ct/v1/sth-pollination Our monitors are using these endpoints to exchange STHs twice an hour. We're using the -00 draft instead of -04 because -00 was the last draft to use v1 STHs. As I mentioned previously, I think it would be good to add v1 support back to the Gossip document, if it's not too late to do so. v1 logs will be with us for some time and the ecosystem would benefit from STH pollination. Second, I've written a lightweight program called "ct-honeybee" which queries public logs and uploads their latest STHs to my and Graham's sth-pollination endpoints: https://github.com/SSLMate/ct-honeybee/ My hope is for a diverse set of people to run ct-honeybee from various vantage points to increase the likelihood of detecting split log views. Let me know if you have any questions. Also, consider running ct-honeybee! :-) Regards, Andrew From nobody Tue Mar 28 06:32:27 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493612953C for ; Tue, 28 Mar 2017 06:32:25 -0700 (PDT) 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 oRXpWA3GmTnu for ; Tue, 28 Mar 2017 06:32:23 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 7DCE1129983 for ; Tue, 28 Mar 2017 06:32:16 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so5081392oif.0 for ; Tue, 28 Mar 2017 06:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PUF7As7/E8v56QDGh2kzDsT5+EFFJ03n2OJlLFty4k8=; b=KWgj2AYBpw8GwWRqNnrpwxavLwHaDKLePKq1l4ODF/hcIOlRv8t+Q8l8rRDSQVx3Cq G3cx/sZTUQM3q0vNAjy745Jr6WgJ0gCVj8RL2pdBVmyJZIMlwdqDh6HguaV2JsrPyprL pGSbmA6egOQyZI9mVA+K4n8TWdoFYTANSP7tgnIB5Red/fNeRHzCMud+Q3JqxcS7fdti 0jZwAQ4btbuAKF1R2cDu0z3jF/dpN0xqeZ8AqrK7Hv3MFQQ7JCJ/CfjWYVLbw2Qq9gGr GFREgka2fPCm686lBo3KvuFKBW7OfgKfCDGQFvcLGsll+S2WXqJTHieH/M7l6mzm7hpx VE8w== 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=PUF7As7/E8v56QDGh2kzDsT5+EFFJ03n2OJlLFty4k8=; b=f4uFfjNkS7vs2UEzTEij4lTy8bPD7xl59ghoEmFezU0n1VX5HeJbe7xNY6Tvknz0Cw R62hyTltfLooTCbPjbCqz2avSqH0MYwqKVMMaBs5M3LMlMZ8zkApYTtBvVrQH4l4saOx Vy//ywarfb4gzN9922PdHzXd8jj2U2lgFFGGDt1nqkXW+4Qro7/MLawqFlDQ3jt7OnRs K3LGnFcZlQ23tKhWbHL0j9mzzKC6YqnqAa8JGAZPSMSkTa0yWPRO2HbGzKRoqZFUxaeb zn+CgSQfBmktEXxYdq9ntUcltduEqdPiDEM88ryhwLkel7Uu0Gmr6K3trzKi394yikbq YxUw== X-Gm-Message-State: AFeK/H1+prsIW1l3X+VApdgo6XYyL74TXk19eJ/3F58H1Ecw8VT9Xp7YBV1t1IHOGaUThLewyY89r6IPHzGBgg== X-Received: by 10.202.239.2 with SMTP id n2mr15396273oih.22.1490707935418; Tue, 28 Mar 2017 06:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.6 with HTTP; Tue, 28 Mar 2017 06:32:11 -0700 (PDT) In-Reply-To: <20170327153907.435444debbebff6d9a08f95b@andrewayer.name> References: <20170327153907.435444debbebff6d9a08f95b@andrewayer.name> From: Peter Bowen Date: Tue, 28 Mar 2017 06:32:11 -0700 Message-ID: To: Andrew Ayer Cc: Tarah Wheeler , "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 13:32:25 -0000 On Mon, Mar 27, 2017 at 3:39 PM, Andrew Ayer wrote: > On Wed, 22 Mar 2017 19:31:43 +0000 > Tarah Wheeler wrote: > >> Peter Bowen and I have been collaborating on a possible solution for >> certificate privacy. Thoughts? >> > Your proposal is very similar to the original redaction mechanism > that existed in draft-ietf-trans-rfc6962-bis-16, the main differences > being your proposal also supports IP address redaction and solves the > multiple-certs-per-precert problem. > > Like the original redaction mechanism, your proposal imposes a high > complexity cost on TLS clients by forcing them to do a lot of decoding > and re-encoding of a certificate in order to reconstruct the > pre-certificate. This problem was discussed here: > > https://mailarchive.ietf.org/arch/msg/trans/WU_XveDh0GmyyiQbmqEr1SVuC84 > https://mailarchive.ietf.org/arch/msg/trans/eOHPqmAskBXMrGzSJAFzT9dzwOQ > > It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in > draft-strad-trans-redaction-00), described here: > > https://mailarchive.ietf.org/arch/msg/trans/gGWZhqCXG0wlkktB_d0a2fPM4VU > > I think that any new redaction proposal should address the problem of > client complexity at least as well as draft-strad-trans-redaction-00 > does. Andrew, Thank you for the feedback. I take full responsibility for the failure to make the tech spec as friendly to clients as the strad-trans-redaction draft. When I was drafting this proposal, I ended up covering two related but distinct issues, which I think muddies the water. First, I think it would be good to have an explicit precertificate transformation algorithm called out. 6962 and 6962bis both have algorithms discussed in the text for how to go from a final certificate to a precertificate. The two algorithms are slightly different. From an implementer's perspective, I would prefer to have a clear statement of that algorithm being used which then also allows for clear introduction of new algorithms, instead of relying upon hints such as the presence of a new extension. Second is a proposal for an algorithm for precertificate transformation that occludes discovery of full SANs from precertificates. This proposal needs a few tweaks to hit the points covered in the discussions above and strad-trans-redaction draft; I'll work on revising it to address these. Thanks, Peter From nobody Tue Mar 28 07:36: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 A06031296B4 for ; Tue, 28 Mar 2017 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzJq4vXqFLoa for ; Tue, 28 Mar 2017 07:36:17 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 DB784129654 for ; Tue, 28 Mar 2017 07:36:14 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 190so20775858itm.0 for ; Tue, 28 Mar 2017 07:36:14 -0700 (PDT) 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=S8K1SRTzx38FnPqc8EdhfH/tUit7fJf4lqH7GSIy6KI=; b=Lw2QIe23KILEZ1rd+se8TdTIebqLtH7sn3WlkN0DTx63wgwxIxg0irQ/Uq/Rkula/a 9FNIwyd31njfCbMtjmres2mViovkCIwrfd4KYPWRd5oDFa4AePJdruU8Kgob5xfw0XjA 2cW9CGKzjGf+JIQdZDuW8ug6Jbj88J9Ul7mUwCZhrb8Gg/5p+qQUzuZMOA3p4iWymVaU e1H18XTSmpf32YKvLyxNTq4cREPdub5z3XrjEZ/rRqlj27SayRV80ESzaHPqq8HXLw4e iqYMpNeSPLS22USdpyZo9HwEWQBfROttRkaQjGz0Aub+R5d9fVlSnokx0vVxdguPsGTq dxNg== 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=S8K1SRTzx38FnPqc8EdhfH/tUit7fJf4lqH7GSIy6KI=; b=V9yucjoZhYDVmEqBX1TxEn68m2VunUwLfDg16sHcZyzx4TTc1wqL5jftBynEQIh1/4 dCprSJrUM10JTYna9uK+SIMpKqqvSPrrdZj7GwCKX75Mk+x7bIT6zTP7MedtyfixeqS2 I4IwujvyFYigfb1NfupXd3WVmVvRaWSqHT9LdosI0V/d8djLZPI9F75UojVx74ZwFALK Gl68JWBtBOP0+hbos3oFcvU02JmgWu7eK3JDBKJhbr6IZfpeOatH+aNmMMgZPupLUAXr RyRthSNt6mmzAveCHnhEy5zDEcUMqSMWG8jxQBKnIMod7cI5GaoMVTIH3gr/LSoah4ue urUw== X-Gm-Message-State: AFeK/H3K+3wEUXj5mT0XFGDqBuiMlYA9mzeg31mBescWExl6IBrbXAn+MaARwKHPxfxd+PXs1k5z6v6CEPY+1wBp X-Received: by 10.36.131.201 with SMTP id d192mr11992600ite.60.1490711773530; Tue, 28 Mar 2017 07:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.200 with HTTP; Tue, 28 Mar 2017 07:36:12 -0700 (PDT) Received: by 10.107.164.200 with HTTP; Tue, 28 Mar 2017 07:36:12 -0700 (PDT) In-Reply-To: References: <20170327153907.435444debbebff6d9a08f95b@andrewayer.name> From: Eran Messeri Date: Tue, 28 Mar 2017 09:36:12 -0500 Message-ID: To: Peter Bowen Cc: "trans@ietf.org" , Tarah Wheeler , Andrew Ayer Content-Type: multipart/alternative; boundary=94eb2c118a36b9e212054bcb61ac Archived-At: Subject: Re: [Trans] Proposal to modularize pre certificate transformation X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 14:36:20 -0000 --94eb2c118a36b9e212054bcb61ac Content-Type: text/plain; charset=UTF-8 On 28 Mar 2017 8:32 am, "Peter Bowen" wrote: On Mon, Mar 27, 2017 at 3:39 PM, Andrew Ayer wrote: > On Wed, 22 Mar 2017 19:31:43 +0000 > Tarah Wheeler wrote: > >> Peter Bowen and I have been collaborating on a possible solution for >> certificate privacy. Thoughts? >> > Your proposal is very similar to the original redaction mechanism > that existed in draft-ietf-trans-rfc6962-bis-16, the main differences > being your proposal also supports IP address redaction and solves the > multiple-certs-per-precert problem. > > Like the original redaction mechanism, your proposal imposes a high > complexity cost on TLS clients by forcing them to do a lot of decoding > and re-encoding of a certificate in order to reconstruct the > pre-certificate. This problem was discussed here: > > https://mailarchive.ietf.org/arch/msg/trans/WU_ XveDh0GmyyiQbmqEr1SVuC84 > https://mailarchive.ietf.org/arch/msg/trans/ eOHPqmAskBXMrGzSJAFzT9dzwOQ > > It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in > draft-strad-trans-redaction-00), described here: > > https://mailarchive.ietf.org/arch/msg/trans/ gGWZhqCXG0wlkktB_d0a2fPM4VU > > I think that any new redaction proposal should address the problem of > client complexity at least as well as draft-strad-trans-redaction-00 > does. Andrew, Thank you for the feedback. I take full responsibility for the failure to make the tech spec as friendly to clients as the strad-trans-redaction draft. When I was drafting this proposal, I ended up covering two related but distinct issues, which I think muddies the water. First, I think it would be good to have an explicit precertificate transformation algorithm called out. 6962 and 6962bis both have algorithms discussed in the text for how to go from a final certificate to a precertificate. The two algorithms are slightly different. From an implementer's perspective, I would prefer to have a clear statement of that algorithm being used which then also allows for clear introduction of new algorithms, instead of relying upon hints such as the presence of a new extension. That's a concern Richard Barnes brought up as well. Assuming we'll get the green light to make further changes to 6962-bis, I'm hoping to describe a clearer, more accurate algorithm to re-construct the data structure which the signature in the SCT covers (as well as reconstructing the Log Entry). Second is a proposal for an algorithm for precertificate transformation that occludes discovery of full SANs from precertificates. This proposal needs a few tweaks to hit the points covered in the discussions above and strad-trans-redaction draft; I'll work on revising it to address these. Saba's presentation on the meeting today should describe something for that purpose. Thanks, Peter _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --94eb2c118a36b9e212054bcb61ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 28 Mar 2017 8:32 am, "Peter Bowen" <pzbowen@gmail.com> wrote:
On Mon, Mar 27, 2= 017 at 3:39 PM, Andrew Ayer <agw= a@andrewayer.name> wrote:
> On Wed, 22 Mar 2017 19:31:43 +0000
> Tarah Wheeler <Tarah_= Wheeler@symantec.com> wrote:
>
>> Peter Bowen and I have been collaborating on a possible solution f= or
>> certificate privacy. Thoughts?
>>
> Your proposal is very similar to the = original redaction mechanism
> that existed in draft-ietf-trans-rfc6962-bis-16, the main differe= nces
> being your proposal also supports IP address redaction and solves the<= br> > multiple-certs-per-precert problem.
>
> Like the original redaction mechanism, your proposal imposes a high > complexity cost on TLS clients by forcing them to do a lot of decoding=
> and re-encoding of a certificate in order to reconstruct the
> pre-certificate. This problem was discussed here:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.org/arch/msg/trans/WU_XveDh0Gmy= yiQbmqEr1SVuC84
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.org/arch/msg/trans/eOHPqmAskBXM= rGzSJAFzT9dzwOQ
>
> It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in=
> draft-strad-trans-redaction-00), described here:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.org/arch/msg/trans/gGWZhqCXG0wl= kktB_d0a2fPM4VU
>
> I think that any new redaction proposal should address the problem of<= br> > client complexity at least as well as draft-strad-trans-redaction-00 > does.

Andrew,

Thank you for the feedback.=C2=A0 I take full responsibility for the
failure to make the tech spec as friendly to clients as the
strad-trans-redaction draft.
When I was drafting this proposal, I ended up covering two related but
distinct issues, which I think muddies the water.

First, I think it would be good to have an explicit precertificate
transformation algorithm called out.=C2=A0 6962 and 6962bis both have
algorithms discussed in the text for how to go from a final
certificate to a precertificate.=C2=A0 The two algorithms are slightly
different.=C2=A0 From an implementer's perspective, I would prefer to h= ave
a clear statement of that algorithm being used which then also allows
for clear introduction of new algorithms, instead of relying upon
hints such as the presence of a new extension.
=
That's a concern Richard Barnes brought up as w= ell. Assuming we'll get the green light to make further changes to 6962= -bis, I'm hoping to describe a clearer, more accurate algorithm to re-c= onstruct the data structure which the signature in the SCT covers (as well = as reconstructing the Log Entry).

Second is a proposal for an algorithm for precertificate
transformation that occludes discovery of full SANs from
precertificates.=C2=A0 This proposal needs a few tweaks to hit the points covered in the discussions above and strad-trans-redaction draft; I'll<= br> work on revising it to address these.
Saba's presentation on the meeting today should describe= something for that purpose.

Thanks,
Peter

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

--94eb2c118a36b9e212054bcb61ac-- From nobody Tue Mar 28 12:21:42 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C148129A05 for ; Tue, 28 Mar 2017 12:21:41 -0700 (PDT) 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 xiEQp4h_naRw for ; Tue, 28 Mar 2017 12:21:40 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E7A0A129A09 for ; Tue, 28 Mar 2017 12:21:39 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id o81so6525347wmb.1 for ; Tue, 28 Mar 2017 12:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PHs8OKCgH13rRPATYbXLmI1UFPfU0YMsI6E8QxhZK64=; b=Yi4QZo0dUphyQPUB09TmE+oIUVIp4X3Kuupw5dX+6ReMY/bSmqgJfHNKlQ9wEMb3YZ vMAlNwo8u7Hwaiim4qHtJhV1YrJ+Hala0Sx6sPgGhgsbutIzyp4NGVtTbDg8D70pprnD g35gjnTfft5cMSS4iysArbJ1ijcSTQ6xQc8cGD7+a2A+3nut8qD9RnXsyKQPgZXizj0q HMEJlpqmmVb7I1Hk87uA98zGdUZ/CP+A7QCpzADJjvXuPnksZ1C7Uv+4eatRB6nOEVNl uqpzBifiTjJX3j50ou7kBbmo+icvyKQYvwoZLEHNQXhibp+Dw/8kivxY0BR/WLdC3Jl4 6naw== 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=PHs8OKCgH13rRPATYbXLmI1UFPfU0YMsI6E8QxhZK64=; b=Y+k30BPoAGTW7xC9OE5VOWliw7Jgb5dsLMhzB0SxYof1haKhetXSGicLKfvIgVmcRN W7n82ltcnBuVInxbks00NTfh9po6upK9oMm+Vs/CPtS8z2h/kP+eoWDMayRGiHko9cxz D8VyO0Yz0iT3nIFsy999n4bYDUyR3EnQdoUS/9b70rhcL93asdV2Mg9/6LTFU/RDQ4eK H+wLnZ1ZxZiROnv8my5l6wMJtp1HulZ187lxnXXSdZpdeOe9286TXII4rVwGrnv2eXoZ Rldb+8chjylWzSlhwp7Mve2N/uhYcFxk3RJHZMsds/1nvh6Dd5HTWQ3RwaC6SBAQiWHj 0SQA== X-Gm-Message-State: AFeK/H0Twhy6pn9GVP6lbejLQKWuuQgNWoSXZz7uUqnzS+Z7bxfDHdwBGwBc7/OW4dEjvn93SFUnx0Q4XhWy/Q== X-Received: by 10.28.102.86 with SMTP id a83mr16004520wmc.76.1490728898128; Tue, 28 Mar 2017 12:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Tue, 28 Mar 2017 12:21:37 -0700 (PDT) From: Richard Barnes Date: Tue, 28 Mar 2017 15:21:37 -0400 Message-ID: To: Trans Content-Type: multipart/alternative; boundary=001a114b2ec46df348054bcf5e3e Archived-At: Subject: [Trans] Mozilla's basic take on Binary Transparency X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 19:21:41 -0000 --001a114b2ec46df348054bcf5e3e Content-Type: text/plain; charset=UTF-8 As I said at the mic, there's some work going on at Mozilla to implement a form of Binary Transparency, leveraged on top of CT. Here's the outline: https://wiki.mozilla.org/Security/Binary_Transparency --001a114b2ec46df348054bcf5e3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I said at the mic, there's some work going on at Mo= zilla to implement a form of Binary Transparency, leveraged on top of CT.= =C2=A0 Here's the outline:



--001a114b2ec46df348054bcf5e3e-- From nobody Wed Mar 29 04:48: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 97D8A1296B2 for ; Wed, 29 Mar 2017 04:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKr7mcGq3ZZO for ; Wed, 29 Mar 2017 04:48:51 -0700 (PDT) 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 ACCD51296A6 for ; Wed, 29 Mar 2017 04:48:51 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id z204so14173928vkd.1 for ; Wed, 29 Mar 2017 04:48:51 -0700 (PDT) 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=X1MgGNEYy1TWCPdHaEB27EFAFA+VsxOUhn5bAkTmeBg=; b=TcObeE90OMMNDoGqYvibHQCba47JEp/hDA4qX60t3T6v4v4LlKQV7zG6EXRimdGbaD Zl8AQOVrAsfwgp3+RBOscDyMC3bYmqXVqEJBe88PFxKwskp/GKmN+s3YVvbe+c3m119P KKbEJRsV8taE7+7kJVEzhz9jvirOnhRMuiGvPR1jfTPs6O+HHp39eeB34PYS3i9qjLBM LkNRRbdTIKbRQKFqusPTIC1ziSeSlF505KLjzv+mok4ovm/Ach29Jqrqx8Ad0icXu7HS ooT3G014uFK9btdY9lJzvPcJEfYQpsYZpJJpZixcE+ObhNG4cBTnl7mS9DJrhbvZCkDK Rd1A== 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=X1MgGNEYy1TWCPdHaEB27EFAFA+VsxOUhn5bAkTmeBg=; b=Dt8z+dXy02JOFEZ2t0XXrxGF5rhzgvgLQJ25nG0XGQoGDGo5TmpJ4lJyiYko4AFHxl fjDiyjBxwPp1bvFpH28wbTFGomi1mAf9dz16mY0KUJfDb3tzV2z+xfDOqZQjsZ2FowLG t35HiecPqmCTb3OTAULa13dIt7ILuvOHLbrBErZtDGJgeOnDnwK8d4KK3pEhyBJRMAyg C3YBaal7LlPUyKqR2Vj1/vt/DJaG/2bv5sUMkwzefjpvUYWVUo85/OTBg/401IpDWnsW aM7kLi7WIoiYc5nhW1K4O6i8ZLXoS9MAsdGeYTenM013GuiS1QRdNoo8/8PPydPxGfMD AZbg== X-Gm-Message-State: AFeK/H0PB+czbb2sRJxWn62W7I2+dnZ6HKCNbAvpaQjD5wtlR2Aqs3opYVr/1pwQTdLcBy0ZsJkA839EsGF3GmH4 X-Received: by 10.159.40.7 with SMTP id c7mr13490uac.91.1490788130461; Wed, 29 Mar 2017 04:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.174.73 with HTTP; Wed, 29 Mar 2017 04:48:49 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Wed, 29 Mar 2017 12:48:49 +0100 Message-ID: To: Richard Barnes Cc: Trans Content-Type: multipart/alternative; boundary=94eb2c1ab7aaf424a3054bdd28be Archived-At: Subject: Re: [Trans] Mozilla's basic take on Binary Transparency X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 11:48:54 -0000 --94eb2c1ab7aaf424a3054bdd28be Content-Type: text/plain; charset=UTF-8 On 28 March 2017 at 20:21, Richard Barnes wrote: > As I said at the mic, there's some work going on at Mozilla to implement a > form of Binary Transparency, leveraged on top of CT. Here's the outline: > > https://wiki.mozilla.org/Security/Binary_Transparency > Cool! Are you planning to build this from scratch, or use Trillian ( https://github.com/google/trillian)? > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --94eb2c1ab7aaf424a3054bdd28be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 28 March 2017 at 20:21, Richard Barnes <rlb@ipv.sx> wrote:
As I s= aid at the mic, there's some work going on at Mozilla to implement a fo= rm of Binary Transparency, leveraged on top of CT.=C2=A0 Here's the out= line:


Cool! Are= you planning to build this from scratch, or use Trillian (https://github.com/google/trillian)?=C2= =A0




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


--94eb2c1ab7aaf424a3054bdd28be-- From nobody Wed Mar 29 07:33: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 4259412706D for ; Wed, 29 Mar 2017 07:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G6GHGV9Ztyp for ; Wed, 29 Mar 2017 07:33:05 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 D73DD129474 for ; Wed, 29 Mar 2017 07:33:04 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so19711929vke.2 for ; Wed, 29 Mar 2017 07:33:04 -0700 (PDT) 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=ELqmOff7XmJwPebSXz96vQu6FgCaMaHiyiIPAcjtXbw=; b=LjB+/bXq0jCcumvgMPoAYbR916JHxrxTOPCin0j+ze7ApPVvgb4ay1MY+RhZgF5nB4 6E3SfEkrZFc9KsaoKQd/jkmlkwaQprCI+xLuCzeJMCbrM5k8i07u48z+isULa4ysUTrh Hm+UvEiJMRJ8QD+Hrji3Pb+Bl49tijA0lZvIC8+DO0ihigTUojtqbjTgiH/tGSk2LrMM /J8bcI1B+lkD1of3+F/MjvcaImg0RxFKN3SphuFOrfYE+g3EUbFfkSiYUDmWAWpE2pUp j6VX6SeofsXbySeWDd0f2ev8w4zzvK0I2D4w4x8F47kHS4dnnS+hT0r1RJ+hcBtX6tf7 P3rA== 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=ELqmOff7XmJwPebSXz96vQu6FgCaMaHiyiIPAcjtXbw=; b=I+5XbKBciHCuQhwRKpSgzekeZIYNHwTZsvhQucPEGbDydMySILlF1xqRbQByXiIlYK 9KTevvvWbju4q/ARFPwdIZ6HyrPX0U6C2iI6BlQrP2sELSRJ1D4pEcivBgBfFd/7s1Se JA76fSmYyyGiu9rX3MAtPr/E6e3vL3w6GY9Mh0oyHN8N3mWG5kHZXVMRF1SLLCYRuiaY Yb/R/hmLqHsCTgo3NoMRqn3HpCTNRcK5+tcVFwfAzskhM30UVhuMC2o33tymNHWYjdE3 4OKYjTAk7CfAqYl4xV17ug7g14JLg3Mf3BPKPLsW+FF2BCzlDdTse/KHPH9wuQVspfAF EnRA== X-Gm-Message-State: AFeK/H2TkQQ9KrN1epVkELlcRSpOotp1XdbQQtrbZWHAsay10ZsmWKimlIJ2/efY2UeHm9jjwIFQRWBKLvBV29SU X-Received: by 10.159.49.81 with SMTP id n17mr350521uab.178.1490797983570; Wed, 29 Mar 2017 07:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.8.6 with HTTP; Wed, 29 Mar 2017 07:33:02 -0700 (PDT) In-Reply-To: <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> From: Wei Chuang Date: Wed, 29 Mar 2017 09:33:02 -0500 Message-ID: To: Viktor Dukhovni Cc: trans@ietf.org, IETF DANE Mailinglist Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045ddecc467831054bdf7487" Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 14:33:07 -0000 --f403045ddecc467831054bdf7487 Content-Type: multipart/alternative; boundary=f403045ddecc3efcbe054bdf749b --f403045ddecc3efcbe054bdf749b Content-Type: text/plain; charset=UTF-8 Thanks very much Viktor that explanation of NSEC(3). Just one follow up idea: On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni wrote: > > > On Mar 20, 2017, at 6:43 PM, Wei Chuang wrote: > > > >>> No, this is because the parent can spoof any data for the child. > >>> It is unrelated to DNSSEC. > >> > >> With qname minimization, the parent will first need to deny an NS > >> RRset for the child, and those DOE records are better candidates > >> for logging than routine non-NS queries. > > > > Can you expand on how the the DOE record (which I assumes means > > denial-of-existence) could work with an adversarial parent? > > Yes, DOE is denial of existence. When the child sends NS queries > as part of qname minimization a negative response (no NS records) > will include signed NSEC(3) records to that effect, signed by the > parent zone. These are candidates for logging. > Understood now I think. > The key question is how to avoid logging ridiculous volumes of > data that can DoS any log service and also disclose too much. > +1 as this is logging NSEC(3) would make the logging rate proportional to all RR churn. Let put out an idea to attempt to mitigate this. (And apologies ahead of time if this is obviously wrong as I'm pretty new at DNS/DNSSEC) For this, the main thing this is trying to track is the existence of DS and its DOE. Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS? The effect is then is that every NS will then have either a DS or NDS RR. Then the rate of logging becomes proportional to max of NS and DS changes. I suspect NDS won't have the same enumeration problems as the NSEC(3) since lacks next-signed link, and is paired with an NS record anyways. Also NDS does not change NSEC(3) behavior DOE behavior. (To be complete there could be a policy declaration mechanism for this but that's details). -Wei --f403045ddecc3efcbe054bdf749b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks very much Viktor that explanation of NSEC(3).=C2=A0= Just one follow up idea:

On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni <ietf-da= ne@dukhovni.org> wrote:

> On Mar 20, 2017, at 6:43 PM, Wei Chuang <weihaw@google.com> wrote:
>
>>> No, this is because the parent can spoof any data for the chil= d.
>>> It is unrelated to DNSSEC.
>>
>> With qname minimization, the parent will first need to deny an NS<= br> >> RRset for the child, and those DOE records are better candidates >> for logging than routine non-NS queries.
>
> Can you expand on how the the DOE record (which I assumes means
> denial-of-existence) could work with an adversarial parent?

Yes, DOE is denial of existence.=C2=A0 When the child sends NS queries
as part of qname minimization a negative response (no NS records)
will include signed NSEC(3) records to that effect, signed by the
parent zone.=C2=A0 These are candidates for logging.
<= br>
Understood now I think.


The key question is how to avoid logging ridiculous volumes of
data that can DoS any log service and also disclose too much.

+1 as this is logging NSEC(3) would make the logging= rate proportional to all RR churn.
=C2=A0
Let put out = an idea to attempt to mitigate this. =C2=A0(And apologies ahead of time if = this is obviously wrong as I'm pretty new at DNS/DNSSEC) =C2=A0 For thi= s, the main thing this is trying to track is the existence of DS and its DO= E.=C2=A0 Why not create an explicit Non-existence of DS (NDS) RR that gets = logged along with DS and NS?=C2=A0 The effect is then is that every NS will= then have either a DS or NDS RR. =C2=A0 Then the rate of logging becomes p= roportional to max of NS and DS changes.=C2=A0 I suspect NDS won't have= the same enumeration problems as the NSEC(3) since lacks next-signed link,= and is paired with an NS record anyways.=C2=A0 Also NDS does not change NS= EC(3) behavior DOE behavior. =C2=A0(To be complete there could be a policy = declaration mechanism for this but that's details).

-Wei
--f403045ddecc3efcbe054bdf749b-- --f403045ddecc467831054bdf7487 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBl5cpHSbIQqa/RxVzhv6eU U35TVLumAimo0M+mD7k09DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMjkxNDMzMDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAKqxf0wC2A8vq2sFCu5R/p6NMHtFnf/gHMfLTg5fL XcZbil8R7gEQqvE3vmPJElEktabKDFJtiImGnRGWSj8vUUcFpyvkqfJuBpPZyzllvdk3wtEfgQPk O7uNEHsLzmd84ZXAu4kGmk18Nta+ht3bdsDfsMk9iYRVKFeTziNqaiC+aZIfjscjYHLiWBJlrUOo 1gKqvbEf8tUZP6vJKCDzF5Heoc5U5oWt7GbL2Km+3Z/umdX5TctXBxSZ5Hgj823bJ5MJsp1PMUly c19BkuTNjGrgw2suuHCvP5GOp5lHG66XHNFquica96O3D+JhQLu0/WY+ASeHs9sLd1frUJBkLg== --f403045ddecc467831054bdf7487-- From nobody Wed Mar 29 08:18:51 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E345127599; Wed, 29 Mar 2017 08:18:44 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3drPfO664MML; Wed, 29 Mar 2017 08:18:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D73712954A; Wed, 29 Mar 2017 08:11:42 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5749C7A32F1; Wed, 29 Mar 2017 15:11:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 29 Mar 2017 11:11:40 -0400 Cc: dane@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> To: trans@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] [dane] CT for DNSSEC X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 15:18:45 -0000 > On Mar 29, 2017, at 10:33 AM, Wei Chuang wrote: >=20 > Why not create an explicit Non-existence of DS (NDS) RR that gets = logged along with DS and NS? This is not needed, the NSEC/NSEC3 RRs already serve that role. For NSEC records (RFC4034), an unsigned delegation looks like: example.com. IN NS ns1.example.com. example.com. IN NSEC examplf.com NS example.com. IN RRSIG NSEC ... this proves that NS (or other depending on the content of the type bitmap of the NSEC record) records exist for example.com, but DS records do not. With NSEC3 (rfc5155), and the "opt-out" bit the situation can be more complex because the answer may not establish the existence of example.com. Instead we may get an existence proof for the closest encloser (ancestor domain) and proof that "example.com" is not signed, but no proof of its existence. This means that to avoid spam, a log might want to independently verify the existence of the insecure delegation by repeating the query, so as to avoid storing data for non-existent domains with the insecure NXDOMAIN modified to NOERROR with made up NS records. --=20 Viktor. From nobody Wed Mar 29 08:35: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 BF015129422 for ; Wed, 29 Mar 2017 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWeRS0yqCsYf for ; Wed, 29 Mar 2017 08:35:39 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 1C00A129411 for ; Wed, 29 Mar 2017 08:35:35 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id k6so14230033wre.2 for ; Wed, 29 Mar 2017 08:35:35 -0700 (PDT) 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=dCrPxIPXPJLAh4BvdWoze3D8lJTnl5+n4vM3L9eEy60=; b=iXS/mC05+D2D7ejCLv1+g3rPMA16qRdd2wHirNV4Pjl+dTN+V/BBTmDm9rmcZ27Yga nkJxXu/cKRhamCnhDlo9TtKxKXliuuR3z7g0PSwcLCnFiPvRnS7w3cWWQZGDUEhLTKO9 K4vN0XhEOMtxd+MEOVuZDzdQH24xLVhWWfh23WxMecGP35zGJ4+Xt6YpqhPnOcEQIcSf YYDVWlhO0uUJD0pjsVE5XGwUtJMLY73xZvvgTMAKkeBMa35PsB8FVWSe17o+xMxsMJwq ZyGLLYYV4QTFsneCI9doQO3sZFjPIKHRm2sSgoDNGRa1k7brmKlCTXpWRBH47sDcLFCz SbgA== 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=dCrPxIPXPJLAh4BvdWoze3D8lJTnl5+n4vM3L9eEy60=; b=o0RSgciE14SIll4BxKH+95xyKCcQ2kMXUHRtgjd2yhLshRoILPYx9Kj/KAzpiQkwE9 cfCk1ULWNeiUK1THm0h3fWyVAFsOlmIHsVGtm9A2cto++11H6dYjuVxF+HcuWlyYovGc tAqyzxI1HMKA5V8zlIazgh1V8MkT/bq/8MUwzHRUGXtqGRT0oVz26byrB6oRYA1N8hO+ PUi3AYhzMCMvJRFKwasrToJlzLt8JcqwFRIA3xcAL3Uf9hx9mLAaxl7rT/EXCuY/FjBL mzkfd6jW2Nafw3plep5LzvTDY87BxLjdDMsUYggld9Sfj18lAdVhzSx3nAR+UVihQ2xE bylQ== X-Gm-Message-State: AFeK/H18XMTZRrHHJB7Czuxmv5A9gU4kmnfwnzdtbL0mK4Ts+JrgEZG9B8h+BANPFaEtsfiaHGD6+fNGXNYypw== X-Received: by 10.223.169.70 with SMTP id u64mr993705wrc.187.1490801731761; Wed, 29 Mar 2017 08:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.40.69 with HTTP; Wed, 29 Mar 2017 08:35:31 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 29 Mar 2017 11:35:31 -0400 Message-ID: To: Ben Laurie Cc: Trans Content-Type: multipart/alternative; boundary=f403045cf46ea72d28054be05306 Archived-At: Subject: Re: [Trans] Mozilla's basic take on Binary Transparency X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 15:35:42 -0000 --f403045cf46ea72d28054be05306 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 7:48 AM, Ben Laurie wrote: > > > On 28 March 2017 at 20:21, Richard Barnes wrote: > >> As I said at the mic, there's some work going on at Mozilla to implement >> a form of Binary Transparency, leveraged on top of CT. Here's the outline: >> >> https://wiki.mozilla.org/Security/Binary_Transparency >> > > Cool! Are you planning to build this from scratch, or use Trillian ( > https://github.com/google/trillian)? > I'm no longer in a position to speak for Mozilla, but I think the idea was not to deploy any new logs, but instead just to use the CT logs that exist. --Richard > >> >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > --f403045cf46ea72d28054be05306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 29, 2017 at 7:48 AM, Ben Laurie <benl@google.com> wrote:


On 28 Mar= ch 2017 at 20:21, Richard Barnes <rlb@ipv.sx> wrote:
As I said at the mi= c, there's some work going on at Mozilla to implement a form of Binary = Transparency, leveraged on top of CT.=C2=A0 Here's the outline:

Cool! Are you p= lanning to build this from scratch, or use Trillian (https://github.com/google/t= rillian)?=C2=A0

I'm no longer in a position to speak for Mozilla, but I think the idea= was not to deploy any new logs, but instead just to use the CT logs that e= xist.

--Richard


=C2=A0



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



--f403045cf46ea72d28054be05306-- From nobody Thu Mar 30 06:06:23 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF5F1294AF for ; Thu, 30 Mar 2017 06:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCU0e_F-iAKK for ; Thu, 30 Mar 2017 06:06:20 -0700 (PDT) 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 381F1129451 for ; Thu, 30 Mar 2017 06:06:20 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d188so52933062vka.0 for ; Thu, 30 Mar 2017 06:06:20 -0700 (PDT) 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=5ZmwdrI+ItfUm0/dS39mwXymH1HUwk32t7Q0dkmjUeA=; b=dDw/rRRvkmlxrTXs+JsjyWt2BbbZVsf78yrBhj99sb30okjM9OwsXhHHycLWTPMbL4 NCqxP4Xl94L5NhdZ2fTaAL5IooMqCi0iyl4EH/dq9clzmvEgD3vMQi4+KOXWBMz8foPD 3bfWeKfBEUqcjQl1EnpnFaJ0YZYugHq5iJdf7B0UJOdFPCiXtSsoNfbhvyReRIQwjPdb v8Ozd4lOrNaRXBR9x17JbQc4M3h+RvRjAl7ymLJ9lkCjr7a1w9qGFGuDy/ZmHjQsstpR lv2l7ECGFwN33KrhdZfBKJYg6JXa2tegVNw/LqtmIvi+oNiohJd8y2Cx/BnV8zGrxP46 a+0A== 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=5ZmwdrI+ItfUm0/dS39mwXymH1HUwk32t7Q0dkmjUeA=; b=COzs4IWhLgBxxg4j4seIawRLmIM+JkNvST0ST0+CCAu82xj8CTvoqX/Tx5KCUC01ad N03U9d4UKB3JxgcrZLa4FS37k6WuGwAQHRPWAWoZ5HVCJPxFWYcnaf1v+bO6iwn+yg4t 1WiFSiGwmx0TZQOu1toUU1eJSD+lmZMI5HqP50PXCnN5Seo4/BSScN4C12+IH4oqmGVY IPleO+H8duXrXRqBB6EzVPFL5c2ptE112+oG2Mu+j8w6kz7B81oMm4Kpm3aId0KtF4EY aHiwwiya3F3E2nCZHU1aYtsHMrMt+99rd32ow8Ri9cJvxY+DqOgbuhDS6OYsNbBH/aQl vDHQ== X-Gm-Message-State: AFeK/H0Ak/BLOwBK2taBWRmxXphFBrfQzBUT1wuYJxjTTL/YsP0D2L9XLzyYMpTpmEjgcgUtlS6GPSt1571ccSuD X-Received: by 10.159.40.7 with SMTP id c7mr2884163uac.91.1490879178963; Thu, 30 Mar 2017 06:06:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.201 with HTTP; Thu, 30 Mar 2017 06:06:18 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Thu, 30 Mar 2017 14:06:18 +0100 Message-ID: To: Richard Barnes Cc: Trans Content-Type: multipart/alternative; boundary=94eb2c1ab7aade23d6054bf25b0b Archived-At: Subject: Re: [Trans] Mozilla's basic take on Binary Transparency X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 13:06:22 -0000 --94eb2c1ab7aade23d6054bf25b0b Content-Type: text/plain; charset=UTF-8 On 29 March 2017 at 16:35, Richard Barnes wrote: > > > On Wed, Mar 29, 2017 at 7:48 AM, Ben Laurie wrote: > >> >> >> On 28 March 2017 at 20:21, Richard Barnes wrote: >> >>> As I said at the mic, there's some work going on at Mozilla to implement >>> a form of Binary Transparency, leveraged on top of CT. Here's the outline: >>> >>> https://wiki.mozilla.org/Security/Binary_Transparency >>> >> >> Cool! Are you planning to build this from scratch, or use Trillian ( >> https://github.com/google/trillian)? >> > > I'm no longer in a position to speak for Mozilla, but I think the idea was > not to deploy any new logs, but instead just to use the CT logs that exist. > Hmm. This is not really a scaleable solution. And is exactly why we're building Trillian. I realise that its attractive to layer on top of CT, because then you get a whole ecosystem around the logs for free. But that ecosystem isn't really interested in your problem. What we really need is for a common ecosystem around log correctness (i.e. verifying single view, etc), whilst allowing for independent logs for independent things. This is one reason I rather like the proposal to do "gossip" by including STHs in other logs (even logs that are logging different things). > > --Richard > > > > >> >>> >>> >>> >>> _______________________________________________ >>> Trans mailing list >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >>> >>> >> > --94eb2c1ab7aade23d6054bf25b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 March 2017 at 16:35, Richard Barnes <rlb@ipv.sx> wrote:


On Wed, Mar 29, 2017 = at 7:48 AM, Ben Laurie <benl@google.com> wrote:


On 28 March 2017 at 20:21, Richard Barnes <rlb@ipv.= sx> wrote:
As I said at the mic, there's some work going on at= Mozilla to implement a form of Binary Transparency, leveraged on top of CT= .=C2=A0 Here's the outline:


Cool! Are you planning to build this from scratch, = or use Trillian (https://github.com/google/trillian)?=C2=A0

I'm no longer in a posit= ion to speak for Mozilla, but I think the idea was not to deploy any new lo= gs, but instead just to use the CT logs that exist.
=

Hmm. This is not really a scaleable soluti= on. And is exactly why we're building Trillian.

I realise that its attractive to layer on top of CT, because then you get= a whole ecosystem around the logs for free. But that ecosystem isn't r= eally interested in your problem. What we really need is for a common ecosy= stem around log correctness (i.e. verifying single view, etc), whilst allow= ing for independent logs for independent things.

T= his is one reason I rather like the proposal to do "gossip" by in= cluding STHs in other logs (even logs that are logging different things).
=C2=A0

--Richard


=C2=A0




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




--94eb2c1ab7aade23d6054bf25b0b-- From nobody Thu Mar 30 11:46: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 DAC3F129454; Thu, 30 Mar 2017 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrJkw6vzh-OY; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA562127843; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v2UIkgo9075499; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2UIkgjs044018; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org In-Reply-To: <87a88uksu0.fsf@ta.scs.stanford.edu> References: <87a88uksu0.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2017-06-28 PDT Date: Thu, 30 Mar 2017 11:46:41 -0700 Message-ID: <8760iqr4a6.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Trans] Internet-Level Consensus bar BoF tonight 7:30pm, Amuse X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 18:46:44 -0000 For those interested in further discussion of Internet-level Consensus (ILC) following my talk at the SAAG open meeting, let's meet at 7:30pm at Amuse, the bar inside Swissotel right near the lobby. David David Mazieres writes: > I'll be giving the following 30-minute talk during the saag session at > the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on > Internet-level consensus that evening. > > > Internet-Level Consensus is Practical > > David Mazi=C3=A8res > > Security Area Open Meeting > Thursday March 30, 2017 15:20-17:20 > Zurich D room >=20=09=09=09=09=20=20=20 > Consensus is the problem of agreeing on a valid input value among > members of a distributed system. Internet-level consensus extends the > concept to global agreement, despite the fact that the Internet has no > meaningful notion of membership. This talk will report on the Stellar > consensus protocol (SCP), an existence proof that secure consensus > does not require well-defined membership. SCP's key idea is for > individual participants to decide for themselves which other > participants they cannot afford to diverge from. SCP guarantees > agreement so long as there is transitive overlap in these > dependencies. SCP is in production use by the Stellar payment > network, but has broader potential applications ranging from secure > package distribution to key management in end-to-end email encryption.