(among > other academic CT variants) similarly has no need for gossip; roughly, > monitors sign that they have seen a cert and then clients just verify > the signatures. Multisignatures sound like an elegant way to achieve > that; are they more efficient than /n/ individual signatures for > smallish cothorities e.g. size <10? Note that CT does not require all Monitors to be third parties; self-Monitoring is a viable option and avoids the problem of detecting a misbehaving (3rd party) Monitor. In that context, having multiple Monitors sign something about a cert may not work out well. The Audit function notifies Monitors (and browser vendors, indirectly?) about log misbehavior, not clients. I say this because clients (browsers) get log metadata from browser vendors, and thus most will not need to consume data from Auditors. Monitors need audit info to decide whether the logs they are watching are misbehaving, and browser vendors need to know the same, to properly manage the log metadata distributed to users of their products. > I've never quite understood why CT mandates gossip instead of having > monitors sign that they have seen an STH. Perhaps this is a good > opportunity to clarify that point? Monitors watch logs for entries of interest to the Subjects that serve. (This is true even for self-Monitors.) So, it's not clear on whose behalf a Monitor would sign info about an STH. Steve --------------030802010503070700060202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Katriel,

Note that ARPKI (among other academic CT variants) similarly has no need for gossip; roughly, monitors sign that they have seen a cert and then clients just verify the signatures. Multisignatures sound like an elegant way to achieve that; are they more efficient than n individual signatures for smallish cothorities e.g. size <10?

Note that CT does not require all Monitors to be third parties; self-Monitoring is a viable
option and avoids the problem of detecting a misbehaving (3rd party) Monitor. In that
context, having multiple Monitors sign something about a cert may not work out well.

The Audit function notifies Monitors (and browser vendors, indirectly?) about log
misbehavior, not clients. I say this because clients (browsers) get log metadata
from browser vendors, and thus most will not need to consume data from Auditors.
Monitors need audit info to decide whether the logs they are watching are misbehaving,
and browser vendors need to know the same, to properly manage the log metadata
distributed to users of their products.

I've never quite understood why CT mandates gossip instead of having monitors sign that they have seen an STH. Perhaps this is a good opportunity to clarify that point?

Monitors watch logs for entries of interest to the Subjects that serve. (This is true
even for self-Monitors.) So, it's not clear on whose behalf a Monitor would sign info
about an STH.

Steve
--------------030802010503070700060202-- From nobody Tue Oct 6 07:18:55 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7382A1ACD03 for ; Tue, 6 Oct 2015 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9dDteexkFRIJ for ; Tue, 6 Oct 2015 07:18:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA0F1ACCE6 for ; Tue, 6 Oct 2015 07:18:43 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:41175 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZjT4k-0004dF-Qg for trans@ietf.org; Tue, 06 Oct 2015 10:18:42 -0400 To: trans@ietf.org References: <17C96998-E1FB-4B25-8DC4-EF177D13FCF3@gmail.com> From: Stephen Kent Message-ID: <5613D842.60206@bbn.com> Date: Tue, 6 Oct 2015 10:18:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050006000909040009030500" Archived-At: Subject: Re: [Trans] Long-term: scalable collective signing (of certs, log-heads, and/or SCTs) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2015 14:18:53 -0000 This is a multi-part message in MIME format. --------------050006000909040009030500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Eran, > > > On Wed, Sep 30, 2015 at 2:35 PM, Katriel Cohn-Gordon > wrote: > > Note that ARPKI > (among other academic CT variants) similarly has no need for > gossip; roughly, monitors sign that they have seen a cert and then > clients just verify the signatures. Multisignatures sound like an > elegant way to achieve that; are they more efficient than /n/ > individual signatures for smallish cothorities e.g. size <10? > > I've never quite understood why CT mandates gossip instead of > having monitors sign that they have seen an STH. Perhaps this is a > good opportunity to clarify that point? > > My understanding is that this is mainly a key management / audit > issue: Logs can be checked for compliance with RFC6962, after which > their keys can be distributed to clients. When adding monitors to the > system, we'd have to cope with: > * Monitoring the monitors for behaving correctly - the biggest issue > being defining what monitors do. Ideally monitors would notify domain > owners of newly-issued certificates for their domains, but how can > that behaviour be verified? I've proposed what I believe Monitor behavior should be in several messages, and it is now codified in the arch doc. > * ARPKI (as far as I understand) assumes independence between log > operators and monitors - something that is difficult to audit and, in > practice, hard to demand as parties motivated to participate in CT are > parties with a stake - CAs and browser vendors. I'd add Subjects here too. Steve --------------050006000909040009030500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Eran,

On Wed, Sep 30, 2015 at 2:35 PM, Katriel Cohn-Gordon <me@katriel.co.uk> wrote:

Note that ARPKI (among other academic CT variants) similarly has no need for gossip; roughly, monitors sign that they have seen a cert and then clients just verify the signatures. Multisignatures sound like an elegant way to achieve that; are they more efficient than n individual signatures for smallish cothorities e.g. size <10?

I've never quite understood why CT mandates gossip instead of having monitors sign that they have seen an STH. Perhaps this is a good opportunity to clarify that point?

My understanding is that this is mainly a key management / audit issue: Logs can be checked for compliance with RFC6962, after which their keys can be distributed to clients. When adding monitors to the system, we'd have to cope with:

* Monitoring the monitors for behaving correctly - the biggest issue being defining what monitors do. Ideally monitors would notify domain owners of newly-issued certificates for their domains, but how can that behaviour be verified?

I've proposed what I believe Monitor behavior should be in several messages, and it is now
codified in the arch doc.

* ARPKI (as far as I understand) assumes independence between log operators and monitors - something that is difficult to audit and, in practice, hard to demand as parties motivated to participate in CT are parties with a stake - CAs and browser vendors.

I'd add Subjects here too.

Steve
--------------050006000909040009030500-- From nobody Tue Oct 6 07:58:49 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9D1ACE4A for ; Tue, 6 Oct 2015 07:58:47 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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_FGpMsac-M for ; Tue, 6 Oct 2015 07:58:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025201ACE46 for ; Tue, 6 Oct 2015 07:58:45 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:41754 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZjThU-00052b-Dg for trans@ietf.org; Tue, 06 Oct 2015 10:58:44 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <5613E1A4.8090909@bbn.com> Date: Tue, 6 Oct 2015 10:58:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] whoops? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2015 14:58:47 -0000 It seems that the attack model I-D osted this Am is not the new one! We'll try to fix that RSN! Sorry, Steve From nobody Tue Oct 6 12:34:53 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AC91B31E6; Tue, 6 Oct 2015 12:34:50 -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 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 divABBBVyB4i; Tue, 6 Oct 2015 12:34:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720401B31C7; Tue, 6 Oct 2015 12:34:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151006193449.7084.76890.idtracker@ietfa.amsl.com> Date: Tue, 06 Oct 2015 12:34:49 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-03.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 19:34:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Attack Model and Threat for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-03.txt Pages : 24 Date : 2015-10-06 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 6 12:36:11 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2AC1B31EC for ; Tue, 6 Oct 2015 12:36:09 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zQVCVf_w08Wo for ; Tue, 6 Oct 2015 12:36:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2520A1B31EA for ; Tue, 6 Oct 2015 12:36:08 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:52457 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZjY1u-0005yI-Ul for trans@ietf.org; Tue, 06 Oct 2015 15:36:07 -0400 To: "trans@ietf.org" From: Stephen Kent Message-ID: <561422A6.6000202@bbn.com> Date: Tue, 6 Oct 2015 15:36:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] really posted the update this time X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2015 19:36:09 -0000 the -03 version of the threat/attack model (now available) is the properly updated version. sorry for the confusion, Steve From nobody Thu Oct 8 07:10:37 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8461A011F for ; Thu, 8 Oct 2015 07:10:36 -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 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 KjwbjML6VfkV for ; Thu, 8 Oct 2015 07:10:34 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DAB1A0137 for ; Thu, 8 Oct 2015 07:10:33 -0700 (PDT) Received: (qmail 9644 invoked by uid 1004); 8 Oct 2015 14:10:30 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 08 Oct 2015 15:10:30 +0100 Received: (qmail 1351 invoked by uid 1000); 8 Oct 2015 14:10:30 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 08 Oct 2015 15:10:30 +0100 To: Stephen Kent , Ben Laurie , trans@ietf.org References: <064.63d919d95b92ab76c7b87296ee93e7e2@tools.ietf.org> <079.7c98c2226d9e5ed62316ba3f88211625@tools.ietf.org> <55F1BBA2.9080604@bbn.com> <55F69767.7030407@comodo.com> <560995BC.6020301@bbn.com> <5609A050.1010602@comodo.com> <560AB3B9.50309@bbn.com> <5612C2B0.3000105@bbn.com> From: Rob Stradling Message-ID: <56167955.3050903@comodo.com> Date: Thu, 8 Oct 2015 15:10:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5612C2B0.3000105@bbn.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2015 14:10:36 -0000 On 05/10/15 19:34, Stephen Kent wrote: > Ben, >> >> ... >> >> This is true even if you use hashes, surely? For example, an old key >> (from a log no longer known to someone) could be reused. Or a key for >> a log that was never used publicly. Or the same key could be used for >> two logs accepted by different clients. And so on. > > I would expect a Monitor to keep track of the public key for each log > operator that it watches, (but that should be stated explicitly). Yes. > Thus re-use of an old key by that log operator, for a new log instance, > wouldbe detected easily if the log ID were derived from the public key. That seems like a non sequitur to me. Since a monitor has a copy of every log's public key, it can compare these public keys to ensure that each one is used by only 1 log. Or, since it knows each public_key, the monitor could calculate HASH(public_key) all by itself and then check the uniqueness of each. It makes no difference whether LogID is defined as HASH(public_key), an OID, or something else. > The most common case, if the re-use is accidental, > is probably starting a new log instance but not remembering to change > the key. That would > be obvious/impossible if the ID were derived from the key. > > However, I agree that a log re-using a key from some other log would not be > detected by this approach. > > Steve > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Oct 9 18:38:17 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70A1B50F9 for ; Fri, 9 Oct 2015 18:38:16 -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 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 K3DDbzg91pnD for ; Fri, 9 Oct 2015 18:38:15 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 20CB31B50F0 for ; Fri, 9 Oct 2015 18:38:15 -0700 (PDT) Received: by pablk4 with SMTP id lk4so101371574pab.3 for ; Fri, 09 Oct 2015 18:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zOFfSUgWdEPniEqes+YwoJJRSofF7M4QPgMFOU/sUJs=; b=XVUUDNcGH+DxFCZ5QRYtdmDR9VECB3NgnHTo4SFusvIhxo6liOlzfwLsDn9OgbowfW cg9GuD5UGuXsxzEWjOdEXp0+B+8h0gsIL2YPWAmmXGlaNjhkVs7UbQffc8YP7uOQkpac C99ny4rNEOP1lG7miuW8j8unp8FsvSMYrHnADbSPctJXOCl8ds/sSjGMPv1QRiSVjWNe zUtbGfbRJ2DjhhlPxXWd3Qoll8xI9vDAk2Fbz7aoOPQtdE2nSQzHyPBevPOwIE1luxbN OitRVZZyNByiGwN03GHUxOU6o72/Nv0Fpy1cdl0S9xAkvvNTH9utU27czS2wHQ5BERsw H+uQ== X-Received: by 10.66.151.203 with SMTP id us11mr19310422pab.54.1444441094841; Fri, 09 Oct 2015 18:38:14 -0700 (PDT) Received: from spandex.local (63-140-93-250-radius.dynamic.acsalaska.net. [63.140.93.250]) by smtp.gmail.com with ESMTPSA id tj2sm4925572pab.4.2015.10.09.18.38.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 18:38:14 -0700 (PDT) Message-ID: <56186C02.2060207@gmail.com> Date: Fri, 09 Oct 2015 17:38:10 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <20151010012848.29540.43803.idtracker@ietfa.amsl.com> In-Reply-To: <20151010012848.29540.43803.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20151010012848.29540.43803.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: trans - Requested session has been scheduled for IETF 94 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2015 01:38:17 -0000 The schedule's been finalized, and we're still scheduled for Monday at 1pm. Melinda -------- Forwarded Message -------- Subject: trans - Requested session has been scheduled for IETF 94 Date: Fri, 09 Oct 2015 18:28:48 -0700 From: IETF Secretariat To: melinda.shore@gmail.com CC: trans-ads@ietf.org, melinda.shore@gmail.com, paul@nohats.ca 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 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: Rooms 411/412 size: 120 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Melinda Shore Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: tls dane sidr Second Priority: dnsop acme Special Requests: Due to Ben Laurie's availability prefer earlier in the week --------------------------------------------------------- From nobody Mon Oct 12 07:31:19 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B171B3337 for ; Mon, 12 Oct 2015 07:31:17 -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 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 lqtNdJjK82aQ for ; Mon, 12 Oct 2015 07:31:16 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 6F3151B3383 for ; Mon, 12 Oct 2015 07:31:16 -0700 (PDT) Received: by qkdo1 with SMTP id o1so49615461qkd.1 for ; Mon, 12 Oct 2015 07:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BA7JMkiHusc4zqB6BVnU9a3OT1YSv+WpgfQaH9yR+KU=; b=JGUuGVtVE1SBvDf5QXuF+OXKhMicpMMA7og+/xhEdQAlnKCJ7zl1h3DC1gOQEj9QYO 22ohBAwTfiUM4PmUSGTZ2HWzJb7QhPZIfYQqhdU1cdaEo4flSc7vx1nFg5MWa7qnC65f kgSQeeYTWFKTQDlDNpFfigWzhONP1k/yL9e5JNtAJcpy8jEBtjISW4e2WW/7rvO4x5/0 706UpyPfMwL0YvYF3yKaQ34nHtfrxQ8yvHJQRR3GNO6kA90LnaDGp9Ef8Pkv19KBe2YN UjcV8qm0H8BXfOMESq0X6hj+onZqjhuirFXDSrP4JOpTiS+boR0jPk8Fmew257LIKd89 GBfA== X-Received: by 10.55.198.90 with SMTP id b87mr32370028qkj.20.1444660275655; Mon, 12 Oct 2015 07:31:15 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (nat1.corp-fo.iad1.verisign.com. [216.168.230.7]) by smtp.googlemail.com with ESMTPSA id 103sm7252527qgx.35.2015.10.12.07.31.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2015 07:31:14 -0700 (PDT) Message-ID: <561BC432.6020300@gmail.com> Date: Mon, 12 Oct 2015 06:31:14 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Remote presentation at IETF 94 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2015 14:31:17 -0000 Hi, all: We need to give Meetecho advance warning of any remote presenters at IETF 94. If you are planning on presenting from a remote location, please let us know. (Also, plan on being available for testing a few minutes before the session starts). Thanks, Melinda From nobody Tue Oct 13 03:08:41 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B3E1A00DC; Tue, 13 Oct 2015 03:08:38 -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 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 jyQyMuSQmwiu; Tue, 13 Oct 2015 03:08:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0E1A1BCD; Tue, 13 Oct 2015 03:06:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151013100652.9394.46243.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 03:06:52 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-09.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 10:08:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-09.txt Pages : 43 Date : 2015-10-13 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 13 06:52:10 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F231B3FAF for ; Tue, 13 Oct 2015 06:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 drZvkkZ-2w0t for ; Tue, 13 Oct 2015 06:52:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D351B3FAD for ; Tue, 13 Oct 2015 06:52:07 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:40698 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Zlzzp-0009gD-Vh; Tue, 13 Oct 2015 09:52:06 -0400 From: Stephen Kent To: Rob Stradling , Ben Laurie , trans@ietf.org References: <064.63d919d95b92ab76c7b87296ee93e7e2@tools.ietf.org> <079.7c98c2226d9e5ed62316ba3f88211625@tools.ietf.org> <55F1BBA2.9080604@bbn.com> <55F69767.7030407@comodo.com> <560995BC.6020301@bbn.com> <5609A050.1010602@comodo.com> <560AB3B9.50309@bbn.com> <5612C2B0.3000105@bbn.com> <56167955.3050903@comodo.com> Message-ID: <561D0C85.3080709@bbn.com> Date: Tue, 13 Oct 2015 09:52:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56167955.3050903@comodo.com> Content-Type: multipart/alternative; boundary="------------050407040208030402090506" Archived-At: Subject: Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2015 13:52:09 -0000 This is a multi-part message in MIME format. --------------050407040208030402090506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Rob, > >> Thus re-use of an old key by that log operator, for a new log instance, >> wouldbe detected easily if the log ID were derived from the public key. > > That seems like a non sequitur to me. > > Since a monitor has a copy of every log's public key, a Monitor has a copy of every public key for every log that _it watches_, and perhaps only since it began watching the log. > it can compare these public keys to ensure that each one is used by > only 1 log. only for the logs it watches. > Or, since it knows each public_key, the monitor could calculate > HASH(public_key) all by itself and then check the uniqueness of each. > > It makes no difference whether LogID is defined as HASH(public_key), > an OID, or something else. I expect that the most common way that a "new" log would fail to switch to a new key pair is by reusing the same pair it had been using most recently, i.e., an error, not a malicious action. if so then using a key hash as an ID should make it very obvious when this sort of error occurs. Anyway, I don't think we need to continue to debate this. If you and other developers are happy with the OID approach, so be it. Steve --------------050407040208030402090506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Rob,

Thus re-use of an old key by that log operator, for a new log instance,
wouldbe detected easily if the log ID were derived from the public key.

That seems like a non sequitur to me.

Since a monitor has a copy of every log's public key,

a Monitor has a copy of every public key for every log that it watches, and perhaps
only since it began watching the log.

it can compare these public keys to ensure that each one is used by only 1 log.

only for the logs it watches.

Or, since it knows each public_key, the monitor could calculate HASH(public_key) all by itself and then check the uniqueness of each.

It makes no difference whether LogID is defined as HASH(public_key), an OID, or something else.

I expect that the most common way that a "new" log would fail to switch to a new
key pair is by reusing the same pair it had been using most recently, i.e., an error, not
a malicious action. if so then using a key hash as an ID should make it very obvious
when this sort of error occurs.

Anyway, I don't think we need to continue to debate this. If you and other
developers are happy with the OID approach, so be it.

Steve
--------------050407040208030402090506-- From nobody Sun Oct 18 16:52:30 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781141B2A40 for ; Sun, 18 Oct 2015 16:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 gyqHfdaNLp5F for ; Sun, 18 Oct 2015 16:52:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 72CF61B2A3D for ; Sun, 18 Oct 2015 16:52:28 -0700 (PDT) Received: from localhost ([::1]:53339 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZnxkZ-0002VU-Q4; Sun, 18 Oct 2015 16:52:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, dkg@fifthhorseman.net X-Trac-Project: trans Date: Sun, 18 Oct 2015 23:52:27 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/109 Message-ID: <061.6a3256b56d42ed15e92382b72ed5fc5b@tools.ietf.org> X-Trac-Ticket-ID: 109 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, dkg@fifthhorseman.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20151018235228.72CF61B2A3D@ietfa.amsl.com> Resent-Date: Sun, 18 Oct 2015 16:52:28 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 23:52:29 -0000 #109: log shutdown timeline and behavior 6962-bis currently describes the "Final STH" element of the log's metadata. However, there is no overall description of what the log shutdown process should look like from the log operator's point of view. 6962-bis should include an example timeline of a responsible log shutdown as implementation guidance for operators. Some questions worth answering include: * how long after shutdown should a responsible log continue publishing? * should advance notice of an impending shutdown be given? if so, * how long in advance? * Is there a mechanism for such notice? * for a shutdown log that is still operating, how should it respond to requests for new SCTs? the existing error codes don't seem to indicate an option for "this log is shut down and no longer accepting new requests" See also #101 for how CT gossip needs to interact with a log that has shutdown. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Sun Oct 18 16:54:09 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2021B2A47 for ; Sun, 18 Oct 2015 16:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0R9VcNyAGtCT for ; Sun, 18 Oct 2015 16:54:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 494481B2A46 for ; Sun, 18 Oct 2015 16:54:07 -0700 (PDT) Received: from localhost ([::1]:53592 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Znxm9-0002ax-45; Sun, 18 Oct 2015 16:54:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Sun, 18 Oct 2015 23:54:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/107#comment:3 Message-ID: <079.7f9f8e250d41c21a68c5596ccfe45451@tools.ietf.org> References: <064.037c94c1b2af210ccde96f4d9f68ae88@tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <064.037c94c1b2af210ccde96f4d9f68ae88@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, melinda.shore@gmail.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #107 (rfc6962-bis): Struct-ify STH X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 23:54:08 -0000 #107: Struct-ify STH Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: enhancement | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Oct 19 01:16:56 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189D91A7001 for ; Mon, 19 Oct 2015 01:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8NEE-JYWUNnQ for ; Mon, 19 Oct 2015 01:16:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 906081A6FFC for ; Mon, 19 Oct 2015 01:16:52 -0700 (PDT) Received: from localhost ([::1]:51285 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zo5cg-0002DF-TY; Mon, 19 Oct 2015 01:16:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Mon, 19 Oct 2015 08:16:50 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/98#comment:2 Message-ID: <070.b26c0c0cd90f2835dee4257f2ca6ea35@tools.ietf.org> References: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20151019081652.906081A6FFC@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2015 01:16:52 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #98 (gossip): Update gossip-ct for 6962bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:16:55 -0000 #98: Update gossip-ct for 6962bis Comment (by linus@nordu.net): Addressed in upcoming -01 (commit ca35e2f in https://github.com/ln5/draft- ietf-trans-gossip). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- linus@nordu.net | analysis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 19 01:17:03 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3931A701D for ; Mon, 19 Oct 2015 01:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 5Ii7ybDdW9AH for ; Mon, 19 Oct 2015 01:16:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EE3F21A700D for ; Mon, 19 Oct 2015 01:16:58 -0700 (PDT) Received: from localhost ([::1]:51291 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zo5co-0002oC-Nm; Mon, 19 Oct 2015 01:16:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Mon, 19 Oct 2015 08:16:58 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/98#comment:3 Message-ID: <070.3bccf5c72275a5592396f34f347edb09@tools.ietf.org> References: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <055.bc4011473cb4fc46fd07bb547773f0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20151019081658.EE3F21A700D@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2015 01:16:58 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #98 (gossip): Update gossip-ct for 6962bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:17:02 -0000 #98: Update gossip-ct for 6962bis Changes (by linus@nordu.net): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- linus@nordu.net | analysis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 19 01:27:50 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB251A7D82 for ; Mon, 19 Oct 2015 01:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 4FJMftChpvNP for ; Mon, 19 Oct 2015 01:27:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 53DC61A7D85 for ; Mon, 19 Oct 2015 01:27:43 -0700 (PDT) Received: from localhost ([::1]:51981 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zo5nC-0003db-W4; Mon, 19 Oct 2015 01:27:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Mon, 19 Oct 2015 08:27:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/100#comment:1 Message-ID: <068.e4233f9c9e6751d6c3d8ac72e619b6da@tools.ietf.org> References: <053.5d17eed2b9e6d95cd2ee4d7b33a6d5a4@tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <053.5d17eed2b9e6d95cd2ee4d7b33a6d5a4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-threat-analysis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-threat-analysis@ietf.org Resent-Message-Id: <20151019082743.53DC61A7D85@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2015 01:27:43 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #100 (gossip): Review in light of blocking X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:27:47 -0000 #100: Review in light of blocking Changes (by linus@nordu.net): * status: new => closed * resolution: => fixed Comment: Sections "Censorship/Blocking considerations" and "Blocking Recommendations" added to upcoming -01 (commit 2f98976 in https://github.com/ln5/draft-ietf-trans-gossip). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- tom@ritter.vg | analysis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 19 01:29:44 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4581A7D85 for ; Mon, 19 Oct 2015 01:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 qBwFaC1QnK2a for ; Mon, 19 Oct 2015 01:29:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 815C01A802E for ; Mon, 19 Oct 2015 01:29:41 -0700 (PDT) Received: from localhost ([::1]:52086 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zo5p7-0003zu-86; Mon, 19 Oct 2015 01:29:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net X-Trac-Project: trans Date: Mon, 19 Oct 2015 08:29:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:1 Message-ID: <076.8a29bfa6de2eaa14f0ca0b4a06549c2c@tools.ietf.org> References: <061.6a3256b56d42ed15e92382b72ed5fc5b@tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <061.6a3256b56d42ed15e92382b72ed5fc5b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20151019082941.815C01A802E@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2015 01:29:41 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:29:43 -0000 #109: log shutdown timeline and behavior Changes (by linus@nordu.net): * cc: linus@nordu.net (added) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- dkg@fifthhorseman.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Oct 19 02:28:54 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687851A87D0 for ; Mon, 19 Oct 2015 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 U9_N6jsZlI2w for ; Mon, 19 Oct 2015 02:28:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3C60B1A87A3 for ; Mon, 19 Oct 2015 02:28:52 -0700 (PDT) Received: from localhost ([::1]:54425 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Zo6kN-00075o-Mn; Mon, 19 Oct 2015 02:28:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Mon, 19 Oct 2015 09:28:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/110 Message-ID: <064.3d181d134b4cdc63a4a9ae45acf2b679@tools.ietf.org> X-Trac-Ticket-ID: 110 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #110 (rfc6962-bis): Reorganize requirements into appropriate sections X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:28:53 -0000 #110: Reorganize requirements into appropriate sections The "Log Format and Operation" section should describe just that. Requirements for other parties (Submitters, CAs, TLS servers and TLS clients) should be moved into more appropriate sections. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Oct 19 04:31:38 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE621A8A42 for ; Mon, 19 Oct 2015 04:31:36 -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_40=-0.001, GB_I_LETTER=-2] autolearn=ham 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 ljXcflBNllZt for ; Mon, 19 Oct 2015 04:31:34 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00B11A8A41 for ; Mon, 19 Oct 2015 04:31:33 -0700 (PDT) Received: (qmail 10109 invoked by uid 1004); 19 Oct 2015 11:31:30 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 19 Oct 2015 12:31:30 +0100 Received: (qmail 2308 invoked by uid 1000); 19 Oct 2015 11:31:30 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 19 Oct 2015 12:31:30 +0100 To: certificate-transparency@googlegroups.com, "trans@ietf.org" , "ct-policy@chromium.org" References: From: Rob Stradling Message-ID: <5624D492.8040400@comodo.com> Date: Mon, 19 Oct 2015 12:31:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Certificate Transparency Newsletter - August 2015 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 11:31:36 -0000 On 17/08/15 18:24, 'Adam Eijdenberg' via certificate-transparency wrote: > (posted to certificate-transparency@googlegroups.com, trans@ietf.org > and ct-policy@chromium.org) > Lookahead: > - We're very interested in exploring how we make it viable for a > site-owner to be able to opt-in to requiring CT, ahead of any general > browser-enforced deadlines. We would welcome participation in helping > define what this might look like in a manner that would work well for > both browsers and site-owners. Adam, RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension" This newly standardized certificate extension could be used to signal that the TLS server MUST send the CT TLS extension. I realize that this may not suit many early adopters, since few deployed servers support the CT TLS extension yet. But I figured it was worth mentioning. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Oct 19 06:30:01 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77141A1B17 for ; Mon, 19 Oct 2015 06:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham 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 Qet_djHgD_5J for ; Mon, 19 Oct 2015 06:29:59 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 5222D1A1AFC for ; Mon, 19 Oct 2015 06:29:59 -0700 (PDT) Received: by qgem9 with SMTP id m9so8061944qge.1 for ; Mon, 19 Oct 2015 06:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dEybHmD3Sg5t7nsF6kGPRz3xN8V4UFNhR1wWCdWasAo=; b=BibilUKp9PG3uAxW5jaCNP0ov/x52CZTWH8WnOHvUjYHt5M45gEy2faJNcKLUu7m/U cGHjCMKC8hY8Azh/BIdKFNC3c+blXoH+dUZeEl3ZLpmlJ5iW63POkQjORcGO5rbTVoaB wTgTwJzTojd2zajY5C7j0bBbpJCRhUbKEaUgY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dEybHmD3Sg5t7nsF6kGPRz3xN8V4UFNhR1wWCdWasAo=; b=D/2K+3aYSV0FK9/erGkXxUpW9Oas1RwLbw8dAjy3JWkyHzioVgYW0uWjxWsRb6h97F AXQNialauC3PXTSr9H1LPGxDTxvKurkNOFt0twl80k2CwKzNNPK9jpEelENEdLWgqY1Z +5nq2/tEAJCuzDxl/cxOhAZBMB+BlegW77v+KCWcYFzG4IuywUzUjyNaQEU303Amwwj0 dd4k7pI+WJ328KoekIreOFRLwbVOVfdKHH+qgIHUkd3wgpkGkKl98XxpSKfIHMv5xiXi tDcdCZlNbti1HcO8W3hLh9pbxWwL/1CJvHHzxgxEcQluWqUffVdo5wfr/Ja5yZxvbiZF RKxQ== X-Gm-Message-State: ALoCoQmc0HqJUKiYVD6WAw540C40tWWKWCaIEAcFcrb+p0Lr6cJ432qg/jR8Y8UEEcZj3WahvTmI X-Received: by 10.140.41.81 with SMTP id y75mr36217022qgy.5.1445261398384; Mon, 19 Oct 2015 06:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.6 with HTTP; Mon, 19 Oct 2015 06:29:38 -0700 (PDT) In-Reply-To: <5624D492.8040400@comodo.com> References: <5624D492.8040400@comodo.com> From: Tom Ritter Date: Mon, 19 Oct 2015 08:29:38 -0500 Message-ID: To: certificate-transparency Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ct-policy@chromium.org" , "trans@ietf.org" Subject: Re: [Trans] Certificate Transparency Newsletter - August 2015 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 13:30:01 -0000 On 19 October 2015 at 06:31, Rob Stradling wrote: > On 17/08/15 18:24, 'Adam Eijdenberg' via certificate-transparency wrote: >> >> (posted to certificate-transparency@googlegroups.com, trans@ietf.org >> and ct-policy@chromium.org) > > >> >> Lookahead: >> - We're very interested in exploring how we make it viable for a >> site-owner to be able to opt-in to requiring CT, ahead of any general >> browser-enforced deadlines. We would welcome participation in helping >> define what this might look like in a manner that would work well for >> both browsers and site-owners. > > > Adam, > > RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension" > > This newly standardized certificate extension could be used to signal that > the TLS server MUST send the CT TLS extension. > > I realize that this may not suit many early adopters, since few deployed > servers support the CT TLS extension yet. But I figured it was worth > mentioning. It could... but that seems awfully limited. Requiring CT is a lot easier than requiring one of the specific forms. If you change infrastructure, and lose the ability to include a TLS Extension, you can at least staple OCSP or get them embedded in a cert. -tom From nobody Mon Oct 19 07:06:03 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0791A6FCB for ; Mon, 19 Oct 2015 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 NihEYtlzN7NX for ; Mon, 19 Oct 2015 07:05:59 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) (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 26AA11A6FA3 for ; Mon, 19 Oct 2015 07:05:58 -0700 (PDT) Received: (qmail 28598 invoked by uid 1004); 19 Oct 2015 14:05:55 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 19 Oct 2015 15:05:55 +0100 Received: (qmail 18273 invoked by uid 1000); 19 Oct 2015 14:05:55 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 19 Oct 2015 15:05:55 +0100 To: Tom Ritter References: <5624D492.8040400@comodo.com> From: Rob Stradling Message-ID: <5624F8C3.8020301@comodo.com> Date: Mon, 19 Oct 2015 15:05:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ct-policy@chromium.org" , "trans@ietf.org" , certificate-transparency Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 14:06:02 -0000 On 19/10/15 14:29, Tom Ritter wrote: > On 19 October 2015 at 06:31, Rob Stradling wrote: >> On 17/08/15 18:24, 'Adam Eijdenberg' via certificate-transparency wrote: >>> >>> (posted to certificate-transparency@googlegroups.com, trans@ietf.org >>> and ct-policy@chromium.org) >> >> >>> >>> Lookahead: >>> - We're very interested in exploring how we make it viable for a >>> site-owner to be able to opt-in to requiring CT, ahead of any general >>> browser-enforced deadlines. We would welcome participation in helping >>> define what this might look like in a manner that would work well for >>> both browsers and site-owners. >> >> >> Adam, >> >> RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension" >> >> This newly standardized certificate extension could be used to signal that >> the TLS server MUST send the CT TLS extension. >> >> I realize that this may not suit many early adopters, since few deployed >> servers support the CT TLS extension yet. But I figured it was worth >> mentioning. > > It could... but that seems awfully limited. Requiring CT is a lot > easier than requiring one of the specific forms. If you change > infrastructure, and lose the ability to include a TLS Extension, you > can at least staple OCSP or get them embedded in a cert. That's true. Perhaps 6962-bis should prohibit or recommend against using TLS Feature for the CT TLS extension then. Or... Actually, I can't find any explicit requirement in RFC7633 that says words to the effect of "The TLS server MUST send TLS extension X". The actual requirements are expressed more vaguely than that. e.g. "A server offering an end-entity certificate with a TLS feature extension MUST satisfy a client request for the specified feature" "If these features are requested by the client in its ClientHello message, then the server MUST return a ServerHello message that satisfies this request." So, perhaps 6962-bis could specify that, if a TLS client sends the CT TLS extension and the TLS server's cert contains the TLS Feature cert extension with the CT TLS extension identifier, then the TLS server MUST "satisfy the request" by sending SCTs via any of the three supported mechanisms (CT TLS extension, cert extension, stapled OCSP response extension). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Oct 19 09:29:58 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB81A8996 for ; Mon, 19 Oct 2015 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham 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 Fo1YKukexsyH for ; Mon, 19 Oct 2015 09:29:55 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 743A41A8853 for ; Mon, 19 Oct 2015 09:29:55 -0700 (PDT) Received: by qgad10 with SMTP id d10so68872918qga.3 for ; Mon, 19 Oct 2015 09:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pgRxpUHrRVXFUU2RzXgBfUdvrhP6yByPc5ldWxHsjS4=; b=Yz5ytOn0afBy/65DeFRnashrdc+7f088NBsdefOv8MJwl0v25m2Ihr2MslRTXt8gvl jioF6pd2Y6P/HdCQDJq42k78JLXcu76gjzmKcbki3kxEQ40eJRzvrkrc7ojSNpamqTlw O3/Lox1BiH2AsgNHzKW7jZaYAwgvNkcflYJzI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pgRxpUHrRVXFUU2RzXgBfUdvrhP6yByPc5ldWxHsjS4=; b=VTMCRZIs+CWCm8vIV5mAEQff5SLrYasBnfnVZLsc3amGJcWzeXWvrNKtFR2pkJph3Z 5Pg+B8jrR0dr8ahLrTJfWexs/ocKAKoMNVYeIktdbzcMYUz9nZAiBPQPZqd2nc+AeLAD jARAScNJ0wCJ+/3RxsjdnDg6ZGT5AqrJLv4wxtY0cM2jGjerW8m0AOcpGAtPGym/I+aW gqkpqo+cT/vMzqX/dv5C6VuCCr1Yn/5XM4L7K1fIGJ0SGGH1ojCMkkijajbryMOecLfA V4HPDWoav5aW1X6Jwx2OQ4A9jCExqFBu6op3Q2q2LZomOnyLaC09UZbfgIkDCudw89b+ 2vUg== X-Gm-Message-State: ALoCoQnKFEqafJv2OVzqFM0VI0LAbRSdtp+f2+q8ULsq9EQbKCYgVO2sqy6q+74n1peIXKUwoVma X-Received: by 10.140.100.240 with SMTP id s103mr35928415qge.25.1445272194592; Mon, 19 Oct 2015 09:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.6 with HTTP; Mon, 19 Oct 2015 09:29:35 -0700 (PDT) In-Reply-To: <5624F8C3.8020301@comodo.com> References: <5624D492.8040400@comodo.com> <5624F8C3.8020301@comodo.com> From: Tom Ritter Date: Mon, 19 Oct 2015 11:29:35 -0500 Message-ID: To: certificate-transparency Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ct-policy@chromium.org" , "trans@ietf.org" Subject: Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 16:29:57 -0000 On 19 October 2015 at 09:05, Rob Stradling wrote: > Perhaps 6962-bis should prohibit or recommend against using TLS Feature for > the CT TLS extension then. Or... > > Actually, I can't find any explicit requirement in RFC7633 that says words > to the effect of "The TLS server MUST send TLS extension X". The actual > requirements are expressed more vaguely than that. e.g. > "A server offering an end-entity certificate with a TLS feature > extension MUST satisfy a client request for the specified feature" > "If these features are requested by the client in its ClientHello > message, then the server MUST return a ServerHello message that > satisfies this request." > > So, perhaps 6962-bis could specify that, if a TLS client sends the CT TLS > extension and the TLS server's cert contains the TLS Feature cert extension > with the CT TLS extension identifier, then the TLS server MUST "satisfy the > request" by sending SCTs via any of the three supported mechanisms (CT TLS > extension, cert extension, stapled OCSP response extension). So... you could. But it wouldn't solve the generic problem of letting a site owner dictate that CT should always be enabled for their domain. The reason I'm critical of 7633 is that it only applies to a single certificate[0]. If I want to 'enforce' CT for a single certificate, via a x509 extension... I could just put the CT x509 extension in the certificate. I'm opposed to the idea of a x509 extension seen on one certificate, once, applying a policy for the entire domain. For one thing it's weird, and for another thing it has no way to indicate how long the policy should apply for. (And it couldn't work for wildcard certs.) [0] Now technically where 7633 really comes into play and is very useful is when it's included in intermediates or (my pounding heart be still) - root certs. In *that* case it would work great for requiring CT... but not for site owners, for certificate authorities. A CA is assured that all the certs it issues will be publicly logged, and it can use this as a check against misissuance. I think that's great... but it still doesn't help site owners. =) -tom From nobody Mon Oct 19 15:53:48 2015 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 D1B291ACE51; Mon, 19 Oct 2015 15:53:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019225344.6198.67087.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:53:44 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-gossip-01.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:53:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Gossiping in CT Authors : Linus Nordberg Daniel Kahn Gillmor Tom Ritter Filename : draft-ietf-trans-gossip-01.txt Pages : 26 Date : 2015-10-19 Abstract: The logs in Certificate Transparency are untrusted in the sense that the users of the system don't have to trust that they behave correctly since the behaviour of a log can be verified to be correct. This document tries to solve the problem with logs presenting a "split view" of their operations. It describes three gossiping mechanisms for Certificate Transparency: SCT Feedback, STH Pollination and Trusted Auditor Relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-gossip-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-gossip-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 15:55:19 2015 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 04A161B2E39; Mon, 19 Oct 2015 15:55:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019225517.30916.67444.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:55:17 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-10.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:55:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Eran Messeri Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-10.txt Pages : 43 Date : 2015-10-19 Abstract: This document describes a protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 16:26:26 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33AE1B2EB9 for ; Mon, 19 Oct 2015 16:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 xuefxBbFFL6E for ; Mon, 19 Oct 2015 16:26:24 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 88E1E1B2EB0 for ; Mon, 19 Oct 2015 16:26:24 -0700 (PDT) Received: by qgem9 with SMTP id m9so609404qge.1 for ; Mon, 19 Oct 2015 16:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=YJJ2fQZ3QhaJOF1VTjwdobZgyQk0T1nX2ZoTHsKyZUA=; b=Az1TEusqmndnzpsu3euQhTC1B/hJgG/TsPSUUTaF0QBagsnneezFDb6LqFWZ6eWWla KOqw1r/tMCSKMCqzoKprgn7PFjLV7I3QWejlAAxbds4ewi7KW+2v+cqAErAF2BXqOLlv V0pwHkpahz+C+aL5BgYgy5M1K6anOH1rUT4Ao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=YJJ2fQZ3QhaJOF1VTjwdobZgyQk0T1nX2ZoTHsKyZUA=; b=BCvh+2mCDYtvk73gTN8IReEENt9izuMHaXtVUMIKyoE5iLQHUWn4Ak564rPpKOzlSm 3aXB5aUp7Ir34u6kfZt7Z2vK9C2w7wP/675N3CCzwWKKSbxZwz25AbIMUQFu4N+LJmaB E5DYcwXpXXTAnB7+XW7BdNt6vUBNj2+Iivc7w1bwoSK6Te3/WcrYtXQwNEo8joY9mHlx rkb/+JhDe1gCgxdGd0XZu2R4ax4PJkgHnrNuI6DlpKOiek94CEnpMHkZV5/I9lX3otVT YTDFSqkkFwEu2ZdBqxBn/m5KaMA7zJcwf+S+LAa7/qar1XbUc380eiFQoiiUugQRKVix 0PPw== X-Gm-Message-State: ALoCoQmS10GJxdRAqHeydPDTr2+oPfnBY0nC+Eprd+SFwcWLJtR4e9WxA2ONgqncy4elUZU8pjuJ X-Received: by 10.140.134.211 with SMTP id 202mr48717qhg.51.1445297183805; Mon, 19 Oct 2015 16:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.94.6 with HTTP; Mon, 19 Oct 2015 16:26:04 -0700 (PDT) From: Tom Ritter Date: Mon, 19 Oct 2015 18:26:04 -0500 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Gossip: Unsticking a client caught with potential evidence of log misbehavior X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 23:26:26 -0000 Hi all, So as we're working through the Gossip draft we ran into a problem we're not really sure how to solve. The gist of it is that a client can wind up in a state where it has a piece of data that it is pretty suspicious of, and it might be evidence of log misbehavior - but it's also private data and it has no way to share it with the world. We have not addressed this in the -01 draft, it's an open question with no text currently. Here are some ways that situation can arise (not exhaustive, but the draft will have an exhaustive list): A client has a Cert+SCT and wants an inclusion proof. Every time it sends it up to the log (via an appropriately privacy-preserving mechanism, such as a DNS proxy), it gets the equivalent of a 500 error, even through other inclusion proof requests succeed. A client has an older STH and it wants a consistency proof to a newer STH that it can pollinate. But it gets an error on every request, even though other consistency proof requests succeed. A client knows a log has shut down, and it has the 'final STH'. It has an older STH and wants to resolve it to the final STH, but again - errors. We've been working off the assumption that some data would get out to auditors and the auditors would detect the misbehavior - but here the client has a piece of data that is privacy-sensitive, so it can't just broadcast it widely. But it also could be evidence of log misbehavior - and the fact that it gets other successful responses from the log makes it even more suspicious. What should it do? I've been talking about the possibility of an 'escape valve' where a client would release private information to an auditor-of-last-resort of its choosing (well, chosen by the developer of the client probably) after a sufficiently rigorous attempt to resolve it in a private manner... but that's not very satisfying. And it's even less satisfying to wave our hand and leave the criteria for releasing it undefined (because it ties so much into the algorithm for how to release data in any circumstance.) We even talked about UI/UX. This is such a crazy and rare situation that there's no hope of explaining it to users. It's also something disconnected from any browsing session, so it's not possible to put a link on an intersitial as Chrome has done. The closest analogy is bug/crash reporting, either active (Windows/Apple sometimes asks if you want to submit queued error reports) or general browser opt-in (I believe Chrome/Firefox have some mechanism where you 'share data with the company to make the experience better'). -tom From nobody Mon Oct 19 20:28:39 2015 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B0B1B2A78 for ; Mon, 19 Oct 2015 20:28:38 -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 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 W-1peGssZU6S for ; Mon, 19 Oct 2015 20:28:37 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 32BCE1B29DD for ; Mon, 19 Oct 2015 20:28:37 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so6853447pac.3 for ; Mon, 19 Oct 2015 20:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LHWJre9NgRTpEyFXGBmhaUd8zYhhkZ/I6eUZRmmInmY=; b=Qrer9noqyq8r/W0l1HUM1VEFo/cV7gfpnFyMEXCiVMYob8EcRxkieOItYToHfEGs2q A+tfcdl7aXBNFpTnBA0eOlsKtLkEOdor1zgpuAYfz0xtIdo66o6isfZN13o1XgghFiUb t6V0sGRxRj/1FyBY/YfsGuBnsoGiYOyC+a1i2Ox5lKTQCVhAePVTAkOfgT3ya3nveu4u Bp5iYIzTvNhCwg95wPU208opmdxLZ8K8KCE2aTwB7LOaelCU55db87Uyo7hVwfbCXa5V HgciWgb/cYVY2I1ipuDKIiVcwxs7m3qq8d9+CZbIsDU+U4oHvhn4htuUVuPBwq55P5Ke wQpg== X-Received: by 10.66.157.135 with SMTP id wm7mr1207521pab.22.1445311716732; Mon, 19 Oct 2015 20:28:36 -0700 (PDT) Received: from spandex.local (63-140-87-154-radius.dynamic.acsalaska.net. [63.140.87.154]) by smtp.gmail.com with ESMTPSA id fb1sm711566pab.9.2015.10.19.20.28.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 20:28:35 -0700 (PDT) Message-ID: <5625B4E2.4080109@gmail.com> Date: Mon, 19 Oct 2015 19:28:34 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Draft agenda posted X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: ,