From nobody Wed May 3 07:23: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 223631286CA for ; Wed, 3 May 2017 07:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_40=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8yciXk-kJ-y; Wed, 3 May 2017 07:23:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8521273E2; Wed, 3 May 2017 07:21:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 14:21:06 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/188#comment:1 Message-ID: <043.287e326422423f1cbb47bf379bc2048d@ietf.org> References: <028.e78906507b088d8f45d22542d13dd884@ietf.org> X-Trac-Ticket-ID: 188 In-Reply-To: <028.e78906507b088d8f45d22542d13dd884@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #188: Specify an empty consistency proof for equal tree sizes X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:23:40 -0000 #188: Specify an empty consistency proof for equal tree sizes -------------------------+--------------------------------------------- Reporter: eranm@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: Fixed in https://github.com/google/certificate-transparency- rfcs/commit/7923c89c746c9f0a6d844b70856dd8bdab0e7fbe. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 07:57: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 431AD129B40 for ; Wed, 3 May 2017 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qBMUhNPKrZe; Wed, 3 May 2017 07:57:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98530129AB2; Wed, 3 May 2017 07:54:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 14:54:25 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/171#comment:3 Message-ID: <037.46c6877cf7ccaccef329ee7d418cec63@ietf.org> References: <022.557823a822995bf0907de0140512b193@ietf.org> X-Trac-Ticket-ID: 171 In-Reply-To: <022.557823a822995bf0907de0140512b193@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #171: Simplify Log IDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:57:11 -0000 #171: Simplify Log IDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: From a discussion with the other -bis authors, we've concluded the following: - OIDs can already be 4 bytes long, so switching to INT32 does not save any space. - Using INT32 requires asking an ID allocation from IANA for every log, even testing logs, since even test logs should have unique identities. - "Private" IDs are dangerous: them being used publicly would lead to similar issues presented by private MIME types. - Clients don't need to parse LogID OIDs, they can treat them as opaque blobs. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 08:15: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 B6393129B15 for ; Wed, 3 May 2017 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYeYckkKssCZ; Wed, 3 May 2017 08:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 556DA129502; Wed, 3 May 2017 08:12:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 15:12:45 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/187#comment:3 Message-ID: <037.5b3532c75af279237a6e8fcfb592f2c2@ietf.org> References: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #187: Use IANA-managed OIDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:15:06 -0000 #187: Use IANA-managed OIDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Comment (by rob.stradling@…): OIDs from the 1.3.101 arc are also being used by the CURDLE WG in draft- ietf-curdle-pkix. Rich Salz mentioned that "Work is in progress to turn the arc over to IETF / IANA / someone-like-us." [1] I propose that we close this ticket as "wontfix". [1] https://mailarchive.ietf.org/arch/msg/spasm/656DnTC7JKjuyY8Z_U- FaBowWh8 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 08:17: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 91FE012957B for ; Wed, 3 May 2017 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzdlC-AStRmG; Wed, 3 May 2017 08:17:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7292E129B31; Wed, 3 May 2017 08:15:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 15:15:44 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/187#comment:4 Message-ID: <037.0de359103edbb246a112a20e4dfcfc6a@ietf.org> References: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #187: Use IANA-managed OIDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:17:48 -0000 #187: Use IANA-managed OIDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Comment (by rob.stradling@…): Replying to [comment:3 rob.stradling@…]: > I propose that we close this ticket as "wontfix". In other words, let's continue to use the OIDs from the 1.3.101 arc. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 08:35:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D2E129B43 for ; Wed, 3 May 2017 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yJfKzxqyNJc; Wed, 3 May 2017 08:35:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A929128D44; Wed, 3 May 2017 08:32:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 15:32:52 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/188#comment:2 Message-ID: <043.b43bb67346377f4ae1c3101d90316325@ietf.org> References: <028.e78906507b088d8f45d22542d13dd884@ietf.org> X-Trac-Ticket-ID: 188 In-Reply-To: <028.e78906507b088d8f45d22542d13dd884@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #188: Specify an empty consistency proof for equal tree sizes X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:35:05 -0000 #188: Specify an empty consistency proof for equal tree sizes -------------------------+--------------------------------------------- Reporter: eranm@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 08:38:05 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68151293FF for ; Wed, 3 May 2017 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twmjt3-bOYkt; Wed, 3 May 2017 08:38:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B7A129445; Wed, 3 May 2017 08:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 15:35:44 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/187#comment:5 Message-ID: <037.02a9dd7096cae7c83351385d76421976@ietf.org> References: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #187: Use IANA-managed OIDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 15:38:04 -0000 #187: Use IANA-managed OIDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => wontfix -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 09:34: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 8293E129B3C for ; Wed, 3 May 2017 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOc0dlHtuc1u; Wed, 3 May 2017 09:34:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BF1294D8; Wed, 3 May 2017 09:32:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 16:32:14 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/168#comment:3 Message-ID: <037.ecf698f9d77ed8d2e308c4458db16933@ietf.org> References: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> X-Trac-Ticket-ID: 168 In-Reply-To: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #168: Remove STH from `get-entries` response X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:34:38 -0000 #168: Remove STH from `get-entries` response ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Comment (by eranm@…): Committed in https://github.com/google/certificate-transparency- rfcs/commit/4e17e18ac6562d940572f86dd314935b7d003a6b, before I actually took notice of Ben's objection (apologies!). I've followed-up with Ben out-of-band, but we haven't concluded the discussion yet, so I suggest leaving it open until we do. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 09:40: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 C153A12945C for ; Wed, 3 May 2017 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bOR4FOGG8lGi for ; Wed, 3 May 2017 09:40:38 -0700 (PDT) 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 3DBE5129434 for ; Wed, 3 May 2017 09:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493829526; bh=RcT1MbTcJJuHlK6NMRalV3XlR9p5RIxxVV2u2eC+kRc=; h=Date:From:To:Subject; b=s/MOmBPKqXFDtc/BEb8YWgxPzVt4RhmwDeeZVHXhz0Oeind1LNRCeMceFQy2yoXeI wd3N8SwNXz8TlwOOQcAA3vAklXqsjY3DcgOJYSL7MqYxPEb3Ai0GkBPYN7MjdRmaby Ycb3MNBBi5FKcq2D90nAlaEmgcI84N89JVVu/Ede0cBoeitZBMVhgv5rKGBjrS8d02 p7WyGnl0FUf2uJtO0q/gFda+5ZSVVz8oQJqZZtDmrw4qpASJgF2NGI7vSRW496NRUO sEnG9tBpIT2YYRtRo2z75XWmFKqJok5dcChJfBucotNSs9Lel0tFpM59E5qyQkel5w BclbrDH78jgIQ== Date: Wed, 3 May 2017 09:38:45 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Removal of STH from get-entries response 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, 03 May 2017 16:40:40 -0000 I just noticed that https://github.com/google/certificate-transparency-rfcs/pull/233 was merged, removing the STH from the get-entries response. I am opposed to this change. The STH was added to the get-entries response to address skew between log frontends, a problem that arises today with RFC6962 deployments. Regularly, the Google CT logs will advertise a particular STH to my monitor. but fail to return entries all the way to that STH because the get-entries request is serviced by a different frontend which is lagging behind. When this happens, my monitor cannot authenticate the entries it just received, so it has to discard all of them and download them again later. This is a waste of bandwidth and slows down my monitor. Returning the latest STH with the get-entries response would allow my monitor to authenticate the entries and make forward progress. If the STH is removed from the get-entries response, this problem needs to be addressed a different way, such as by forbidding logs from exhibiting skew. I suspect that the Google log operators wouldn't like that. The same argument applies to the removal of the STH from the get-sth-consistency response (https://github.com/google/certificate-transparency-rfcs/pull/237), which I also oppose. What is the plan for the remaining PRs? If folks have comments, should we be sending them to the list now? Regards, Andrew From nobody Wed May 3 09:46: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 BA6DF128BA2 for ; Wed, 3 May 2017 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 QWNofjSbXoNu for ; Wed, 3 May 2017 09:46:55 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1405F1296B0 for ; Wed, 3 May 2017 09:44:48 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id q66so15230478pfi.3 for ; Wed, 03 May 2017 09:44:48 -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=t5srFezYsyr8zi+3nuj/2ubjoOS/fsK8RaA83Nr7jHk=; b=QAkriuFqzghd6aL7SNXHDDkbL5mfE3Gwu/5cBMnIqkQnOhec80xlsreZLy6T+KP421 rldFQUeIjkNAu4M+3qnzLHqaAOBTEjwP/0jBpE+SvgSZsqPx1cUZ3H6dRkGXOT9kbMqI nYNxuvVe5ZCRdJ4gw5SPrdcZ9u47QOYDz2gLRD5RS7X6yEBIk8UTaSRiuiRaVhyPqv0G 7FB0Vx/DgRM6B0hwCNgtmrxiP7oYMbpNZRc/Du4SLCYGwC87dxoo9aGGoxNeILCzbnEi z9Qr2lSE7FLmRcPWlrqFoQMEx1fnpU3+Eh7UzEWXoRkWFGC1+UuMvOpEMsZBLDXxt3Kl kZxA== 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=t5srFezYsyr8zi+3nuj/2ubjoOS/fsK8RaA83Nr7jHk=; b=kMNE4djVsOcLYNUHzAwW2LSujm83i9ZoYKd9/QGF38a2dzg7tb1FxKsUGXS2QbgAda c1kQI/8fzjdNJozKdtRJ6r25jHUh29y/4dv+T0NCXHUEzVi6H07N/JWUOILzKrb70h5b iMb1lRb2eYibARlNriaNX55K7FwSz+uuiFL8T+IELe8b7OQnIahsyuSo6dLHcHGGwgE7 VesrmQUkFxsZ8NqMgqRphgPk5iEUutqrlaScYgSWboCSVMViAt6+biwjhbfCtxWjqKkd LfLdbpyi4d3M7ZEEYeeX1+pyJ2oF7jI82nvcXxmSfwUZYHcDNOP9/ga6JsrhIOtwmLbv utqQ== X-Gm-Message-State: AN3rC/7biBPBGoPIvvKj3FCh+erN8E/Gl9uu6x41/9QwKj/sxZ1ZmJew jusZzOQcdGRDhiH1+Lk= X-Received: by 10.98.112.134 with SMTP id l128mr5729756pfc.161.1493829887601; Wed, 03 May 2017 09:44:47 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (63-140-69-171-radius.dynamic.acsalaska.net. [63.140.69.171]) by smtp.gmail.com with ESMTPSA id p68sm34011973pga.6.2017.05.03.09.44.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:44:46 -0700 (PDT) To: trans@ietf.org References: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> From: Melinda Shore Message-ID: <0dfeea27-ba54-bee6-d4df-44db3b51c750@gmail.com> Date: Wed, 3 May 2017 08:44:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DBixaOkFp7TrHd5BuhXGBM58msJhR4CRx" Archived-At: Subject: Re: [Trans] Removal of STH from get-entries response 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, 03 May 2017 16:46:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DBixaOkFp7TrHd5BuhXGBM58msJhR4CRx Content-Type: multipart/mixed; boundary="7vpNEWBfxtMJDsvmjNRQ50bwiBMj18UnD"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <0dfeea27-ba54-bee6-d4df-44db3b51c750@gmail.com> Subject: Re: [Trans] Removal of STH from get-entries response References: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> In-Reply-To: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> --7vpNEWBfxtMJDsvmjNRQ50bwiBMj18UnD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/3/17 8:38 AM, Andrew Ayer wrote: > What is the plan for the remaining PRs? If folks have comments, should= > we be sending them to the list now? Yes, please. Melinda --7vpNEWBfxtMJDsvmjNRQ50bwiBMj18UnD-- --DBixaOkFp7TrHd5BuhXGBM58msJhR4CRx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZCgj8AAoJELiGRpM6HoEu8nUP/1q+zMvBeN/RpGnhdxmhAAN1 moK3yoKCTE3ya5SWAbncslDQk2pjIyfJnwxCBz8iUeYxBbNGWWkhsJFKvBngIqWy 2CQGaPgGlFk+OCCgmRuXE/j5DdKk2hrgb6n7bIb3gjzdkacBHaQ57AziQHIjgJYc VqkIg067PZndE5BKIeBvZI97gZ8Jn2WTpWR8KA7JDsgNU3eWYX0ag/l4DJgPG+rI GXH+oRY9SmvLHZJqQGRUTXcji4SASyRDhQ+BZFps+B9N6IU8wmWp9C+8W/yjTzw2 YT0NBKit+iru/yQb4fVYJrsyvN/qAW30OG1DzECwD/qibk/gbSvIfsk+KJIH2x8I 15eIHQLA70hqVCfZwdxRZRBE8OAZoSr+6LprKKHDFACjAl340tqKEljfApcj+kpA 69yu+3VAPndNUIAT5cYplcn+7sl7u3JBvBRJMXwESlLTU8md+m512SvQAZN2rLbf HgcKDwyIumRLGlaJDzzdUD8I/GIIn6nYvzZNjqrfebhiIIvJQDYrX0MdJcSz5ggV V4R14ugnhQgl/5eZwfZfGvgfkhLV+pkVWaNv94HTKIX/YhAF2eEv8Gc6uyIoBhJ2 HjJIzE252CCQ9TJTkRaeqyxsxsgKaRQQiG0WcU8DoSiFEfk1sm535GGpKBIi7FbL ooPCW7YFAu4w5N7UpOtO =L5Zt -----END PGP SIGNATURE----- --DBixaOkFp7TrHd5BuhXGBM58msJhR4CRx-- From nobody Wed May 3 09:59: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 51ED01275C5 for ; Wed, 3 May 2017 09:59:50 -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 9AIoCvSfiJfY for ; Wed, 3 May 2017 09:59:45 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF6C129503 for ; Wed, 3 May 2017 09:57:55 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e65so41308942ita.1 for ; Wed, 03 May 2017 09:57:55 -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=Eki3IBGr4MvxeVxBNPozGEHi7t/oQGBZ2IcluqRGXHY=; b=c3PyCrb/6QoGFj5gmFbcGabZ8nzGDs0GJUXFScxnq4zpN3oeLQlZt6pHFBRkPvPqOy yGIdAj6HIsOY5O2iDM7afjDlh85MHlC59DlyrYFo0BLZGXCApgx+7PEaP1QaXxEeiqab HJCTYaOfCi1S0+agMv1ubDYlpqiTsI/+nCYoJwE09jcZNUKOs5nqVTbj+hwmkjWTxa3r nWurjA9fPWKKf1ONcJxGD/2G+9BwvZHzET2tTQSPvTXgwnmnPsymVxR7+0ns7dW/W5d7 RlFkJGtgpUL/psxmtlazmpOgBvDn4VWMKzEDUOj3VisIcPj4F7BMOT/sIy+SaawhLZrx driA== 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=Eki3IBGr4MvxeVxBNPozGEHi7t/oQGBZ2IcluqRGXHY=; b=GQR+nfF4BDOtyCwygOQZhdCWWqa8+hM+gm1QqGr0CNDn6voAxa3+WEGVU+ARSCav8B U+DRKUfRxHg57kNgjg4KhXVx6LZyBBwzkK58rYNtzpPGKOlbJkQ0Cahu3VpQPewoSSYU c7TLw98dJ9/cxKVkGb4FH94PFOCuSG8AyXNEt0Z/Rz3Mozx+j/feuraYG4LJdRUXR/Hg K11nM2QvFVOYlZLURp4Zs53El0CswVFDh1rMgwuGG5CxoISWK2NnXH3F+MT28gk6oXZC 6wOmLhMcY2CqwzyyvdxhylntWRVGzVtP+fc8z4YUb4o7Amlx9g7Fdb8hOXpEJSXlUy/Z UOgw== X-Gm-Message-State: AN3rC/6c16DVl7T1mrmlK59rXw1cNA8QBqHsLcjbTfFs9zdj7aZjjC22 rVNFPMXJRJVb/naxszgci7N5rrd94/RgCGA= X-Received: by 10.36.43.130 with SMTP id h124mr1803898ita.42.1493830674950; Wed, 03 May 2017 09:57:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.36 with HTTP; Wed, 3 May 2017 09:57:24 -0700 (PDT) In-Reply-To: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> References: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> From: Eran Messeri Date: Wed, 3 May 2017 17:57:24 +0100 Message-ID: To: Andrew Ayer Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a1145b0aabca738054ea18eba Archived-At: Subject: Re: [Trans] Removal of STH from get-entries response 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, 03 May 2017 16:59:50 -0000 --001a1145b0aabca738054ea18eba Content-Type: text/plain; charset=UTF-8 Thanks for the feedback - I've reverted this change now, due to your and Ben's objections (There were no objections to these changes on the trans meeting, hence why I thought there was consensus for them). Given there's a clear, concrete use for having this field in the get-entries response, I proposed closing tickets 168 and 169 as wontfix. On Wed, May 3, 2017 at 5:38 PM, Andrew Ayer wrote: > I just noticed that > https://github.com/google/certificate-transparency-rfcs/pull/233 was > merged, removing the STH from the get-entries response. > > I am opposed to this change. The STH was added to the get-entries > response to address skew between log frontends, a problem that arises > today with RFC6962 deployments. Regularly, the Google CT logs will > advertise a particular STH to my monitor. but fail to return entries > all the way to that STH because the get-entries request is serviced by > a different frontend which is lagging behind. When this happens, my > monitor cannot authenticate the entries it just received, so it has to > discard all of them and download them again later. This is a waste of > bandwidth and slows down my monitor. Returning the latest STH with the > get-entries response would allow my monitor to authenticate the entries > and make forward progress. > > If the STH is removed from the get-entries response, this problem needs > to be addressed a different way, such as by forbidding logs from > exhibiting skew. I suspect that the Google log operators wouldn't > like that. > > The same argument applies to the removal of the STH from the > get-sth-consistency response > (https://github.com/google/certificate-transparency-rfcs/pull/237), > which I also oppose. > > What is the plan for the remaining PRs? If folks have comments, should > we be sending them to the list now? > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1145b0aabca738054ea18eba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the feedback - I've reverted this change no= w, due to your and Ben's objections (There were no objections to these = changes on the trans meeting, hence why I thought there was consensus for t= hem).
Given there's a clear, concrete use for having this field in = the get-entries response, I proposed closing tickets 168 and 169 as w= ontfix.

On Wed, May 3, 2017 at 5:38 PM, Andrew Ayer <agwa@andrewayer.name= > wrote:
I just noticed that https://github.com/google/certi= ficate-transparency-rfcs/pull/233 was
merged, removing the STH from the get-entries response.

I am opposed to this change.=C2=A0 The STH was added to the get-entries
response to address skew between log frontends, a problem that arises
today with RFC6962 deployments.=C2=A0 Regularly, the Google CT logs will advertise a particular STH to my monitor. but fail to return entries
all the way to that STH because the get-entries request is serviced by
a different frontend which is lagging behind.=C2=A0 When this happens, my monitor cannot authenticate the entries it just received, so it has to
discard all of them and download them again later.=C2=A0 This is a waste of=
bandwidth and slows down my monitor.=C2=A0 Returning the latest STH with th= e
get-entries response would allow my monitor to authenticate the entries
and make forward progress.

If the STH is removed from the get-entries response, this problem needs
to be addressed a different way, such as by forbidding logs from
exhibiting skew.=C2=A0 I suspect that the Google log operators wouldn't=
like that.

The same argument applies to the removal of the STH from the
get-sth-consistency response
(https://github.com/google/cert= ificate-transparency-rfcs/pull/237),
which I also oppose.

What is the plan for the remaining PRs?=C2=A0 If folks have comments, shoul= d
we be sending them to the list now?

Regards,
Andrew

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

--001a1145b0aabca738054ea18eba-- From nobody Wed May 3 10:01: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 C23E0129AE7 for ; Wed, 3 May 2017 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkGoxcMtkrF0; Wed, 3 May 2017 10:01:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1D129AB8; Wed, 3 May 2017 09:59:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 16:59:30 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/168#comment:4 Message-ID: <037.7783099d9c07f258f2323d94c60a1893@ietf.org> References: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> X-Trac-Ticket-ID: 168 In-Reply-To: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #168: Remove STH from `get-entries` response X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:01:32 -0000 #168: Remove STH from `get-entries` response ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: Reverted per Ben's objection and Andrew Ayer's objection on the list: https://www.ietf.org/mail-archive/web/trans/current/msg02848.html Given the justification for keeping it, suggest closing as wontfix. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 10:02: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 43D5A128792 for ; Wed, 3 May 2017 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5SPBeDW4nxb; Wed, 3 May 2017 10:02:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC66129B63; Wed, 3 May 2017 10:00:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 17:00:11 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/169#comment:2 Message-ID: <037.190e348967323df514b15996a7edd7d6@ietf.org> References: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #169: Don't guess at STHs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:02:17 -0000 #169: Don't guess at STHs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: See discussion on issue 168 and Andrew Ayer's objection on the list: https://www.ietf.org/mail-archive/web/trans/current/msg02848.html Given the justification for keeping it, suggest closing as wontfix. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 10:15: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 58699124D68 for ; Wed, 3 May 2017 10:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 8yEYDSa4RohL for ; Wed, 3 May 2017 10:14:57 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 34FED129B35 for ; Wed, 3 May 2017 10:12:58 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q66so15571484pfi.3 for ; Wed, 03 May 2017 10:12:58 -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=kNw5f2OzHG5TeJHjn5aA/0UhlW6aFCpjIzDpEH2PF54=; b=C/9t+iUkoHg5x4aI9RFBlikJ3P2689harTRSVpmH43BSkCURWKhfBGsxx4KibnypMZ 9x1vEwJ9+ZopJ9z/1Y7zjl6EA17qrbJt8XD1IStmUuGsWXGGJhx3yzhDzq6z7iQfZIbZ P6zCzUihiBvU1pqnfzsh0CNzHnfSq7qPXy9806jSCNMm4xgLk17It6ANAia46EA26cfq BplqlIxwLeGuzmphKClA73e/ggiskWrJrqykr0SDwiZjSjQg6s4nEVS39G25At238pMX mGMHF0h1QK76ELFmp6mWatVVy06vj0YSyeskzO8wYGpFxDNWNOt39qrR1TRfN2iYOzWx ireg== 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=kNw5f2OzHG5TeJHjn5aA/0UhlW6aFCpjIzDpEH2PF54=; b=XYBxTU+6IF/8Dg7lbxG+L+GkB9B/E+k/858nzVikXkNR6ZiFezbvKVihzvjvxH8wWy 0CMxC/hC8NDHDyrnZaA7nObx2KM9j2Gd7Qn/wpfqnPkzseFEFNSLVS7vEU8xGoAbZ1FZ 1JhNcxGw+t7f4acI1yVwEzMX0HIDvIBmwCcSzhPz+bczIFuPzhJRh4wrYyES5roaE7pi SNqlPSCwso6nRn3zjhDNks9p3y+DOCtFCkhTKQZChKNHvjN7qxE3CQhPQqfHuXAWFvDi DWmlJ3ugH9bqQvUdgNJvdspCz8Bja1ZVS8mojVRnmrq5FwSNx7ynHB05AewSwwcram49 qhHw== X-Gm-Message-State: AN3rC/7wpnSz7xLNimHXZc23bdAM3PzvjsGp6rJvxCmT7vY+axtQTeq4 BD2B9/BYsaeCPpqMYXg= X-Received: by 10.99.113.78 with SMTP id b14mr39828240pgn.223.1493831577459; Wed, 03 May 2017 10:12:57 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (63-140-69-171-radius.dynamic.acsalaska.net. [63.140.69.171]) by smtp.gmail.com with ESMTPSA id n18sm4170915pfb.8.2017.05.03.10.12.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 10:12:56 -0700 (PDT) To: trans@ietf.org References: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> From: Melinda Shore Message-ID: <78759847-e08d-47e6-8366-922eabf44b2a@gmail.com> Date: Wed, 3 May 2017 09:12:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dfA4TCpV4VxOb5KOITHTqT2bR81CUNduH" Archived-At: Subject: Re: [Trans] Removal of STH from get-entries response 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, 03 May 2017 17:14:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dfA4TCpV4VxOb5KOITHTqT2bR81CUNduH Content-Type: multipart/mixed; boundary="q5Et9lW43w6H3pNV9SM4DQ0LPLvdLuInp"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <78759847-e08d-47e6-8366-922eabf44b2a@gmail.com> Subject: Re: [Trans] Removal of STH from get-entries response References: <20170503093845.828d3c193389cd71c3157d3b@andrewayer.name> In-Reply-To: --q5Et9lW43w6H3pNV9SM4DQ0LPLvdLuInp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/3/17 8:57 AM, Eran Messeri wrote: > Thanks for the feedback - I've reverted this change now, due to your an= d > Ben's objections (There were no objections to these changes on the tran= s > meeting, hence why I thought there was consensus for them). We make decisions on the mailing list, not in meetings. Feel free to kick the chairs if you feel something needs to be closed and requires a decision. That said, is there any objection to closing both 168 and 169 as wontfix? Melinda --q5Et9lW43w6H3pNV9SM4DQ0LPLvdLuInp-- --dfA4TCpV4VxOb5KOITHTqT2bR81CUNduH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZCg+XAAoJELiGRpM6HoEu2WAQAKYVNEXuadFy4wZVJj6ru5u2 c8pD8rgo99BFQNfXdpq8C354pQ1dvRWHRwBzNfw2RaDcwOg2jnqcwni5an19nAr3 FrtIVAUBAjEsk/g/BloaCfmqkB0XztcYcxoIS6vHpkzmHDZgRcUegFJgrztzH1Wn 7w6Rmxm3iwHT7x4oSCbtG4+YDfJ9v3DWiIA3xUCuzaYq9UUUih/QzG1GCU20WVNL NQQloA1mFx7li/UoBEwSEmpQdf2K0/fOGP5LNtU6VH7Po6U9hjDAuhMaVOTKhom+ I1v3yQAAk0hybbZfKp5LhutOd66+IAG3eNp0T0sVhf9JQETAeAI8uIiZ8eDMXW7U FcjN6nXa0Xc28YriTtLpR3xUGrqAT4pPFeL0gDRnwyc4Gc3ILWqe+CT4MdOvMJ3+ X64odESb/akfhY1b+FeGg7koff2MLEKYRnwtICZfGblu45UpVysniv6GTevvBk58 2t04KJ3btUNNGITxpTA58ObOXHFB/mjY0urdZGVLl+LIPMzjYohS2dPQTJfAPcGN YJJ9MUuYrM4UwWK6cm9KBF4c1ilTLP3AfP+kQS5fOM6levZiUFUipjeefKDce14g a1A2w+XK7bbdQzJRor7V2YW+TxGYd5IsDIjrDv8sdUpKxFxtQkkEnu9Kr2ukLWQE w2OWhWe4uIAtRqXKpAPD =CO22 -----END PGP SIGNATURE----- --dfA4TCpV4VxOb5KOITHTqT2bR81CUNduH-- From nobody Wed May 3 10:47: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 BFE82129B44 for ; Wed, 3 May 2017 10:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3FVtftBtCPN; Wed, 3 May 2017 10:47:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9412948D; Wed, 3 May 2017 10:45:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 03 May 2017 17:45:35 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/179#comment:3 Message-ID: <037.e3fcee5a6593dd3d3b5683ee98bd975b@ietf.org> References: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #179: Indicate certificate / precertificate in Entry and SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:47:17 -0000 #179: Indicate certificate / precertificate in Entry and SCT -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Comment (by eranm@…): Corollary: - SCTs *are* defined as TransItems of type x509_sct_v2 or precert_sct_v2. - This is a non-trivial change to the data structures, which may require a stronger justification than the one we currently have (at least two structures I've identified, and signature scheme may change). - Other fields may have to move into the SignedCertificateTimestampDataV2 to contain all the necessary information to be passed around without the TransItem (see previous point). - This would undo the work to unify several "type" indicators in 6962 into a single one in -bis. Overall I agree with the sentiment that some data structures in 6962-bis need to be renamed to clarify what role they play. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 3 10:56: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 3D87C129649 for ; Wed, 3 May 2017 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 l14ijESntC2k for ; Wed, 3 May 2017 10:56:04 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 38E1D1296B0 for ; Wed, 3 May 2017 10:53:32 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id e65so43084195ita.1 for ; Wed, 03 May 2017 10:53:32 -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=dPhZyd97UXIqbJiVR12rwhRqkJq2MWUyYKTpps7bSqg=; b=JLbpLgDzxIvUy1EYqMkF2/qeQmi5+iOB/xBC2ifcue9PmsXPbtzoEx4TSoUUk3kMnf D8ldHCqUVIyxKKBh2uRfgccc+y1RVwPg0Xk/9+gPRyXjN7uy667nmr15/4tIjOlhrKUI cX0edKbXEV/ZI+/k1K/wEY9uq9v1M2wvz92AyF/VRHCZW4Kc14reR4rpZILnhlNFfNB4 LvlRmRZWD/FUvi9oPGcP1JqozQrmnTCSGUFd1q03usDcCYmg8F2dDYffcKgbuarAXBgm uQr81lOkxSKRx+QokcTN48CI7KKb4TGkkjDgyQA1CofRJOHQw38VEjqUH3KEk9q3+pxA E3cw== 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=dPhZyd97UXIqbJiVR12rwhRqkJq2MWUyYKTpps7bSqg=; b=jrIho5eYfpDy/j+VUIw54PlbIvM78qQV6PQrP0BfnoOi42DFcWSlnT/PhBImGPdg39 D5gWuOfKQaTYCeUeGbY4+wQQoI0MhpRX64xjo8ULD+iW8sTIaqsBSYRhQdV2GQ2uUdqW tcw+RNis1Y6xakHc1bjR4B4ooO9gLC93siZ3lF1k5WwcGuYDDhugVb7xuxiupsyRaoqC CS27UlHAP1WBUD2wb0izgp05uxvarjI3h+3WKoDp6ceIoDK8d1BCClVTn1clLeiLnJs0 OnRZqL/V0w2ta0ZBIs+trrpX49mQcHmNaf9UF6S+tLvYn7YYkRzhbatqBDLYfTM8yNJv l68Q== X-Gm-Message-State: AN3rC/7HW0lP5LhVuJ8RHSDi+aUi6XBIwfu4XZHNQcC5zCiq1oVijTRN k0YYJq4NJIsp/7c4ktQs6kh3HLpjCWPqWmg= X-Received: by 10.36.79.80 with SMTP id c77mr1979398itb.53.1493834011394; Wed, 03 May 2017 10:53:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.36 with HTTP; Wed, 3 May 2017 10:53:00 -0700 (PDT) From: Eran Messeri Date: Wed, 3 May 2017 18:53:00 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11449bbc9a933b054ea25596 Archived-At: Subject: [Trans] Ticket 179 - moving Cert/Precert indicator into the data structure 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, 03 May 2017 17:56:06 -0000 --001a11449bbc9a933b054ea25596 Content-Type: text/plain; charset=UTF-8 I'm looking for opinions on ticket 179 , which suggests "folding" the Cert/Precert indicator for an SCT into the data structure contained in the TransItem (right now it's part of the TransItem type indicator). Personally I find it hard to justify such a change, since SCTs are already clearly defined as TransItems and it's a non-trivial change to the data structures without a strong benefit. Suggestions? Eran --001a11449bbc9a933b054ea25596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm looking for opinions on ticket 179, which suggests "folding&= quot; the Cert/Precert indicator for an SCT into the data structure contain= ed in the TransItem (right now it's part of the TransItem type indicato= r).

Personally I find it hard to justify such a change, = since SCTs are already clearly defined as TransItems and it's a non-tri= vial change to the data structures without a strong benefit.

=
Suggestions?

Eran
--001a11449bbc9a933b054ea25596-- From nobody Thu May 4 01:39:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666F1129BCF for ; Thu, 4 May 2017 01:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-FOjLvD7raJ; Thu, 4 May 2017 01:39:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4319129BE0; Thu, 4 May 2017 01:39:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 08:39:12 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:4 Message-ID: <037.ed987e77989d1496cfacca61ee32fd6c@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 08:39:18 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Comment (by eranm@…): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/248, feedback welcome. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 01:42: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 021AF12942F for ; Thu, 4 May 2017 01:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC4Zxj96HULK; Thu, 4 May 2017 01:42:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1864F128796; Thu, 4 May 2017 01:42:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 08:42:53 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:5 Message-ID: <037.42ea9bc67d761328d37b5f475d19fbee@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 08:42:54 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Changes (by eranm@…): * milestone: => review Comment: Change merged - chairs, please review. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 01:43:07 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7F9129BCD for ; Thu, 4 May 2017 01:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkfIe2NlV73W; Thu, 4 May 2017 01:43:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7412420B; Thu, 4 May 2017 01:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 08:43:01 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:6 Message-ID: <037.b03bcf8f28e6fad1ee476d1ec65c8897@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 08:43:02 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 03:42:25 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 EE3E212E872 for ; Thu, 4 May 2017 03:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpWhllKIFS-v; Thu, 4 May 2017 03:42:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA012EA52; Thu, 4 May 2017 03:42:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 10:42:22 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/165#comment:2 Message-ID: <037.3fd8ed4a8050db32fd068f5f1c15798f@ietf.org> References: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> X-Trac-Ticket-ID: 165 In-Reply-To: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #165: Remove unnecessary operational restrictions on logs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 10:42:24 -0000 #165: Remove unnecessary operational restrictions on logs ---------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned Comment: Out for review in https://github.com/google/certificate-transparency- rfcs/pull/250 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 03:45: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 ED9C112E85E for ; Thu, 4 May 2017 03:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 SHNECGT_ff-U for ; Thu, 4 May 2017 03:45:10 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 E91C512E872 for ; Thu, 4 May 2017 03:45:08 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f102so17066200ioi.2 for ; Thu, 04 May 2017 03:45: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=kQpbX7vEQPETZka0J+ZnM4ziJkWGtqmP1xL6S2EuXP8=; b=no76PqI4DciVVADGS/KAh7Kx3ihDa7Zy7xb22/V/d6LjpxNz8ang1rV44PMWENETOB 7gi76tb5W9o0DVZLj6MuNOg02Hd4giL8KqfOFw5uHsh2oOGaOcamBjrLR+Scmv3jDbol pCHIwWGZyrktoGVgubGhJuZgL68kmDQ+BS1/wMkWiImRGX2F5faIqgBXzyMcnzAdYtvg wzhtxTaAeMN9VJlt9sIxwrcZZWmW+FpNg3bEEe4JMPEBVMI76ZFx93TXoOSRhw6/0Oxn DdRB3eIpOfUcdE1FFCGyArQELRwicIkF//15eceZGc/zOZGMJ4hAUnxu2LjV4s59FHW9 rNUg== 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=kQpbX7vEQPETZka0J+ZnM4ziJkWGtqmP1xL6S2EuXP8=; b=EB8SD0YgOKbDOckKi9+jhjNVVUZu6Tu2I7ObluerwyDmxuNpT/kV+6W0rm1WqKG+C/ TIwo6klZlHeo0qI8VBjADqdIeOUfs9NCQ8TT/wUDm67zXEcOSIkyvxr6y71zyTS62UR1 PWz8vTJai92mIcd/QXgURfft1ySqtcByQE/URCh30Oex8y2/sB7oBlnpwQ3Vw0VkO20M oiVO3SEmKXwAMzblIbUFURJVMANUV+2gbvT+4ZqC9I5H6NEteQHQ/1+iNFzhtFHJ6j3l bbAEJWB01ppObUekYE5nxR0dEwMMPo+WST+DpdL9A2xP+AzTzkwqcSJ6eUVLixzIqGOW hgPw== X-Gm-Message-State: AN3rC/73SL8Y+84OAQW2Y2r5RlkaqVU37DBnpIY7LowDaSAhpu0yV52x A/TriP3tlLN+5tgSct+APgbguf3m1E31 X-Received: by 10.107.133.106 with SMTP id h103mr11981378iod.230.1493894708188; Thu, 04 May 2017 03:45:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.47.41 with HTTP; Thu, 4 May 2017 03:44:37 -0700 (PDT) In-Reply-To: References: <0f1433b8-84a7-754c-6463-ee73808abf9e@gmail.com> From: Eran Messeri Date: Thu, 4 May 2017 11:44:37 +0100 Message-ID: To: Melinda Shore Cc: "trans@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary=001a113ff9a66a4624054eb07770 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: Thu, 04 May 2017 10:45:14 -0000 --001a113ff9a66a4624054eb07770 Content-Type: text/plain; charset=UTF-8 In line with the suggestion on this thread, I propose adopting Richard Barnes's PR for documenting the reasoning behind deviating from BCP 190: https://github.com/google/certificate-transparency-rfcs/pull/249 (which contains Richard's original commit and a small follow-up fix). On Mon, Apr 10, 2017 at 8:15 PM, Melinda Shore wrote: > On 4/7/17 1:05 AM, Eran Messeri wrote: > > Instead, we could: > > (1) Clarify why BCP 190 may not apply here (based on experience > > deploying V1 logs) > > (2) Remove the 'ct/v2' portion from all the URIs. > > > > Any preferences? Mine would be for (2), but it's not a strong preference. > > I think that in general, when there's a deviation from a BCP > it's a good idea to document why it's inapplicable - the question > is very likely to come up at some point during the review process. > I don't think that removing the ct/v2 portion would be sufficient to > resolve the conflict with BCP 190, although it may be > desirable for other reasons. > > Melinda > > > --001a113ff9a66a4624054eb07770 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In line with the suggestion on this thread, I propose adop= ting Richard Barnes's PR for documenting the reasoning behind deviating= from BCP 190:
https://github.com/google/certificate-transparency-rfc= s/pull/249 (which contains Richard's original commit and a small fo= llow-up fix).

On Mon, Apr 10, 2017 at 8:15 PM, Melinda Shore <melinda.= shore@gmail.com> wrote:
On 4/7/17 1:05 AM, Eran Messeri wrote:
> Instead, we could:
> (1) Clarify why BCP 190 may not apply here (based on experience
> deploying V1 logs)
> (2) Remove the 'ct/v2' portion from all the URIs.
>
> Any preferences? Mine would be for (2), but it's not a strong pref= erence.

I think that in general, when there's a deviation from a BCP
it's a good idea to document why it's inapplicable - the question is very likely to come up at some point during the review process.
I don't think that removing the ct/v2 portion would be sufficient to resolve the conflict with BCP 190, although it may be
desirable for other reasons.

Melinda



--001a113ff9a66a4624054eb07770-- From nobody Thu May 4 04:40: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 ACE2E129BE0 for ; Thu, 4 May 2017 04:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPbXoKX0wW9W; Thu, 4 May 2017 04:40:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE11B1293D9; Thu, 4 May 2017 04:40:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 11:40:20 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/185#comment:3 Message-ID: <037.918c6c6bfe31407af73f2d402ac3cefe@ietf.org> References: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #185: Don't violate BCP 190 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 11:40:22 -0000 #185: Don't violate BCP 190 -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 05:32: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 D694912948B for ; Thu, 4 May 2017 05:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVLJlh75iqvu; Thu, 4 May 2017 05:31:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B01126E01; Thu, 4 May 2017 05:31:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 12:31:59 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/163#comment:4 Message-ID: <037.acf46427135f40b4e8f605d34ae20197@ietf.org> References: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #163: The entire STH history of the log must be accessible X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 12:32:00 -0000 #163: The entire STH history of the log must be accessible -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Comment (by eranm@…): (alternative discussed out-of-band with colleagues): Allow requesting STHs by specification of time range. Similar to get-entries, the log would return a list of STHs issued on that time range (capped by an amount chosen by the log). The problem it solves is the lack of ability to verify that the log did not breach the MMD throughout its lifetime: A submission's timestamp is available via get-entries, but unless a monitor has observed STHs issued by the log around the time an entry was created for it, there's no proof that the entry was incorporated within the MMD. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 05:42: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 0509E126E01 for ; Thu, 4 May 2017 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 dnjU1pGHc65p for ; Thu, 4 May 2017 05:42:30 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0681292F5 for ; Thu, 4 May 2017 05:42:30 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id o5so15381486ith.1 for ; Thu, 04 May 2017 05:42:30 -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=X+MzadfZABHa8ovp0ULhRo4SsxNcO5U+R4jY8rndmLk=; b=eVOj86kr+yHHc3sXFv3UTGjm1p7/PxluQkk2PrDizFnaN+2qu0AmPgznKAukXxlx8j po6gVfahy0eTB7kSjmdWrtVVkt+rsHJHNtydKfMmPOCHx3dnvgBRGdRNeyTJqnEZEocY 3jGVrEP09hCmSQPddZX9l0anhOGgE/YTPjnHDrddB9SGYlLqQhqyc4K0bw6j/Qq39FJY ZcNYaugPQuIn8KKLGeU5nAIkGs4UptR/RBK5h2KoEddz7vOgjUVKYP0vWwce5eaT6FIl dVWg3bcYhzb+TlaaiBFowDbg/GfNk7hE/7rfpB5ZuBU+vTp01t99+iuGs2uLwzJbb1aB zarQ== 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=X+MzadfZABHa8ovp0ULhRo4SsxNcO5U+R4jY8rndmLk=; b=J8JZ3PZ62SzRMn6PYYEzEyUmVEAf8UrM/sC/ronZeVCLYkh+986wwRMXhp4JZTxcDg qAs4+/Hgj2SLs95+z8ffSoSupVEdYDzozvfKEwvbJ0vMssTRvmp8tMTcXcmTCnIgXLOX 6kPO+x2dc1omk0q85MHZZ10Gea8Zf452vKmN8C0uSzfOHHUryTOHJAr6Pe4g6Zh3Uni1 XgSitbXYxvCvclZSvvIroHfXItwYnKvf+qCnUM3qTk3SMbxlA0WfGj576KzL1Dw9GGtb 2r1YwJi9UsxuekLrNPcpFghVRoNZdM7pmVm08hNhmC5/2h61Pra+W2SwduqyJguUEdOg Vt0A== X-Gm-Message-State: AN3rC/7/C0HYBIIz+wRy5VGIKcxoykosMaG8vbDJ0fQG+xaPCVYMYYeW VR39sgxliHPQ9cYnZhSkb53JIJgZUS8O4FJQng== X-Received: by 10.36.3.13 with SMTP id e13mr1657028ite.112.1493901749575; Thu, 04 May 2017 05:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.47.41 with HTTP; Thu, 4 May 2017 05:41:59 -0700 (PDT) From: Eran Messeri Date: Thu, 4 May 2017 13:41:59 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11419bfa1d2391054eb21b17 Archived-At: Subject: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 12:42:32 -0000 --001a11419bfa1d2391054eb21b17 Content-Type: text/plain; charset=UTF-8 I'm looking for feedback on the proposal to add an API endpoint which would provide access to historical STHs issued by the log ( https://trac.ietf.org/trac/trans/ticket/163). I personally think it's a good idea to have such an API since it'd allow auditing a log for past compliance with the MMD requirement. Rob Stradling has sent a PR for this. Eran --001a11419bfa1d2391054eb21b17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm looking for feedback on the proposal to add an API= endpoint which would provide access to historical STHs issued by the log (= https://trac.ietf.o= rg/trac/trans/ticket/163).

I personally think it'= ;s a good idea to have such an API since it'd allow auditing a log for = past compliance with the MMD requirement.

Rob Stra= dling has sent a PR for this.

Eran
--001a11419bfa1d2391054eb21b17-- From nobody Thu May 4 05:50: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 196E2120727 for ; Thu, 4 May 2017 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffe7yljWw9GW; Thu, 4 May 2017 05:50:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB371294E6; Thu, 4 May 2017 05:50:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 12:50:32 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/182#comment:4 Message-ID: <037.de3e0de907ce1469064772e16795ec50@ietf.org> References: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #182: Clarify notation in the Merkle tree section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 12:50:33 -0000 #182: Clarify notation in the Merkle tree section -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 06:01: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 87BED126E01 for ; Thu, 4 May 2017 06:01:53 -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 lUc_nn94aT5e for ; Thu, 4 May 2017 06:01:52 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 A5479127BA3 for ; Thu, 4 May 2017 06:01:50 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id o3so8213792pgn.2 for ; Thu, 04 May 2017 06:01: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=3Cb6GUTxmlAikbyGef/xfRDHM/dBmFyLCfVGT1h4WrQ=; b=MzVEzZ5HDjBk/VicTflWim8ZfkzgI9Vpl6IELMsCgspboa9qvGiHkzwmkvtbLjrhVS Pub+XTQrpJ/48PtR9jNyU0WcLyzh4F+UBxc7XuLQBGHk/qvecV6OKb9ScVXnrU8bTTTp MHH7TclTUvrEBNPcIgk5Ub7EHltrkGOlgG2YmtbO94D/2HmV/hh9yDMefR1p4vAx+MaY luF2jESy+RLOhwVqHhNlndw2RSEtCvnanUp5Z+q4UVjt2f4zcg6QVoA8zUvA9CPTLw/I zkEKsSupb8XAiVx/03xd6icUpVUN4ca8YihhpX/nMFLIj9d6u4tcmIhItt3IESMtbwlW 6RUw== 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=3Cb6GUTxmlAikbyGef/xfRDHM/dBmFyLCfVGT1h4WrQ=; b=AOkJL0xC5KD2arimdlouMkg1anIifU7OyCQMu5+SfgxI/SUf5hsOP3nbcxzO0OBepw NlXvV+S7Y8wmQZJq1CNMwW8+/HW921GJeuHW+Tig5aEiEPxz7OPbZouF7xfCeB7aSIYF XYIz6uN5sP6NuJy/TY8r0UIvEB5glPS3tVT0m2VgkTjEeXOh8xOBn0NWDEkQ4am20kSx IVt5HFvQVxxZMm9fj3C+5as94OKV/+ffUxn6iY83mo8vIzjmgd+M6aUl+eFieE18DMQB fIkomEZ5mRq8Wakz2N22F92yCfusZjgXssqZW2CF7har4DjcGLpCrryGokThFmwISlPd QvCg== X-Gm-Message-State: AN3rC/6PpICzhNonrZz+iAw0fdb6nWdYttY4pEKXJK6vUl93BBIgfpga NBgFkbiMRH2WPW17DvfkiJyzcOaDTu8fh4Q= X-Received: by 10.98.84.194 with SMTP id i185mr10856205pfb.234.1493902910088; Thu, 04 May 2017 06:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.141.80 with HTTP; Thu, 4 May 2017 06:01:49 -0700 (PDT) In-Reply-To: References: From: Paul Hadfield Date: Thu, 4 May 2017 14:01:49 +0100 Message-ID: To: Eran Messeri Cc: "trans@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0ce1d24e9c28054eb260d5" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 13:01:53 -0000 --94eb2c0ce1d24e9c28054eb260d5 Content-Type: multipart/alternative; boundary=94eb2c0ce1d2494a0f054eb26034 --94eb2c0ce1d2494a0f054eb26034 Content-Type: text/plain; charset=UTF-8 I support the addition of this API; Rob's PR was created in response to my original proposal for this made Oct, 25 2016. As the operator of a CT Monitor, I could use the STH history API to perform historic analysis of the logs my monitor visits. This includes determination of whether MMD violations occurred in the past. Without this API, CT Monitors that ingest a log's entries from STHm to STHn (n>m) could incorrectly identify an MMD violation, as it is possible for them to have missed an STH that sits between m and n. With this API, a log operator that is incorrectly called out for a MMD violation has the ability to demonstrate that the monitor drew an incorrect conclusion as a consequence of not observing the log's complete STH sequence. Paul On Thu, May 4, 2017 at 1:41 PM, Eran Messeri wrote: > I'm looking for feedback on the proposal to add an API endpoint which > would provide access to historical STHs issued by the log ( > https://trac.ietf.org/trac/trans/ticket/163). > > I personally think it's a good idea to have such an API since it'd allow > auditing a log for past compliance with the MMD requirement. > > Rob Stradling has sent a PR > for > this. > > Eran > --94eb2c0ce1d2494a0f054eb26034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the addition of this API; Rob's PR was created in response to my orig= inal proposal for this made Oct, 25 2016.

As the ope= rator of a CT Monitor, I could use the STH history API to perform historic = analysis of the logs my monitor visits. This includes determination of whet= her MMD violations occurred in the past.

Without t= his API, CT Monitors that ingest a log's entries from STHm to STHn (n&g= t;m) could incorrectly identify an MMD violation, as it is possible for the= m to have missed an STH that sits between m and n.

With this API, a log operator that is incorrectly called out for a MMD vio= lation has the ability to demonstrate that the monitor drew an incorrect co= nclusion as a consequence of not observing the log's complete STH seque= nce.

Paul
On Thu, May 4, 2017 at 1:41 PM, Eran Messeri <= span dir=3D"ltr"><= eranm@google.com> wrote:
I'm looking for feedback on the proposal to add an API e= ndpoint which would provide access to historical STHs issued by the log (htt= ps://trac.ietf.org/trac/trans/ticket/163).

I pe= rsonally think it's a good idea to have such an API since it'd allo= w auditing a log for past compliance with the MMD requirement.
Rob Stradling has sent a PR for this.=

Er= an

--94eb2c0ce1d2494a0f054eb26034-- --94eb2c0ce1d24e9c28054eb260d5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMYpkl+6l4POFgwKr3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTE4NDMyM1oXDTE3MTAx ODE4NDMyM1owJTEjMCEGCSqGSIb3DQEJAQwUaGFkZmllbGRwQGdvb2dsZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDF9iQEIDbCb24rTftc3VkRg3i0MswpI6BZlSyx2ApUq8CA QiZBcyhJGTf1DpNQDDVAxfZOVwMPWxrNvjk/fvdu9uyk4/thfXrXQJgclWjIVDciJ5E3VN8X/fi8 aUcuBuR/K/B+Rc7JMLn829Jdz7cfaCgIJev4Nqq1ZGVvX3kOS4TuzI5eSLZ1qIWVmZ4mO1sEcSDz ev1nlDtY2+0otYc1FICoYPWSzIkEgOUOy8VfWCRJRCXfurtikQxsRKgHDHVHQ8SixnCgrYO5MYJ4 04RJWWTVO7ybjkBR7T/i/wC4CIOerUZ4w2BQOxfHiUmr8Xf1eqS1dgDpLPzbtFCyw8knAgMBAAGj ggFxMIIBbTAfBgNVHREEGDAWgRRoYWRmaWVsZHBAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt ZWNhMS5jcnQwHQYDVR0OBBYEFGZeOsvil5Hx7rcVSR15h2AANCrNMB8GA1UdIwQYMBaAFMs4ErDH mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0 dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0 dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBu6pwLtR5w CWPkMMpjCAZBKUo7ZtoEubCG8nqzrzu8YPPg3RN8rW9GUNWm2PsZv6eZgDx0eFT+L7cXOqWHWwX6 iAIWcQfGC9m4cvZGQQgZO3DgKpx2PIRjJOu9elyAqsRPstHZgeXRl6MPIUwGCh03Q7TB6kVaeVrC WD/OUB8J6fBmuKzW5zTkB0DFCqY1b36pIRkIsyR7q651i0v+ejRQdh10ruH8ESM3CXCXTSoLAm1q ExhzkXVsC0w5z+KFi7m9E+4Mz2JQ0hok+8oIbDrKrCcmpP7dAyqdrfnU5AuoNEIGOhwCM52h29uU JFAlHBfJzMbCqANMlwdnlTi/Qv+5MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM Ypkl+6l4POFgwKr3MA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAgl+BiXztAf8+Z CFF9zg+8g/1PHdJ8tYuAZuBtpdqftzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA1MDQxMzAxNTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEARKs5+0Oc65/DGRw+U9IYhIszUnKjulG/ 2+LWhrvdYdQwLn0bADarusuvUDO8GbPUxOL5kfqT1v0h5+LCgjh4tgh+iSYJ7Eeu/8s2fMu+PDjX Tq7cHhcbqLm5w4tSnJJcUBtx7Ei2/suUUkZfh9VsfMA+Zjp11IvwhzWPPDUybP0AbVA9SOlvDLAy UPQ6kR2c18auO8Fmjyz+jx7Sx5fuWCiUPeeMGSuMXKiwS3L1EA5asFENF9ite/mce49nEazYCttB QnbO6NntUGkduODKfH065JJMoj3RJpdzQbxozqsi7Dx8wgDmWe1UuO2hApMCizRMiyMlUi6eLdhI ysMNuw== --94eb2c0ce1d24e9c28054eb260d5-- From nobody Thu May 4 06:09: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 7ECD312956D for ; Thu, 4 May 2017 06:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeckRzZ3UT_v; Thu, 4 May 2017 06:09:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 980DA129467; Thu, 4 May 2017 06:09:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 13:09:29 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/179#comment:4 Message-ID: <037.5caa082384b88a425064e8c547ad5cc5@ietf.org> References: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #179: Indicate certificate / precertificate in Entry and SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:09:35 -0000 #179: Indicate certificate / precertificate in Entry and SCT -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+--------------------------------------------- Comment (by rob.stradling@…): Replying to [comment:3 eranm@…]: > Overall I agree with the sentiment that some data structures in 6962-bis need to be renamed to clarify what role they play. I agree. How about opening a new ticket to discuss structure renaming? -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 06:48: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 02548129A9F for ; Thu, 4 May 2017 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfwZqKkV04CC; Thu, 4 May 2017 06:48:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E8F129572; Thu, 4 May 2017 06:48:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 13:48:53 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/185#comment:4 Message-ID: <037.e66a7e136347288e3ea1cf0bf276ee0c@ietf.org> References: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #185: Don't violate BCP 190 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:48:55 -0000 #185: Don't violate BCP 190 -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 06:53: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 BB48D129406 for ; Thu, 4 May 2017 06:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWs5obmrh1VF; Thu, 4 May 2017 06:53:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 234E2128AFE; Thu, 4 May 2017 06:53:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 13:53:23 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/165#comment:3 Message-ID: <037.4ef4d2ed16ce640937a25a4935733a24@ietf.org> References: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> X-Trac-Ticket-ID: 165 In-Reply-To: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #165: Remove unnecessary operational restrictions on logs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:53:25 -0000 #165: Remove unnecessary operational restrictions on logs ---------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: Landed. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 07:03: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 0C849129AD7 for ; Thu, 4 May 2017 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_50=0.8, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2nj-xsp1BNW; Thu, 4 May 2017 07:03:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14B129AF6; Thu, 4 May 2017 07:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 14:03:30 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/169#comment:3 Message-ID: <037.3ff7290718cc3e72cca6be1dd423b044@ietf.org> References: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #169: Don't guess at STHs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:03:37 -0000 #169: Don't guess at STHs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: new Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: Keywords: | ---------------------------+--------------------------------------------- Comment (by eranm@…): I'll note this came up today again in an out-of-band discussion with colleagues: Having the option of getting the new STH by not specifying the 2nd tree size is an efficient way to catch up with the log without calling get-sth first - a single call is enough to get a new STH and a consistency proof to it from the STH the client currently knows about. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 07:04: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 A8D4C1296B3 for ; Thu, 4 May 2017 07:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZtFfntkwzTR; Thu, 4 May 2017 07:04:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1F129A9C; Thu, 4 May 2017 07:04:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 14:04:45 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/180#comment:3 Message-ID: <037.bc699e9fd9e389ada701bc115e1b6137@ietf.org> References: <022.fbeed8d444d177069bcee6293bf51e4a@ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <022.fbeed8d444d177069bcee6293bf51e4a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #180: Consolidate all Merkle tree data formats and computations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:04:52 -0000 #180: Consolidate all Merkle tree data formats and computations -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis * milestone: => review -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 07:05: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 9B12612EA93 for ; Thu, 4 May 2017 07:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWxhhPHWNuaR; Thu, 4 May 2017 07:05:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 525C3129AF6; Thu, 4 May 2017 07:05:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 14:05:17 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/174#comment:3 Message-ID: <037.384781cacc15e2891eb94349c3644925@ietf.org> References: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <022.bc3bdfe661186204aa95d08583fc6798@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #174: Remove use of `digitally-signed`? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:05:29 -0000 #174: Remove use of `digitally-signed`? -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 07:06: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 5E81512EA97 for ; Thu, 4 May 2017 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH_dn-ZtFlOu; Thu, 4 May 2017 07:06:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4C12EA6A; Thu, 4 May 2017 07:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 14:06:45 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/160#comment:3 Message-ID: <051.077b1ffb5344b2399ee349a7e1fdec5d@ietf.org> References: <036.294435e9c2fd7583ffa63bcf96f58873@ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <036.294435e9c2fd7583ffa63bcf96f58873@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #160: New get-sths API for fetching all STHs in a given time range X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:06:55 -0000 #160: New get-sths API for fetching all STHs in a given time range -----------------------------+------------------------------ Reporter: rob.stradling@… | Owner: rob.stradling@… Type: enhancement | Status: assigned Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------ Changes (by eranm@…): * component: to-be-decided => rfc6962-bis Comment: Given recent support for this feature (https://www.ietf.org/mail- archive/web/trans/current/msg02865.html), moving to the -bis component. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 07:08: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 2F93F1296CD for ; Thu, 4 May 2017 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCkNAfosVETm; Thu, 4 May 2017 07:08:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6333B1294F5; Thu, 4 May 2017 07:08:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 04 May 2017 14:08:33 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/163#comment:5 Message-ID: <037.5613e5610a652359d9ff25d1745d6fff@ietf.org> References: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #163: The entire STH history of the log must be accessible X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:08:34 -0000 #163: The entire STH history of the log must be accessible -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: Suggest marking as a duplicate of 160. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 4 08:28: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 A37DB12941C for ; Thu, 4 May 2017 08:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 fFEc8kgCfoMi for ; Thu, 4 May 2017 08:28:29 -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 5634E1200CF for ; Thu, 4 May 2017 08:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493911708; bh=J7X3Hgoxb2aAnDXgFWdyV967sma5EtSK35QTpt5WjWQ=; h=Date:From:To:Subject; b=maosRjzIohDMnrMELLs4+F7bZP+vwNPK0pX0H5LmoDAeDbIVNzzlvVSPw3l3+GF2G DOfCNHKjiYH8IPWqL5eCL45NBFbSrVWhBTV6e1iGu4BEV6TD1b0M1ZkQ9aNaMp71AB td/bxmySFTKLhXZcFUtBLuvDiFuP2k3hLXQFb4SzkgNwI6AZHql3EV1vDBY0vylxDA I8wiBHX+yEf62b0LOfQ2jo1rj4HiS9CwLK01+kHbeKjkn4LXyVxGaCDLWO3Dcx8bSd VlNveUFtSE0V7+bLAMNdIasMOzPlSAMdc/TwgGTG5cALMveQMlH46P4MsDR9+kPY7p C1RKpWxIo8CEQ== Date: Thu, 4 May 2017 08:25:53 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 04 May 2017 15:28:30 -0000 Regarding https://github.com/google/certificate-transparency-rfcs/pull/248 I do not think this is a good change. If an implementation wants to use a struct to represent the add-entry message (as Google's Golang CT library currently does), the struct would need to contain nullable variables for the certificate and precertificate fields. Nullable variables are error-prone and are best avoided if possible. For example, a client might accidentally send null as one of these fields instead of omitting it (with Go, this can easily happen if you forget to tag the struct field as omitempty). Although this would be a malformed add-entry message, I expect many servers would accept it because many JSON deserializers I've seen (such as Go's) do not distinguish between a null struct field and an omitted struct field. This risks causing interoperability problems. I expect the predominant 6962-bis log server will be Google's Trillian, which means clients will be interacting mostly with log servers which exhibit the lax deserialization behavior. The client's mistake won't be noticed until it tries to submit a chain to a rarer, stricter server, which might happen long after the client code has been deployed. Therefore, I favor keeping add-chain and add-pre-cert as separate endpoints. That way, the structure of the messages are rigid and clearly indicated by the name of the endpoint. The protocol will have only one joint (the endpoint name) instead of two (the endpoint name plus the presence or absence of the precertificate and certificate fields). Regards, Andrew From nobody Thu May 4 08:28:45 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C832412941C for ; Thu, 4 May 2017 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zkILO1A44Ynx for ; Thu, 4 May 2017 08:28:29 -0700 (PDT) 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 B683E120454 for ; Thu, 4 May 2017 08:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493911709; bh=l86UWlsGlan/RGN0zkeK634rfiwhdHtTJoKiH3NknBQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=TvcPzb6K4cNpvknuu0cy+0vWZ6DW3UlE2mbF7dCr4US/6tx6MQ0YlOJg3vJtvh6ak awj0zRZmEKKwWpt/7NaqKbr6gEHEMGRVbF4aXvQWio3/GZl62zz05Kc5zOEldIDDE2 ve9ffKr/U6JjT/ED+unVgeEB+6UGPx3+a/et723tpMb/hyaOChrnfpZowhs+1lwfCM Oj7f6D+cybOI6QSx3aZfwnfczU/13pZXdUdI+kbqMwCKd2bUKimmp6ocRSMe3iu/9F bfh9Zd8mVycLd5K5ytCZ+tUVbw0IAMDXU7wV/RMyRufAppTJNoC1y/H7WeFxBkikmy Yz8VG/vXjDfsQ== Date: Thu, 4 May 2017 08:26:33 -0700 From: Andrew Ayer To: Eran Messeri Cc: "trans@ietf.org" Message-Id: <20170504082633.81f2ce21509fc2268005dff4@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] Ticket 179 - moving Cert/Precert indicator into the data structure 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, 04 May 2017 15:28:32 -0000 On Wed, 3 May 2017 18:53:00 +0100 Eran Messeri wrote: > I'm looking for opinions on ticket 179 > , which suggests > "folding" the Cert/Precert indicator for an SCT into the data > structure contained in the TransItem (right now it's part of the > TransItem type indicator). > > Personally I find it hard to justify such a change, since SCTs are > already clearly defined as TransItems and it's a non-trivial change > to the data structures without a strong benefit. > > Suggestions? I agree that there isn't a very strong justification for making a non-trivial change like this. I would also like to understand why 6962-bis consolidated all the type indicators into a single one before that work is undone. Absent a stronger justification and an explanation of why the consolidation was done in the first place, I favor keeping 6962-bis as-is. Regards, Andrew From nobody Thu May 4 08:28: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 399E41294F0 for ; Thu, 4 May 2017 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 7jaNlkvJstPQ for ; Thu, 4 May 2017 08:28:31 -0700 (PDT) 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 B68C71200CF for ; Thu, 4 May 2017 08:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493911710; bh=0a6xuozb/n9uMaHtNhPkYsCqjFZVvXBfKVS+56Qrd0I=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=xFpIiruJ/y51yuiM8vevxJLdXBPYDVd5vyG/mBr/ZISoSZMYo67D6LypuxKv5v+cA rdBoKlZTz1HPo6zNHnzZgXFP8t9g+K9UsY6hJkmoiRphZXQOBf5kYGLWnA7sM3O1CI IGi/PUeFZS8D+lHmtrFTYHH3RTR7mjhOsjdL3xyvrxKiOJQ43ycZGXbGrazAasl3/U oxIAgYQMXgohmGpG7KSyqpZV6vCI23K6vbU7zmOKFJked5cSSREDik0PQvaliErrRq oMnS7IA2Gk53BHT7oecuDt2Cdu85/VJw5bebUdLqC5xRaN4Bxg8iJ+Zxa4bVDpGbh0 XduaVgSYQDhNQ== Date: Thu, 4 May 2017 08:26:36 -0700 From: Andrew Ayer To: Eran Messeri Cc: "trans@ietf.org" Message-Id: <20170504082636.dd0212e34e17949eb69b2fed@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] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 15:28:33 -0000 On Thu, 4 May 2017 13:41:59 +0100 Eran Messeri wrote: > I'm looking for feedback on the proposal to add an API endpoint which > would provide access to historical STHs issued by the log ( > https://trac.ietf.org/trac/trans/ticket/163). > > I personally think it's a good idea to have such an API since it'd > allow auditing a log for past compliance with the MMD requirement. > > Rob Stradling has sent a PR > > for this. I support adding this endpoint, and I think it should be mandatory. In addition to helping monitors, this endpoint would allow a TLS client vendor (e.g. Mozilla) to aggregate all the STHs for a log and ship them in bulk to clients so that clients can easily verify a stapled inclusion proof without needing to make any network access. That should please Mozilla. Regards, Andrew From nobody Thu May 4 09:18:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9631270AC for ; Thu, 4 May 2017 09:18:18 -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 SIMMMVbkLmvY for ; Thu, 4 May 2017 09:18:17 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB37127863 for ; Thu, 4 May 2017 09:18:09 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id p24so28659516ioi.0 for ; Thu, 04 May 2017 09:18:09 -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=D1YjF04uJif1u3c0XsgBnHJoaK/luYcxRz47hYmethg=; b=PRgJ7RoKwCEzwMdzfxa36Ee6i3TRaLUOE6qyFJt9HsShyYCqHwwJDei+yC/kJVzwF7 yCKJFkvAuyMYtBP9d6SmwVB/jdVzKnRmx0llyVJu/YW5J3axfPtI6Yit2AHnsRMvempq +Y8ByimV1MIH5m2Y+ObSLdEhK70BuNdATGAsMO6nWNCnVEvLPcCLCLwf8lTDwaXIJm73 DkoMu0UkdHa9hd7Q/nqf7WAGQBDqva/FUmqvaol/OhZCnLpXXR654/Ul3UT/qWgb9aJg sYq0VjOlIx9xKBfzjUtpqvmt8x3F57C/Pejz+lgqETD+6yavRF1xv3uIYbrotEpqZ2+j D4wg== 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=D1YjF04uJif1u3c0XsgBnHJoaK/luYcxRz47hYmethg=; b=LZap4OM30AZ/JDCUId3i+Mhs8Lg3tKohUFOL2hnkCKHyTydjaLRJQ5b3uXUXiEBIMW eB3UD7JS750EwNPBuYN2QhK5JBh6mjT1So9gf7lDRbUE1TVnwBXTbyMZEyfWdM6C/AgU MZ8QgagrjBWzYUdaQFJfXuYTvirneeEPPIj8/o9tZWNQY07b2egZdE6ZuODQIunLgtYT WQ0z+Uo8IwZ6WKjfqmfIoDMeftm1LIrVkpjBSoOqFeq6I3Js9TLopeJ6a/Fk3HhwHkcX qMQtCgOwsIdV+uiWGg3AKSXhUJqNhZzOkQBA6XkcH9n3DEGcEArhcDSDPCKx4xrNErhV mlFg== X-Gm-Message-State: AN3rC/5q/iVzqUE2mQYU74wKHZRFrjae4/T+H3ROS4cc5x0FrwYItW6L pdbdiubQLbiIt02k5bXqyJCKYOkGhMBlP5/VUw== X-Received: by 10.107.133.106 with SMTP id h103mr13775750iod.230.1493914688271; Thu, 04 May 2017 09:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.47.41 with HTTP; Thu, 4 May 2017 09:17:37 -0700 (PDT) In-Reply-To: <20170504082633.81f2ce21509fc2268005dff4@andrewayer.name> References: <20170504082633.81f2ce21509fc2268005dff4@andrewayer.name> From: Eran Messeri Date: Thu, 4 May 2017 17:17:37 +0100 Message-ID: To: Andrew Ayer Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113ff9a6522c20054eb51e2c Archived-At: Subject: Re: [Trans] Ticket 179 - moving Cert/Precert indicator into the data structure 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, 04 May 2017 16:18:19 -0000 --001a113ff9a6522c20054eb51e2c Content-Type: text/plain; charset=UTF-8 On Thu, May 4, 2017 at 4:26 PM, Andrew Ayer wrote: > On Wed, 3 May 2017 18:53:00 +0100 > Eran Messeri wrote: > > > I'm looking for opinions on ticket 179 > > , which suggests > > "folding" the Cert/Precert indicator for an SCT into the data > > structure contained in the TransItem (right now it's part of the > > TransItem type indicator). > > > > Personally I find it hard to justify such a change, since SCTs are > > already clearly defined as TransItems and it's a non-trivial change > > to the data structures without a strong benefit. > > > > Suggestions? > > I agree that there isn't a very strong justification for making a > non-trivial change like this. > > I would also like to understand why 6962-bis consolidated all the type > indicators into a single one before that work is undone. > In 6962 different structures had versions (SCT, MerkleTreeLeaf, TreeHeadSignature), making it appear as if "v2" STHs can be mixed with "v1" SCTs or tree leaves. In practice, while it may be possible, it's not as straightforward as the independent data structure versioning makes it appear, since there's a dependency between the data structures. Moving the version to the topmost layer, together with the data structure type, makes it explicit which type is being dealt with. Another problem is that the different versions in 6962 were incorrectly interpreted by implementations, some using a "global" versioning scheme, some using per-type versioning scheme, and not all implementations checking these are versions they know about. Requiring inspection of the (versioned) type for correct interpretation of the TransItem forces implementations to consider the version they're dealing with, removing the potential pitfall of having a version field that's not properly checked. Rob, who undertook this non-trivial change, may have a more complete context. > > Absent a stronger justification and an explanation of why the > consolidation was done in the first place, I favor keeping 6962-bis > as-is. > > Regards, > Andrew > --001a113ff9a6522c20054eb51e2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 4, 2017 at 4:26 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
<= span class=3D"gmail-">On Wed, 3 May 2017 18:53:00 +0100
Eran Messeri <eranm@google.com&g= t; wrote:

> I'm looking for opinions on ticket 179
> <https://trac.ietf.org/trac/trans/tic= ket/179>, which suggests
> "folding" the Cert/Precert indicator = for an SCT into the data
> structure contained in the TransItem (right now it's part of the > TransItem type indicator).
>
> Personally I find it hard to justify such a change, since SCTs are
> already clearly defined as TransItems and it's a non-trivial chang= e
> to the data structures without a strong benefit.
>
> Suggestions?

I agree that there isn't a very strong justification for making = a
non-trivial change like this.

I would also like to understand why 6962-bis consolidated all the type
indicators into a single one before that work is undone.
In 6962 different structures had versions (SCT, MerkleTreeLeaf, TreeHead= Signature), making it appear as if "v2" STHs can be mixed with &q= uot;v1" SCTs or tree leaves.
In practice, while it may b= e possible, it's not as straightforward as the independent data structu= re versioning makes it appear, since there's a dependency between the d= ata structures.

Moving the version to the topmost = layer, together with the data structure type, makes it explicit which type = is being dealt with.
Another problem is that the different versio= ns in 6962 were incorrectly interpreted by implementations, some using a &q= uot;global" versioning scheme, some using per-type versioning scheme, = and not all implementations checking these are versions they know about.

Requiring inspection of the (versioned) type for cor= rect interpretation of the TransItem forces implementations to consider the= version they're dealing with, removing the potential pitfall=C2=A0
of having a version field that's not properly checked.

Rob, who undertook this non-trivial change, may have a more= complete context.

Absent a stronger justification and an explanation of why the
consolidation was done in the first place, I favor keeping 6962-bis
as-is.

Regards,
Andrew

--001a113ff9a6522c20054eb51e2c-- From nobody Thu May 4 11:25:06 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 77BFA1294A8 for ; Thu, 4 May 2017 11:25:05 -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 Ypmtaodn9Igh for ; Thu, 4 May 2017 11:24:57 -0700 (PDT) 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 67ED5129B11 for ; Thu, 4 May 2017 11:24:53 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m123so3227445wma.0 for ; Thu, 04 May 2017 11:24:53 -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=mrOTPueAWswN6J3sgJkcxGvKkCB2rRXIzrTY5LjgGJo=; b=jgScH6GGxkqY1wrF3TUFBIaVR1s5I6s8vxXWajOUSIlUBQkkX6cL7u96C7tNlchsk3 iykfD6HOWcdp+TTYW37C5/vHc8nlwuilqiLQXKhAoHUN3dU7R7f9ZDyrVEim7yszEpKY Sc09dO1657hAJbxF3ehmeKwGxd7SRcA2FvP/ToV+Q+/EwTT5VPrAKiD5/dklM+kHCL9I s+jJJMUdwQSQSarbmoNVctMTdg8CJXG1s5OGMI+4jX8DOCG5isTLhOwPJMqM+Q5bIt3o dw9gzCgpTSUrqgHNq7EQiFG7j0nzKGzs0nOgR6SyOU8gXc1ZfQFvrxzK55xlTus3msjZ Z/GA== 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=mrOTPueAWswN6J3sgJkcxGvKkCB2rRXIzrTY5LjgGJo=; b=hTTVEDWg4/kGLIM34j0ck2+o2X4SGESMpVjw3fnEPZmLxQjY6trLNIffSFevOeXHj3 TSAX95hUQU4aZPkll1v+MaFxIwjX1VGdDLuvoQEbjrpJkBP3OiUqRPfRk8c+krrHg9AB moKtpkOTCXFVVBlLB/TK4SEea6r3Hy2EkuKDSOaeYuVWEXoVEE9CfHdHUwW91+VaIgav YSwo26aMwdsPjBfw3ifDxeMZktTADzBQMi2Ow9DN4bIVrdk3eoNbtr2XvH7JmKrqTGJF XDDFIk0dcvYMg3+lDXjwL+F6Z4z8md9mt9SVf9JbDp+Kfq9kttTgmGYycvf1nf4zgBYR a0aQ== X-Gm-Message-State: AN3rC/479RSu+N/OCOQ9KfOOgUj/bwGs3PPhbzoWvFu32Qc3gK9I5jSG lXvTQ+LrQfDx5RBpiZtRc6aIE1FaXXsQ X-Received: by 10.28.0.200 with SMTP id 191mr3020800wma.12.1493922291786; Thu, 04 May 2017 11:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.179.68 with HTTP; Thu, 4 May 2017 11:24:51 -0700 (PDT) In-Reply-To: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> From: Richard Barnes Date: Thu, 4 May 2017 14:24:51 -0400 Message-ID: To: Andrew Ayer Cc: Trans Content-Type: multipart/alternative; boundary=001a113d81de863e16054eb6e3dd Archived-At: Subject: Re: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 04 May 2017 18:25:05 -0000 --001a113d81de863e16054eb6e3dd Content-Type: text/plain; charset=UTF-8 TBH, I don't feel very strongly about this. Andrew's analysis seems pretty sound. On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer wrote: > Regarding https://github.com/google/certificate-transparency-rfcs/pull/248 > > I do not think this is a good change. > > If an implementation wants to use a struct to represent the add-entry > message (as Google's Golang CT library currently does), the struct would > need to contain nullable variables for the certificate and > precertificate fields. Nullable variables are error-prone and are best > avoided if possible. > > For example, a client might accidentally send null as one of these > fields instead of omitting it (with Go, this can easily happen if you > forget to tag the struct field as omitempty). Although this would be a > malformed add-entry message, I expect many servers would accept it > because many JSON deserializers I've seen (such as Go's) do not > distinguish between a null struct field and an omitted struct field. > This risks causing interoperability problems. I expect the predominant > 6962-bis log server will be Google's Trillian, which means clients will > be interacting mostly with log servers which exhibit the lax > deserialization behavior. The client's mistake won't be noticed until > it tries to submit a chain to a rarer, stricter server, which might > happen long after the client code has been deployed. > > Therefore, I favor keeping add-chain and add-pre-cert as separate > endpoints. That way, the structure of the messages are rigid and > clearly indicated by the name of the endpoint. The protocol will have > only one joint (the endpoint name) instead of two (the endpoint name > plus the presence or absence of the precertificate and certificate > fields). > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113d81de863e16054eb6e3dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TBH, I don't feel very strongly about this.=C2=A0 Andr= ew's analysis seems pretty sound.
<= br>
On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer = <agwa@andrewayer.name> wrote:
Regarding https://github.com/= google/certificate-transparency-rfcs/pull/248

I do not think this is a good change.

If an implementation wants to use a struct to represent the add-entry
message (as Google's Golang CT library currently does), the struct woul= d
need to contain nullable variables for the certificate and
precertificate fields.=C2=A0 Nullable variables are error-prone and are bes= t
avoided if possible.

For example, a client might accidentally send null as one of these
fields instead of omitting it (with Go, this can easily happen if you
forget to tag the struct field as omitempty).=C2=A0 Although this would be = a
malformed add-entry message, I expect many servers would accept it
because many JSON deserializers I've seen (such as Go's) do not
distinguish between a null struct field and an omitted struct field.
This risks causing interoperability problems.=C2=A0 I expect the predominan= t
6962-bis log server will be Google's Trillian, which means clients will=
be interacting mostly with log servers which exhibit the lax
deserialization behavior. The client's mistake won't be noticed unt= il
it tries to submit a chain to a rarer, stricter server, which might
happen long after the client code has been deployed.

Therefore, I favor keeping add-chain and add-pre-cert as separate
endpoints.=C2=A0 That way, the structure of the messages are rigid and
clearly indicated by the name of the endpoint.=C2=A0 The protocol will have=
only one joint (the endpoint name) instead of two (the endpoint name
plus the presence or absence of the precertificate and certificate
fields).

Regards,
Andrew

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

--001a113d81de863e16054eb6e3dd-- From nobody Thu May 4 12:21: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 8B70312869B for ; Thu, 4 May 2017 12:21: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, HTML_MESSAGE=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 (1024-bit key) header.d=cloudflare.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 gpBBy6fXuEXo for ; Thu, 4 May 2017 12:21:00 -0700 (PDT) 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 CA4AF128BB6 for ; Thu, 4 May 2017 12:20:59 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id g49so15875158uaa.1 for ; Thu, 04 May 2017 12:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XyOlhrDfrbCfo5jjLoWVoHI8v8kGHOqnRswUJMLOBsE=; b=bhYwNG4vhmpypg1QRcs9xhE6ODa1HgSlkVEixI6C9LHmjrcguPneiTk6REJynfcu1p ehW2HAJNOfDYynN+TcKDNzELKkG87iv5XqGdnb5F67egj4pdqWQRP73S7c/WPAk3LXXW FGUsdULvWlpgWf86CSiygXNQRqNPTqzuYAIZA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XyOlhrDfrbCfo5jjLoWVoHI8v8kGHOqnRswUJMLOBsE=; b=pukzZwJwfmCYhWQVPBHKJL0jM4RLKfP+LwjxXb1OYmt+Nq/I1w/ocbvZmRuA6TgUKz yswQQvNsv/e5A7bY3imXX6xd+UL5fcB7wMLG0cGuAMIQg6QohxFNdOl9JRGTSilW5UKA aeRr34LRkOQzOEFpDA+PZk0tqkyzzHgVvuydKNocCHYscB8mUs/LcPVJCM5J3JH1D2y5 LVMGxDxeKx3vgvQIt+7WVxnwMF+k4CfztP+ZcxSteuTMNIrPWRSjAt+XWL5oJnoQKvdk asyHSmOgeHmwRY9hEx1+EoGPAcAJN0KvzDLI89JkPgzPmOwIX1ZTY/zWkcj7Qn4eMpPk 1fzg== X-Gm-Message-State: AN3rC/65sxKhE1FuUsHFgA38KSV0INw+PVx9JfhfolpTW+kTJKlkC00F KziqPxKATNKrLiYR1yh8RlrSw4GWwvbZHZw= X-Received: by 10.159.34.54 with SMTP id 51mr17010856uad.110.1493925658950; Thu, 04 May 2017 12:20:58 -0700 (PDT) MIME-Version: 1.0 References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> In-Reply-To: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> From: Nick Sullivan Date: Thu, 04 May 2017 19:20:47 +0000 Message-ID: To: Andrew Ayer , Eran Messeri Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113e39e6391885054eb7ac3c Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 19:21:02 -0000 --001a113e39e6391885054eb7ac3c Content-Type: text/plain; charset=UTF-8 I'm also in favor of this change. I would further suggest that this list be required to be consistent, monotonically increasing and that the results of this API be something that monitors exchange information about. On Thu, May 4, 2017 at 8:28 AM Andrew Ayer wrote: > On Thu, 4 May 2017 13:41:59 +0100 > Eran Messeri wrote: > > > I'm looking for feedback on the proposal to add an API endpoint which > > would provide access to historical STHs issued by the log ( > > https://trac.ietf.org/trac/trans/ticket/163). > > > > I personally think it's a good idea to have such an API since it'd > > allow auditing a log for past compliance with the MMD requirement. > > > > Rob Stradling has sent a PR > > > > for this. > > I support adding this endpoint, and I think it should be mandatory. > > In addition to helping monitors, this endpoint would allow a TLS client > vendor (e.g. Mozilla) to aggregate all the STHs for a log and ship them > in bulk to clients so that clients can easily verify a stapled > inclusion proof without needing to make any network access. That > should please Mozilla. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113e39e6391885054eb7ac3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also in favor of this change. I would further sugg= est that this list be required to be consistent, monotonically increasing a= nd that the results of this API be something that monitors exchange informa= tion about.

On Thu, Ma= y 4, 2017 at 8:28 AM Andrew Ayer <agwa@andrewayer.name> wrote:
On Thu, 4 May 2017 13:41:59 +0100
Eran Messeri <eran= m@google.com> wrote:

> I'm looking for feedback on the proposal to add an API endpoint wh= ich
> would provide access to historical STHs issued by the log (
> https://trac.ietf.org/trac/trans/ticket/163). >
> I personally think it's a good idea to have such an API since it&#= 39;d
> allow auditing a log for past compliance with the MMD requirement.
>
> Rob Stradling has sent a PR
> <https://github.com/google/= certificate-transparency-rfcs/pull/200/>
> for this.

I support adding this endpoint, and I think it should be mandatory.

In addition to helping monitors, this endpoint would allow a TLS client
vendor (e.g. Mozilla) to aggregate all the STHs for a log and ship them
in bulk to clients so that clients can easily verify a stapled
inclusion proof without needing to make any network access.=C2=A0 That
should please Mozilla.

Regards,
Andrew

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a113e39e6391885054eb7ac3c-- From nobody Thu May 4 12:34: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 A92BE1294CF for ; Thu, 4 May 2017 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HaU6w813x2vO for ; Thu, 4 May 2017 12:34:48 -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 AD0F212949B for ; Thu, 4 May 2017 12:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1493926488; bh=ePEYNTmb8MPvE/qhouy2cy0awGjxvQyAjHScNtzAcUQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=PAElZwy3FtKEnJ6kXC+EKjeT0JXUFneWh4GLq61s+A4G9M0GZHnuywfMb28q0Go/P z707f7Zy/EcSSBWrYMZB+6yB/6X86OVrJpQkW/54zyPCVNyXpexTGw47xtl52KIZUQ aHHL0hI5Ffdgy7iYAk1t8EySa4L9p6tglNo+uR6cxL12NV9V/fUj+0rv0SE8dd9llK t0ZIzFGOvLhGpHAbkaj5+mgDkA9vs9KuJJx8l/v8ZX43I1wiEgnYVQQoZj/yHTnEp8 siCzSWSfdG0YY8ohCMEPLKii8/w/WdUMBGKQjQCo75TADEIk0YO+DIkAFAlZ7wiwbJ DMxswEl2slkYg== Date: Thu, 4 May 2017 12:34:47 -0700 From: Andrew Ayer To: Nick Sullivan Cc: Eran Messeri , "trans@ietf.org" Message-Id: <20170504123447.41d957a88bd65417e714be78@andrewayer.name> In-Reply-To: References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 19:34:51 -0000 On Thu, 04 May 2017 19:20:47 +0000 Nick Sullivan wrote: > I'm also in favor of this change. I would further suggest that this > list be required to be consistent, monotonically increasing and that > the results of this API be something that monitors exchange > information about. Hi Nick, Could you explain what you mean by "consistent"? As for monotonically increasing, does the following language in Rob's PR match what you mean? "These STHs SHALL be ordered chronologically by timestamp, oldest first, beginning with the earliest STH in the specified range." The gossip draft defines an STH pollination mechanism that monitors can use to exchange STHs that they observe. Would this work, or were you thinking about something else? Regards, Andrew From nobody Thu May 4 13:58: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 9742E128DF2 for ; Thu, 4 May 2017 13:58:30 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 m1YrcysIQHRL for ; Thu, 4 May 2017 13:58:29 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 C4F66127977 for ; Thu, 4 May 2017 13:58:28 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id g49so17647134uaa.1 for ; Thu, 04 May 2017 13:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JV4bMGe14rjaXra08QV8S11MHzFBZPY4oX89qTEMlJc=; b=pVDnBVONsUialkbG6wzZBHKxnOdLIwYM/fbYUbGCDRNrF1Kzumi0CNSRy+ZVjDSN/X 0HeEDlbZE1nCYu58qcEHQC/pChlpP+4N05qUc6/UylYn8UqTM0jyWl39FhFPhnwassQO HrQ7PTAO614PkVApBluzwQYmmlNQ2P+pIoqhQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JV4bMGe14rjaXra08QV8S11MHzFBZPY4oX89qTEMlJc=; b=EPNLxtTWZt7qxDPHzFiWZXCU0CXp9syqZW0xnFIslzg3kJnvNZdz53lllpv19MfuMK U+FRiBKbqhMdRaePcHnMZv1ElkKyzMN0uHcHQxDD2Y16Nt0PpnI5b6Ah3yYZwXGmoSvf 1eOFZnzKjUYWEoe4PgVYAgDsFSSxlVGeOjPEQ29H3GoteVWLaaRIH3MnlY8WOa6iUDBW l3+XVH8+QLxLG8r7bm0MHwtAUyVhCx7w6LykqsPpKyGpMPsF1NGVJ1+FneIe9vGR3+X1 USuIMjRBKkCU1bdLgpVNL2pClwt6ZrvabXnJ80Ug0aYe4iP0iyOx3Ht+SE+yNiDzghQm AW3A== X-Gm-Message-State: AODbwcB2AGANqmpOMKkbZjGFakiNTVymTHTrA9hwlGFcegGkhqDbHh4r SPirrGt8G1SpW8JR+M1DOsGU83d0znicK4k= X-Received: by 10.159.59.44 with SMTP id i44mr1279225uah.43.1493931507849; Thu, 04 May 2017 13:58:27 -0700 (PDT) MIME-Version: 1.0 References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> In-Reply-To: <20170504123447.41d957a88bd65417e714be78@andrewayer.name> From: Nick Sullivan Date: Thu, 04 May 2017 20:58:16 +0000 Message-ID: To: Andrew Ayer Cc: Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary=f403043c4488d84fd1054eb908b4 Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 04 May 2017 20:58:31 -0000 --f403043c4488d84fd1054eb908b4 Content-Type: text/plain; charset=UTF-8 By consistent I mean that if a sequence of STHs such as (A, B, C) are presented on day 1, that a different sequence is not presented on day 2 (A, C) or (A, D, B, C). Rob's language works in term of chronological order. STH pollination could be a way to support auditing this, but I don't think it's sufficiently robust as currently defined. To prevent STHs from going missing, or for new STHs to appear after the fact, STHs should be exchanged along with metadata indicating the previous and (if it exists yet) the next STH in the tree. On Thu, May 4, 2017 at 12:34 PM Andrew Ayer wrote: > On Thu, 04 May 2017 19:20:47 +0000 > Nick Sullivan wrote: > > > I'm also in favor of this change. I would further suggest that this > > list be required to be consistent, monotonically increasing and that > > the results of this API be something that monitors exchange > > information about. > > Hi Nick, > > Could you explain what you mean by "consistent"? > > As for monotonically increasing, does the following language in Rob's > PR match what you mean? > > "These STHs SHALL be ordered chronologically by timestamp, oldest > first, beginning with the earliest STH in the specified range." > > The gossip draft defines an STH pollination mechanism that monitors can > use to exchange STHs that they observe. Would this work, or were you > thinking about something else? > > Regards, > Andrew > --f403043c4488d84fd1054eb908b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By consistent I mean that if a sequence of STHs such as (A= , B, C) are presented on day 1, that a different sequence is not presented = on day 2 (A, C) or (A, D, B, C).

Rob's language work= s in term of chronological order.

STH pollination = could be a way to support auditing this, but I don't think it's suf= ficiently robust as currently defined. To prevent STHs from going missing, = or for new STHs to appear after the fact, STHs should be exchanged along wi= th metadata indicating the previous and (if it exists yet) the next STH in = the tree.

On Thu= , May 4, 2017 at 12:34 PM Andrew Ayer <agwa@andrewayer.name> wrote:
On Thu, 04 May 2017 19:20:47 +0000
Nick Sullivan <= nick@cloudflare.com> wrote:

> I'm also in favor of this change. I would further suggest that thi= s
> list be required to be consistent, monotonically increasing and that > the results of this API be something that monitors exchange
> information about.

Hi Nick,

Could you explain what you mean by "consistent"?

As for monotonically increasing, does the following language in Rob's PR match what you mean?

"These STHs SHALL be ordered chronologically by timestamp, oldest
first, beginning with the earliest STH in the specified range."

The gossip draft defines an STH pollination mechanism that monitors can
use to exchange STHs that they observe.=C2=A0 Would this work, or were you<= br> thinking about something else?

Regards,
Andrew
--f403043c4488d84fd1054eb908b4-- From nobody Thu May 4 15:21:20 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045C129478 for ; Thu, 4 May 2017 15:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 dGLW2Bro8UQK for ; Thu, 4 May 2017 15:21:16 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 8B6DE129469 for ; Thu, 4 May 2017 15:21:15 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e65so7579266ita.1 for ; Thu, 04 May 2017 15:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GQB/GSJjXn/FbiI7hEXbQnN6zBZKP5rF8F5U+/Xe7MA=; b=PYYaTg7lRQk9mELg6MpY6Boor3E9pKyN8Ft6aUNfVvzvV9mmX1RH4dSAQD3R5RaGUC ukLDLREMbrpmDR4AAeILevybwNSIsa/zqTw0LIkD3os4WngT6frW9haAtfwBLf2TcuyH MWezqMoiOPMFa/8BxhV5S9ypfoJJRwKMi355k8EnTZIx5nhrmwFrRdvGJa417oRSONU3 ib4hco3Wb1tLrB1jiOVbog7QdTH/hsAu2g+0vXXSqzQblCgmv8qVEgAcDN/l4NLratLe a4kEWpmvh4lEKbX7uBXBHBqH8WYNWjzApZs4SN+pyhdbP6hi1+KbMYeIiJ/d5mG44Y36 1OOg== 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=GQB/GSJjXn/FbiI7hEXbQnN6zBZKP5rF8F5U+/Xe7MA=; b=KyIKn60HsD1IHGEBVNPkRUjqZDpUpBeE0I7FEh6IXSljrbeLkBWsNDLOxi/21ZrEIm QDt5Xs3A/L7O01B/hHQh1fW6STP2qH2sC9441aYviE4shhP18E5wpah3Q5/wt81+wDd4 aGiQEnfgKD4s+uGBb3xeR6r051+Y/frPc7e8TV49Y0I9nQaZVG5RoHVmNgsWP2e3sLbe MYElCdShYS1xLk7KmKG0udkIzL9R9vnH0tg8ji/vgx/zUsTjcPNRYpIHpz6pa/Scaz14 NF1cLh3f5Hkq8DCfsqWFE26mj4QO7HHa+cTqsoBF5Phhsvz/eOjaNtRiK3nyuvpeBY1i MGaQ== X-Gm-Message-State: AN3rC/4FARIR/zlZRmBq13wf7rnXgLOsdKDJRllx1fZbcPx3WP0HGyeZ up7+MzqHQWFnz1YwdJp60zYjLWW976P6 X-Received: by 10.36.124.85 with SMTP id a82mr4958748itd.90.1493936474817; Thu, 04 May 2017 15:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Thu, 4 May 2017 15:21:14 -0700 (PDT) From: Brian Smith Date: Thu, 4 May 2017 12:21:14 -1000 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 04 May 2017 22:21:19 -0000 Hi, Recently I implemented RFC 6979 and also I'm implementing some CT things. Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA signatures. However, the requirement to use RFC 6979 is problematic for several reasons, noted below. I think this group should reconsider if the fingerprinting threat that motivated the requirement for deterministic signatures is significant enough to overcome these problems. If the requirement for deterministic signatures were removed, all the problems below would be resolved. (Additionally the more secure RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1 1.5.) If it is still seen as very important to require signatures be deterministic, the requirement to to use specifically RFC 6979 should be be removed, and replaced with a more general requirement to use *some* secure deterministic nonce for ECDSA signatures, without mandating RFC 6979 specifically. Here are the problems I see with mandating the use of RFC 6979: 1. RFC 6979 deterministic signatures are not and cannot be compliant with FIPS and other regulations. This means, in particular, that a log cannot use the same CABForum-compliant (HSM) ECDSA implementation that it could use to sign certificates. 2. RFC 6979 is a very inefficient way of generating deterministic signatures. Every RFC 6979 signature requires invoking the SHA-256 compression function 19 to 22 times. The BitCoin core developers reported that this takes 10% of total signature generation time. [0] 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for ECDSA. This is a step backward from recent progress towards provable security of internet protocols. 4. Because of #1, #2, and #3, most crypto libraries and HSM implementations would be better off using a different deterministic signature scheme (such as a variant of the much more efficient one used for Ed25519). And/or they may use a different, non-deterministic, solution to the concerns that originally motivated the creation of RFC 6979 in the first place, such as the one that Google's BoringSSL [1] and Cisco [2] have implemented. If one is going to use a better scheme, then maintaining RFC 6979 support too just for this one protocol is a large burden. 5. There is no way to check that the log actually used RFC 6979, or any other specific secure deterministic scheme, because part of calculating the nonce involves hashing the private key. Thus the requirement to use RFC 6979 is unenforceable technically or even by policy. [0] https://crypto.stackexchange.com/a/42551 (I can't find the original citation for what the Bitcoin people said.) [1] https://boringssl.googlesource.com/boringssl/+/783e0957875ac62b35aa4f8741069e133695a3d4 [2] https://blogs.cisco.com/security/fips-and-deterministic-ecdsa-achieving-robust-security-and-conformance Cheers, Brian -- https://briansmith.org/ From nobody Fri May 5 02:03: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 BE94912946A for ; Fri, 5 May 2017 02:02:57 -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, 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 AjfR7Arg8fbP for ; Fri, 5 May 2017 02:02:55 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 36AD01276AF for ; Fri, 5 May 2017 02:02:55 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id k91so87466ioi.1 for ; Fri, 05 May 2017 02:02:55 -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=2YcDs6JE8reQCk3r6mZwRlh4rVxTc4c4EoXRnVVALGo=; b=ZfFdKhM7c0ZVm+563XyDRBCUcSd/1ti/vonK6Es6iJRv/WGfAqzViVWG2wsIqoHAMP QMTEtfzNSJEUol0GSiLILJalo9Fa8cHWp/iapvD2w1ArA76SeOO4OUaBVOEurg3Oa4xQ hu83PVmbnCCPZk3z8VivdUBUA0cEAs96yzhLgeYClGXnfkHh5SJGt5Qsqgb1IFkaStWi yhj43H6b+eK0Let+mz7xOkBDja9BY4/YpuuQ9DSipPti5yEIn1iJylnEVi0szF56NwXz woJctj0v2eHFbMK4KbKsIKUJr5dkI30QpQup7wBsxaslrbuItKdu1RjEQpHugPCN3L5O ni8w== 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=2YcDs6JE8reQCk3r6mZwRlh4rVxTc4c4EoXRnVVALGo=; b=XsG3I3fzHhPgv20Vw+4rLx29x05KDuh8FEGd9coEsKxqFnLGNWjaa0C1DZT7bL7HBZ 9ywQsk/h/jXDNM1Fes58y6SBHl4hrLJKRwOufohUzafpBWEkENot5zOXe4OZaFjZBCGe q6hxdHvXZDsL1uj2oBJKXRCyZ3K0EVxw68yBKOO6EL4/1g6nwhEjeibm/agbX4H9urjt OBapuw9oncPDojHHVqC8rSa7oQSxV/wVZwljZXvIbx6bA5HqU/T9kH/A4Ownh86R6iYY M3tu5MPiiWTdZOUZn5E9D3fLaefTmkJlgfnths9t0RrNHcKycNQwrwb1XwB0/Cvea1/V bDew== X-Gm-Message-State: AODbwcAJnWVwjdgnb4efPSkIoXhL2pIxECeT8ANmHbD9nHy+fvidx5so iyFcS4JSL3frzxc3bRNx5ik2CXsW6G/u X-Received: by 10.107.128.98 with SMTP id b95mr5819220iod.25.1493974974436; Fri, 05 May 2017 02:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.47.41 with HTTP; Fri, 5 May 2017 02:02:23 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Fri, 5 May 2017 10:02:23 +0100 Message-ID: To: Brian Smith Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113dfdaea7f7a4054ec3276f Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 05 May 2017 09:02:58 -0000 --001a113dfdaea7f7a4054ec3276f Content-Type: text/plain; charset=UTF-8 I share the concern, due to the difficulty I've had finding implementations of this RFC (or any deterministic signature scheme for ECDSA in general). I'd like to hear the opinion of people who've worked on the Gossip protocol - as Brian said, the purpose behind deterministic signatures is to make it difficult to fingerprint individual clients. However, the only gossip that's taking place right now is STH exchange between monitors, where this is not a concern, My proposal for 6962-bis is then to: * State 6962-bis logs SHOULD use a deterministic signature scheme (making it optional, but strongly suggested). * Remove normative references to RFC6979. Eran On Thu, May 4, 2017 at 11:21 PM, Brian Smith wrote: > Hi, > > Recently I implemented RFC 6979 and also I'm implementing some CT things. > > Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA > signatures. However, the requirement to use RFC 6979 is problematic > for several reasons, noted below. I think this group should reconsider > if the fingerprinting threat that motivated the requirement for > deterministic signatures is significant enough to overcome these > problems. > > If the requirement for deterministic signatures were removed, all the > problems below would be resolved. (Additionally the more secure > RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1 > 1.5.) > > If it is still seen as very important to require signatures be > deterministic, the requirement to to use specifically RFC 6979 should > be be removed, and replaced with a more general requirement to use > *some* secure deterministic nonce for ECDSA signatures, without > mandating RFC 6979 specifically. > > Here are the problems I see with mandating the use of RFC 6979: > > 1. RFC 6979 deterministic signatures are not and cannot be compliant > with FIPS and other regulations. This means, in particular, that a log > cannot use the same CABForum-compliant (HSM) ECDSA implementation that > it could use to sign certificates. > > 2. RFC 6979 is a very inefficient way of generating deterministic > signatures. Every RFC 6979 signature requires invoking the SHA-256 > compression function 19 to 22 times. The BitCoin core developers > reported that this takes 10% of total signature generation time. [0] > > 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for > ECDSA. This is a step backward from recent progress towards provable > security of internet protocols. > > 4. Because of #1, #2, and #3, most crypto libraries and HSM > implementations would be better off using a different deterministic > signature scheme (such as a variant of the much more efficient one > used for Ed25519). And/or they may use a different, non-deterministic, > solution to the concerns that originally motivated the creation of RFC > 6979 in the first place, such as the one that Google's BoringSSL [1] > and Cisco [2] have implemented. If one is going to use a better > scheme, then maintaining RFC 6979 support too just for this one > protocol is a large burden. > > 5. There is no way to check that the log actually used RFC 6979, or > any other specific secure deterministic scheme, because part of > calculating the nonce involves hashing the private key. Thus the > requirement to use RFC 6979 is unenforceable technically or even by > policy. > > [0] https://crypto.stackexchange.com/a/42551 (I can't find the > original citation for what the Bitcoin people said.) > [1] https://boringssl.googlesource.com/boringssl/+/ > 783e0957875ac62b35aa4f8741069e133695a3d4 > [2] https://blogs.cisco.com/security/fips-and- > deterministic-ecdsa-achieving-robust-security-and-conformance > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113dfdaea7f7a4054ec3276f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I share the concern, due to the difficulty I've had fi= nding implementations of this RFC (or any deterministic signature scheme fo= r ECDSA in general).

I'd like to hear the opinion of= people who've worked on the Gossip protocol - as Brian said, the purpo= se behind deterministic signatures is to make it difficult to fingerprint i= ndividual clients. However, the only gossip that's taking place right n= ow is STH exchange between monitors, where this is not a concern,

My proposal for 6962-bis is then to:
* State 6962= -bis logs SHOULD use a deterministic signature scheme (making it optional, = but strongly suggested).
* Remove normative references to RFC6979= .

Eran



On Thu, May 4, 2017= at 11:21 PM, Brian Smith <brian@briansmith.org> wrote:
Hi,

Recently I implemented RFC 6979 and also I'm implementing some CT thing= s.

Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA
signatures. However, the requirement to use RFC 6979 is problematic
for several reasons, noted below. I think this group should reconsider
if the fingerprinting threat that motivated the requirement for
deterministic signatures is significant enough to overcome these
problems.

If the requirement for deterministic signatures were removed, all the
problems below would be resolved. (Additionally the more secure
RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1
1.5.)

If it is still seen as very important to require signatures be
deterministic, the requirement to to use specifically RFC 6979 should
be be removed, and replaced with a more general requirement to use
*some* secure deterministic nonce for ECDSA signatures, without
mandating RFC 6979 specifically.

Here are the problems I see with mandating the use of RFC 6979:

1. RFC 6979 deterministic signatures are not and cannot be compliant
with FIPS and other regulations. This means, in particular, that a log
cannot use the same CABForum-compliant (HSM) ECDSA implementation that
it could use to sign certificates.

2. RFC 6979 is a very inefficient way of generating deterministic
signatures. Every RFC 6979 signature requires invoking the SHA-256
compression function 19 to 22 times. The BitCoin core developers
reported that this takes 10% of total signature generation time. [0]

3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for
ECDSA. This is a step backward from recent progress towards provable
security of internet protocols.

4. Because of #1, #2, and #3, most crypto libraries and HSM
implementations would be better off using a different deterministic
signature scheme (such as a variant of the much more efficient one
used for Ed25519). And/or they may use a different, non-deterministic,
solution to the concerns that originally motivated the creation of RFC
6979 in the first place, such as the one that Google's BoringSSL [1] and Cisco [2] have implemented. If one is going to use a better
scheme, then maintaining RFC 6979 support too just for this one
protocol is a large burden.

5. There is no way to check that the log actually used RFC 6979, or
any other specific secure deterministic scheme, because part of
calculating the nonce involves hashing the private key. Thus the
requirement to use RFC 6979 is unenforceable technically or even by
policy.

[0] https://crypto.stackexchange.com/a/42551 (I can= 't find the
original citation for what the Bitcoin people said.)
[1] https://b= oringssl.googlesource.com/boringssl/+/783e0957875ac62b35aa4f87410= 69e133695a3d4
[2] https://blogs.cisco.com/security/fips-and-deterministic-ec= dsa-achieving-robust-security-and-conformance

Cheers,
Brian
--
ht= tps://briansmith.org/

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

--001a113dfdaea7f7a4054ec3276f-- From nobody Fri May 5 10:09:14 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BA0127863 for ; Fri, 5 May 2017 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 f8KOKB8uPr0i for ; Fri, 5 May 2017 10:09:12 -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 E19B7124234 for ; Fri, 5 May 2017 10:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494004151; bh=ANr05lC+C+baomsbxoVKjgP7f41BDdwaUUn/jn4reZs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=BKcIElGt1ieTNAuEP4H5nJbBvAEiBT/E1BJGoykH+MsFhb+T2WX0eRw4jpr7gNNO+ MhwRc00tGWuG0tksl+jkonv0Aho+/hdhKsABrMS9oABBHEn3DlW38aLjbZt7Wy1mPe ehnBvHzrhOiwj3jQcRKrLA4bdIcpNxVnV5s8iKcPOWKYPzjp9v7euhtUR3DieaafgQ dQ/HHW25dby4aYb816VreSdcj4K2eEMlDbCwH0OFl/NXVPl+vJzh2k1XNZwVukyXdJ o6LmMYYRQ9BNrU569IzRvUmr/mgmbNUL5jBTnT2V1yiQhrGErpKbodV6F+J+6CYGYe PuB8+jsW9Zufg== Date: Fri, 5 May 2017 10:09:10 -0700 From: Andrew Ayer To: Nick Sullivan Cc: Eran Messeri , "trans@ietf.org" Message-Id: <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> In-Reply-To: References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 05 May 2017 17:09:13 -0000 On Thu, 04 May 2017 20:58:16 +0000 Nick Sullivan wrote: > By consistent I mean that if a sequence of STHs such as (A, B, C) are > presented on day 1, that a different sequence is not presented on day > 2 (A, C) or (A, D, B, C). The PR doesn't currently say the log must retain and return all STHs it has ever signed. That should be added. Such language, plus the existing chronological ordering requirement, plus the requirement that STH timestamps be unique ("Each subsequent timestamp MUST be more recent than the timestamp of the previous update") should ensure consistency, right? > Rob's language works in term of chronological order. > > STH pollination could be a way to support auditing this, but I don't > think it's sufficiently robust as currently defined. To prevent STHs > from going missing, or for new STHs to appear after the fact, STHs > should be exchanged along with metadata indicating the previous and > (if it exists yet) the next STH in the tree. To be an effective auditing mechanism, this information needs to be signed by the log. Otherwise, a monitor could lie about what it has seen. Perhaps the STH could contain the timestamp of the previous STH. If it did, I believe that STH pollination would be sufficient for detecting STHs that go missing or appear after the fact. That said, is there a compelling security need for this to be auditable? Regards, Andrew From nobody Fri May 5 10: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 F1627129ACD for ; Fri, 5 May 2017 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPP8iMVXV8OC; Fri, 5 May 2017 10:31:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2E3129527; Fri, 5 May 2017 10:31:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 17:31:51 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:7 Message-ID: <037.49ca9c7967349aac04eff70864ad46aa@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:31:52 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 12:39: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 78FC112940C for ; Fri, 5 May 2017 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 6g67qJV_6F9r for ; Fri, 5 May 2017 12:39:38 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 CA7CD12878D for ; Fri, 5 May 2017 12:39:38 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id x188so14456484itb.0 for ; Fri, 05 May 2017 12:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EsFouX9mffJyHVJ+uLv7eVWuiVc05sMwSbX/oeH07k4=; b=Fc6DNKMyiz7Csh/YSmQjRiS35T/zgnqCBKtQwealIQ8HcFJMDmxI2O4pkDg4m/wsWm JniJKh2a04r0jNkGxkGKQZW11nez/y+WNt29cGDrUx9ig7ZKSLG4S92oym9DQyyhlZ41 fjgDxugrhD5CPhh7zixfTEtMBGsWBjIpEnP1/QDCLhuCrS9IPefsgOM8XWvwTpqdDKAe jnfE7qyQsLmQD3UlqgoqyvBmkKlkwIyr/8IQracssmUYntz2RZfYBu884UF5tZJqWsKv HPEkIN/JsjnSp8wS3oSN8Vf5NQYAwUZl2zr8gaelxBdbF5X2XVqHAT/ABywdtLsTu09g zXAQ== 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=EsFouX9mffJyHVJ+uLv7eVWuiVc05sMwSbX/oeH07k4=; b=O1Q0i4CY83dhXZ7f+LlZ2F4FIEQcpebuRwnD1NQQkmF0DMzhjt4CezLLZiRkY1vUMK o1mIe9ANnnchJGvIAMa7kocfmPf/2wItPCG6bo3VYyuR/LBiBaUjkWn7zHK8t/zwJc6j 1cFZ05ukzGzQPStpat/D4M4DTNmFLRhmfbqOsINKg7q6jiqysA472WyoAjrMqn0kjSVw 7v3SnMot/Ifgkb4oIgVWflJNHnbDgt6KnssgHhJIk3wuNfjbmPIyTbnsEqyv63cEBKt6 GqLkdq8ezGsK7+MdvaZ6Jf5NnYGtx95ArMaizJ/p/gFduOlLcSK1UnlgxKVJe7FZASf5 ND/g== X-Gm-Message-State: AN3rC/4i3ElJgfnLBfOoCyjemvEwop5+p/w7R0XDdTbNC+uRYGB+32V6 6XvRfKyn2rDR+dNOp8B5352gcfeajUav X-Received: by 10.36.124.85 with SMTP id a82mr10284941itd.90.1494013177969; Fri, 05 May 2017 12:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Fri, 5 May 2017 12:39:37 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Fri, 5 May 2017 09:39:37 -1000 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 05 May 2017 19:39:40 -0000 On Thu, May 4, 2017 at 12:21 PM, Brian Smith wrote: > [0] https://crypto.stackexchange.com/a/42551 (I can't find the > original citation for what the Bitcoin people said.) I found it: https://bitcoin.stackexchange.com/questions/36127/problems-with-deterministic-ecdsa-based-on-rfc6979-in-bitcoin#comment42214_36142 Cheers, Brian -- https://briansmith.org/ From nobody Fri May 5 13: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 6FB3E12946B for ; Fri, 5 May 2017 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAZQXTVH-2Wi; Fri, 5 May 2017 13:59:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E69B712940C; Fri, 5 May 2017 13:59:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 20:59:05 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/163#comment:6 Message-ID: <037.c8c94454999ae7c7cba863b4aa06f165@ietf.org> References: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <022.7da86585e9c171aeb8d893a2431c2e8c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #163: The entire STH history of the log must be accessible X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:59:08 -0000 #163: The entire STH history of the log must be accessible -------------------------+------------------------ Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by melinda.shore@…): * status: assigned => closed * resolution: => duplicate -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 13:59: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 2A56D129442 for ; Fri, 5 May 2017 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VUUWJaw5Vo3; Fri, 5 May 2017 13:59:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28735128954; Fri, 5 May 2017 13:59:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 20:59:53 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/165#comment:4 Message-ID: <037.137c297fbc84085056d638a4b289f938@ietf.org> References: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> X-Trac-Ticket-ID: 165 In-Reply-To: <022.e77409e82bb9951734c10818ffd3332b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #165: Remove unnecessary operational restrictions on logs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:59:54 -0000 #165: Remove unnecessary operational restrictions on logs ---------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:00: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 2022812940C for ; Fri, 5 May 2017 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ9WCObf1ZuJ; Fri, 5 May 2017 14:00:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6512869B; Fri, 5 May 2017 14:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:00:52 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/168#comment:5 Message-ID: <037.81e946ecf7151f8394a3c42827379fbd@ietf.org> References: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> X-Trac-Ticket-ID: 168 In-Reply-To: <022.bbbc4614e7927a8abba43a48732d9c6a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #168: Remove STH from `get-entries` response X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:00:53 -0000 #168: Remove STH from `get-entries` response ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => wontfix -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:02: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 058DE12940C for ; Fri, 5 May 2017 14:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkMYoIzVTMvl; Fri, 5 May 2017 14:02:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D52B128B44; Fri, 5 May 2017 14:02:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:02:14 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/169#comment:4 Message-ID: <037.01be2577d1086b20eaf2b91b9849091f@ietf.org> References: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> X-Trac-Ticket-ID: 169 In-Reply-To: <022.49cb2ce48e6c69ea03e9be8fdc15b66c@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #169: Don't guess at STHs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:02:15 -0000 #169: Don't guess at STHs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => wontfix -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:03: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 360A0128B44 for ; Fri, 5 May 2017 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUJSeRXWS7D2; Fri, 5 May 2017 14:03:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5115712869B; Fri, 5 May 2017 14:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:03:13 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/171#comment:4 Message-ID: <037.7114d5bdb2367526b1d2d32ee4fe9dc3@ietf.org> References: <022.557823a822995bf0907de0140512b193@ietf.org> X-Trac-Ticket-ID: 171 In-Reply-To: <022.557823a822995bf0907de0140512b193@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #171: Simplify Log IDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:03:14 -0000 #171: Simplify Log IDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: to-be-decided | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => wontfix -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:03: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 1B84512869B for ; Fri, 5 May 2017 14:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg84Vw3aA8ec; Fri, 5 May 2017 14:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 386D71272E1; Fri, 5 May 2017 14:03:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:03:50 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/172#comment:4 Message-ID: <037.c392f073b89e7e9772c1aba0e5949ae8@ietf.org> References: <022.a3303d909c1e68dc720d7e9303056408@ietf.org> X-Trac-Ticket-ID: 172 In-Reply-To: <022.a3303d909c1e68dc720d7e9303056408@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #172: Pick one structure for multiple TransItems X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:03:51 -0000 #172: Pick one structure for multiple TransItems -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:04: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 D59E212869B for ; Fri, 5 May 2017 14:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VimO9p1tRInp; Fri, 5 May 2017 14:04:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F407F1272E1; Fri, 5 May 2017 14:04:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:04:23 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/173#comment:4 Message-ID: <037.919272fa3eabde8300ad56069a55c61a@ietf.org> References: <022.56595096787251f10de4ef011cf00142@ietf.org> X-Trac-Ticket-ID: 173 In-Reply-To: <022.56595096787251f10de4ef011cf00142@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #173: De-duplicate Extension types X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:04:25 -0000 #173: De-duplicate Extension types -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:05: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 47C1C129413 for ; Fri, 5 May 2017 14:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C9BccnE-z4t; Fri, 5 May 2017 14:05:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ED01272E1; Fri, 5 May 2017 14:05:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:05:02 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/180#comment:4 Message-ID: <037.c410909ebfcc7a2ad228f1918308c4cc@ietf.org> References: <022.fbeed8d444d177069bcee6293bf51e4a@ietf.org> X-Trac-Ticket-ID: 180 In-Reply-To: <022.fbeed8d444d177069bcee6293bf51e4a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #180: Consolidate all Merkle tree data formats and computations X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:05:03 -0000 #180: Consolidate all Merkle tree data formats and computations -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:05: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 9BC85129480 for ; Fri, 5 May 2017 14:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt2Juj3Cj8m4; Fri, 5 May 2017 14:05:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BF412869B; Fri, 5 May 2017 14:05:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:05:54 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/183#comment:4 Message-ID: <037.2776dd443403eae4c134d39397a76308@ietf.org> References: <022.295eae2746f71208d1209aa6a1a3dfbd@ietf.org> X-Trac-Ticket-ID: 183 In-Reply-To: <022.295eae2746f71208d1209aa6a1a3dfbd@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #183: Don't violate the TLS Feature extension definition X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:05:56 -0000 #183: Don't violate the TLS Feature extension definition -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:07: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 D2FD2129413 for ; Fri, 5 May 2017 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuEc806ZhXaZ; Fri, 5 May 2017 14:07:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0386D12869B; Fri, 5 May 2017 14:07:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:07:47 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/185#comment:5 Message-ID: <037.44db19995efda60e74809677bfa610e3@ietf.org> References: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #185: Don't violate BCP 190 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:07:48 -0000 #185: Don't violate BCP 190 -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:08: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 CF617128990 for ; Fri, 5 May 2017 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWL0iOJCh5eZ; Fri, 5 May 2017 14:08:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 265D2126BF0; Fri, 5 May 2017 14:08:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:08:45 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/185#comment:6 Message-ID: <037.57c533aa8f1992bf4487e1f32518fedd@ietf.org> References: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> X-Trac-Ticket-ID: 185 In-Reply-To: <022.1fa1b00308285582a13c8034f9ee16f4@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #185: Don't violate BCP 190 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:08:46 -0000 #185: Don't violate BCP 190 -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Comment (by melinda.shore@…): (Note that this isn't "fixed" in the sense that the protocol has not changed, but that some explanatory text has been added to the document) -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:09: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 B848512869B for ; Fri, 5 May 2017 14:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJKEFl2Jjka8; Fri, 5 May 2017 14:09:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0336126BF0; Fri, 5 May 2017 14:09:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:09:29 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/166#comment:3 Message-ID: <037.d27f1f5ac10292bdc74ca11249ac1167@ietf.org> References: <022.61b128bf9fd19c4d2718fedd21bde6a4@ietf.org> X-Trac-Ticket-ID: 166 In-Reply-To: <022.61b128bf9fd19c4d2718fedd21bde6a4@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #166: State the log parameters in the section that defines a log X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:09:31 -0000 #166: State the log parameters in the section that defines a log -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:10:06 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 510C0129480 for ; Fri, 5 May 2017 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KztHEEeDDJeb; Fri, 5 May 2017 14:10:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23844126BF0; Fri, 5 May 2017 14:10:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 05 May 2017 21:10:04 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/186#comment:3 Message-ID: <037.1c3441a3a428588f34c23652571be8e1@ietf.org> References: <022.94d31db1d9862800877b119c11cca767@ietf.org> X-Trac-Ticket-ID: 186 In-Reply-To: <022.94d31db1d9862800877b119c11cca767@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #186: Add a registry for error codes X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:10:05 -0000 #186: Add a registry for error codes -------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: minor | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+--------------------------------------------- Changes (by melinda.shore@…): * status: new => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 5 14:16: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 E092E12778D for ; Fri, 5 May 2017 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFktzq_89odE for ; Fri, 5 May 2017 14:16:11 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 1A404124BFA for ; Fri, 5 May 2017 14:16:11 -0700 (PDT) Received: (qmail 23585 invoked by uid 1004); 5 May 2017 21:16:09 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 05 May 2017 22:16:09 +0100 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 201705052216091636; Fri, 05 May 2017 22:16:09 +0100 To: Brian Smith , "trans@ietf.org" References: From: Rob Stradling Message-ID: Date: Fri, 5 May 2017 22:16:08 +0100 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 05 May 2017 21:16:15 -0000 On 04/05/17 23:21, Brian Smith wrote: > 4. Because of #1, #2, and #3, most crypto libraries and HSM > implementations would be better off using a different deterministic > signature scheme (such as a variant of the much more efficient one > used for Ed25519). Given that RFC8032 has been published and we're still working 6962-bis... Would it be a good idea to add Ed25519 to the initial list of permitted signature algorithms that logs can use? https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-24#section-10.4 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri May 5 14:48: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 80022126BF7 for ; Fri, 5 May 2017 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tALnFQuSLCr for ; Fri, 5 May 2017 14:48:08 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 67F4D126BF0 for ; Fri, 5 May 2017 14:48:08 -0700 (PDT) Received: (qmail 26079 invoked by uid 1004); 5 May 2017 21:48:05 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 05 May 2017 22:48:05 +0100 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 201705052248059772; Fri, 05 May 2017 22:48:05 +0100 To: Eran Messeri , Andrew Ayer References: <20170504082633.81f2ce21509fc2268005dff4@andrewayer.name> Cc: "trans@ietf.org" From: Rob Stradling Message-ID: <706a2e3d-1bd3-db6e-bc27-57210e6d7032@comodo.com> Date: Fri, 5 May 2017 22:48:04 +0100 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Ticket 179 - moving Cert/Precert indicator into the data structure 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, 05 May 2017 21:48:10 -0000 On 04/05/17 17:17, Eran Messeri wrote: > Rob, who undertook this non-trivial change, may have a more complete > context. This was the (non-trivial!) change... https://github.com/google/certificate-transparency-rfcs/pull/89 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri May 5 18:22: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 B9564127077 for ; Fri, 5 May 2017 18:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 uKU8pylKlshU for ; Fri, 5 May 2017 18:21:56 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 44379126D05 for ; Fri, 5 May 2017 18:21:56 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id k91so25266977ioi.1 for ; Fri, 05 May 2017 18:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aLk5XUCoI/+TDGxWVer/QuNYyYj6K8MunXM0A/187tA=; b=H/yc2ciHQtHW9uZJSv5hSpMvzQ6uL/krdygCIqK7rCiJcOaA5xk12msLgj4CzFbBiB 5A+QBviperH14pI7jmmlGBbzKjcuUuNu6AvpXJW2lXJEptZV2abMlVX8wkfSmBniJ5t1 SSUsyO8GGF11Zfq3gS25nFyYApKgjUZscQvN1KdMenfBgZmywOwm9cTaBy2FQqHnpnv/ rBy/wPSJ30t2Q+bskBuqyTHWpxfgbDwaqKfuSJ9vfmvM+c0HZFLXjiX4Ja6qQ4v4qTZI WNbYXMogIfWiOeTgOmBFuZxe4JZcAo9auNAmAnZLVYYTV7AvWB7WLQIZ0M1V2lfhrsT8 FwSA== 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=aLk5XUCoI/+TDGxWVer/QuNYyYj6K8MunXM0A/187tA=; b=QymW6DkowcnI9PK/yj1TsbrvSTdg9fcN6SDrNin8h8lLEVADMSfLnHhefZBgo2OZ2j fpIq4p7o4xszDlDfkMrI9ZKCimsW4vKVBtboG+VpnbRI6fmT0k4rcirn7t7PsCgO1ywA NfJ9ROsOgPYPoNq410Wh240ftlk6llZImCgoihIZ12RZnPceWowqsFANZ70xxd2be4A1 qMab6yY3iMbt7NOiVhLr13kIWTag1OK+QvV3rXuyrbhqnHrfgMq9vTUdMHC2Pw+cDjrw GEi8rmWw/f5XX2X4Sq17Z7gNjph7VuTPsxXWLgNiDAsZa+pWR44VFxYZxzPlHxTDmrkO V8Dg== X-Gm-Message-State: AN3rC/4qIASkqXOZgvZWUkAugMcBlpxicwAhO3HqKYwYdmmbolfNVoTU KPwGxGTBdZodDVG+5/PuP3jNgIsHHA== X-Received: by 10.107.50.136 with SMTP id y130mr59243063ioy.152.1494033715629; Fri, 05 May 2017 18:21:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Fri, 5 May 2017 18:21:55 -0700 (PDT) In-Reply-To: References: From: Brian Smith Date: Fri, 5 May 2017 15:21:55 -1000 Message-ID: To: Paul Hadfield Cc: Eran Messeri , "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 06 May 2017 01:22:07 -0000 On Thu, May 4, 2017 at 3:01 AM, Paul Hadfield wrote: > Without this API, CT Monitors that ingest a log's entries from STHm to STHn > (n>m) could incorrectly identify an MMD violation, as it is possible for > them to have missed an STH that sits between m and n. Wouldn't this require the monitor to know what time the claimed in-between STH was generated? Cheers, Brian -- https://briansmith.org/ From nobody Mon May 8 05:41:14 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0212945F for ; Mon, 8 May 2017 05:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_40=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYxr9cR9gqv0; Mon, 8 May 2017 05:41:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A65012945B; Mon, 8 May 2017 05:41:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 08 May 2017 12:41:12 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:8 Message-ID: <037.d6b26f2de114db039d864cd32e7bba4f@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 12:41:13 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: reopened Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * status: closed => reopened * resolution: fixed => * milestone: review => Comment: My bad - that has not been resolved yet and the PR not actually merged. Reverting resolution. Andrew Ayer objected to that, in https://www.ietf.org/mail- archive/web/trans/current/msg02874.html, I'll follow up with him to better understand the objection and we'll bring it back to the list once we have a clear suggestion. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon May 8 09:31: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 B1798129510 for ; Mon, 8 May 2017 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_05=-0.5, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SORUGoMR5xkg; Mon, 8 May 2017 09:30:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90643129502; Mon, 8 May 2017 09:30:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 08 May 2017 16:30:51 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/182#comment:5 Message-ID: <037.1dd1cb36332c24642290c4532cb2a240@ietf.org> References: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #182: Clarify notation in the Merkle tree section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 16:30:54 -0000 #182: Clarify notation in the Merkle tree section -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Comment (by eranm@…): A follow-up PR is out: https://github.com/google/certificate-transparency-rfcs/pull/251 It'd get too messy to merge Richard's original PR and incorporate Ben's comments in a follow-up commit, so I've merged it all to a new PR. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon May 8 10:39: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 D162A127B31 for ; Mon, 8 May 2017 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEMv__f7DN7H for ; Mon, 8 May 2017 10:39:07 -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 DFC04126FDC for ; Mon, 8 May 2017 10:39:06 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id t26so40477640qtg.0 for ; Mon, 08 May 2017 10:39:06 -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; bh=v1mwvWA/Xbnp6uHhcikJShLWQ3ikXNxbQO2Bf+19BEw=; b=RIojuXtRGAxlN/q64zZQgqilL9unfCUTnAgpXrYYHpb9UNbdNnHXfSzz+cyv3cc+fT 8ef2svzClfLtnw6tp0ynBTSa48k6H4VeyjfHNguuyoYazhQLrAodB9wj5Ts78QHuEjeM Qf5pRak6RFRfKA5O3s3+af4gxp1xZKsLSL2WM= 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=v1mwvWA/Xbnp6uHhcikJShLWQ3ikXNxbQO2Bf+19BEw=; b=CE92/YkVLUmkV3bJMOxacnifXAIAu4qMx3OTURnzzB1jJ7gpG3Ze+wkKSfSjKa2hpt PFE/8F7X1Qse1azlqX6tKjn2rT2ng6DRQfVsr/ihDyWPco3OQ0+QJspd5XrpfiHrFaj9 hxMs73h+jMx6VWj9qOckEqi8mwJXbaopljMYakKP4PSJ1b8mXc3SjBG2ih3eL5Ow5DOv hXlaTN8U5sISZ4VQHH0Kg9ZrI5FnMKregP+NjqKluW4fsHmljkzYWmn/0nKKfIYrii/D IeBlmfT3HRKiCv95l6kajGJT8Yv6HK3/78udsaIOA36434Kz8teH2EcPx9dbb9MN7d60 mctA== X-Gm-Message-State: AN3rC/72X36iN8deLd7iW66Bw13vJ/m3pRMX1YeDskeeD8NeFA3PkOKy y/rekgQj556tz/vlZF0l/kWfksbDqzoAKWOVoA== X-Received: by 10.237.62.200 with SMTP id o8mr23930201qtf.152.1494265145836; Mon, 08 May 2017 10:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.101.148 with HTTP; Mon, 8 May 2017 10:38:45 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Mon, 8 May 2017 12:38:45 -0500 Message-ID: To: Brian Smith Cc: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 08 May 2017 17:39:09 -0000 On 4 May 2017 at 17:21, Brian Smith wrote: > 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for > ECDSA. This is a step backward from recent progress towards provable > security of internet protocols. I just want to make sure I understand this point. Skimming the draft I gather this is because the proof of ECDSA relies on k being indistinguishable from the output of a Random Oracle? Deterministic generation of k uses HMAC_DRBG which sure looks like the ROM, but isn't (?) provably so? Assuming I understand - when you implement ECDSA you don't get to use a RO, you use a CSPRNG which also doesn't count as a RO so that probably invalidates the proof. So one assumes the CSPRNG behaves like the ROM, so why don't you just assume HMAC-DRBG behaves like the ROM and your proof is repaired! On 5 May 2017 at 04:02, Eran Messeri wrote: > I'd like to hear the opinion of people who've worked on the Gossip protocol > - as Brian said, the purpose behind deterministic signatures is to make it > difficult to fingerprint individual clients. However, the only gossip that's > taking place right now is STH exchange between monitors, where this is not a > concern, All of Brian's points are strong points. My concern with fingerprinting still stands though. While not Gossip - Google plans to resolve inclusion proofs for SCTs via DNS. The end DNS server for this is their own log mirror - but I believe this is for scaling, not privacy. If a log and server colluded to issue and serve different SCT signatures for the same SCT, there are no great options to detect it: - very complicated logic in the client - auditors performing aggressive fake-client spidering from multiple network vantage points combined with significant refactoring and data storage requirements - the SCT Feedback part of the Gossip draft combined with the auditor changes As far as the concern of this attack goes: without long-term storage of the SCT (such as that in SCT Feedback) - the impact is minimal when it comes to log+webserver-collaboration-for-tracking. But the log is still able to send different SCTs out and can do this without the server participating. With the distribution part outside the log's control it's not as effective, and more turns into a game of "I wonder what happens...". (I think.) Anyway, so I still think there's fingerprinting concerns. But even if we require deterministic signatures - if the log *wants* to be malicious, it can still issue non-deterministic signatures, and there's no way to know, because as I said above - detection is hard. So I think Eran's suggested changes are okay. -tom From nobody Mon May 8 11:11:45 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBB4128AFE for ; Mon, 8 May 2017 11:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sRP1u0Gsn5B5 for ; Mon, 8 May 2017 11:11:43 -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 69C3712896F for ; Mon, 8 May 2017 11:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494267102; bh=7TSLDuYrNrJIBmVfqaFhptMKRzYc5Y2YzyrgG6nkq/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=b3B5L4QnE2gju1Xc6cBHxR7OLn8gmrqFomarB1zdRbRiCUr74S+ExQsVexW0GrYej aYrvf5ICjm+kudhboB5CLccxsLfhZ3HDsk/MHFQsUI33W8pmsG/x0AsnVmPYCtDf0N knLqOa+mXlUjnquI5wIEDvqUwytKjCMTU6vr9QBpPYrI4AfX905lI9XvdUNDA5P4sZ DHWpLfx93wdFkl1CFQ/F0szDbdH2UC6ib5DmLTei9iFdi+OiUngO/BR8UOhxIjWWD8 wU487K4s5j64BMafIMQS37ZzsfAYLrwfy5YuX8ik0ieu3WWcqg6vvP3259IWQGYHwf OWj8vqOd5X+TA== Date: Mon, 8 May 2017 11:11:41 -0700 From: Andrew Ayer To: Brian Smith Cc: "trans@ietf.org" Message-Id: <20170508111141.2ad103252b01cf48b5e988c8@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] The RFC6979 requirement in RFC6962-bis is bad 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, 08 May 2017 18:11:44 -0000 On Thu, 4 May 2017 12:21:14 -1000 Brian Smith wrote: > Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA > signatures. However, the requirement to use RFC 6979 is problematic > for several reasons, noted below. I think this group should reconsider > if the fingerprinting threat that motivated the requirement for > deterministic signatures is significant enough to overcome these > problems. I think preventing fingerprinting is important. I suggest we loosen the requirement on logs. Logs should still be forbidden from producing more than one distinct signature for any given STH or SCT, but we shouldn't specify how logs must satisfy this requirement. Here are some of the ways a log could satisfy this requirement: 1. Use RFC 6979. 2. Use a different deterministic signature scheme. 3. When producing a new STH or SCT, sign it, store the signature, and serve the stored signature instead of re-signing on-the-fly every time the log needs to serve the STH or SCT. Since the log already needs to store information about STHs and SCTs, also storing the signature should not be burdensome. I'll also note that forbidding the log from producing more than one signature per STH makes it slightly easier for people participating in STH pollination to deduplicate STHs, as it becomes possible to deduplicate based on the entire STH rather than parsing out the non-signature parts. Regards, Andrew From nobody Mon May 8 15:46:25 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 3BF2012894A for ; Mon, 8 May 2017 15:46:24 -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 70eI56HM2XXt for ; Mon, 8 May 2017 15:46:21 -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 C75A0124BE8 for ; Mon, 8 May 2017 15:46:17 -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 v48MkBCA002804 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 00:46:11 +0200 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 v48Mk4oe004313 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 22:46:09 GMT From: Linus Nordberg To: Andrew Ayer Cc: trans@ietf.org Organization: Sunet References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> Date: Tue, 09 May 2017 00:46:11 +0200 In-Reply-To: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> (Andrew Ayer's message of "Mon, 8 May 2017 11:11:41 -0700") Message-ID: <87tw4vj7bg.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: 0aThWKbA8 - d8e70ffd8b22 - 20170509 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] The RFC6979 requirement in RFC6962-bis is bad 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, 08 May 2017 22:46:24 -0000 Andrew Ayer wrote Mon, 8 May 2017 11:11:41 -0700: > On Thu, 4 May 2017 12:21:14 -1000 > Brian Smith wrote: > >> Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA >> signatures. However, the requirement to use RFC 6979 is problematic >> for several reasons, noted below. I think this group should reconsider >> if the fingerprinting threat that motivated the requirement for >> deterministic signatures is significant enough to overcome these >> problems. > > I think preventing fingerprinting is important. I suggest we loosen > the requirement on logs. Logs should still be forbidden from producing > more than one distinct signature for any given STH or SCT, but we > shouldn't specify how logs must satisfy this requirement. +1 From nobody Mon May 8 15:54: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 1F7AE12894A for ; Mon, 8 May 2017 15:54:44 -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 wJj964F53reJ for ; Mon, 8 May 2017 15:54:42 -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 C04FA1200FC for ; Mon, 8 May 2017 15:54:41 -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 v48MsbLA004391 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 00:54:37 +0200 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 v48MsWdY000425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 22:54:36 GMT From: Linus Nordberg To: Andrew Ayer Cc: trans@ietf.org Organization: Sunet References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> Date: Tue, 09 May 2017 00:54:38 +0200 In-Reply-To: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> (Andrew Ayer's message of "Mon, 8 May 2017 11:11:41 -0700") Message-ID: <87pofjj6xd.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: 0aThWSBBV - 8eb9830fa7e7 - 20170509 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: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad) 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, 08 May 2017 22:54:44 -0000 Andrew Ayer wrote Mon, 8 May 2017 11:11:41 -0700: > 3. When producing a new STH or SCT, sign it, store the signature, and > serve the stored signature instead of re-signing on-the-fly every time > the log needs to serve the STH or SCT. Since the log already needs > to store information about STHs and SCTs, also storing the signature > should not be burdensome. Why do logs already need to store information about SCTs? Do logs already need to store information about STHs because of the proposed get-sths API [0][1][2] or something else? [0] https://trac.ietf.org/trac/trans/ticket/160 [1] https://trac.ietf.org/trac/trans/ticket/163 [2] https://github.com/google/certificate-transparency-rfcs/pull/200 From nobody Mon May 8 16:08: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 71DB2126B7F for ; Mon, 8 May 2017 16:08:41 -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 Gt4qFOZ7EbUk for ; Mon, 8 May 2017 16:08:39 -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 2BBD01200FC for ; Mon, 8 May 2017 16:08:38 -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 v48N8YNZ007080 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 01:08:35 +0200 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 v48N8TsH009054 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 23:08:34 GMT From: Linus Nordberg To: Andrew Ayer Cc: trans@ietf.org Organization: Sunet References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> Date: Tue, 09 May 2017 01:08:36 +0200 In-Reply-To: <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> (Andrew Ayer's message of "Fri, 5 May 2017 10:09:10 -0700") Message-ID: <87lgq7j6a3.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: 0aThX8yFF - 2e92e089fa6a - 20170509 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] Providing the history of STHs a log has issued (in 6962-bis) 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, 08 May 2017 23:08:41 -0000 Andrew Ayer wrote Fri, 5 May 2017 10:09:10 -0700: > On Thu, 04 May 2017 20:58:16 +0000 > Nick Sullivan wrote: > >> By consistent I mean that if a sequence of STHs such as (A, B, C) are >> presented on day 1, that a different sequence is not presented on day >> 2 (A, C) or (A, D, B, C). > > The PR doesn't currently say the log must retain and return all STHs > it has ever signed. That should be added. Such language, plus the > existing chronological ordering requirement, plus the requirement that > STH timestamps be unique ("Each subsequent timestamp MUST be more > recent than the timestamp of the previous update") should ensure > consistency, right? > >> Rob's language works in term of chronological order. >> >> STH pollination could be a way to support auditing this, but I don't >> think it's sufficiently robust as currently defined. To prevent STHs >> from going missing, or for new STHs to appear after the fact, STHs >> should be exchanged along with metadata indicating the previous and >> (if it exists yet) the next STH in the tree. > > To be an effective auditing mechanism, this information needs to be > signed by the log. Otherwise, a monitor could lie about what it has > seen. Perhaps the STH could contain the timestamp of the previous > STH. If it did, I believe that STH pollination would be sufficient for > detecting STHs that go missing or appear after the fact. > > That said, is there a compelling security need for this to be > auditable? I'm probably missing something crucial here but if it's not auditable, what use does it have? It seems to me that you're transcending towards a log of STHs, which I wouldn't mind thinking about but probably not as an ad-hoc addon to a new get-sths API. For the record, I'd like to express hesitance about adding an STH history API until I understand the problem better, with apologies for not being fully up to speed at the moment. From nobody Mon May 8 16:14: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 7F6DB127078 for ; Mon, 8 May 2017 16:14:45 -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 KLfxUXh3E-Bh for ; Mon, 8 May 2017 16:14:44 -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 AD66B1200FC for ; Mon, 8 May 2017 16:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494285284; bh=/GXudZUz232J7avUeCTjt3REg2/5V5QrEokxdHsmZv0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gOLzgpV7R2mLmkIOJm4/0iRe7zPre8k/csrylIfOqy9Ptew9ZC4S8d7kf96V2HF3F 5gvj1a8qIIuCBiX+OVrrZoOyFL32EJFn8wQgxbcZJSCT8M3pgEdzxYu/Cp9nEEIm3b zCB+QbqsuHHnkGLZbAkfl2dhMHVkLYD8qbWZ5hpmN7k+jqjCfSTwFKlswX7eV3Pmg5 wMzqR9a3SmCYiiTGlO8dNa/TeFXZWWM2FO/+f0ibZudQuTYnxtrlbAe5MFN9rEi1ub tWQEltXx7DVvEnfgUfAYXNrpNt99M/05JSksxhdnETWPvTz1f4lBmunWFV3a6TMI3u f8MYre30ndgDg== Date: Mon, 8 May 2017 16:14:43 -0700 From: Andrew Ayer To: Linus Nordberg Cc: trans@ietf.org Message-Id: <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> In-Reply-To: <87pofjj6xd.fsf_-_@nordberg.se> References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> <87pofjj6xd.fsf_-_@nordberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad) 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, 08 May 2017 23:14:45 -0000 On Tue, 09 May 2017 00:54:38 +0200 Linus Nordberg wrote: > Andrew Ayer wrote > Mon, 8 May 2017 11:11:41 -0700: > > > 3. When producing a new STH or SCT, sign it, store the signature, > > and serve the stored signature instead of re-signing on-the-fly > > every time the log needs to serve the STH or SCT. Since the log > > already needs to store information about STHs and SCTs, also > > storing the signature should not be burdensome. > > Why do logs already need to store information about SCTs? Technically it's not required, but practically speaking logs need to return an SCT for an existing entry when someone submits an already-logged certificate (otherwise the log could be spammed into oblivion). To construct that SCT, the log needs to know the timestamp of the existing entry. A logical place to store the signature would be alongside the timestamp. > Do logs already need to store information about STHs because of the > proposed get-sths API [0][1][2] or something else? Even without the get-sths API, the log needs to store the timestamp of the current STH. That would be a logical place to store the signature. Regards, Andrew From nobody Mon May 8 16:32: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 51C5012894A for ; Mon, 8 May 2017 16:32:37 -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 IMzAABDK3Nrb for ; Mon, 8 May 2017 16:32:35 -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 EC13F1200FC for ; Mon, 8 May 2017 16:32: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 v48NWTjH011324 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 01:32:30 +0200 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 v48NWOiK000426 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 May 2017 23:32:29 GMT From: Linus Nordberg To: Andrew Ayer Cc: trans@ietf.org Organization: Sunet References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> <87pofjj6xd.fsf_-_@nordberg.se> <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> Date: Tue, 09 May 2017 01:32:31 +0200 In-Reply-To: <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> (Andrew Ayer's message of "Mon, 8 May 2017 16:14:43 -0700") Message-ID: <87h90ukjqo.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: 0aThXwtKg - 6e5fff42fc9b - 20170509 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] What logs are storing 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, 08 May 2017 23:32:37 -0000 Andrew Ayer wrote Mon, 8 May 2017 16:14:43 -0700: > On Tue, 09 May 2017 00:54:38 +0200 > Linus Nordberg wrote: > >> Andrew Ayer wrote >> Mon, 8 May 2017 11:11:41 -0700: >> >> > 3. When producing a new STH or SCT, sign it, store the signature, >> > and serve the stored signature instead of re-signing on-the-fly >> > every time the log needs to serve the STH or SCT. Since the log >> > already needs to store information about STHs and SCTs, also >> > storing the signature should not be burdensome. >> >> Why do logs already need to store information about SCTs? > > Technically it's not required, but practically speaking logs need to > return an SCT for an existing entry when someone submits an > already-logged certificate (otherwise the log could be spammed into > oblivion). To construct that SCT, the log needs to know the timestamp > of the existing entry. A logical place to store the signature would be > alongside the timestamp. Ah, I see the confusion. I view the SCT as the data sent as a response to an add-chain request, not the various parts it's being made of. Storing the timestamp together with the cert chain makes a lot of sense. Caching the signature as well is a different thing. (On a side note, our log implementation has recently started mandating caching of SCTs at frontend nodes in order to protect against a "dropping-entries-attack" by a rogue frontend.) >> Do logs already need to store information about STHs because of the >> proposed get-sths API [0][1][2] or something else? > > Even without the get-sths API, the log needs to store the timestamp of > the current STH. That would be a logical place to store the signature. Right. Storing information about the _current_ STH is useful, agreed. From nobody Tue May 9 01:03: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 D1CA8129B29 for ; Tue, 9 May 2017 01:03:10 -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 hf3otHz6dat1 for ; Tue, 9 May 2017 01:03:08 -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 4BDB9120046 for ; Tue, 9 May 2017 01:03:07 -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 v49832vV010579 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 10:03:03 +0200 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 v4982xe5016076 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 08:03:02 GMT From: Linus Nordberg To: Rob Stradling Cc: trans@ietf.org Organization: Sunet References: Date: Tue, 09 May 2017 10:03:06 +0200 In-Reply-To: (Rob Stradling's message of "Fri, 5 May 2017 22:16:08 +0100") Message-ID: <87wp9qihj9.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: 0aTi832Fn - 07c56d5cf2c0 - 20170509 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] The RFC6979 requirement in RFC6962-bis is bad 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, 09 May 2017 08:03:11 -0000 Rob Stradling wrote Fri, 5 May 2017 22:16:08 +0100: > Would it be a good idea to add Ed25519 to the initial list of > permitted signature algorithms that logs can use? I think it would. From nobody Tue May 9 01:54: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 21501127B5A for ; Tue, 9 May 2017 01:54:01 -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 uLeptYhMGEVb for ; Tue, 9 May 2017 01:53:58 -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 8DD951243FE for ; Tue, 9 May 2017 01:53:58 -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 v498rtVO000703 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 10:53:55 +0200 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 v498rq42017386 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 08:53:55 GMT From: Linus Nordberg To: Tom Ritter Cc: trans@ietf.org Organization: Sunet References: Date: Tue, 09 May 2017 10:53:59 +0200 In-Reply-To: (Tom Ritter's message of "Mon, 8 May 2017 12:38:45 -0500") Message-ID: <87pofiif6g.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: 0aTi8RTPA - bad6f2f0d24b - 20170509 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] The RFC6979 requirement in RFC6962-bis is bad 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, 09 May 2017 08:54:01 -0000 Tom Ritter wrote Mon, 8 May 2017 12:38:45 -0500: > Anyway, so I still think there's fingerprinting concerns. But even if > we require deterministic signatures - if the log *wants* to be > malicious, it can still issue non-deterministic signatures, and > there's no way to know, because as I said above - detection is hard. You seem to focus on SCTs, which are indeed hard to share between privacy concerned clients because they contain sensitive data. But STHs have signatures too and I think we should limit the ways a log can track clients asking for STHs. Catching a log serving different log clients different bits for the same timestamp, tree_size and root_hash is a matter of clients comparing retrieved STHs. Keeping the requirement for deterministic signatures and the limitation on STH issuance frequency (6962bis-24 4.8) makes gossiping about STHs reasonable even for clients serving end users with privacy expectations (gossip-04 10.5.4). > So I think Eran's suggested changes are okay. I think we should keep requiring deterministic signatures being used but stop mandating how it is being done. From nobody Tue May 9 01:56: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 A065A129407 for ; Tue, 9 May 2017 01:56:54 -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 thJPqK03Vib5 for ; Tue, 9 May 2017 01:56:53 -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 11BC6127B5A for ; Tue, 9 May 2017 01:56:52 -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 v498uouT001876 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 10:56:50 +0200 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 v498uldg020365 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 May 2017 08:56:50 GMT From: Linus Nordberg To: Brian Smith Cc: trans@ietf.org Organization: Sunet References: Date: Tue, 09 May 2017 10:56:54 +0200 In-Reply-To: (Brian Smith's message of "Thu, 4 May 2017 12:21:14 -1000") Message-ID: <87lgq6if1l.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: 0aTi8UOT5 - 9c0d229af7a7 - 20170509 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] The RFC6979 requirement in RFC6962-bis is bad 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, 09 May 2017 08:56:55 -0000 Brian Smith wrote Thu, 4 May 2017 12:21:14 -1000: > 1. RFC 6979 deterministic signatures are not and cannot be compliant > with FIPS and other regulations. This means, in particular, that a log > cannot use the same CABForum-compliant (HSM) ECDSA implementation that > it could use to sign certificates. I'm going to expose my lack of knowledge of FIPS and ask why. What makes RFC 6979 signatures unable to comply with FIPS? From nobody Tue May 9 03:35:06 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 0E30F129BD7 for ; Tue, 9 May 2017 03:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCg6Tii2knhF; Tue, 9 May 2017 03:35:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAF6129BC5; Tue, 9 May 2017 03:35:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 10:35:04 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/182#comment:6 Message-ID: <037.db31b8c4f2936d4e2398a71fb96636a0@ietf.org> References: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #182: Clarify notation in the Merkle tree section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 10:35:05 -0000 #182: Clarify notation in the Merkle tree section -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: Merged - please review. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 04:22: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 A0571129C03 for ; Tue, 9 May 2017 04:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHokEeC2xudQ; Tue, 9 May 2017 04:21:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A469D1201FA; Tue, 9 May 2017 04:21:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 11:21:59 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/170#comment:2 Message-ID: <037.e20821597edbafb14dff420740784189@ietf.org> References: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 11:22:01 -0000 #170: Allow for separate SCT and STH keys? -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis * milestone: => review Comment: I agree with the analysis that the keys used for signing SCTs and STHs do not have to be the same. However, I'm not sure there's value in allowing that, and it does incur added cost. In theory it allows for separate security domains between the front-end and the signer. But I’d argue that as a log operator, that doesn’t buy us much because the signer is not tied to a single datacenter / HSM. The signing "role" migrates between jobs at different datacenters (for resiliency). Additionally, the key separation would be completely unnecessary if we ever build a log with immediate incorporation, where a signer is not necessary since sequencing of entries (and STH production) is done for each submission. As Richard points out, compromise of either keys has the same implications. It does complicates the client implementation: Client now has to keep two keys for the log instead of one. So I suggest closing this as wontfix. We can mention the option somewhere in the document, but currently I don't see the need. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 05:53: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 5BD5C129463 for ; Tue, 9 May 2017 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW4FjZcn6Hcr; Tue, 9 May 2017 05:53:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6D412943D; Tue, 9 May 2017 05:53:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 12:53:57 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/187#comment:6 Message-ID: <037.342c05f1b02f5fb95c62c64964493702@ietf.org> References: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <022.c3d45294c9d7b2fba48a28d9523aa926@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #187: Use IANA-managed OIDs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 12:53:58 -0000 #187: Use IANA-managed OIDs ---------------------------+--------------------------------------------- Reporter: rlb@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: defect | Status: closed Priority: major | Milestone: Component: to-be-decided | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+--------------------------------------------- Comment (by rob.stradling@…): Replying to [comment:3 rob.stradling@…]: > OIDs from the 1.3.101 arc are also being used by the CURDLE WG in draft- ietf-curdle-pkix. > > Rich Salz mentioned that "Work is in progress to turn the arc over to IETF / IANA / someone-like-us." [1] See this I-D: https://datatracker.ietf.org/doc/draft-schaad-curdle-oid-registry Should TRANS produce a similar document for the OIDs under the 1.3.101 arc that we're using? -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 06:32: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 984D5129B82 for ; Tue, 9 May 2017 06:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbflPabr8UsA; Tue, 9 May 2017 06:32:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0F312944B; Tue, 9 May 2017 06:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 13:32:36 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/170#comment:3 Message-ID: <037.ebb778ccc78e52dac71c39e8b73f37fb@ietf.org> References: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:32:37 -0000 #170: Allow for separate SCT and STH keys? -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Comment (by linus@…): As a log implementer and log operator I'd like to express support for the idea of using separate keys for signing SCTs and STHs. In an architecture where the log owner can delegate //some// power to other organisations for operating frontend nodes by allowing frontend nodes to sign SCTs but not STHs, this would lower the risk of "full takeover" of a log. While there certainly are attacks that can be performed by an adversary capable of producing either SCTs //or// STHs I think there are also attacks that require that //both// SCTs and STHs can be signed. Note that the threat is not limited to an adversary getting hold of a copy of key material but also includes the capability of having SCTs and STHs signed by a signing service. I mention this because the design and implementation of such signing services would be less complex if they didn't have to deal with multiple keys and roles for these keys. While I disagree with the stated lack of benefit I do agree that there is a cost in client implementation and also in overall complexity of the system. I think that the benefit outweigh the cost but would like to hear other peoples view on this, especially CT client implementors. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 06:55: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 3915712D0C3 for ; Tue, 9 May 2017 06:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmhMY9XrRWU0; Tue, 9 May 2017 06:55:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C84C12AF6E; Tue, 9 May 2017 06:55:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 13:55:11 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/167#comment:2 Message-ID: <037.7e58f5c0b4e6943caaf6d10e178707ae@ietf.org> References: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #167: Define "incorporate" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 13:55:12 -0000 #167: Define "incorporate" -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis Comment: The different phases of a certificate being added to the tree: * The thing that gets submitted to a CT log is not an entry. It's a 'submission'. * At some point, an entry in the log is created for the submission. The entry is the input to the Merkle Tree: "The input to the Merkle Tree Hash is a list of data entries;". * There's an intermediate phase, of an entry existing before it's actually in the tree - Essentially, the entry is "created" when a sequence number is assigned to the submission + timestamp combination. Incorporation should be defined as the allocation of an sequence number to the entry and production of an STH that includes the hash of that sequenced entry. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 07:44: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 22B9B12949A for ; Tue, 9 May 2017 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdl_Lpzusc7; Tue, 9 May 2017 07:44:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 006051289B5; Tue, 9 May 2017 07:44:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 14:44:47 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/167#comment:3 Message-ID: <037.3e08e20cd75b89d1aeeec267253194de@ietf.org> References: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #167: Define "incorporate" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 14:44:49 -0000 #167: Define "incorporate" -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Comment (by eranm@…): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/254 Note I plan a bigger change that unifies the names of data structures with their semantic meaning. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 09:51: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 C43A81294F7 for ; Tue, 9 May 2017 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 sRPneSpduBAT for ; Tue, 9 May 2017 09:51:00 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 49CC512945E for ; Tue, 9 May 2017 09:51:00 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id u187so2568205pgb.0 for ; Tue, 09 May 2017 09:51:00 -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=xyl59f31lP8SpJ5kSLfVaIgdb6vQFlhAViHJ1GexdB4=; b=Jc+r89uxHF/tQjH3SISd0yQmFdF1+6N+l2fSZFcMRZ5RFbVnV82Es+6ft6MT4R7dkm WX0YnAZJmjGD3Lo4/kUHFw9fX6FRbZzUYUKfXTD83hckmzK9fSlRxDZqAyb4RofoQn19 SyWpUfsdmTbod945CaK4KkBk+1jfTcX7/7KTAC8f/3SNqro9K/JkAp2tWEiZ10hQ2tbP XLviogz1pt/oWecK/H5cnoIKzVjBYWZYM+ReI7FbzbwMiUqijbJ2C8UTkbWCnQ2WfB1I bLK3nW9sZvb8EIfNdl0bUHIxwkDvmyZo6pFwkTklb3vpCRaRgikAeTT4a2jspWEprD8b PrPA== 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=xyl59f31lP8SpJ5kSLfVaIgdb6vQFlhAViHJ1GexdB4=; b=DlSNNHL51HAYKTF4eUpvPFSE08lEoKOYp4rkL5yp3EwzmRMQfTK22BSNoWONXv5tgx GyXxHPgpG7ehxZ0DDNK20hFn/wTUz4lT9oFeY63EvngeH631ju9eLBgWjC1Xrr9eOuKr obud4ss6EjjvRqmHAzJHo7Npq2WauC5YKnU2Qr1xW/DMn8jW++EReG+pssgWuOc181nk d0m6tjS842iv309CYkuvYV0qJO1MN3x/3qMQyKS8TuTNP2nRq8XNCdoDWep9/dm46aha WYkiQnKYXcsx/6q0fF1jx7phecQgPwsJ+Tr9S5Mj/h+XDpT0zu1fM1pPrERB37LcyuF7 ylQQ== X-Gm-Message-State: AODbwcCxM+KNr+nYm7TXltEgU/DD4dErdBMMPcf39Aq8Ym/jfNZVfmiM TePVdTXg8jN15bEzM/E= X-Received: by 10.98.155.28 with SMTP id r28mr975172pfd.198.1494348659616; Tue, 09 May 2017 09:50:59 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([2620:11a:c081:20:5cd2:e060:3f82:f97a]) by smtp.gmail.com with ESMTPSA id v4sm878032pfa.81.2017.05.09.09.50.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 09:50:58 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> Date: Tue, 9 May 2017 09:50:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mP9OS0dE0BtoqA6dnwiIubMS9nj0GcRqg" Archived-At: Subject: [Trans] Ticket 170 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, 09 May 2017 16:51:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mP9OS0dE0BtoqA6dnwiIubMS9nj0GcRqg Content-Type: multipart/mixed; boundary="EbQ8fUnICj01RQrhHJgJei5WCthjKkaGX"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> Subject: Ticket 170 --EbQ8fUnICj01RQrhHJgJei5WCthjKkaGX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: We have a disagreement on closing ticket 170 (https://trac.ietf.org/trac/trans/ticket/170), on the use of distinct keys for signing SCTs and STHs. Eran proposed closing it as "wontfix" (i.e. not provide text describing how to use different keys on the frontend and the backend). Linus disagreed, and since he's both a log implementer and operator that carries some weight. This needs a bit more discussion, and in particular we need feedback from people running logs. Melinda --EbQ8fUnICj01RQrhHJgJei5WCthjKkaGX-- --mP9OS0dE0BtoqA6dnwiIubMS9nj0GcRqg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZEfNyAAoJELiGRpM6HoEuOpAQAMtBYJ+6vEm/iJxhEU4J0y6v aSfu6mdptlhvHFmJxnKO3qEPZ8ASY3K4ISGdh9uJP54HUD3mRf48doP6j0ayOttC 77ZkiGLyuodUTSf0BJUDzGWgDYwgyuAf3x+zB89LnWF2qHaCwDD02i5Lintj13dj wJqyAH6yMRulXvd3QcnGTSZZ5T/gP3uL/sRrfnj5YYkGnSX1uwS0F7acjbJI5QTS XpqkRFzgOXoqnL5GTgcAeLz6IyLbC8kNj0Bk7qejLo5psfOwIBbgpZc1xQFBI62T b8q38MRAz1D654HL1mU3qMjkBmlAo7EFmYZszrKxqQngEz5/UmuQ6sCSVpNAlFKh 2i/0CLGw8YJhOZgvyAu3XWFo0Ijs8a7lRk9ZIKPF+uqcIrG5UimYL30MUpTJAtxI Tj8TRuGHX+WUcUWnQD4Y6p94TOffRgUCOPNlT5uJphJ4JdAfieIiSYsebYSs9Tmc M425uQNbTeGcgLUsd/ZAyzHSmG/XnVr96DjvH6Az9gCeGCwl9XBINpxI/x955H03 tSLoMDR2yyONSHY1iSI1TdtqZCFeghb64wkZuP63gERkjeF9tCh+UUujdgiUObNW tyfllOK0s+wXrnPiIpopbCnCQEE4MA9VudpcX3Ya06k/mNqEVl9FyKafpCor7HoU s8BobHenYekZqBh1blry =3yj/ -----END PGP SIGNATURE----- --mP9OS0dE0BtoqA6dnwiIubMS9nj0GcRqg-- From nobody Tue May 9 09:51: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 D36D8129B4D for ; Tue, 9 May 2017 09:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trUHj4RGB31y; Tue, 9 May 2017 09:51:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D332312945E; Tue, 9 May 2017 09:51:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Tue, 09 May 2017 16:51:39 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/182#comment:7 Message-ID: <037.de13faead4b0903c330655c43c5d1c26@ietf.org> References: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <022.ac1ccde743de6df157b674f64d23cdd7@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #182: Clarify notation in the Merkle tree section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:51:41 -0000 #182: Clarify notation in the Merkle tree section -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Tue May 9 10:37:41 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7A129487 for ; Tue, 9 May 2017 10:37:39 -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 FS0Mdrf0Gm51 for ; Tue, 9 May 2017 10:37:37 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 497FC127076 for ; Tue, 9 May 2017 10:37:37 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id f102so6599233ioi.2 for ; Tue, 09 May 2017 10:37:37 -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=dl/sAWwLxSUSI453FBfKJQ5LsY3H1OjJJ/J/yJWP/wE=; b=W9H8ydiShVv5JAHW8pW4Wd7dQq0xS/q7UDH9BGUnK4klA4GQSCaC+IMWbpmWvL4NDT YDXdutAzYReJw5Q45an3XZhgKEimAJNiFwi+uSGKynHXTOfGsB0w/3LwvjGe0hGXeFx5 J3M/D37Yakwwsupj2xUeUzu12nd2U2UXsCwAxmRsY7sTzq/5n/rcTVglXaotxwOjLvhu Nm1izk/4OZYFL5E8PN4Ypc6SOIFzqUElLxpTv23YjjXAq60wvuXafBGWwtoPI5RmjxMp +0Mjf0fk7tl9kL79C4RjsfMvzciy4mIXpRC21ve1Nlojnf0961FcXoR/VpVZnJ7q4Gcf Mh6w== 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=dl/sAWwLxSUSI453FBfKJQ5LsY3H1OjJJ/J/yJWP/wE=; b=XNTsVVUBxEUkFLvQ4DMXtnmHfjHb8R1+tucW6v6sm7uJ/2FOInuexAVicLO0Kxy4GN rXVuc+Npi9E1F9ALBIkJEVCcOqHATTeU5AWEtGDe6ZkX2+zHvBgnVCJLfl0nuA2NGVN7 biUZ37F55Evi2W0ac2Mhjs86fkW2fc/hUqdWweIxVy3j6f4FkOiDSq7sWU7V8MW6Q62q cBpRJZkVDf2QW47PKOY/wsypAzai1lUZXsGvTQMjpzHT6WjX7GaVK/SBfHHO2jyZNp4K QO0jlIcnP97/2LOtWIO4PIeHi+6vnVuBq6+TDaQZOPjiueKvJtj5jvKgvAz9TM9RI3fy yBLw== X-Gm-Message-State: AODbwcC8wBdLRBBrahviuklMI6O3Khrhusaqbi/b04Wmal6N7scr/Cse lWMtCZutFUDKNYgVfofwfuP2VXyKt6K1ECY= X-Received: by 10.107.128.98 with SMTP id b95mr1091429iod.25.1494351456436; Tue, 09 May 2017 10:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Tue, 9 May 2017 10:37:05 -0700 (PDT) In-Reply-To: <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> <87pofjj6xd.fsf_-_@nordberg.se> <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> From: Eran Messeri Date: Tue, 9 May 2017 18:37:05 +0100 Message-ID: To: Andrew Ayer Cc: Linus Nordberg , "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a113dfdaebb6f03054f1acfe5 Archived-At: Subject: Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad) 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, 09 May 2017 17:37:39 -0000 --001a113dfdaebb6f03054f1acfe5 Content-Type: text/plain; charset=UTF-8 The downsides with storing signatures (for SCTs and STHs), which is an additional storage requirement for something that can be generated on-the-fly: * Storage costs and processing: Logs have to use highly-reliable storage, so every piece of data stored costs more and requires more processing to be verified. * Potential corruptions: What would a log do if it finds out it stores a corrupted signature? It could continue operation by re-signing without problems, unlike a corruption of the list of entries, where it's clear it's unhealthy (a safety measure in some log implementations is to hash all entries up to the last-issued STH and verify root hash, before adding new entries and producing a new one). This is a viable solution to the problem of deterministic signatures, though, so it should be mentioned in -bis. How about requiring returning the same signature for the same SCT / STH, without requiring the use of deterministic signature schemes? On Tue, May 9, 2017 at 12:14 AM, Andrew Ayer wrote: > On Tue, 09 May 2017 00:54:38 +0200 > Linus Nordberg wrote: > > > Andrew Ayer wrote > > Mon, 8 May 2017 11:11:41 -0700: > > > > > 3. When producing a new STH or SCT, sign it, store the signature, > > > and serve the stored signature instead of re-signing on-the-fly > > > every time the log needs to serve the STH or SCT. Since the log > > > already needs to store information about STHs and SCTs, also > > > storing the signature should not be burdensome. > > > > Why do logs already need to store information about SCTs? > > Technically it's not required, but practically speaking logs need to > return an SCT for an existing entry when someone submits an > already-logged certificate (otherwise the log could be spammed into > oblivion). To construct that SCT, the log needs to know the timestamp > of the existing entry. A logical place to store the signature would be > alongside the timestamp. > > > Do logs already need to store information about STHs because of the > > proposed get-sths API [0][1][2] or something else? > > Even without the get-sths API, the log needs to store the timestamp of > the current STH. That would be a logical place to store the signature. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113dfdaebb6f03054f1acfe5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The downsides with storing signatures (for SCTs and STHs),= which is an additional storage requirement for something that can be gener= ated on-the-fly:
* Storage costs and processing: Logs have to use highl= y-reliable storage, so every piece of data stored costs more and requires m= ore processing to be verified.
* Potential corruptions: What woul= d a log do if it finds out it stores a corrupted signature? It could contin= ue operation by re-signing without problems, unlike a corruption of the lis= t of entries, where it's clear it's unhealthy (a safety measure in = some log implementations is to hash all entries up to the last-issued STH a= nd verify root hash, before adding new entries and producing a new one).

This is a viable solution to the problem of determin= istic signatures, though, so it should be mentioned in -bis.
How = about requiring returning the same signature for the same SCT / STH, withou= t requiring the use of deterministic signature schemes?

On Tue, May 9, 2017 at 12= :14 AM, Andrew Ayer <agwa@andrewayer.name> wrote:
On Tue, 09 May 2017 00:54:38 +0= 200
Linus Nordberg <linus@sunet.se>= wrote:

> Andrew Ayer <agwa@andrewaye= r.name> wrote
> Mon, 8 May 2017 11:11:41 -0700:
>
> > 3. When producing a new STH or SCT, sign it, store the signature,=
> > and serve the stored signature instead of re-signing on-the-fly > > every time the log needs to serve the STH or SCT.=C2=A0 Since the= log
> > already needs to store information about STHs and SCTs, also
> > storing the signature should not be burdensome.
>
> Why do logs already need to store information about SCTs?

Technically it's not required, but practically speaking logs nee= d to
return an SCT for an existing entry when someone submits an
already-logged certificate (otherwise the log could be spammed into
oblivion).=C2=A0 To construct that SCT, the log needs to know the timestamp=
of the existing entry.=C2=A0 A logical place to store the signature would b= e
alongside the timestamp.

> Do logs already need to store information about STHs because of the > proposed get-sths API [0][1][2] or something else?

Even without the get-sths API, the log needs to store the timestamp = of
the current STH.=C2=A0 That would be a logical place to store the signature= .

Regards,
Andrew

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

--001a113dfdaebb6f03054f1acfe5-- From nobody Tue May 9 10:43: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 70AF9129536 for ; Tue, 9 May 2017 10:43:56 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JtMBl22YIDY for ; Tue, 9 May 2017 10:43:55 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 E5333126DFF for ; Tue, 9 May 2017 10:43:54 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a72so7509431qkj.2 for ; Tue, 09 May 2017 10:43: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; bh=+W7OEcWINzgszMWdckCWQoxvvsQbJJeyDCx5M50Bqu0=; b=Wvxalpxs3YUciDr4K4kxKA48d8iDVzb8E3lNxcKZX0Q+fgxNnkOWgJZUcrmv4I76iW U5lv2TSHrOx/LrWqwxt+lmefm1xNwJiGwMFLDBm2vvvFpHU8r5F5yL9fh4PABDvNSNOg YErRyCcunA6AwMmmL26K5ZfdorfdfCsLJ3yZo= 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=+W7OEcWINzgszMWdckCWQoxvvsQbJJeyDCx5M50Bqu0=; b=Ps+ieehky1aL6JT4TzJ81ZBECxrCsYsxXfcsj58apB1QEG4e7a74jREhOab9K8hMTR sRjHshm2OyzT6BCUnwea8yNoDRi2GwNdLFCBUPH+pYjRkk0CQka53tMtbiRrC1v+UXTr h+Keb8XBkxQbY9eHPlr6XQDZXT4TkO5RiIowsCS1FVZ8/YasfHUpT5ovACKRp2QoVvrS rYE7TTbcy09xtwBr4aIwgmiTJJc7Edr8LiSeWxvlhIep36bmbQb4NYRlABG8QZmjT+6a tHY4guV8ydUCB3C5ap0LouKQsWHmx+zWzwkbGHh7fMDyudS7pi2kXhfRNagBInqHXs8W dlCA== X-Gm-Message-State: AODbwcDCcMJJIhudz/wLasdKp3lbDci1tenLbrCCQlyv+qtIiHkHn5ki bq6om4Ilkz1qNe+DLnWlDsEj1fj9LO9lf00= X-Received: by 10.55.94.1 with SMTP id s1mr1305838qkb.83.1494351834041; Tue, 09 May 2017 10:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.101.148 with HTTP; Tue, 9 May 2017 10:43:33 -0700 (PDT) In-Reply-To: <87pofiif6g.fsf@nordberg.se> References: <87pofiif6g.fsf@nordberg.se> From: Tom Ritter Date: Tue, 9 May 2017 12:43:33 -0500 Message-ID: To: Linus Nordberg Cc: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 09 May 2017 17:43:56 -0000 On 9 May 2017 at 03:53, Linus Nordberg wrote: > Tom Ritter wrote > Mon, 8 May 2017 12:38:45 -0500: > >> Anyway, so I still think there's fingerprinting concerns. But even if >> we require deterministic signatures - if the log *wants* to be >> malicious, it can still issue non-deterministic signatures, and >> there's no way to know, because as I said above - detection is hard. > > You seem to focus on SCTs, which are indeed hard to share between > privacy concerned clients because they contain sensitive data. But STHs > have signatures too and I think we should limit the ways a log can track > clients asking for STHs. > > Catching a log serving different log clients different bits for the same > timestamp, tree_size and root_hash is a matter of clients comparing > retrieved STHs. Keeping the requirement for deterministic signatures and > the limitation on STH issuance frequency (6962bis-24 4.8) makes > gossiping about STHs reasonable even for clients serving end users with > privacy expectations (gossip-04 10.5.4). I agree that we could catch logs who do this to STHs relatively easily. >> So I think Eran's suggested changes are okay. > > I think we should keep requiring deterministic signatures being used but > stop mandating how it is being done. Definitely agree that we not mandate how it is done. I guess I'm more on the fence now because of the STH situation. -tom From nobody Tue May 9 11:29: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 DFD43127B31 for ; Tue, 9 May 2017 11:29:04 -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 7PWVD_EZ7taF for ; Tue, 9 May 2017 11:28:57 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 AA362129516 for ; Tue, 9 May 2017 11:28:55 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l135so4799700ywb.2 for ; Tue, 09 May 2017 11:28:55 -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=5wrcJvflOCn20QN3AcB2lYZCIiJPxHG+fAtIotlacjc=; b=UZrwe11Ln0T23ZcmFHvkjl9roBoDgWW0q1w5KoA18fdbCGjKgqgs72JoxMwDKr180H RvoeGZ5ZSSiygoC2GcTnVVF6r/M4EBFaOed+fNwJgo/Dt8K/KZWjUUyuDsgWuQ7TAacW 49KWXa8K5mGVIIDdTpp6IzdE+AkTwzVZfLardIV7NSePGBgVbAauJ/eTUrr+YHVoeAyO OqRtvTj0f0YWO0i21Dx6fPB/dE4OpxfG3e4u4I3jlmDvDtf03AkPYmCcAmc1axDMtGsw IeZdPKxijYPZQ3w6ll1EwipSKVkiXtHGhHJUZeqcYuAKSmImTtH1VjDVpq5TqsfRXXO9 6T7Q== 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=5wrcJvflOCn20QN3AcB2lYZCIiJPxHG+fAtIotlacjc=; b=er6sGZZ84b4p5KxCQT+RWHQb3c00Aplz+GEfIJ0jJLM418GBckd0yYSl1OnT7oMvAn xLsTrcWa9gmwwvISTkAS7G7iiygljD9UUZ4CL3z50xc40OncH75t1T9Tr4RJHROv5LQh Cbtb5E4w7MXrQqNwA3+uH2mcM/h8pgNHgk1n3iNY+vC1tDdTPOtm72h8aQI184Fna94z iWqNKxreLCEnvwNaLIZCUZbXXhmkf8qobF7OrVWxT//v8TIWrUjw8SBOUFZkwkYETKQt 1AWlHAFCWqLn57wurTC0yfzk0k81YtFuvG+0riuvXCWlpX92DoyFzsttcpB+lKTnNkmq Bweg== X-Gm-Message-State: AODbwcA8kJJEaryC4cIrdNx+ECGOIynxFpfHbmFrN5q5wS/YKj4+xayV WFz8xVehhft6HcidN8wtjVnawSjFHDRH X-Received: by 10.129.138.131 with SMTP id a125mr1163878ywg.277.1494354534656; Tue, 09 May 2017 11:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.48.215 with HTTP; Tue, 9 May 2017 11:28:54 -0700 (PDT) In-Reply-To: References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> <87pofjj6xd.fsf_-_@nordberg.se> <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> From: Al Cutter Date: Tue, 9 May 2017 19:28:54 +0100 Message-ID: To: Eran Messeri Cc: Andrew Ayer , "trans@ietf.org" , Linus Nordberg Content-Type: multipart/alternative; boundary=94eb2c0816d835a005054f1b872d Archived-At: Subject: Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad) 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, 09 May 2017 18:29:05 -0000 --94eb2c0816d835a005054f1b872d Content-Type: text/plain; charset=UTF-8 On Tue, May 9, 2017 at 6:37 PM, Eran Messeri wrote: > The downsides with storing signatures (for SCTs and STHs), which is an > additional storage requirement for something that can be generated > on-the-fly: > * Storage costs and processing: Logs have to use highly-reliable storage, > so every piece of data stored costs more and requires more processing to be > verified. > TBH the cost of running a log is mostly going to be opex, the overhead of storing an extra few tens of GB for a really big log like Pilot are probably not going to be that noticeable. > * Potential corruptions: What would a log do if it finds out it stores a > corrupted signature? It could continue operation by re-signing without > problems, unlike a corruption of the list of entries, where it's clear it's > unhealthy (a safety measure in some log implementations is to hash all > entries up to the last-issued STH and verify root hash, before adding new > entries and producing a new one). > This is an interesting one... Recalculating the root of a large tree from the leaf images is a kinda* sequential operation but verifying the signatures over SCTs+leaves can be as obscenely parallel as your storage permits. (*Not entirely true, you can recurse and go wide of course, but that's considerably more complicated than existing implementations I'm aware of which mostly tend to use a compact Merkle tree approach.) Also, unless the corruption of your signature and/or corresponding leaf entry caused precisely one of them to be invalid DER, you don't really have any idea which part is wrong, so simply re-signing and continuing operation would probably not be wise. > > This is a viable solution to the problem of deterministic signatures, > though, so it should be mentioned in -bis. > How about requiring returning the same signature for the same SCT / STH, > without requiring the use of deterministic signature schemes? > At least for SCTs this is not a good idea; if you require this, then by implication you also require a strongly consistent global queue with deduping for putting the to-be-sequenced leaves into. That's certainly one way of building a log, but there are others, and not everyone's got Spanner :) Incidentally this is why RFC6962 says 'the log ... MAY return the same SCT as it returned before'; I'd imagine most log implementations will generally do this because it makes sense from the operators' PoV of controlling growth, but there may be situations when they can't guarantee it. > > On Tue, May 9, 2017 at 12:14 AM, Andrew Ayer wrote: > >> On Tue, 09 May 2017 00:54:38 +0200 >> Linus Nordberg wrote: >> >> > Andrew Ayer wrote >> > Mon, 8 May 2017 11:11:41 -0700: >> > >> > > 3. When producing a new STH or SCT, sign it, store the signature, >> > > and serve the stored signature instead of re-signing on-the-fly >> > > every time the log needs to serve the STH or SCT. Since the log >> > > already needs to store information about STHs and SCTs, also >> > > storing the signature should not be burdensome. >> > >> > Why do logs already need to store information about SCTs? >> >> Technically it's not required, but practically speaking logs need to >> return an SCT for an existing entry when someone submits an >> already-logged certificate (otherwise the log could be spammed into >> oblivion). To construct that SCT, the log needs to know the timestamp >> of the existing entry. A logical place to store the signature would be >> alongside the timestamp. >> >> > Do logs already need to store information about STHs because of the >> > proposed get-sths API [0][1][2] or something else? >> >> Even without the get-sths API, the log needs to store the timestamp of >> the current STH. That would be a logical place to store the signature. >> >> Regards, >> Andrew >> >> _______________________________________________ >> 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 > > --94eb2c0816d835a005054f1b872d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 6:37 PM, Eran Messeri <eranm@google.com><= /span> wrote:
The downsi= des with storing signatures (for SCTs and STHs), which is an additional sto= rage requirement for something that can be generated on-the-fly:
* Stor= age costs and processing: Logs have to use highly-reliable storage, so ever= y piece of data stored costs more and requires more processing to be verifi= ed.

TBH the cost of running a l= og is mostly going to be opex, the overhead of storing an extra few tens of= GB for a really big log like Pilot are probably not going to be that notic= eable.=C2=A0
=C2=A0
* Potential corruptions: What would a log do if it finds out = it stores a corrupted signature? It could continue operation by re-signing = without problems, unlike a corruption of the list of entries, where it'= s clear it's unhealthy (a safety measure in some log implementations is= to hash all entries up to the last-issued STH and verify root hash, before= adding new entries and producing a new one).
=
This is an interesting one...
Recalculating the ro= ot of a large tree from the leaf images is a kinda* sequential operation bu= t verifying the signatures over SCTs+leaves can be as obscenely parallel as= your storage permits. (*Not entirely true, you can recurse and go wide of = course, but that's considerably more complicated than existing implemen= tations I'm aware of which mostly tend to use a compact Merkle tree app= roach.)
Also, unless the corruption of your signature and/or corr= esponding leaf entry caused precisely one of them to be invalid DER, you do= n't really have any idea which part is wrong, so simply re-signing and = continuing operation would probably not be wise.=C2=A0
=C2=A0

This = is a viable solution to the problem of deterministic signatures, though, so= it should be mentioned in -bis.
How about requiring returning th= e same signature for the same SCT / STH, without requiring the use of deter= ministic signature schemes?

At = least for SCTs this is not a good idea; if you require this, then by implic= ation you also require a strongly consistent global queue with deduping for= putting the to-be-sequenced leaves into. That's certainly one way of b= uilding a log, but there are others, and not everyone's got Spanner :)<= /div>

Incidentally this is why RFC6962 says =C2=A0't= he log ... MAY return the same SCT as it returned before'; I'd imag= ine most log implementations will generally do this because it makes sense = from the operators' PoV of controlling growth, but there may be situati= ons when they can't guarantee it.
=C2=A0

On Tue, May 9, 2017 at 12:14 AM, And= rew Ayer <agwa@andrewayer.name> wrote:
On Tue, 09 May 2017 00:54:38 +0200
Linus Nordberg <linu= s@sunet.se> wrote:

> Andrew Ayer <agwa@andrewayer.name> wrote
> Mon, 8 May 2017 11:11:41 -0700:
>
> > 3. When producing a new STH or SCT, sign it, store the signature,=
> > and serve the stored signature instead of re-signing on-the-fly > > every time the log needs to serve the STH or SCT.=C2=A0 Since the= log
> > already needs to store information about STHs and SCTs, also
> > storing the signature should not be burdensome.
>
> Why do logs already need to store information about SCTs?

Technically it's not required, but practically speaking logs nee= d to
return an SCT for an existing entry when someone submits an
already-logged certificate (otherwise the log could be spammed into
oblivion).=C2=A0 To construct that SCT, the log needs to know the timestamp=
of the existing entry.=C2=A0 A logical place to store the signature would b= e
alongside the timestamp.

> Do logs already need to store information about STHs because of the > proposed get-sths API [0][1][2] or something else?

Even without the get-sths API, the log needs to store the timestamp = of
the current STH.=C2=A0 That would be a logical place to store the signature= .

Regards,
Andrew

_______________________________________________
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


--94eb2c0816d835a005054f1b872d-- From nobody Tue May 9 11:37:28 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFEA12954D for ; Tue, 9 May 2017 11:37:27 -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 pvDQTRfy3PJ8 for ; Tue, 9 May 2017 11:37:26 -0700 (PDT) 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 981BE128896 for ; Tue, 9 May 2017 11:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494355044; bh=WGLPBNvXokjjYZzB1N3285Ci/0qTymicCWqs9Jebtug=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=J9jP2eCiSrAbc1RmPdzU1LGCGv60QnPFXCsHiZQn4SLAgRKIAJDUFEuDtr0AwYzVx vtfSY0nSGXATJQmpgcmTiUZMOhWz6oOr1JNd997G3Rpvkqd2tdcemxZKMi3AK18nmP 9gSZkWgffa4AqOnJv0WAuSxA1OZgZeCqS19MwYPlY4fjqmG8U6rFH4avQMel7KYsGK jOIUpRnGn1GGcwiBxjSvzI9/u1Vx+H45YXx8yMHi0Sk6U92M0CCBQ/ib626+V9nEPG SYmE1DVymfEUANPJrTWHzzZt90zcmWOneqhzsU4DJd1mY4AQhVrl/cF5UukB3co+9w 27A7/Ukv1x2uA== Date: Tue, 9 May 2017 11:37:23 -0700 From: Andrew Ayer To: Al Cutter Cc: Eran Messeri , Linus Nordberg , "trans@ietf.org" Message-Id: <20170509113723.fe6bb0f2ef39dd120ebf353d@andrewayer.name> In-Reply-To: References: <20170508111141.2ad103252b01cf48b5e988c8@andrewayer.name> <87pofjj6xd.fsf_-_@nordberg.se> <20170508161443.be44c605e67bec0feeb50e3a@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad) 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, 09 May 2017 18:37:27 -0000 On Tue, 9 May 2017 19:28:54 +0100 Al Cutter wrote: > > This is a viable solution to the problem of deterministic > > signatures, though, so it should be mentioned in -bis. > > How about requiring returning the same signature for the same SCT / > > STH, without requiring the use of deterministic signature schemes? > > > > At least for SCTs this is not a good idea; if you require this, then > by implication you also require a strongly consistent global queue > with deduping for putting the to-be-sequenced leaves into. That's > certainly one way of building a log, but there are others, and not > everyone's got Spanner :) > > Incidentally this is why RFC6962 says 'the log ... MAY return the > same SCT as it returned before'; I'd imagine most log implementations > will generally do this because it makes sense from the operators' PoV > of controlling growth, but there may be situations when they can't > guarantee it. Ah, good point. Maybe we should only require same/deterministic signatures for STHs. As Tom and Linus have discussed, that's where same/deterministic signatures are the most needed anyways. Regards, Andrew From nobody Tue May 9 11:38:30 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D727126FDC for ; Tue, 9 May 2017 11:38:29 -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 bIkT1g9mnhkK for ; Tue, 9 May 2017 11:38:27 -0700 (PDT) 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 938CD12009C for ; Tue, 9 May 2017 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494355107; bh=/3smxAa8svuqy4vkTqE1EE9rdkz6NpAoZaMdqpggFmA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VsU/LleOO8qjpZmOMpptBCDXhJlwG3iIxKovu6FcfY1E+06EsjpZw4D4OONPTqJIv Z/NPFFzNXjhF7HVSiZsKQ5q7SVHDbQ3axlaSkYsnIo95MzGcWFacsCUDvbvdpANjgl Ju27vTUJouq3ehqMuI/1/7xoYuWs1IVqZgT8XkWKl01yQA53WUZ6Avnl7V1dnQbOcr IXNwKATmSi4u9rsCl9l5U5qh/LaVlAHGxHBHcvMwm/u7N9pAief//GBjTtd+vCqT8H u0LbYFGWsqEjqXe0c/cBUHPVhGvDfJLOGS/NKxM5rWHF1TKsfhLhtwOgMUqdYBq1ei 69oDSVJ5NImTw== Date: Tue, 9 May 2017 11:38:26 -0700 From: Andrew Ayer To: Melinda Shore Cc: "trans@ietf.org" Message-Id: <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> In-Reply-To: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Ticket 170 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, 09 May 2017 18:38:29 -0000 On Tue, 9 May 2017 09:50:57 -0700 Melinda Shore wrote: > We have a disagreement on closing ticket 170 > (https://trac.ietf.org/trac/trans/ticket/170), > on the use of distinct keys for signing SCTs and STHs. I'm not entirely convinced of the security benefit. However, speaking as a monitor/auditor implementer, I do not believe separate keys would add any complexity to implementations - it's just a matter of storing two keys instead of one and using the right one when verifying signatures. Therefore, this proposal seems like a costless addition to the protocol that might help security. I'm assuming logs would still be free to use the same key if they wanted, right? Regards, Andrew From nobody Tue May 9 12:21: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 0FD7F12EADF for ; Tue, 9 May 2017 12:21:04 -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 X5FYLFm784YX for ; Tue, 9 May 2017 12:21:02 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 70D7112EADB for ; Tue, 9 May 2017 12:21:02 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u28so4447843pgn.1 for ; Tue, 09 May 2017 12:21:02 -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=Ffz6062k2SwxR0wkutKAgrwXuW+wz39M08KFdbdi0l8=; b=Lqi9AxLGd9+T4pa7q544ocz8u74RwE5GuwQrRL7JWqrZN6HkfGadyooEQ3TXdgMwHK SZjGEe/CVFg2eL13rJhygO8TnonCjgL9O/7SjNk0x7A077KG2+hhltBqtnFkC40rl5tW k2YyhlqlyJpSSG272b/YavxFXBi2jpDJIsL8bjSykqWNf3qKdWlM/RbGQHwTKlFKTBEn dMTTt5SpcJSEdtsuVTJAJ6M3ukEVjX0HfdMQcoK91OZCpgprfpRdNk36cl/dkrYLef+5 9oro8bwmncWOtJiGNzw/PGtgZkDs9A6VS18Wg023ETM0fqgGzEyPjw0BxiajDohPIgNJ cDTg== 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=Ffz6062k2SwxR0wkutKAgrwXuW+wz39M08KFdbdi0l8=; b=uYeYv7NNnFlIXyeJmXfHfTmE0gNndbUYLiOzLpXRAtAsbhYtlSrjEU0j6dGtw0mqzi 1v9LwlfNoPuZJYzb7bmVx/l7ltIA15IvrzPBUqwQuZTd7wNN3IiknL26hMNRK5135waM 7FUIVfkZEpZ19NnJxVoWKD/aj/NDy4zCV3kqX9khGXyH7uoVp+dzQPdhTZv7nRfWtYhs XTDe/SiNgtiePHsJEGX7GuvItuCffvgnxdPfAAfdzsx0AzW4W0uLti0R4IVPOeGal3GY u7mBsTVpmwaHQbwwYvQcDxu9Q+Wdsl5PL3gEEXHqKhvcw0szN/BLYV86XfQRZLdfQ0Zm nbyg== X-Gm-Message-State: AODbwcCj7PqjV1VptdUP/DCKyQo+KqtSjB54ZogxPrWQRAtgUyZa3CU+ 241zk+DL0ck+ps3nmhk= X-Received: by 10.98.64.221 with SMTP id f90mr1677930pfd.123.1494357661688; Tue, 09 May 2017 12:21:01 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([8.18.217.202]) by smtp.gmail.com with ESMTPSA id y78sm1378801pfd.32.2017.05.09.12.21.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 12:21:00 -0700 (PDT) To: Andrew Ayer References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> Cc: "trans@ietf.org" From: Melinda Shore Message-ID: <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> Date: Tue, 9 May 2017 12:20:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j4gv2xiHM8BLQPLHeDkDdlATSEqqUffQW" Archived-At: Subject: Re: [Trans] Ticket 170 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, 09 May 2017 19:21:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j4gv2xiHM8BLQPLHeDkDdlATSEqqUffQW Content-Type: multipart/mixed; boundary="CJfu4kMqKLcNlDhEDqe1wD2b6wwVb5IIP"; protected-headers="v1" From: Melinda Shore To: Andrew Ayer Cc: "trans@ietf.org" Message-ID: <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> Subject: Re: [Trans] Ticket 170 References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> In-Reply-To: <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> --CJfu4kMqKLcNlDhEDqe1wD2b6wwVb5IIP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/9/17 11:38 AM, Andrew Ayer wrote: > I'm assuming logs would still be free to use the same key if they > wanted, right? Right, and the question raised in the ticket was whether or not key identiers needs to be added to the log metadata. Melinda --CJfu4kMqKLcNlDhEDqe1wD2b6wwVb5IIP-- --j4gv2xiHM8BLQPLHeDkDdlATSEqqUffQW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZEhabAAoJELiGRpM6HoEueSUP/j2tCfuMrQRCx3o8GLtCByq2 RYsEHcH2ERrGD6ugZW5qI8LgCv2LmX416ocH0aOLH6iZLmtlGNaBFQ4aWKn+zT4i C1ASKIU0ZSymeCEaPym/rhE7dPjXqJUwzcSuocDz60fLAhecuUAGusvI43/ve2Ch 0jmmR378+tlrzlm98Egydf1TpENj84FXlwEqDJvVpbpVKF5rkgzfV5xN8V2s4znU wppBWX1xAwaamLfqq8YUw1i7GOZJAxzdqpdpvUG1U1tiGVH8ll3+fFJ/tLLZE/Ir Xn2u8mAVdlS6pwo/LRcYYBv9Vv5qVJflewDm7kOa4bXnqXHfJAxk6nUHoSElXzay mLCL9xYSiGEMolcl9XTAhme7rH03yuQPs8SCtteqAwxlmGgYMxX+lUP/Mpa0Hw6v /b8DFCGDmyuemRC38/S4LUIvCcEoH1G86pCpU1DDtbXioN7WoOb5CxvJ9kcmWpXC kya19dxiE4c5V3arbktfIOo2ZyavmwWbsqUFpw7E9KIHtt+dlBFb18ZavObIANMA 6xNc4al4GYP4eDb4/COdeuwdBZhhq3oD2lbsri3TNQU7gpvph5uE3lo6WxQoTu+d yfBJdUOMAB+bBiMIJNPUYEW33nhJrUpnICxIOIURcOEe33P/eY2hocAK1HeqntEM wkeJLBHFfIvlZIB94RQL =qeTM -----END PGP SIGNATURE----- --j4gv2xiHM8BLQPLHeDkDdlATSEqqUffQW-- From nobody Wed May 10 03:44: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 EB768128C84 for ; Wed, 10 May 2017 03:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 WmeXR6Ae1TBC for ; Wed, 10 May 2017 03:44:47 -0700 (PDT) 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 0806A128BBB for ; Wed, 10 May 2017 03:44:47 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id l50so37933009wrc.3 for ; Wed, 10 May 2017 03:44: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=crAK2d3jnV8On2/ADsn10C+Tjhbb01gWATIxeupLJW8=; b=iTDnfhP/eRlX6RvKqRaG83LNgPc9wwoBwE9stBm3rCVByZARY8ekR3O1ZDJ4VGScPR q5fD9mjHXfYxVpajX3Jg5woXuMNFnxrpGTLXsqDV0yGoiy5/Ar24Oduudl7AWrAk7ZIQ Eug1+b7y5j2+N6qTRmL3hR8TCwfgrxyZmj62xh8OXjkHKiLIoxmFl0vlKXAz7jyciad2 xbTsNQ898tl+IWfkLy02+oOZv41ZpLaf3NG2hwzxECUyhcm26I+jeEi4ixdN0g0QX/hf HritRrAzDvrEL34oJVsfQIb7SjEwJT4J5avIcmyEZE6gOpU2h7z2GcxCW/7ObayBebf/ tGhA== 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=crAK2d3jnV8On2/ADsn10C+Tjhbb01gWATIxeupLJW8=; b=TPdbqNbW0eUq0MxeHfpKF8ku67pGK4kjPSxoCQlL0ihFzNg0/uW8fRufqm4ShGxug8 iZEqP8g3YGGBsx+gnj4PlS+8WPYjENnF2zAMC4klUw2Rr6Uc/6uJ0k49iGf0X5ri+8tc qUJ6Au1nxzTDaIvaNFxytg/2scU/5HcjTAHRVcrR15lvJV8ilYUAcjA3L7TkU7DOyie8 rC+n2HmA+vbaibbWnTqyKrd1dKrgzBwu0SAP8VQ5MWFksapHTxEElTFBYq3pWdB/7Ghb GQNxpvp2+NdiJdESbtU9ksDxQi7Gee5Ov36TyWnENHPXwWEX/fDao34JyAbXI0ASMvk1 CcrQ== X-Gm-Message-State: AODbwcDZLRzF0b1y3xq4gNtyCFV/zUGo/kHp4lGo8MFJyNqI6CzYi/MK 2bPyTAdasa39nj6IMJaKlDRLvkcNDJQnDy0= X-Received: by 10.28.49.131 with SMTP id x125mr624247wmx.86.1494413085422; Wed, 10 May 2017 03:44:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.133 with HTTP; Wed, 10 May 2017 03:44:14 -0700 (PDT) In-Reply-To: <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> From: Eran Messeri Date: Wed, 10 May 2017 11:44:14 +0100 Message-ID: To: Melinda Shore Cc: Andrew Ayer , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1142426e1b136b054f292975" Archived-At: Subject: Re: [Trans] Ticket 170 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, 10 May 2017 10:44:49 -0000 --001a1142426e1b136b054f292975 Content-Type: text/plain; charset="UTF-8" On Tue, May 9, 2017 at 8:20 PM, Melinda Shore wrote: > On 5/9/17 11:38 AM, Andrew Ayer wrote: > > I'm assuming logs would still be free to use the same key if they > > wanted, right? > > Right, and the question raised in the ticket was whether or > not key identiers needs to be added to the log metadata. > It's a bit more nuanced than that: We have to go through the document and specify which key should be used for signing and which key should be used for verification every time a signing operation is mentioned. Adding a second key would complicate client implementation: Clients that verify SCTs and audit them would need both keys (more metadata) and would have to choose the right one for each verification (more logic). That applies both to monitors and TLS clients. It would complicate the specification and has the potential for creating a joint that would immediately rust: If all 6962-bis logs choose to use the same key for signing SCTs and STHs then there'd be no guarantee that clients could cope with different keys for each. Andrew asserts it "might help security" but does not specify how - I assume he refers to the ability for different components of a log to be in different security domains (front-ends that can sign SCTs are in one, signers that issue STHs are in another). However, compromise of any of those security domains (either in the form of stealing key material or compelling signing of arbitrary SCTs / STHs) would create a breach of compliance with the Merkle Tree properties required in 6962-bis: * If a rogue SCT is issued, it will fail auditing - the log will not be able to produce an inclusion proof to any STH. * If a rogue STH is issued, it will fail consistency checking - the log will not be able to produce a consistency proof to other STHs. * If a rogue SCT and STH are issued, then the rogue STH will fail consistency checking. Both kinds of failure are equally bad as far as 6962-bis is concerned: Because of the tight coupling between SCT and STH signatures, I don't see the value of using a separate key for each. > > Melinda > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a1142426e1b136b054f292975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 8:20 PM, Melinda Shore <melinda.shore@gma= il.com> wrote:
On 5/9/17 11:38 AM, Andrew Ayer wrote:
> I'm assuming logs would still be free to use the same key if they<= br> > wanted, right?

Right, and the question raised in the ticket was whether or
not key identiers needs to be added to the log metadata.
It's a bit more nuanced than that: We have to go through the documen= t and specify which key should be used for signing and which key should be = used for verification every time a signing operation is mentioned.

Adding a second key would complicate client implementation= : Clients that verify SCTs and audit them would need both keys (more metada= ta) and would have to choose the right one for each verification (more logi= c). That applies both to monitors and TLS clients.

It would complicate the specification and has the potential for creating a= joint that would immediately rust: If all 6962-bis logs choose to use the = same key for signing SCTs and STHs then there'd be no guarantee that cl= ients could cope with different keys for each.

And= rew asserts it "might help security" but does not specify how - I= assume he refers to the ability for different components of a log to be in= different security domains (front-ends that can sign SCTs are in one, sign= ers that issue STHs are in another).
However, compromise of any o= f those security domains (either in the form of stealing key material or co= mpelling signing of arbitrary SCTs / STHs) would create a breach of complia= nce with the Merkle Tree properties required in 6962-bis:
* If a = rogue SCT is issued, it will fail auditing - the log will not be able to pr= oduce an inclusion proof to any STH.
* If a rogue STH is issued, = it will fail consistency checking - the log will not be able to produce a c= onsistency proof to other STHs.
* If a rogue SCT and STH are issu= ed, then the rogue STH will fail consistency checking.

=
Both kinds of failure are equally bad as far as 6962-bis is concerned:= Because of the tight coupling between SCT and STH signatures, I don't = see the value of using a separate key for each.

Melinda



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


--001a1142426e1b136b054f292975-- From nobody Wed May 10 04:08:45 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A75129B01 for ; Wed, 10 May 2017 04:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmp6ZqZIkSIx; Wed, 10 May 2017 04:08:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 649CC1201F2; Wed, 10 May 2017 04:08:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 10 May 2017 11:08:42 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/189 Message-ID: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> X-Trac-Ticket-ID: 189 Archived-At: Subject: [Trans] [Public Notary Transparency Wiki] #189: Permit logs to use EdDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 11:08:43 -0000 #189: Permit logs to use EdDSA -----------------------------+-------------------------------------------- Reporter: rob.stradling@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -----------------------------+-------------------------------------------- The specification for EdDSA was published as RFC8032 a few months ago. The advantages of EdDSA over ECDSA are summarized at https://tools.ietf.org/html/rfc8032#section-1 We should add one or more of the EdDSA Instances to the Signature Algorithms registry. Expert advice on which of the EdDSA Instances to add would be appreciated. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 10 05:51: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 771C9128CFF for ; Wed, 10 May 2017 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 nL0MRIjGN3Pa for ; Wed, 10 May 2017 05:51:05 -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 AC1A5129447 for ; Wed, 10 May 2017 05:51:04 -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 v4ACp1cV017955 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 May 2017 14:51:01 +0200 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 v4ACovZ0018726 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 May 2017 12:51:00 GMT From: Linus Nordberg To: Eran Messeri Cc: trans@ietf.org Organization: Sunet References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> Date: Wed, 10 May 2017 14:51:05 +0200 In-Reply-To: (Eran Messeri's message of "Wed, 10 May 2017 11:44:14 +0100") Message-ID: <87k25ozxhi.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: 0aTiAP1qa - b343ab6f67b3 - 20170510 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] Ticket 170 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, 10 May 2017 12:51:08 -0000 Eran Messeri wrote Wed, 10 May 2017 11:44:14 +0100: > However, compromise of any of those security domains (either in the form of > stealing key material or compelling signing of arbitrary SCTs / STHs) would > create a breach of compliance with the Merkle Tree properties required in > 6962-bis: > * If a rogue SCT is issued, it will fail auditing - the log will not be > able to produce an inclusion proof to any STH. > * If a rogue STH is issued, it will fail consistency checking - the log > will not be able to produce a consistency proof to other STHs. > * If a rogue SCT and STH are issued, then the rogue STH will fail > consistency checking. > > Both kinds of failure are equally bad as far as 6962-bis is concerned: > Because of the tight coupling between SCT and STH signatures, I don't see > the value of using a separate key for each. I've so far been thinking of a misissued SCT as a less severe breach of log compliance. SCT's are silly creatures anyway and we'll have to dispose of them ASAP, aight? That's probably not correct. An adversary who can continously produce SCT's wouldn't even have trouble fooling TLS clients which refused to accept an SCT with a timestamp older than now() - MMD. Which leaves us with an even smaller class of attacks. I withdraw my support for separate keys for signing SCT's and STH's and will update #170 to reflect this. Thanks for your patience. From nobody Wed May 10 05:53: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 0C230129A9F for ; Wed, 10 May 2017 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEpSqaFkmpC1; Wed, 10 May 2017 05:53:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6191293E4; Wed, 10 May 2017 05:53:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 10 May 2017 12:53:16 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/170#comment:4 Message-ID: <037.cf9a26445081cd09e3a5f02e69eccb34@ietf.org> References: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:53:20 -0000 #170: Allow for separate SCT and STH keys? -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Comment (by linus@…): From https://mailarchive.ietf.org/arch/msg/trans/slDhAuH3WW1AvX9wManfViWe4fg: "I withdraw my support for separate keys for signing SCT's and STH's and will update #170 to reflect this." -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Wed May 10 07:29:30 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E166A129BA9 for ; Wed, 10 May 2017 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNcJqDwV77Ga; Wed, 10 May 2017 07:29:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E9F129B8D; Wed, 10 May 2017 07:29:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Wed, 10 May 2017 14:29:12 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/167#comment:4 Message-ID: <037.cc7f850d4a48a5dcd4e6244027ca322c@ietf.org> References: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #167: Define "incorporate" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:29:29 -0000 #167: Define "incorporate" -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: Committed in https://github.com/google/certificate-transparency- rfcs/commit/1916b9a570a718588b80aaafc3168f4b9464172c, please review. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 11 08:35:28 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885A11314CE for ; Thu, 11 May 2017 08:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYNiQXxHEY17; Thu, 11 May 2017 08:35:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E7212EC5F; Thu, 11 May 2017 08:29:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 11 May 2017 15:29:47 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/190 Message-ID: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> X-Trac-Ticket-ID: 190 Archived-At: Subject: [Trans] [Public Notary Transparency Wiki] #190: Simplify data structures in 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:35:27 -0000 #190: Simplify data structures in 6962-bis -------------------------+--------------------- Reporter: eranm@… | Owner: eranm@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+--------------------- 6962-bis has data structures that aren't really useful: X509ChainEntry / PrecertChainEntryV2 They are only used in the return value for get-entries, where a simpler, JSON output can be used. Also their names end with 'Entry', hinting these are log entries, but they are not. See if there are any additional data structures that can be removed/simplified or renamed to reflect their true meaning. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 11 08:36: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 726B912EC67 for ; Thu, 11 May 2017 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do3_Fv79jHCk; Thu, 11 May 2017 08:36:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB312EC04; Thu, 11 May 2017 08:30:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 11 May 2017 15:30:14 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/179#comment:5 Message-ID: <037.b218c648b8e234c86c98e4656cdc034e@ietf.org> References: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #179: Indicate certificate / precertificate in Entry and SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:36:03 -0000 #179: Indicate certificate / precertificate in Entry and SCT -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * milestone: => review Comment: Suggest closing this ticket as a duplicate of https://trac.ietf.org/trac/trans/ticket/190. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 11 08:44: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 0EB62131476 for ; Thu, 11 May 2017 08:44:09 -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 1L9LESZ56gaA for ; Thu, 11 May 2017 08:44:07 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 57D7013144A for ; Thu, 11 May 2017 08:38:01 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o12so23855652iod.3 for ; Thu, 11 May 2017 08:38:01 -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=BGYorYdoWbUg+oA6/xzLPIUBdkl3Us8l0G4Eazkw5j8=; b=SQSo8BGpcmYvvOE1/yh8XbgO4hjqDIRxGW14486KEDM5wpM21npLxwVvp45mVRjQMe +pmfmsvLjYrYYO7njq9+gTtN/rhPkcdomrN/WX1gMByFAgB+Xe8cWo5Jo79qezMEYqh2 ro+4ZvKuwJHO/WXpB08EdwfZYVxGLnb/pVaZNSF3R6NZ7MoYqfikVWqSent5k1vAkl52 G5l1gRIAtOKVlovuTGKMhLf9LmeLbJ7E6gAvT2uOiqpLX5U7bbyukesmt+b+JHvZWMAt fnvc50cQ1vRRi6itap4bWUS8K695uhMjhFYSU6nSiqRKgyCpoUBy3XmemoVeI+h+GiSz PG6A== 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=BGYorYdoWbUg+oA6/xzLPIUBdkl3Us8l0G4Eazkw5j8=; b=ohamZxzdeAcdPHNNlDkTqUNm4YCyV1ZbuWF81QlmnToyFvQOOJus9hY7QO6/VMrA/W IwHmUAFw14p14uzqfJsJT0VO8MghYtCbRxuAG6GPQ8VOFV7TxeLkZAXGE1jirwBMzQrG 7aGYhvsAIkcTFFXa3T5Yu58bf1OCqUir1UNvZ+UPL3UxWgtFLKgkzll/TL8npnRbzrwe D63yJSV9v6TozRUlvX6OmchZMFBo4J8WK3d39uWHZcsaMrGiWpyI4RFauxBMXlj0VuAv f+aFYFJmZNyPObem05DoKVdXT4Coi0qe1TFkrUY224RZizU6xoYAVgN4tyuGOQkkRlOT Soqw== X-Gm-Message-State: AODbwcBxVRsiRn2iBOTLkuNMCXb663ArgJOU5fmeJmLEHiAefjBY733p sMkTzUVlkZBnp+BgXbKbbevru4BSJo5v4VRFtw== X-Received: by 10.107.184.9 with SMTP id i9mr988017iof.153.1494517080272; Thu, 11 May 2017 08:38:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Thu, 11 May 2017 08:37:29 -0700 (PDT) From: Eran Messeri Date: Thu, 11 May 2017 16:37:29 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06d100ae98da054f415f3f" Archived-At: Subject: [Trans] Seeking feedback: Simplification of get-entries in 6962-bis and associated data structures 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, 11 May 2017 15:44:09 -0000 --94eb2c06d100ae98da054f415f3f Content-Type: text/plain; charset="UTF-8" I'm looking for feedback on the following proposal: - Make 'get-entries' in 6962-bis return the submission as-is (i.e., a JSON object with the submitted certificate / precertificate and associated chain). - Remove the X509ChainEntry and PrecertChainEntryV2 structures, whose sole use is a container for the submission that can be put in a TransItem. This proposal has the following benefits: - The get-entries output mirrors the submission input, making it easier to reason about. - Parsing the output of get-entries would only require JSON & base64 decoding, not TLS decoding anything: The whole purpose behind CT logs is storing certificates, this change makes it easier to parse them. - The spec would be simpler, removing two data structures which aren't really used in the log's internal structure, making it clearer what's up to the implementation to decide and what's required by the spec. This would resolve issues 190 and 176 . A preview of the change could be found here . Thanks, Eran --94eb2c06d100ae98da054f415f3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm looking for feedback on the following proposal:- Make 'get-entries' in 6962-bis return the submission as-is (i.e= ., a JSON object with the submitted certificate / precertificate and associ= ated chain).
- Remove the =C2=A0X509ChainEntry and =C2=A0PrecertC= hainEntryV2 structures, whose sole use is a container for the submission th= at can be put in a TransItem.

This proposal has th= e following benefits:
- The get-entries output mirrors the submis= sion input, making it easier to reason about.
- Parsing the outpu= t of get-entries would only require JSON & base64 decoding, not TLS dec= oding anything: The whole purpose behind CT logs is storing certificates, t= his change makes it easier to parse them.
- The spec would be sim= pler, removing two data structures which aren't really used in the log&= #39;s internal structure, making it clearer what's up to the implementa= tion to decide and what's required by the spec.=C2=A0

This would resolve issues 190=C2=A0and=C2=A0176.

A preview of the change= could be found here.

Thanks,
Eran=
--94eb2c06d100ae98da054f415f3f-- From nobody Thu May 11 13:50: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 C37E312E85B for ; Thu, 11 May 2017 13:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SETNRA69_YXY; Thu, 11 May 2017 13:50:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A117A12EABA; Thu, 11 May 2017 13:44:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 11 May 2017 20:44:45 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/170#comment:5 Message-ID: <037.cb8ff323b0793062e497f69d4fd6cc41@ietf.org> References: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <022.9d8a06990859596aaa23fdb00d6774bc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #170: Allow for separate SCT and STH keys? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:50:05 -0000 #170: Allow for separate SCT and STH keys? -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => wontfix -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 11 13:50: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 670B3131483 for ; Thu, 11 May 2017 13:50:57 -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 i2f-0gwD_faG for ; Thu, 11 May 2017 13:50:56 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 02FB9129AB7 for ; Thu, 11 May 2017 13:45:28 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e64so19337170pfd.1 for ; Thu, 11 May 2017 13:45:27 -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=WdV9Vv4nu+VQ+LnDCYYtnAr8H8/pbQ7yhPOKc3IoBq0=; b=u6kUUsQp5vBmrlO/5Fp7/4ei1KHIP+wwofiEQ81kzJWTqAl/X5uFjvN+fchBnaQT+y NplVYcJUrpHHuEZitATO9GbE7S5o9sJNX2cC8nBM1b2HwmFRjqsc4ss9XX5tVjm0l/w8 xk/zJI1/DMqja13O8hoObGYjlFA9qHuGSA8TRU2mIo88pN3lfT2WQbsj+Y73zfINKzGY w+hsALk7PQf2oto+J3/4JIh8BA6jiYbYy9FL2FBedc9h5Dz84eD8w5UPv7el1qdjD+3Z m4MZG5CeLHXcq0Io5k5UXjaoFC1HfN/NfEJ5HJyAJjF5F2WfwFEc+zb1NtHTLzMNi0d+ sUMg== 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=WdV9Vv4nu+VQ+LnDCYYtnAr8H8/pbQ7yhPOKc3IoBq0=; b=Ud41B0SgIkhF+cXr8ZR7v8sXRwp+RUY0iwhqRhe1TYnpuyYZfRP1TJ+iQRvKYqUAVI 2NBBIr0k9EaPv0ca20fvTQyweS4DZ7d+QTuHpnBuLUiR4MAVdudv13JrIwJPUXhbklsy D3ZZB73B47+oKshu3GocSs0QyiTCDXhP1hzy4p/93/vztkOI+O5EyIbxwWRr3oBc19oz r6+LiMSSV3asESaw3gOy41KPur9+NDwnXpbNMk23Qk3Dg5iCNqu/uIFrXhbxKFANeW0q 9ypIMGKQ/ffaNxZ2ofCIRGyC4DmyoC900N0WuWuK8RWCfO2pur+kl6sbR58D0vggs+HQ W98A== X-Gm-Message-State: AODbwcAoBF9cZhMt8Y6H1PqmIZHGaMJapnEAavNZOLHo8A1WbO4S65KW PCYuJdqxpJlr9Kz4mHs= X-Received: by 10.98.147.26 with SMTP id b26mr436803pfe.65.1494535527417; Thu, 11 May 2017 13:45:27 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (66-230-113-158-radius.dynamic.acsalaska.net. [66.230.113.158]) by smtp.gmail.com with ESMTPSA id c7sm1968901pfk.103.2017.05.11.13.45.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 13:45:26 -0700 (PDT) To: trans@ietf.org References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> <87k25ozxhi.fsf@nordberg.se> From: Melinda Shore Message-ID: <7e808ebf-ad96-5c7f-0d3a-486d9aa62a72@gmail.com> Date: Thu, 11 May 2017 12:45:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87k25ozxhi.fsf@nordberg.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="F6UUkml1GrhRTNDRFfchjdEmf4cJGS1nu" Archived-At: Subject: Re: [Trans] Ticket 170 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, 11 May 2017 20:50:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F6UUkml1GrhRTNDRFfchjdEmf4cJGS1nu Content-Type: multipart/mixed; boundary="q169xePtl3JjrTl9gGo3xLjEXSMNMCAAm"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <7e808ebf-ad96-5c7f-0d3a-486d9aa62a72@gmail.com> Subject: Re: [Trans] Ticket 170 References: <4058f163-97f9-2ba3-8730-f2f2e0b0bb5d@gmail.com> <20170509113826.69c9822ecca8b7ba833df719@andrewayer.name> <319e0da7-2daa-e6eb-140a-17a9eb51d7cf@gmail.com> <87k25ozxhi.fsf@nordberg.se> In-Reply-To: <87k25ozxhi.fsf@nordberg.se> --q169xePtl3JjrTl9gGo3xLjEXSMNMCAAm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you, Linus. I've closed the ticket as "wontfix." Melinda --q169xePtl3JjrTl9gGo3xLjEXSMNMCAAm-- --F6UUkml1GrhRTNDRFfchjdEmf4cJGS1nu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZFM1kAAoJELiGRpM6HoEukAYQAJV6nD5ZheYXcfNoDHEOlXwW H4oVE34FvGxQnO5NQIo/1sE3bNCXA2d2tn0PZE+m3LdsWlgo/3MGJKCAbfYwH/qc GhJtUymLPnjG1BprtjdktVEFiVYh4Ov6eydEjfhlwatH0z0pPkQHa1+7fbZhaeeq PIpBnZObgz7bvHH2kEK8MXE+Xevh+F4D9CY8ZdAlZu0uWGeHfpK8wpVjXaZ3zySa Dm1YKLq3hHYojyepx7JHcXvTX36mZ+XmtNx664cL9Xl/AVD0/CJ224ivotihTpzw xog/T6j3OTDnYBe2aoToSzrlF9nmBPyQgt212YPqh7YZnpJ55R8+aVGqid36MGUL lrN/hrOjViX6UeDrg0yVTxv2Gecj7+TT+1A4K1/V+DpetnU6iD3b2TFtiBDzkkWr xL60pcTosVTQpnr7hklaeY6egBwr/p6yOHjM/LnWZ2xDLrUgh9+AtnNIcP57t+jY SINjPY/zPmbTCxffCjOgjdOc/kpiMtlAz39Z4rUTCciEuKpZ29tIRBUi/mB2+K3D etX06dJxuVFLn+wf7RJIPWp9eB4w/CGzf/yyVZD5M8bbqkC9rZ+/SQLS5Pl8NQaJ 5fqDpZhRbazNIZjKu8KGJv0nzRgPLLX4mJI3o2gMDtbX3T8aYDLJG9svDC1YWfOR 5x+OQ6b2S0Mbcab3uE9G =ATpl -----END PGP SIGNATURE----- --F6UUkml1GrhRTNDRFfchjdEmf4cJGS1nu-- From nobody Thu May 11 13:52: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 2049212EC9A for ; Thu, 11 May 2017 13:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoqI-VbnKrL6; Thu, 11 May 2017 13:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0D1314CF; Thu, 11 May 2017 13:46:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 11 May 2017 20:46:25 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/167#comment:5 Message-ID: <037.0d671c231871666d0ddedace7ca64529@ietf.org> References: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> X-Trac-Ticket-ID: 167 In-Reply-To: <022.939ff09b1ad711b922b654bfb738621a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #167: Define "incorporate" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:52:09 -0000 #167: Define "incorporate" -------------------------+---------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+---------------------- Changes (by melinda.shore@…): * status: assigned => closed * resolution: => fixed -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Thu May 11 13:53: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 D4EED12EA98 for ; Thu, 11 May 2017 13:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErpyeMz3LxbY; Thu, 11 May 2017 13:53:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBCB129B5D; Thu, 11 May 2017 13:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Thu, 11 May 2017 20:47:13 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/179#comment:6 Message-ID: <037.00ef6c56a2a9273e31c0452ac3ae6fed@ietf.org> References: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> X-Trac-Ticket-ID: 179 In-Reply-To: <022.c4deaa956f97aaf7d924c4d1ddc41cbf@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #179: Indicate certificate / precertificate in Entry and SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:53:05 -0000 #179: Indicate certificate / precertificate in Entry and SCT -------------------------+------------------------ Reporter: rlb@… | Owner: eranm@… Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: duplicate Keywords: | -------------------------+------------------------ Changes (by melinda.shore@…): * status: assigned => closed * resolution: => duplicate -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 12 01:47: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 5799C12EA7F for ; Fri, 12 May 2017 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIjo6lXCW706; Fri, 12 May 2017 01:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 862251298A1; Fri, 12 May 2017 01:42:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 12 May 2017 08:42:43 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/175#comment:4 Message-ID: <037.c9d39473ce986ef8050ab8fbf1a1c18f@ietf.org> References: <022.1197840a8a29deb402e60d707464842f@ietf.org> X-Trac-Ticket-ID: 175 In-Reply-To: <022.1197840a8a29deb402e60d707464842f@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #175: Clarify guarantees around MMD, STH age X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 08:47:46 -0000 #175: Clarify guarantees around MMD, STH age -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned Comment: Out for review in https://github.com/google/certificate-transparency- rfcs/pull/257 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 12 03:38: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 B9288129ADC for ; Fri, 12 May 2017 03:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Cmj-gIXr-y; Fri, 12 May 2017 03:38:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5121294BC; Fri, 12 May 2017 03:32:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 12 May 2017 10:32:09 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/164#comment:2 Message-ID: <037.836ae66da2ff410cd6b9f4e2ead26206@ietf.org> References: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <022.cb417955443b987d41bd54530fd8fa72@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #164: Incorporate new protocol mechanisms into TLS Client section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 10:38:34 -0000 #164: Incorporate new protocol mechanisms into TLS Client section -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis Comment: Re-reading the "TLS Clients" section (now 8.1) It seems to me this is covered pretty well. There's some repetition there, which I've fixed in this PR: https://github.com/google/certificate-transparency-rfcs/pull/258 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 12 03:43: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 68DF812EB4D for ; Fri, 12 May 2017 03:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1N3NDf0TvO3; Fri, 12 May 2017 03:43:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8111D127B52; Fri, 12 May 2017 03:37:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 12 May 2017 10:37:37 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/176#comment:3 Message-ID: <037.c508ced2f26e8e697fef629d60c1f893@ietf.org> References: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <022.a61c2efd583cb5d6d92a69e29e45826a@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 10:43:26 -0000 #176: Remove `X509ChainEntry` and `PrecertChainEntryV2` -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned Comment: I've proposed this in: https://www.ietf.org/mail-archive/web/trans/current/msg02936.html And there's a PR: https://github.com/google/certificate-transparency-rfcs/pull/256 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 12 04:21: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 EB5B112F253 for ; Fri, 12 May 2017 04:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsAR8SrsxqXB; Fri, 12 May 2017 04:21:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB4213013D; Fri, 12 May 2017 04:15:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Fri, 12 May 2017 11:15:00 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/178#comment:4 Message-ID: <037.804e9e703a09fdea05739337a5646b8d@ietf.org> References: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> X-Trac-Ticket-ID: 178 In-Reply-To: <022.a550ca4084a919cdc9173ec2b964eb58@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #178: Add description of how to validate an SCT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 11:21:20 -0000 #178: Add description of how to validate an SCT -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned Comment: Out for review: https://github.com/google/certificate-transparency-rfcs/pull/259 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Fri May 12 06:32: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 3B15612EB84 for ; Fri, 12 May 2017 06:32: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 O0LQVdt8NlS0 for ; Fri, 12 May 2017 06:32:50 -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 37EC812EB71 for ; Fri, 12 May 2017 06:27:36 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id o5so10454577ith.1 for ; Fri, 12 May 2017 06:27:36 -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=csRVG+kTvqBniH9va8z+NTgJUXehERQwC6XvQuyfMj0=; b=hxXW1rzYH8XqG16Fw1u444JnwK67+Vl4ANi3IIHXCmQM99hMjFkacozqsoD3oL9pzF CaeVkQg1pJJHVnfsanwwGQ8LGu9Ll5V7vyxZBdnpb2GIJkoXVa1qNx1MMiUadSewj4vO UPDyCNCrCT1h66S/UEPeT9r1D0EyWtOyCMcZoW2xH2+302cR+qFKZ90D/kqZrJwyK29L HmhcvMUsYLHxXZpLh66C5xj3KbhaUhMWwfJ7JR2lQIgG+L8tyDAmcVDCFfjCrcDHwhXI +HJbqghaPttcGKPbDPrCdfdLdr+b+Ys0XU7ACXXMn2lFpFX5LbVwwCXowrM+8g1mW3br dg6w== 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=csRVG+kTvqBniH9va8z+NTgJUXehERQwC6XvQuyfMj0=; b=kKc7Kf/ZqzCO9UxMc1NlqkRMwF8MTlU1rg+0zb1XnLZR1V/nCD5pfWaYcayif9ncKy esskMle2JGM7c/eWwPXwMIo5TNw/QciPNrytUgdQMOa1wsBFJHGh9+lpEBEJgF3a5JOc WrcVbs11Uq21ck1BJBELNKULQEGvXGxdoeHtDXZdhZP2GeCMFmthsILFgmwGcvmp2yez Jex0rTTVQz3aOdM6YkyNoENFC5Tit1AiE0w6exhCWQulPxbocfi2Cw5ldmTKRxQ+IAxN +CFrwVy144kGb9veK0S8lxw8sUbJOM0nRFJmAm9jHyk4Ha+43hqup9MFkrVXJJf0+upC W8yg== X-Gm-Message-State: AODbwcC5Bft1QdnPxT2PdkYiH1Zm9Z/5uenJiA5V5QCfjgTA89NLTlQF enTWg+D/WYfRduGKGUQ/5S4eNUJrim3waiS4XA== X-Received: by 10.36.3.13 with SMTP id e13mr3589328ite.112.1494595655305; Fri, 12 May 2017 06:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Fri, 12 May 2017 06:27:04 -0700 (PDT) In-Reply-To: References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> From: Eran Messeri Date: Fri, 12 May 2017 14:27:04 +0100 Message-ID: To: Richard Barnes Cc: Andrew Ayer , Trans Content-Type: multipart/alternative; boundary="001a11419bfa1e8b61054f53ab10" Archived-At: Subject: Re: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 12 May 2017 13:32:53 -0000 --001a11419bfa1e8b61054f53ab10 Content-Type: text/plain; charset="UTF-8" (follow-up from an out-of-band discussion with Andrew) The concern Andrew has raised,of some implementations accepting a null values, it is very valid. Fortunately, it's easy to check that logs do not behave that way. An alternative approach to unifying add-chain/add-pre-chain is to have a single add-entry call which takes, as inputs: 'submission' - base64-encoded DER certificate OR CMS Precertificate. 'chain' - chaining the submission to a root, like now. 'is_precertificate' - indicating whether the 'submission' parameter should be parsed as a DER-encoded certificate or CMS Precertificate. Any opinions on that? Personally I think the concern Andrew has raised is very valid and the spec should explicitly deal with it, forbidding the presence of an empty 'precertificate' parameter if a 'certificate' is being supplied, and vice versa, and logs can easily be checked for compliance with that requirement. However I'm also OK with leaving add-chain / add-pre-chain as separate methods. Eran On Thu, May 4, 2017 at 7:24 PM, Richard Barnes wrote: > TBH, I don't feel very strongly about this. Andrew's analysis seems > pretty sound. > > On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer wrote: > >> Regarding https://github.com/google/certificate-transparency-rfcs/pull >> /248 >> >> I do not think this is a good change. >> >> If an implementation wants to use a struct to represent the add-entry >> message (as Google's Golang CT library currently does), the struct would >> need to contain nullable variables for the certificate and >> precertificate fields. Nullable variables are error-prone and are best >> avoided if possible. >> >> For example, a client might accidentally send null as one of these >> fields instead of omitting it (with Go, this can easily happen if you >> forget to tag the struct field as omitempty). Although this would be a >> malformed add-entry message, I expect many servers would accept it >> because many JSON deserializers I've seen (such as Go's) do not >> distinguish between a null struct field and an omitted struct field. >> This risks causing interoperability problems. I expect the predominant >> 6962-bis log server will be Google's Trillian, which means clients will >> be interacting mostly with log servers which exhibit the lax >> deserialization behavior. The client's mistake won't be noticed until >> it tries to submit a chain to a rarer, stricter server, which might >> happen long after the client code has been deployed. >> >> Therefore, I favor keeping add-chain and add-pre-cert as separate >> endpoints. That way, the structure of the messages are rigid and >> clearly indicated by the name of the endpoint. The protocol will have >> only one joint (the endpoint name) instead of two (the endpoint name >> plus the presence or absence of the precertificate and certificate >> fields). >> >> Regards, >> Andrew >> >> _______________________________________________ >> 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 > > --001a11419bfa1e8b61054f53ab10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(follow-up from an out-of-band discussion with Andrew)The concern Andrew has raised,of some implementations accepting a null val= ues, it is very valid. Fortunately, it's easy to check that logs do not= behave that way.

An alternative approach to unify= ing add-chain/add-pre-chain =C2=A0is to have a single add-entry call which = takes, as inputs:
'submission' - base64-encoded DER certi= ficate OR CMS Precertificate.
'chain' - chaining the subm= ission to a root, like now.
'is_precertificate' - indicat= ing whether the 'submission' parameter should be parsed as a DER-en= coded certificate or CMS Precertificate.

Any opini= ons on that?

Personally I think the concern Andrew= has raised is very valid and the spec should explicitly deal with it, forb= idding the presence of an empty 'precertificate' parameter if a = 9;certificate' is being supplied, and vice versa, and logs can easily b= e checked for compliance with that requirement.

Ho= wever I'm also OK with leaving add-chain / add-pre-chain as separate me= thods.

Eran
=
On Thu, May 4, 2017 at 7:24 PM, Richard Barn= es <rl= b@ipv.sx> wrote:
TBH, I don't feel very strongly about this.=C2=A0 Andrew's= analysis seems pretty sound.

On Thu, May 4= , 2017 at 11:25 AM, Andrew Ayer <agwa@andrewayer.name> wr= ote:
Regarding https://github.com/google/certificate-transparency-rfcs/p= ull/248

I do not think this is a good change.

If an implementation wants to use a struct to represent the add-entry
message (as Google's Golang CT library currently does), the struct woul= d
need to contain nullable variables for the certificate and
precertificate fields.=C2=A0 Nullable variables are error-prone and are bes= t
avoided if possible.

For example, a client might accidentally send null as one of these
fields instead of omitting it (with Go, this can easily happen if you
forget to tag the struct field as omitempty).=C2=A0 Although this would be = a
malformed add-entry message, I expect many servers would accept it
because many JSON deserializers I've seen (such as Go's) do not
distinguish between a null struct field and an omitted struct field.
This risks causing interoperability problems.=C2=A0 I expect the predominan= t
6962-bis log server will be Google's Trillian, which means clients will=
be interacting mostly with log servers which exhibit the lax
deserialization behavior. The client's mistake won't be noticed unt= il
it tries to submit a chain to a rarer, stricter server, which might
happen long after the client code has been deployed.

Therefore, I favor keeping add-chain and add-pre-cert as separate
endpoints.=C2=A0 That way, the structure of the messages are rigid and
clearly indicated by the name of the endpoint.=C2=A0 The protocol will have=
only one joint (the endpoint name) instead of two (the endpoint name
plus the presence or absence of the precertificate and certificate
fields).

Regards,
Andrew

_______________________________________________
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


--001a11419bfa1e8b61054f53ab10-- From nobody Fri May 12 06:42: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 B57BA12EC08 for ; Fri, 12 May 2017 06:42: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 H9FI8ch24Spy for ; Fri, 12 May 2017 06:42:05 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582DB129AE8 for ; Fri, 12 May 2017 06:36:35 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id o5so10609747ith.1 for ; Fri, 12 May 2017 06:36:35 -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=ttCCsnRGvdwDNyC/4OvrsZpNOW3c+oU9I6RdTti40DE=; b=vfuYmgw9CEwQ1w17CV/mzdPltzLkSd1zLfyQSdhLEfBgbMstvuzvQa5N6QC+iuII3V hocZvERMx11DKV+MVASkzCeU4HLnUgeI6mu+HW6fTjlcBUfSZNvQf5OK4GXpRciVC3Wt kaPcsYx4lH3gUZF6y920Osu4rd974AnhGb9yxiPwcpgyvrGXgzUo0jxkRpvgoK/zWhXo QfP4ZI2l2/OA4aruhx/vXvTt3H+qMYmkc4vhorDckvgjj6rYjmJFFhEautCx8jVzdojp 9lPdb1V1h8TrB3wpZ91z9u1v2WsKHqeAk64ctlW7cgyhB41qgKroC1CU/F85JUUkTEhs umLg== 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=ttCCsnRGvdwDNyC/4OvrsZpNOW3c+oU9I6RdTti40DE=; b=DddmpBaTUTltbv1/LdD04B4oiNo/LBKqWhBOaC1a/jvZaExAi2K36wZ72TUIkpndkK uCQMmwSZMlZvXsLu3XngmEc0m/BNaVV/CU1CfADDJiYE7tfkqNbCjJ4BS4uPirYtQWMs 0N9HpB2/fBswgQKHncX57IpmbW8kfIeQb4QU9bEdAD2M+AizlGDayHtPBKJwCyGbibB0 NpJQUFaUCrACopqPz8Wlt8gvwbABEgfGmqid29DBvnf4lNvkhAZf0yy1ABFLDy2JrdIi EpD83iGszDzWT7cyD2gTby+aeswjLaGic0K00QLNPptgzFYeD8VhjWyVRINNpZRjRcN7 01vQ== X-Gm-Message-State: AODbwcDETE2NT449/+YS68wdkO5xm9KPdGRK+s0BhH8DDgVBNm0nzmkH nRnC+AtXEBbqKWEz3pKWwLyzJWp7A7Yl6bM= X-Received: by 10.36.55.149 with SMTP id r143mr3132224itr.53.1494596194565; Fri, 12 May 2017 06:36:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Fri, 12 May 2017 06:36:04 -0700 (PDT) In-Reply-To: References: <87pofiif6g.fsf@nordberg.se> From: Eran Messeri Date: Fri, 12 May 2017 14:36:04 +0100 Message-ID: To: Tom Ritter Cc: Linus Nordberg , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1140c83842dfa3054f53cb72" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 12 May 2017 13:42:08 -0000 --001a1140c83842dfa3054f53cb72 Content-Type: text/plain; charset="UTF-8" Thanks for the feedback. It helped me realize deterministic signatures could be achieved not only by using a deterministic signature scheme, but also by logs storing the produced signatures and returning them instead of re-signing SCTs, for example. That's my understanding of the discussion so far: * Requiring the use of RFC6979 is bad, for the reasons Brian has mentioned. * It is not yet clear where deterministic signatures may be more important (SCTs or STHs) because it's not clear what TLS clients will gossip and how. * It is not necessary to require the use of a deterministic signature scheme - only that the same signature is present in all instances of a particular SCT (note that different SCTs for the same submission, with different timestamps, which the log may issue, cannot have the same signature). Also, in 6962-bis, my focus is on correct operation of the log & Merkle Tree - and deterministic signatures are not strictly necessary for that. To make progress on this issue, I propose the following: * Remove references to 6979. * Remove the strong requirement to use deterministic signature schemes (MUST -> SHOULD), so implementations can use non-deterministic signature schemes and still be compliant with the spec. * Add reference to EdDSA, which includes a deterministic signature scheme variant. * Mention that deterministic signatures can be achieved by storing the produced signatures. Any objections? On Tue, May 9, 2017 at 6:43 PM, Tom Ritter wrote: > On 9 May 2017 at 03:53, Linus Nordberg wrote: > > Tom Ritter wrote > > Mon, 8 May 2017 12:38:45 -0500: > > > >> Anyway, so I still think there's fingerprinting concerns. But even if > >> we require deterministic signatures - if the log *wants* to be > >> malicious, it can still issue non-deterministic signatures, and > >> there's no way to know, because as I said above - detection is hard. > > > > You seem to focus on SCTs, which are indeed hard to share between > > privacy concerned clients because they contain sensitive data. But STHs > > have signatures too and I think we should limit the ways a log can track > > clients asking for STHs. > > > > Catching a log serving different log clients different bits for the same > > timestamp, tree_size and root_hash is a matter of clients comparing > > retrieved STHs. Keeping the requirement for deterministic signatures and > > the limitation on STH issuance frequency (6962bis-24 4.8) makes > > gossiping about STHs reasonable even for clients serving end users with > > privacy expectations (gossip-04 10.5.4). > > I agree that we could catch logs who do this to STHs relatively easily. > > >> So I think Eran's suggested changes are okay. > > > > I think we should keep requiring deterministic signatures being used but > > stop mandating how it is being done. > > Definitely agree that we not mandate how it is done. > > I guess I'm more on the fence now because of the STH situation. > > -tom > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1140c83842dfa3054f53cb72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feedback. It helped me realize deterministi= c signatures could be achieved not only by using a deterministic signature = scheme, but also by logs storing the produced signatures and returning them= instead of re-signing SCTs, for example.

That's my = understanding of the discussion so far:
* Requiring the use of RF= C6979 is bad, for the reasons Brian has mentioned.
* It is not ye= t clear where deterministic signatures may be more important (SCTs or STHs)= because it's not clear what TLS clients will gossip and how.
* It is not necessary to require the use of a deterministic signature sche= me - only that the same signature is present in all instances of a particul= ar SCT (note that different SCTs for the same submission, with different ti= mestamps, which the log may issue, cannot have the same signature).
Also, in 6962-bis, my focus is on correct operation of the log & Mer= kle Tree - and deterministic signatures are not strictly necessary for that= .

To make progress on this issue, I propose the fo= llowing:
* Remove references to 6979.
* Remove the stro= ng requirement to use deterministic signature schemes (MUST -> SHOULD), = so implementations can use non-deterministic signature schemes and still be= compliant with the spec.
* Add reference to EdDSA, which include= s a deterministic signature scheme variant.
* Mention that determ= inistic signatures can be achieved by storing the produced signatures.

Any objections?


=

On Tue, May 9, 2017 at 6:43 PM, Tom Ritter <tom@ritter.vg> wr= ote:
On 9 May 2017 at 03= :53, Linus Nordberg <linus@sunet.se> wrote:
> Tom Ritter <tom@ritter.vg> = wrote
> Mon, 8 May 2017 12:38:45 -0500:
>
>> Anyway, so I still think there's fingerprinting concerns. But = even if
>> we require deterministic signatures - if the log *wants* to be
>> malicious, it can still issue non-deterministic signatures, and >> there's no way to know, because as I said above - detection is= hard.
>
> You seem to focus on SCTs, which are indeed hard to share between
> privacy concerned clients because they contain sensitive data. But STH= s
> have signatures too and I think we should limit the ways a log can tra= ck
> clients asking for STHs.
>
> Catching a log serving different log clients different bits for the sa= me
> timestamp, tree_size and root_hash is a matter of clients comparing > retrieved STHs. Keeping the requirement for deterministic signatures a= nd
> the limitation on STH issuance frequency (6962bis-24 4.8) makes
> gossiping about STHs reasonable even for clients serving end users wit= h
> privacy expectations (gossip-04 10.5.4).

I agree that we could catch logs who do this to STHs relatively easi= ly.

>> So I think Eran's suggested changes are okay.
>
> I think we should keep requiring deterministic signatures being used b= ut
> stop mandating how it is being done.

Definitely agree that we not mandate how it is done.

I guess I'm more on the fence now because of the STH situation.

-tom

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

--001a1140c83842dfa3054f53cb72-- From nobody Fri May 12 07:01: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 3C0671205D3 for ; Fri, 12 May 2017 07:01:46 -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 Zd6xJBz8TapL for ; Fri, 12 May 2017 07:01:42 -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 E3EA012EC12 for ; Fri, 12 May 2017 06:55:48 -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 v4CDtiLm017880 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 15:55:44 +0200 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 v4CDtfcu009886 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 13:55:44 GMT From: Linus Nordberg To: Eran Messeri Cc: trans@ietf.org Organization: Sunet References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> Date: Fri, 12 May 2017 15:55:51 +0200 In-Reply-To: (Eran Messeri's message of "Fri, 12 May 2017 14:27:04 +0100") Message-ID: <8760h6i3h4.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: 0aTjpTIEi - 8d0437c5e735 - 20170512 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] Consolidating add-chain and add-pre-chain endpoints 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, 12 May 2017 14:01:46 -0000 I like the single add-entry call idea together with the explicit 'is_precertificate' indication. The naming here is a bit unfortunate though, at least when compared with PR 256 [1] where 'submission' seems to mean end-entity-(pre)cert _and_ chain. I suggest making the input to an add-entry call and the output from the get-entries call identical, if at all possible. [1] https://github.com/google/certificate-transparency-rfcs/pull/256/files Eran Messeri wrote Fri, 12 May 2017 14:27:04 +0100: > (follow-up from an out-of-band discussion with Andrew) > The concern Andrew has raised,of some implementations accepting a null > values, it is very valid. Fortunately, it's easy to check that logs do not > behave that way. > > An alternative approach to unifying add-chain/add-pre-chain is to have a > single add-entry call which takes, as inputs: > 'submission' - base64-encoded DER certificate OR CMS Precertificate. > 'chain' - chaining the submission to a root, like now. > 'is_precertificate' - indicating whether the 'submission' parameter should > be parsed as a DER-encoded certificate or CMS Precertificate. > > Any opinions on that? > > Personally I think the concern Andrew has raised is very valid and the spec > should explicitly deal with it, forbidding the presence of an empty > 'precertificate' parameter if a 'certificate' is being supplied, and vice > versa, and logs can easily be checked for compliance with that requirement. > > However I'm also OK with leaving add-chain / add-pre-chain as separate > methods. > > Eran > > On Thu, May 4, 2017 at 7:24 PM, Richard Barnes wrote: > >> TBH, I don't feel very strongly about this. Andrew's analysis seems >> pretty sound. >> >> On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer wrote: >> >>> Regarding https://github.com/google/certificate-transparency-rfcs/pull>> /248 >>> >>> I do not think this is a good change. >>> >>> If an implementation wants to use a struct to represent the add-entry >>> message (as Google's Golang CT library currently does), the struct would >>> need to contain nullable variables for the certificate and >>> precertificate fields. Nullable variables are error-prone and are best >>> avoided if possible. >>> >>> For example, a client might accidentally send null as one of these >>> fields instead of omitting it (with Go, this can easily happen if you >>> forget to tag the struct field as omitempty). Although this would be a >>> malformed add-entry message, I expect many servers would accept it >>> because many JSON deserializers I've seen (such as Go's) do not >>> distinguish between a null struct field and an omitted struct field. >>> This risks causing interoperability problems. I expect the predominant >>> 6962-bis log server will be Google's Trillian, which means clients will >>> be interacting mostly with log servers which exhibit the lax >>> deserialization behavior. The client's mistake won't be noticed until >>> it tries to submit a chain to a rarer, stricter server, which might >>> happen long after the client code has been deployed. >>> >>> Therefore, I favor keeping add-chain and add-pre-cert as separate >>> endpoints. That way, the structure of the messages are rigid and >>> clearly indicated by the name of the endpoint. The protocol will have >>> only one joint (the endpoint name) instead of two (the endpoint name >>> plus the presence or absence of the precertificate and certificate >>> fields). >>> >>> Regards, >>> Andrew >>> >>> _______________________________________________ >>> 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> >> > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri May 12 11:44: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 40913129C6A for ; Fri, 12 May 2017 11:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 Za7UmfnGRH_P for ; Fri, 12 May 2017 11:44:37 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 E927712EB84 for ; Fri, 12 May 2017 11:40:35 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k91so45376953ioi.1 for ; Fri, 12 May 2017 11:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qN7UaFiPZI3/3SXAGr+iuEmgzwd7sxOwll0CFdQVp8A=; b=vA7jfItiBe7MMaVKnb7McrOngoi7q6O2/ysMd5XkjM01ZOGuKPOJRoXDEX4DMDI1u/ 9h7Lh0+iOK3oyeYpjRCU08aqS9cgtPOni7DXdI97RHM2XZp2JnoXqM4br9Af6TRT2uP+ zAjfzpup5TzdGKFFClq9o5WJx9N7SULiKZ05ElSoqKXfKA7Nv61E9kMz2UYl1g02pPC9 hckBZLbRtlNcxfkpJq7tVgON8iF4sJw7k2M5k5VJATbkzjGHvxMxGv15zITTy/s9AvJx DgR+BfhFG//39uUUZx+7+vRs92jtBrPmJqm6IXCCFBz5iTAB6DCsGmsHoY8fAzjCx+Il pCIw== 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=qN7UaFiPZI3/3SXAGr+iuEmgzwd7sxOwll0CFdQVp8A=; b=YcEasoptlU68vitF/ZoBKjeadRHJGHjEll+H/3a6kA40rLQCnWo+mHtE4uK5NgcRVh Y1HfPlCtl4xXBgV4j7bNntJWHcNlDCXybWFoCeKbLID9aBfY0kZ2osctptB4PxObxwQb UUCNDGKkDFDqe6jY2nRAbRC87q8p0//iDZsOLQE8qQxma5C3dg3vJeFOTiSh+h7pTNVl e+LMoQ4vu4b0RFW9ztBrI+QxZGQqMnTJH38MR4GBAJMzqsxML+uJPHf++b1TDNNs5dH4 PCVXUM7KJcUqbhSiDF73mb0u5SuQyACrTfbMyl+h3Xp797HHUKetaduDYZVGEzQH/5Vd wUFw== X-Gm-Message-State: AODbwcBGN3XpYFsW7gD3NuCF4mQFadAILeqJUPcVjJvLOI2joZvlz7sN gqiIjkc0ZvhU0jKtLscbWYoowWw3VA== X-Received: by 10.107.12.28 with SMTP id w28mr5298261ioi.209.1494614435212; Fri, 12 May 2017 11:40:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Fri, 12 May 2017 11:40:34 -0700 (PDT) In-Reply-To: References: <87pofiif6g.fsf@nordberg.se> From: Brian Smith Date: Fri, 12 May 2017 08:40:34 -1000 Message-ID: To: Eran Messeri Cc: Tom Ritter , "trans@ietf.org" , Linus Nordberg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 12 May 2017 18:44:38 -0000 Eran Messeri wrote: > * Remove references to 6979. > * Remove the strong requirement to use deterministic signature schemes (MUST > -> SHOULD), so implementations can use non-deterministic signature schemes > and still be compliant with the spec. > * Add reference to EdDSA, which includes a deterministic signature scheme > variant. > * Mention that deterministic signatures can be achieved by storing the > produced signatures. This sounds good to me. I'm not sure that the reference to RFC 6979 needs to be removed. It could be referenced as an example of a deterministic signature scheme. Cheers, Brian From nobody Fri May 12 11:55: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 29B5F12944A for ; Fri, 12 May 2017 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 4Tw121MkAaOT for ; Fri, 12 May 2017 11:55:23 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FB712FEE2 for ; Fri, 12 May 2017 11:51:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id w68so5302853itc.0 for ; Fri, 12 May 2017 11:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=SEHaj5QkswQYoX+CT0iOBKUEEQSDgaFsoBSwiiMP1oo=; b=wJfP2eXi0LWX2U4JM5X7aR9C5Cp7xj572CYpeL9tJyz8hF4G5cI0YBqYC/rg1g9FF1 E6tDAwiUb0biA7NwOxNaWGkFFpNODGwY70nSXtTPtpAdPzWvA+Ff2tyRbuwWfAfAnMTe +Qjd2PXID3YUi68pVNlCq8KfTIM6VZ7XAFHnpfNCcoMD+zv/s/f7M6y+JRmPgxEV3q5q sY8ZTVlzbYnEwoIKz6jWaWk3WSCLg1gUvOLqHBUtTKTTLYZtj2Btbqf2NeF5oK65fMmi CXuvudvAvFvnyyYAdku4BpX7WfzwOI5L+CBbre1zVQTMubVFCexHI8N8mlXlZPJku5Mm F4dw== 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=SEHaj5QkswQYoX+CT0iOBKUEEQSDgaFsoBSwiiMP1oo=; b=GkRANtfhbMyYGVn10uwdemMyPyah2mKVm/8QF+JAbZWg6EFY/R1yn6Qf1tFzuUPruQ V08YZFoWsJmj9JHYQWC7q8ihfH3ULaVZ8tkFVLVysmaFcJIra58zf0tyLXnhHmgKiO22 2XIyEb2wq+fijbAC7Bvx+RyurJy2oGUk/cv7wQ+qM05d8OHPsQZUDuIAdlfq8aerBnfk eNcXSGsQdX1hmpQikMYpX3NTnXV/p/9FXGoeWREgc5DybXGX4eiEcNDixyCCBNoFMqs7 qtnmza2dd5ZdYFr/vqrCCshoQDOX+82d1jalsdZGAnl2nq8HaTXIJhbM8dWGOthu7kfk mhrw== X-Gm-Message-State: AODbwcDki4jUW37uoSTRV8XMaQnespdHBwCIj848TuffCDTsz4qmzict 2UBDm0mACCT199aoNwIfb8Wgic47qTq3Sy8= X-Received: by 10.36.82.85 with SMTP id d82mr2760639itb.13.1494615098807; Fri, 12 May 2017 11:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Fri, 12 May 2017 11:51:38 -0700 (PDT) From: Brian Smith Date: Fri, 12 May 2017 08:51:38 -1000 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Trans] Drop RSA PKCS#1 1.5 signatures; maybe replace with RSA PSS 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, 12 May 2017 18:55:25 -0000 Hi, PKCS#1 1.5 signatures are obsolete. New specifications should not mandate support for them. RSA signatures in general are difficult for some devices to process due to their large size. It would be frustrating to have used a pure ECC infrastructure with no RSA involved at all, only to need to implement RSA for the purpose of verifying signatures from logs. Thus I think the group should consider dropping any mention of RSA signatures from section 10.4.so that log clients do not have to implement RSA. If it really is important to have RSA signatures, then RSA PSS should be used instead. In particular, it would be good to require the same restricted form specified for TLS, where the same digest algorithm must be used for all parts of the signature. Note that RSA PSS can be made deterministic by using a fixed salt, and most implementations of RSA PSS seem to support fixed salts if the salt length is set to zero. As mentioned in the RSA PSS specification, PSS signatures are more secure than PKCS#1 1.5 signatures even with a zero-length salt. Cheers, Brian -- https://briansmith.org/ From nobody Fri May 12 12:08: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 3A06D129A99 for ; Fri, 12 May 2017 12:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 NiEwDAQElwmo for ; Fri, 12 May 2017 12:08:06 -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 0769E129AAA for ; Fri, 12 May 2017 12:02:29 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e64so34286746pfd.1 for ; Fri, 12 May 2017 12:02:29 -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=oh6FKGnir2RKlRGQHABfS/yY/0meiv8pSY/vP+Gb/0E=; b=IWNlKOr6OVZvpkMfWH+E1OGJROlVe9LJAsP/EwLZrGjnzF1POtnkY6CfgVZEBFAOwe whq9RL9/hjqISyvYC6fI4RRbqdWDGO5VmOOw/EsMhTGZ7IhacxJj/ilqx3aYg3wRw2u5 b2nHP6D1DZLNeUC7oB8EUq+8vzXgDtjAQBKA85ZaJzFsnpCJ0IB4DEdLUifjGDeeNG6I ayZoVZPhSaj60Y2DnkSDhpHar12tzQ/iwCOFvKDGBWJZoTgeslPh2fXXApCYyDXCinYc 6cFz4Nu7FfaQ6e5dEb2DRtCaMgS9Pgu4JY/J4A6rmJgPbfPtn7VgiPqOy1mMZt9PtA+l l4pA== 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=oh6FKGnir2RKlRGQHABfS/yY/0meiv8pSY/vP+Gb/0E=; b=JHX8TQkL+f9FbRTYKYKc0PIRWfFc6cihMYK01EmDCNZtlvvvWg2YKvwLLXnkHsDqN0 2KthV7eX9tdlC2lpSYNMPXyT7dXG9YtZ+XZRLxubRHd30cTHKuArGpapZyuSzgllHxWf qMLHDWLsndfmGfINqguvYcFSJoz0EaTLJULrxOk6bG0pOmGODXAR3q7sgcYm4zicGpVh jxZIw9VJWVdod5gm1UM8hbGB3mp10/6Qk1Yry3KYKjWdV29G/NJR9uTctAhkVAuwc5o2 ziNOyQiKT8ADNDDrOEFBhCw8zr8VSXLLVS92jby2IOFqoZ7VAKaVY0LNn9wd5wvLe1yV LzPA== X-Gm-Message-State: AODbwcAeZ8a7sqCg+KOWuYm8l3mkwdohhhCwzS5ajDj4dxUTExSGm/Fb avEHDoHduMtgfA4JAu8= X-Received: by 10.98.89.201 with SMTP id k70mr6095313pfj.196.1494615748261; Fri, 12 May 2017 12:02:28 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (74-124-101-111-radius.dynamic.acsalaska.net. [74.124.101.111]) by smtp.gmail.com with ESMTPSA id r68sm8342671pfd.91.2017.05.12.12.02.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 12:02:27 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <423ef45b-6a1d-62c4-9864-a76efde037c9@gmail.com> Date: Fri, 12 May 2017 11:02:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DEjLODCdInLQjM8s9WJ745cRNvdg6gMdW" Archived-At: Subject: [Trans] Reminder: we'd like to get into wg last call 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, 12 May 2017 19:08:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DEjLODCdInLQjM8s9WJ745cRNvdg6gMdW Content-Type: multipart/mixed; boundary="TRCSgmNLx0r3sssJPHOWsRP8KUfmIe3DW"; protected-headers="v1" From: Melinda Shore To: "trans@ietf.org" Message-ID: <423ef45b-6a1d-62c4-9864-a76efde037c9@gmail.com> Subject: Reminder: we'd like to get into wg last call --TRCSgmNLx0r3sssJPHOWsRP8KUfmIe3DW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: Just a reminder that we're trying to get to working group last call as quickly as possible, and that we need to minimize changes to 6962-bis. At this point proposals have to focus on correcting errors in the document. 6962-bis has to be correct but it does not have to be complete - we can always adopt new documents. Let's get this done. Many thanks, Melinda --TRCSgmNLx0r3sssJPHOWsRP8KUfmIe3DW-- --DEjLODCdInLQjM8s9WJ745cRNvdg6gMdW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZFgbBAAoJELiGRpM6HoEu6w8P/jZ4pFvar0g95JrQgM7x89N+ epDuCqh9SpB79c9KzfLhz1/vgJerwS8DjwNjHcO/p+xq6Z3SdoJr73SMqj2HFVwe W7ViTjA5gm/6hZZP8tu22qXQezYi0tmhRK71vSC6gvNaKRnCXdr7yBSQ+i4BTcNw UBay7Jc7qmxE6rAT1GsISrILKBY9HvWbBEvaaNjZdr4PRH/nhFg0kDu4b7bB1uCs Y8S1KP35YQBm5CDVDFbbMVQ4qIPrB+id1MwedxJKuFpnvMJsjLDk6zzBSmYz/Pk8 h0FdVzIiSHSBRZDLXPv3kapQk3o1nFPWUN1YhSchIq/urS4SKVUgSAvQIzS54RGR IR2+BmsmKMnEMraIW9u0DVum3BXVIjvCa0QJrNC9aVn0HQuIgxXTCHQYMmf5BFil 7LzQ7RGu2DiwJath4miEgbEfzlS5WrIts4hRxbin78feXQrNWjCa6uPTBUiq7o93 npZURi2ACX3syv3w88yNOLrj32LhEMT3cLgEiDxxNUMLFZfmqsqylv+gYqD5GSz9 2s5gFcqP0Hpcqw4Eo3OKaEGucZ/cxyeXnoW7+sY3iUGGGuk8mC4qHAAcIn67QRub u7x/Mu6NlQhDzBzAOGO2f6o5EH1u3FJoHkIr/aYU5lVTJC0Euwu2xn5Xuo1Gux8+ aVjzruC4j17wsmSol+5G =dQmY -----END PGP SIGNATURE----- --DEjLODCdInLQjM8s9WJ745cRNvdg6gMdW-- From nobody Fri May 12 12:23: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 C62CD129BD7 for ; Fri, 12 May 2017 12:23:07 -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 e1PnJ0OV6Ugn for ; Fri, 12 May 2017 12:23:06 -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 A2778129B21 for ; Fri, 12 May 2017 12:18:24 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b84so29697376wmh.0 for ; Fri, 12 May 2017 12:18:24 -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=+Wk6a2s8Zns830OPuY40bGvGTw1/4S82FOrC/8dpvtg=; b=eR9fhsNz8Mrowdty+fC5fkU/rvWTjcuunX234Ncnf+feqipXOjc0/Li88TQMLdOfV9 8vZV5RFyGXVJjAuEQKQSujFKrFu2rcpZMy/LF3VSaGQvus4X8ctcudHZ90geCCVMqDsz IDysmRmdQUZUVO5M/lQjHHCj+BaY0u9J1irVTyk/x99Zey7qilgFrIjgjMNqmRBm4M0s XMVin4C2cT8GDDPzVtIOFj2zWGPtagIkP8KVoyDgweG/VrzXfxJFIvZ4Jx/zJqIVxN5N lYEp/CIR0IoXbGjcxPWkU6h2knhAJ1TsMOtdx5ZEVn3qCclmwfdQ4XOBoHiUO9KIjZfL WRkg== 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=+Wk6a2s8Zns830OPuY40bGvGTw1/4S82FOrC/8dpvtg=; b=G9unGKE44DUiOIVD/a9e55qhBsoo/1Emp2y7d8ipmFoSBeull8NHZk6Dbo8U5Db7Md ly+6VRCvLKdPxHEIxGqbcCtOV8WYM96IBEpOicRXJewLLCapMCvgL6m6rX7HoTEcyYpf J+Pv/NMYgpz1NvpmnbHqs1Nm/Wcd5uBQ1NUjkgaM1ilnApaBJ788qiwHv5bTgLZ1u3Zt b9oJDq9c0Cn82RQXcU/cpQ2antBi6wGT5h3fucxqObJ1ePC7EpQM8qBENtq/wbkkOK0A pa8KNB6TkEvK5ZSrFkWzv6RUTpxOU3VEtEnFPx9cz5lZxJCL6Gz3a4mN2HHrjGEUB1/i iSig== X-Gm-Message-State: AODbwcB1o235W/tHmLe46OI48+vLH7BWhkVeVMELNtKmoEJVgmY+TdWh 2aDmUZpFqVUjD/GXowsvOf1aY6PuiyP5 X-Received: by 10.28.156.197 with SMTP id f188mr4052321wme.76.1494616703051; Fri, 12 May 2017 12:18:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.179.68 with HTTP; Fri, 12 May 2017 12:18:22 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 12 May 2017 15:18:22 -0400 Message-ID: To: Brian Smith Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a114b3168a94ebb054f589176" Archived-At: Subject: Re: [Trans] Drop RSA PKCS#1 1.5 signatures; maybe replace with RSA PSS 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, 12 May 2017 19:23:08 -0000 --001a114b3168a94ebb054f589176 Content-Type: text/plain; charset="UTF-8" +1 On Fri, May 12, 2017 at 2:51 PM, Brian Smith wrote: > Hi, > > PKCS#1 1.5 signatures are obsolete. New specifications should not > mandate support for them. > > RSA signatures in general are difficult for some devices to process > due to their large size. It would be frustrating to have used a pure > ECC infrastructure with no RSA involved at all, only to need to > implement RSA for the purpose of verifying signatures from logs. Thus > I think the group should consider dropping any mention of RSA > signatures from section 10.4.so that log clients do not have to > implement RSA. > > If it really is important to have RSA signatures, then RSA PSS should > be used instead. In particular, it would be good to require the same > restricted form specified for TLS, where the same digest algorithm > must be used for all parts of the signature. Note that RSA PSS can be > made deterministic by using a fixed salt, and most implementations of > RSA PSS seem to support fixed salts if the salt length is set to zero. > As mentioned in the RSA PSS specification, PSS signatures are more > secure than PKCS#1 1.5 signatures even with a zero-length salt. > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114b3168a94ebb054f589176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1


On Fri, May 12, 2017 at 2:51 PM, Brian Sm= ith <brian@briansmith.org> wrote:
Hi,

PKCS#1 1.5 signatures are obsolete. New specifications should not
mandate support for them.

RSA signatures in general are difficult for some devices to process
due to their large size. It would be frustrating to have used a pure
ECC infrastructure with no RSA involved at all, only to need to
implement RSA for the purpose of verifying signatures from logs. Thus
I think the group should consider dropping any mention of RSA
signatures from section 10.4.so that log clients do not have to
implement RSA.

If it really is important to have RSA signatures, then RSA PSS should
be used instead. In particular, it would be good to require the same
restricted form specified for TLS, where the same digest algorithm
must be used for all parts of the signature. Note that RSA PSS can be
made deterministic by using a fixed salt, and most implementations of
RSA PSS seem to support fixed salts if the salt length is set to zero.
As mentioned in the RSA PSS specification, PSS signatures are more
secure than PKCS#1 1.5 signatures even with a zero-length salt.

Cheers,
Brian
--
ht= tps://briansmith.org/

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

--001a114b3168a94ebb054f589176-- From nobody Mon May 15 03:54: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 E86EB129443 for ; Mon, 15 May 2017 03:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6_B4jwKBwhBg for ; Mon, 15 May 2017 03:54:18 -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 8AF7F129C6A for ; Mon, 15 May 2017 03:49:58 -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 v4FAnsRk004807 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 May 2017 12:49:55 +0200 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 v4FAnp8t027581 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 May 2017 10:49:54 GMT From: Linus Nordberg To: Eran Messeri Cc: trans@ietf.org Organization: Sunet References: <87pofiif6g.fsf@nordberg.se> Date: Mon, 15 May 2017 12:50:02 +0200 In-Reply-To: (Eran Messeri's message of "Fri, 12 May 2017 14:36:04 +0100") Message-ID: <87inl25r8l.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: 0aTkyNTkN - 0573c02c1bb9 - 20170515 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] The RFC6979 requirement in RFC6962-bis is bad 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, 15 May 2017 10:54:22 -0000 Eran Messeri wrote Fri, 12 May 2017 14:36:04 +0100: > Thanks for the feedback. It helped me realize deterministic signatures > could be achieved not only by using a deterministic signature scheme, but > also by logs storing the produced signatures and returning them instead of > re-signing SCTs, for example. > > That's my understanding of the discussion so far: > * Requiring the use of RFC6979 is bad, for the reasons Brian has mentioned. > * It is not yet clear where deterministic signatures may be more important > (SCTs or STHs) because it's not clear what TLS clients will gossip and how. Not to argue against that statement but I think that it's clear that gossiping about STHs would become more problematic for a client caring about privacy if logs were allowed to send different strings of bits to different clients for a given pair of `log_id` and `tree_head` in an STH. > * It is not necessary to require the use of a deterministic signature > scheme - only that the same signature is present in all instances of a > particular SCT (note that different SCTs for the same submission, with > different timestamps, which the log may issue, cannot have the same > signature). This sounds like a requirement, i.e. a MUST, which is not reflected in the reasoning below ("MUST->SHOULD" and "Mention that"). Also, this talks about SCTs specifically. What do you think the story is for STHs? > Also, in 6962-bis, my focus is on correct operation of the log & Merkle > Tree - and deterministic signatures are not strictly necessary for that. While I think it's fair to try to limit the scope I think it would be bad to make it hard to gossip since that's supposed to protect against attacks on the ability to audit the correctness of said operation. Admittedly, one problem here is that "hard to gossip" is far from well defined. Also, does this imply that the limitation on STH issuance frequency should be removed too? > To make progress on this issue, I propose the following: > * Remove references to 6979. > * Remove the strong requirement to use deterministic signature schemes > (MUST -> SHOULD), so implementations can use non-deterministic signature > schemes and still be compliant with the spec. > * Add reference to EdDSA, which includes a deterministic signature scheme > variant. > * Mention that deterministic signatures can be achieved by storing the > produced signatures. > > Any objections? I think that 6962bis should mandate that the same bits are sent over the wire to every client asking for a given piece of signed data. (This can be accomplished by either using a deterministic signing scheme or by storing the data under a unique key for later use.) The main reason for this requirement is to make it possible for log clients to gossip about STHs -- limiting the number of outstanding STHs that a log can have at any given time is important in order to limit the ability for a log to fingerprint its clients, as described in draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that the same bits are sent over the wire to everyone asking for a given STH. The privacy argument for imposing this same-bits-for-same-data rule for SCTs too seems weaker since SCTs carry much more privacy sensitive data but I'm not convinced that this holds for all gossip scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to linking an SCT to a user of an HTTPS client. I think this is reason enough to not separate STHs and SCTs with regard to this requirement. From nobody Mon May 15 04:40:22 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6989712EA98 for ; Mon, 15 May 2017 04:40:21 -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 q_0nzoTtOHyj for ; Mon, 15 May 2017 04:40:18 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 BFBDB129C00 for ; Mon, 15 May 2017 04:36:03 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id k91so71242076ioi.1 for ; Mon, 15 May 2017 04:36:03 -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=IsMZPB/7WjoswEb3wSq+evOl3IMG00sUUMKGWdHRmgc=; b=e//PT+k64G/03CSUhzytlacV5QB2HWeNYlgzyPihWKMLfPBX+IJj+WYEI7DrqUpqbR g4WfRpVQnQjweBRVrFiRV3uFuvuWrcEwkO7zHfgi9X4M0fTz5mXCA1YKXoOAOdjQElVX iweb1lHAyDq7ClnOVY+TOfBdc3NFn5eqRS5DDgljz9Pqe06jl19JrRLaGha7eUI/hYFw f9mJGxn0fwIbqvjClml4wHJtjVinoq+SEuQy5OAdOdzGrxE0ccBk+JFopSO5jqMLAVBo KKzNVbRLRmYEYymyzdQrpyHcNA5HQCE3gHSUWUEJxGCA8pFRh9oNbfrITBv1MKfeQAMZ ZZQw== 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=IsMZPB/7WjoswEb3wSq+evOl3IMG00sUUMKGWdHRmgc=; b=sNSdVu0q6oRqJvuH+XN5s4xAjBmETDKylzdtjvqNx7+/RnqtUQGk32z4i5ebRwUJSv c1E7g49CgZg+mpelyF/trHmF8MXGhznrILR3jP3he9us86EfhLEpLIM3DLHsr+By2n76 xzQib981gxwrPB3B0e4En/vf+MHr8xBhaneKWsX+bfzDzi20iCouB5v3ahRzesvebHeG 7OtpSKzxfzXRY4aAtpu413dC2Q8jAG3/6NWk7q4YaP1QPFLaHxfCmOPEI1VU0fZ+1AQc 7XbF6LaN/gMiRWkfvLVS6pZmKXlircOQSVJ9R9tW53TQbx0BX7icOBG5GUYybqd9fUxH LDyg== X-Gm-Message-State: AODbwcAZFcYFIPrcGhIGlL7X9bnxIpjC459CnNRb86cmX92WL6Som8gf OiuTNliksu9OV1BewO3G8CBqj1s6T9bbyfk= X-Received: by 10.107.184.9 with SMTP id i9mr4658302iof.153.1494848162953; Mon, 15 May 2017 04:36:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Mon, 15 May 2017 04:35:32 -0700 (PDT) In-Reply-To: <87inl25r8l.fsf@nordberg.se> References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> From: Eran Messeri Date: Mon, 15 May 2017 12:35:32 +0100 Message-ID: To: Linus Nordberg Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06d100bf8506054f8e7541" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 15 May 2017 11:40:21 -0000 --94eb2c06d100bf8506054f8e7541 Content-Type: text/plain; charset="UTF-8" On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg wrote: > Eran Messeri wrote > Fri, 12 May 2017 14:36:04 +0100: > > > Thanks for the feedback. It helped me realize deterministic signatures > > could be achieved not only by using a deterministic signature scheme, but > > also by logs storing the produced signatures and returning them instead > of > > re-signing SCTs, for example. > > > > That's my understanding of the discussion so far: > > * Requiring the use of RFC6979 is bad, for the reasons Brian has > mentioned. > > * It is not yet clear where deterministic signatures may be more > important > > (SCTs or STHs) because it's not clear what TLS clients will gossip and > how. > > Not to argue against that statement but I think that it's clear that > gossiping about STHs would become more problematic for a client caring > about privacy if logs were allowed to send different strings of bits to > different clients for a given pair of `log_id` and `tree_head` in an > STH. > > I completely agree - it would be more difficult for clients caring about privacy (which should be all TLS clients used by end-users these days, really) to exchange STHs they've obtained themselves, if logs were allowed to use unique signatures. I'm not saying the reasoning is wrong - it is very solid as far as I can tell - but that we don't know if we need it yet, see below. > > * It is not necessary to require the use of a deterministic signature > > scheme - only that the same signature is present in all instances of a > > particular SCT (note that different SCTs for the same submission, with > > different timestamps, which the log may issue, cannot have the same > > signature). > > This sounds like a requirement, i.e. a MUST, which is not reflected in > the reasoning below ("MUST->SHOULD" and "Mention that"). > > Also, this talks about SCTs specifically. What do you think the story is > for STHs? > Seems to me like the same reasoning applies to both - sorry, wasn't clear about it. > > > > Also, in 6962-bis, my focus is on correct operation of the log & Merkle > > Tree - and deterministic signatures are not strictly necessary for that. > > While I think it's fair to try to limit the scope I think it would be > bad to make it hard to gossip since that's supposed to protect against > attacks on the ability to audit the correctness of said > operation. Admittedly, one problem here is that "hard to gossip" is far > from well defined. > > Also, does this imply that the limitation on STH issuance frequency > should be removed too? > I'd leave that, as it has several benefits beyond gossip (for example, the ability to cache STHs and their consistency proofs or coordinating selection of an SCT). > > > > To make progress on this issue, I propose the following: > > * Remove references to 6979. > > * Remove the strong requirement to use deterministic signature schemes > > (MUST -> SHOULD), so implementations can use non-deterministic signature > > schemes and still be compliant with the spec. > > * Add reference to EdDSA, which includes a deterministic signature scheme > > variant. > > * Mention that deterministic signatures can be achieved by storing the > > produced signatures. > > > > Any objections? > > I think that 6962bis should mandate that the same bits are sent over the > wire to every client asking for a given piece of signed data. (This can > be accomplished by either using a deterministic signing scheme or by > storing the data under a unique key for later use.) > > The main reason for this requirement is to make it possible for log > clients to gossip about STHs -- limiting the number of outstanding STHs > that a log can have at any given time is important in order to limit the > ability for a log to fingerprint its clients, as described in > draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the > log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that > the same bits are sent over the wire to everyone asking for a given STH. > > The privacy argument for imposing this same-bits-for-same-data rule for > SCTs too seems weaker since SCTs carry much more privacy sensitive data > but I'm not convinced that this holds for all gossip > scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to > linking an SCT to a user of an HTTPS client. I think this is reason > enough to not separate STHs and SCTs with regard to this requirement. > Overall I agree with the sentiment. However I'm trying to balance the attempt to make SCTs & STHs non-identifying as much as possible with ease of implementation and the current deployment: - As Melinda said on a separate post, 6962-bis has to be correct but it doesn't have to be complete. We could add the stricter requirement of producing consistent signatures for the same data later on. - There's an added cost for implementations: Either more storage (storing produced signatures) or reliance on features that are not widely supported in crypto libraries (deterministic signatures). - Right now, how the gossip is going to take place is unclear: The only thing currently operating (AFAIK) is STH exchange between several monitors. I don't know of any TLS client implementation that intends to fetch STHs directly (we've actually removed this capability from Chrome recently). Even if there was such an implementation, because it's not clear who it will be exchanging STHs with, it's unclear what's the threat model - who has to collude to compromise a client's privacy by tracking it. To put it simply, I don't know yet if we'll need it - which is why I suggest we strongly recommend deterministic signatures, but not mandate it. What do you think? --94eb2c06d100bf8506054f8e7541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <= linus@sunet.se><= /span> wrote:
Eran Messeri <eranm@google.com> wrote
Fri, 12 May 2017 14:36:04 +0100:

> Thanks for the feedback. It helped me realize deterministic signatures=
> could be achieved not only by using a deterministic signature scheme, = but
> also by logs storing the produced signatures and returning them instea= d of
> re-signing SCTs, for example.
>
> That's my understanding of the discussion so far:
> * Requiring the use of RFC6979 is bad, for the reasons Brian has menti= oned.
> * It is not yet clear where deterministic signatures may be more impor= tant
> (SCTs or STHs) because it's not clear what TLS clients will gossip= and how.

Not to argue against that statement but I think that it's clear = that
gossiping about STHs would become more problematic for a client caring
about privacy if logs were allowed to send different strings of bits to
different clients for a given pair of `log_id` and `tree_head` in an
STH.

I completely agree - it would= be more difficult for clients caring about privacy (which should be all TL= S clients used by end-users these days, really) to exchange STHs they'v= e obtained themselves, if logs were allowed to use unique signatures.
=
I'm not saying the reasoning is wrong - it is very solid as far as= I can tell - but that we don't know if we need it yet, see below.


> * It is not necessary to require the use of a deterministic signature<= br> > scheme - only that the same signature is present in all instances of a=
> particular SCT (note that different SCTs for the same submission, with=
> different timestamps, which the log may issue, cannot have the same > signature).

This sounds like a requirement, i.e. a MUST, which is not reflected = in
the reasoning below ("MUST->SHOULD" and "Mention that&quo= t;).

Also, this talks about SCTs specifically. What do you think the story is for STHs?
Seems to me like the same reasoning applies = to both - sorry, wasn't clear about it.=C2=A0


> Also, in 6962-bis, my focus is on correct operation of the log & M= erkle
> Tree - and deterministic signatures are not strictly necessary for tha= t.

While I think it's fair to try to limit the scope I think it wou= ld be
bad to make it hard to gossip since that's supposed to protect against<= br> attacks on the ability to audit the correctness of said
operation. Admittedly, one problem here is that "hard to gossip" = is far
from well defined.

Also, does this imply that the limitation on STH issuance frequency
should be removed too?
I'd leave that, as it has s= everal benefits beyond gossip (for example, the ability to cache STHs and t= heir consistency proofs or coordinating selection of an SCT).=C2=A0


> To make progress on this issue, I propose the following:
> * Remove references to 6979.
> * Remove the strong requirement to use deterministic signature schemes=
> (MUST -> SHOULD), so implementations can use non-deterministic sign= ature
> schemes and still be compliant with the spec.
> * Add reference to EdDSA, which includes a deterministic signature sch= eme
> variant.
> * Mention that deterministic signatures can be achieved by storing the=
> produced signatures.
>
> Any objections?

I think that 6962bis should mandate that the same bits are sent over= the
wire to every client asking for a given piece of signed data. (This can
be accomplished by either using a deterministic signing scheme or by
storing the data under a unique key for later use.)

The main reason for this requirement is to make it possible for log
clients to gossip about STHs -- limiting the number of outstanding STHs
that a log can have at any given time is important in order to limit the ability for a log to fingerprint its clients, as described in
draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the
log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that the same bits are sent over the wire to everyone asking for a given STH.
The privacy argument for imposing this same-bits-for-same-data rule for
SCTs too seems weaker since SCTs carry much more privacy sensitive data
but I'm not convinced that this holds for all gossip
scenarios. Fingerprinting of a gossip peer doesn't necessarily relate t= o
linking an SCT to a user of an HTTPS client. I think this is reason
enough to not separate STHs and SCTs with regard to this requirement.

Overall I agree wit= h the sentiment. However I'm trying to balance the attempt to make SCTs= & STHs non-identifying as much as possible with ease of implementation= and the current deployment:
- As Melinda s= aid on a separate post, 6962-bis has to be correct but it doesn't have = to be complete. We could add the stricter requirement of producing consiste= nt signatures for the same data later on.
-= There's an added cost for implementations: Either more storage (storin= g produced signatures) or reliance on features that are not widely supporte= d in crypto libraries (deterministic signatures).
- Right now, how the gossip is going to take place is unclear: The o= nly thing currently operating (AFAIK) is STH exchange between several monit= ors. I don't know of any TLS client implementation that intends to fetc= h STHs directly (we've actually removed this= capability from Chrome recently). Even if there was such an implementa= tion, because it's not clear who it will be exchanging STHs with, it= 9;s unclear what's the threat model - who has to collude to compromise = a client's privacy by tracking it.

=
To put it simply, I don't know yet if = we'll need it - which is why I suggest we strongly recommend determinis= tic signatures, but not mandate it.

What do you think?
--94eb2c06d100bf8506054f8e7541-- From nobody Mon May 15 09:05: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 E2B82129B1E for ; Mon, 15 May 2017 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 eoTzzfAAfTit for ; Mon, 15 May 2017 09:05:33 -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 EF1F812EAC0 for ; Mon, 15 May 2017 09:01:28 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id c15so45807428ith.0 for ; Mon, 15 May 2017 09:01:28 -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=1dM1v/TiOlE9DB9oCr9vclooh8n+fEyg6GI24fyFQxg=; b=bbRznYO8GE/pyQm/iHaSqdgwoHRLon8jdY3NVMjr4KlxtTqCvs0Ox27WKhOuVZQeBV RvEyE5yaBT6eP/XRMkYD91HW3g0y4RiVr/EN9S034GTztu/vdZkWqszWDtll/+0vQ+DG U75GMbzTb2rtsXz7knGMgF+L/2o92OH8pL1i+RLr6PJ7rBsNJ3gEra3NG0A6wDBH4l87 MmaX/IBEikdbUY3OI6yHMNnzCo/SE4ImQfZNnW9HXET4m3egKbxxpgme8AbqkW9MXqYa 3OH3IYKDBafgl9oYIfSDHllZ37iWJY8iNxcoYkb8Bh0zRmWootCz5icE0OQ2ayc5kw4B kzZQ== 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=1dM1v/TiOlE9DB9oCr9vclooh8n+fEyg6GI24fyFQxg=; b=KEllgxF/LS+oddb2vcnsgLRRhQwmZV4GPddJzvPfNhrvCDZ94UyAq6+bliVS9sAL/W zg5j8JyeqWs6Tu4CtwQgGXXiWkVrxjnFLEeJe5fa/hC4OwijvWJ9oYiUv/Pz8kY692p6 nxHmEUYURDBelhNDzftwH4uWmNlmwX1A13gerPpK3Hqucjytg46/enABUM1+jxmkQdww +nnbLQMhMwtLyMiHQBtIWpPsqWkRHuwa45MLnFg3vmF0AeBIDvs2ilGG5E7cX2WcJvOS iKRp9NLYBaflaZIvRJSaRJysejkno3HOdNQg2d2HYwo5tpIg5C0INcOU47RjhivQUv1a j05w== X-Gm-Message-State: AODbwcA4OgkekiHX0zC1tnUUB/FK5rlm0kP5X/DsQp8MvqwdYwUMwE4v 0VITpGkcySBMGURR1rt0eXffMYp9msodQVOf3Q== X-Received: by 10.36.3.13 with SMTP id e13mr6111067ite.112.1494864088140; Mon, 15 May 2017 09:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.30 with HTTP; Mon, 15 May 2017 09:00:55 -0700 (PDT) From: Eran Messeri Date: Mon, 15 May 2017 17:00:55 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11419bfaf685ed054f922ac2" Archived-At: Subject: [Trans] Removal of the use of digitally-signed (issue #174) 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, 15 May 2017 16:05:36 -0000 --001a11419bfaf685ed054f922ac2 Content-Type: text/plain; charset="UTF-8" In issue #174 Richard suggests removing the use of digitally-signed in favour of the signature description in prose used in TLS 1.3. A PR to that effect: https://github.com/google/certificate-transparency-rfcs/pull/260 Are there any opinions on the matter? Personally I don't mind either; generally, digitally-signed unambiguously specifies what data the signature is over, but in 6962-bis it's always over a well-defined data structure (defined somewhere else). Eran --001a11419bfaf685ed054f922ac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In issue #174 Richard suggests removing the use of digitally-signed in fa= vour of the signature description in prose used in TLS 1.3.

<= div>A PR to that effect:

Are there any o= pinions on the matter? Personally I don't mind either; generally, digit= ally-signed unambiguously specifies what data the signature is over, but in= 6962-bis it's always over a well-defined data structure (defined somew= here else).

Eran

--001a11419bfaf685ed054f922ac2-- From nobody Mon May 15 09:22: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 0203F12EACF for ; Mon, 15 May 2017 09:22: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 2e3QE4RVL5zj for ; Mon, 15 May 2017 09:22:43 -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 C002312EA6A for ; Mon, 15 May 2017 09:18:53 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id g126so71787835ith.0 for ; Mon, 15 May 2017 09:18:53 -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=e2fqnmx2qK/JyEVtbKlUPLey0eC0XUrS0/eq/0MrxNM=; b=c8uc8m/G56ZGSeuOsZHKPpRZNxJXxlz9RKBoZHHEdcIcTIzXZKGjKWbZfGSMWgfmVi KiZzF7EjeXngKcJlt5ZOJn1m6WoezhAYxWQ6K1AnJ5Cg1wtJ6Kmcbg+v1uc0kF5OLjZI HjyG/+fQYRMia5KKNK7MRz7pxlBFE9OLRPwQLsAtTNjZLm6lCOS3Kjnm9bK9GtzrSeOQ 9lBnsBncp1Ob8L45zAK+Gg6LPc7+a4hWY1vi/w/BOglnvaOCeyKp7TCR5yimAviYjYSj ThdyfpEAOPdXs7MbKCcasaxKLL7ZINpYAEEOVArn2RY5uckh0QpEcHkhYwYsM990Hp3b Q2Zw== 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=e2fqnmx2qK/JyEVtbKlUPLey0eC0XUrS0/eq/0MrxNM=; b=tjXjFTZDP+Y8dgX/cunHYFKgLbgLfX+lV2aAWbRNcuY04u3zMh28SKu+9KIumCMoOc 6yivrnPj1/suGvvGeh/JIOqPWEX+1Wa9PN44GxAqnsR4LqpNBFsnF6ZOfTQbFHqUO3uG zPm3wFoJKD70ajxtW6yDt+/JoDblk5hUGc8E2Vcytw0ctL3Qju5h3wDKeuwsPbAtOio9 0k2nYFIGCgyJJQQ/frm5j20gXF78R/68YBD+PtPkCu1QTYUdl7rhhV98eQxIojdqQ23K iZw6bufki7YVSPfg96v4xHtvAugGkgJCLA2oo7PmQoheVd+f8j+Yz4reg8ZefbBvPWOY CWxg== X-Gm-Message-State: AODbwcDCztt4GRCEgv/XLmFPha1QBGqXDFGQ2/Xi6ScOVfoLl8dd2h+W EHNeVthtPSMuKw/8gR3Uju6JxfFqZlVEKs86jQ== X-Received: by 10.36.3.13 with SMTP id e13mr6215654ite.112.1494865132892; Mon, 15 May 2017 09:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Mon, 15 May 2017 09:18:22 -0700 (PDT) In-Reply-To: <87lgq7j6a3.fsf@nordberg.se> References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> From: Eran Messeri Date: Mon, 15 May 2017 17:18:22 +0100 Message-ID: To: Linus Nordberg Cc: Andrew Ayer , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11419bfa3c12a7054f926927" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 15 May 2017 16:22:46 -0000 --001a11419bfa3c12a7054f926927 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As it has been pointed out to me, the STH history API, even with the proposed changes of adding a sequence number to issued STHs, or requiring an STH refers to a previous STH, would not prevent backdating of STHs in a meaningful way - see explanation below. Because of that, I'm not sure it'll add anything to have this API - and if we do add it, it should be an optional one. Note that the threat I=E2=80=99m focusing on is detection of MMD breach: Wh= ere the log hasn=E2=80=99t incorporated an entry corresponding to an issued SCT for= more than the MMD, _and a monitor could feasibly observe evidence of it_. Here=E2=80=99s why, I think, adding references to past STHs wouldn=E2=80=99= t improve the situation: Currently, clients cannot prove that a log has misbehaved, by serving an STH that=E2=80=99s more than an MMD old. A client can claim that at a given= time the log has served it an STH that=E2=80=99s MMD + delta hours old, but cann= ot prove it. Additionally, close monitoring of a log can identify an MMD breach, but only until 2*MMD - (some delta, marked d in the diagram) time has passed: [image: MMD breach detection.png] (Note in this diagram STH1 is on a tree that does not yet contain the SCT; Only STH2 is). Because the RFC requires an incorporation within the MMD, yet allows serving an STH that=E2=80=99s up to MMD old, a log could incorporate an SCT= within the MMD but it would only be evident after more than MMD of the submission time has passed - or it could backdate inclusion by backdating issuance of an STH that includes the entry[0]. AFAICT requiring that STHs refers to previous ones does not change that in any way - it does not prevent any backdating that=E2=80=99s now possible, n= or does it make it easier for a client to detect backdating: * When a cunning log realises that it will fail to incorporate a pending entry for longer than the MMD, it can immediately generate a back-dated STH that shows it was included within the MMD, and an =E2=80=9Cinnocent looking= =E2=80=9D STH (timestamped =E2=80=98now=E2=80=99), that refers to the back-dated STH. * A failure by the log to provide an STH in the =E2=80=9Cchain=E2=80=9D of = STHs (should STHs include reference to previous ones) is equivalent to a failure by the log to provide an STH that proves an inclusion of a particular entry: In both cases the evidence would be STHs surrounding the entry that was not incorporated. * If a monitor has observed an STH that=E2=80=99s more than MMD old and doe= s not include an entry for a particular SCT, this is evidence enough for misbehaviour. So my concrete suggestion is then to not add get-sths entirely or make it an optional API (because a log can only use it to incriminate itself, not prove that it behaved). [0] Note that backdating of selective submissions is not possible either with or without back-references in STHs: A single submission that hasn=E2= =80=99t been incorporated cannot be retroactively incorporated, once the MMD has passed, if other entries have been incorporated. On Tue, May 9, 2017 at 12:08 AM, Linus Nordberg wrote: > Andrew Ayer wrote > Fri, 5 May 2017 10:09:10 -0700: > > > On Thu, 04 May 2017 20:58:16 +0000 > > Nick Sullivan wrote: > > > >> By consistent I mean that if a sequence of STHs such as (A, B, C) are > >> presented on day 1, that a different sequence is not presented on day > >> 2 (A, C) or (A, D, B, C). > > > > The PR doesn't currently say the log must retain and return all STHs > > it has ever signed. That should be added. Such language, plus the > > existing chronological ordering requirement, plus the requirement that > > STH timestamps be unique ("Each subsequent timestamp MUST be more > > recent than the timestamp of the previous update") should ensure > > consistency, right? > > > >> Rob's language works in term of chronological order. > >> > >> STH pollination could be a way to support auditing this, but I don't > >> think it's sufficiently robust as currently defined. To prevent STHs > >> from going missing, or for new STHs to appear after the fact, STHs > >> should be exchanged along with metadata indicating the previous and > >> (if it exists yet) the next STH in the tree. > > > > To be an effective auditing mechanism, this information needs to be > > signed by the log. Otherwise, a monitor could lie about what it has > > seen. Perhaps the STH could contain the timestamp of the previous > > STH. If it did, I believe that STH pollination would be sufficient for > > detecting STHs that go missing or appear after the fact. > > > > That said, is there a compelling security need for this to be > > auditable? > > I'm probably missing something crucial here but if it's not auditable, > what use does it have? > > It seems to me that you're transcending towards a log of STHs, which I > wouldn't mind thinking about but probably not as an ad-hoc addon to a > new get-sths API. > > For the record, I'd like to express hesitance about adding an STH > history API until I understand the problem better, with apologies for > not being fully up to speed at the moment. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11419bfa3c12a7054f926927 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As it has been pointed out to me, the STH history API, eve= n with the proposed changes of adding a sequence number to issued STHs, or = requiring an STH refers to a previous STH, would not prevent backdating of = STHs in a meaningful way - see explanation below.

Becaus= e of that, I'm not sure it'll add anything to have this API - and i= f we do add it, it should be an optional one.

Note that the threat I=E2=80=99m focusing on is detection of MMD breach: W= here the log hasn=E2=80=99t incorporated an entry corresponding to an issue= d SCT for more than the MMD, _and a monitor could feasibly observe evidence= of it_.
=C2=A0
Here=E2=80=99s why, I think, adding ref= erences to past STHs wouldn=E2=80=99t improve the situation:
=C2= =A0
Currently, clients cannot prove that a log has misbehaved, by= serving an STH that=E2=80=99s more than an MMD old. A client can claim tha= t at a given time the log has served it an STH that=E2=80=99s MMD + delta h= ours old, but cannot prove it.
=C2=A0
Additionally, clo= se monitoring of a log can identify an MMD breach, but only until 2*MMD - (= some delta, marked d in the diagram) time has passed:
3D"MMD
(Note in this diagram STH1 is on a tree that does not yet contain the SC= T; Only STH2 is).
=C2=A0
Because the RFC requires an in= corporation within the MMD, yet allows serving an STH that=E2=80=99s up to = MMD old, a log could incorporate an SCT within the MMD but it would only be= evident after more than MMD of the submission time has passed - or it coul= d backdate inclusion by backdating issuance of an STH that includes the ent= ry[0].
=C2=A0
AFAICT requiring that STHs refers to prev= ious ones does not change that in any way - it does not prevent any backdat= ing that=E2=80=99s now possible, nor does it make it easier for a client to= detect backdating:
* When a cunning log realises that it will fa= il to incorporate a pending entry for longer than the MMD, it can immediate= ly generate a back-dated STH that shows it was included within the MMD, and= an =E2=80=9Cinnocent looking=E2=80=9D STH (timestamped =E2=80=98now=E2=80= =99), that refers to the back-dated STH.
* A failure by the log t= o provide an STH in the =E2=80=9Cchain=E2=80=9D of STHs (should STHs includ= e reference to previous ones) is equivalent to a failure by the log to prov= ide an STH that proves an inclusion of a particular entry: In both cases th= e evidence would be STHs surrounding the entry that was not incorporated.
* If a monitor has observed an STH that=E2=80=99s more than MMD ol= d and does not include an entry for a particular SCT, this is evidence enou= gh for misbehaviour.
=C2=A0
So my concrete suggestion i= s then to not add get-sths entirely or make it an optional API (because a l= og can only use it to incriminate itself, not prove that it behaved).
=
=C2=A0
[0] Note that backdating of selective submissions is = not possible either with or without back-references in STHs: A single submi= ssion that hasn=E2=80=99t been incorporated cannot be retroactively incorpo= rated, once the MMD has passed, if other entries have been incorporated.



On Tue, May 9, 2017 at 12:08 AM, Linu= s Nordberg <linus@sunet.se> wrote:
Andrew Ayer <agwa@andrew= ayer.name> wrote
Fri, 5 May 2017 10:09:10 -0700:

> On Thu, 04 May 2017 20:58:16 +0000
> Nick Sullivan <nick@cloudfla= re.com> wrote:
>
>> By consistent I mean that if a sequence of STHs such as (A, B, C) = are
>> presented on day 1, that a different sequence is not presented on = day
>> 2 (A, C) or (A, D, B, C).
>
> The PR doesn't currently say the log must retain and return all ST= Hs
> it has ever signed.=C2=A0 That should be added.=C2=A0 Such language, p= lus the
> existing chronological ordering requirement, plus the requirement that=
> STH timestamps be unique ("Each subsequent timestamp MUST be more=
> recent than the timestamp of the previous update") should ensure<= br> > consistency, right?
>
>> Rob's language works in term of chronological order.
>>
>> STH pollination could be a way to support auditing this, but I don= 't
>> think it's sufficiently robust as currently defined. To preven= t STHs
>> from going missing, or for new STHs to appear after the fact, STHs=
>> should be exchanged along with metadata indicating the previous an= d
>> (if it exists yet) the next STH in the tree.
>
> To be an effective auditing mechanism, this information needs to be > signed by the log.=C2=A0 Otherwise, a monitor could lie about what it = has
> seen.=C2=A0 Perhaps the STH could contain the timestamp of the previou= s
> STH.=C2=A0 If it did, I believe that STH pollination would be sufficie= nt for
> detecting STHs that go missing or appear after the fact.
>
> That said, is there a compelling security need for this to be
> auditable?

I'm probably missing something crucial here but if it's not = auditable,
what use does it have?

It seems to me that you're transcending towards a log of STHs, which I<= br> wouldn't mind thinking about but probably not as an ad-hoc addon to a new get-sths API.

For the record, I'd like to express hesitance about adding an STH
history API until I understand the problem better, with apologies for
not being fully up to speed at the moment.

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

--001a11419bfa3c12a7054f926927-- From nobody Mon May 15 09:33: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 EB7FF129B8B for ; Mon, 15 May 2017 09:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydlkApm585PH; Mon, 15 May 2017 09:33:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC986129C49; Mon, 15 May 2017 09:29:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 15 May 2017 16:29:43 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/162#comment:3 Message-ID: <037.357a292346eae2521d917e27cdf15907@ietf.org> References: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <022.7212bc2ce646972ebd8eb69407a1fe1b@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #162: Bound the set of artifacts a log is expected to produce X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 16:33:03 -0000 #162: Bound the set of artifacts a log is expected to produce -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * owner: draft-ietf-trans-rfc6962-bis@… => eranm@… * status: new => assigned * component: to-be-decided => rfc6962-bis Comment: I think that the protocol should enable minimizing the number of artifacts, but not force it. Given that STH issuance frequency is already limited, that allows logs to produce a limited number of consistency proofs. As TransItems can be bundled, a "chain" of consistency proofs between STHs can already be provided to clients. But its size would be linear in the number of STHs, while an actual consistency proof between two STHs will be shorter, or equal to, a chain of consistency proofs between intermediate STHs. In practice, no log operator has ever complained on the difficulty of calculating inclusion and consistency proofs on-the-fly (that's never a part we ran into difficulty implementing). My suggestions: * Outline how a log may limit the artifacts it produces. * Change some of the HTTP endpoints to return a TransItemList rather than a TransItem to accommodate a collection of inclusion/consistency proofs and an STH. -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon May 15 09:54: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 BCC5D129527 for ; Mon, 15 May 2017 09:54:38 -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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 p1Lq99BdHIrP for ; Mon, 15 May 2017 09:54:37 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 987521294C9 for ; Mon, 15 May 2017 09:51:10 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v4FGlMOh014726; Mon, 15 May 2017 17:51:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=iBBGEalgn48JQr9G7mH/Vjhq4AB4K1q/TyAUZhTslOk=; b=HQXLhZbTHejMMiWbdpddzEK6+fMFjZ+WkOethC8214w+fwLvUYt4twS98uriXKo7N9iO 3Hd1KVXLVzBgaQo1REvc53ECzss4soi4RDOLKdHFiRIeE7pVyWGQFJw7YsmHkQuyIvUi RT50T9/2MefdwICVyFaaNoXt7Vw63y7SqCPa514E6tbfBOOFO+GYQ4dG9lKEw6sWhxf4 EPybRnMQfGlvh/JMFzRfwrclTy8aksGltjb59E1EpC+6iMsI7bp7ZxfitCKkIF/BoyH5 /tf/AqBMAlWfi4H2RnCFt+9APUOuAU4+JWl6y/AMNI8KA/OU7yC4cz+HXzpDpg3SSdw3 RA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2afcuu1ryw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 May 2017 17:51:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v4FGjmfa007852; Mon, 15 May 2017 12:51:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2adwfu43c7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 May 2017 12:51:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 May 2017 12:51:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 15 May 2017 12:51:04 -0400 From: "Salz, Rich" To: Eran Messeri , "trans@ietf.org" Thread-Topic: [Trans] Removal of the use of digitally-signed (issue #174) Thread-Index: AQHSzZUamCW1fPuPJUiWHXrBblIMeaH1m4Ig Date: Mon, 15 May 2017 16:51:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.200] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705150163 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1705150163 Archived-At: Subject: Re: [Trans] Removal of the use of digitally-signed (issue #174) 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, 15 May 2017 16:54:39 -0000 PiBBcmUgdGhlcmUgYW55IG9waW5pb25zIG9uIHRoZSBtYXR0ZXI/IFBlcnNvbmFsbHkgSSBkb24n dCBtaW5kIGVpdGhlcjsgZ2VuZXJhbGx5LCBkaWdpdGFsbHktc2lnbmVkIHVuYW1iaWd1b3VzbHkg c3BlY2lmaWVzIHdoYXQgZGF0YSB0aGUgc2lnbmF0dXJlIGlzIG92ZXIsIGJ1dCBpbiA2OTYyLWJp cyBpdCdzIGFsd2F5cyBvdmVyIGEgd2VsbC1kZWZpbmVkIGRhdGEgc3RydWN0dXJlIChkZWZpbmVk IHNvbWV3aGVyZSBlbHNlKS4NCg0KTm8gb2JqZWN0aW9uLg0K From nobody Tue May 16 22:21: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 BDDBF129C5F for ; Tue, 16 May 2017 22:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 N157yRtTjDKp for ; Tue, 16 May 2017 22:21:07 -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 DD66B129426 for ; Tue, 16 May 2017 22:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1494998238; bh=1EqjReNQxwEmX8ZlDORc5B3B06VUCO8p93+zbzpKUik=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=AOlJL0h5LQ9p0v4BCrPJaBmeBuoIX/lBpWThflvLJeQCd4MJkJjzkCPD8Uyc+qkA0 OFwAxRbqtlo1LhRUDjwjowNfMiQBdXp8SmIwfoCGi9D5z/PmqO9EsUNQZeDSYWeUy6 g3VFOKvxEpGf0oZhi15XTCzpLLk0Qki3nCShG1BU64UKJ2k182XtKAaIfU/7xFIFNV 7bHUe7PqSognJ9wyivfkH7pfN6EdOxMeCTQ2mEFmRX/BTKcH+PCW70f2YHv4jFwRIu 9VAeyWGJibFvmYw2rMAC5J/WJC2SjNL57xcxkjClJo/NN4sZLW06OOCoMkyR9BBHD5 HHFY7qAHvxY0g== Date: Tue, 16 May 2017 22:17:17 -0700 From: Andrew Ayer To: Eran Messeri Cc: Linus Nordberg , "trans@ietf.org" Message-Id: <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> In-Reply-To: References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 17 May 2017 05:21:10 -0000 On Mon, 15 May 2017 17:18:22 +0100 Eran Messeri wrote: > As it has been pointed out to me, the STH history API, even with the > proposed changes of adding a sequence number to issued STHs, or > requiring an STH refers to a previous STH, would not prevent > backdating of STHs in a meaningful way - see explanation below. This is not the only reason for a get-sths API. The other reason is that it facilitates the prospective auditing model favored by Mozilla, which is why Richard Barnes has asked for it[1]. There seems to be a general agreement that in the long term, TLS servers should send inclusion proofs due to the difficulty of auditing SCTs robustly and privately. 6962-bis already provides a way to embed inclusion proofs in the certificate, OCSP response, or TLS handshake. However, this is just shifting the problem to auditing STHs. Unfortunately, gossiping STHs or requesting consistency proofs has similar privacy problems[2]. An alternative to auditing STHs on-the-fly is for clients to download and cache batches of every STH the log has produced. An inclusion proof would be considered valid as long as it is based on one of the cached STHs. Currently, there are two obstacles to doing this: 1. Getting the STHs. Calling get-sth repeatedly isn't robust, because an STH might be missed. A get-sths endpoint allows all STHs to be obtained so they can be cached. 2. Auditing the STHs. Obtaining consistency proofs for every STH would require a lot of bandwidth. For this reason, Richard Barnes called for the use of a Haber-Stornetta hash chain[3], which would be a rather drastic change to the protocol. I have a simpler proposal: have each STH contain the hash of the previous STH. This provides the same properties as a Haber-Stornetta hash chain while making only a modest, backwards-compatible change to the protocol. Clients need only gossip the latest STH to be confident that everyone has the same view of the log, including its entire STH history. Therefore, there is no need for clients to audit the consistency of each STH, as this job can be left to auditors who are guaranteed to have the same view of the log's STH history. A get-sths endpoint, plus embedding the hash of the previous STH in each STH, plus the existing ability to embed inclusion proofs, will permit RFC6962-bis to be used with a robust, privacy-preserving, and prospective auditing model, while remaining conceptually backwards compatible with the auditing model of RFC6962. This seems like a win-win to me. Regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c [2] Although an STH doesn't uniquely identify a certificate like an SCT does, in practice a client auditing or gossiping a particular STH may be a very strong indicator that it just saw a particular certificate. For example, if 10 certificates embed an inclusion proof to STH X, but 9 of those certificates are expired or aren't used on the public Internet, then a client auditing STH X probably just connected to the server identified by the 10th certificate. [3] https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368 From nobody Fri May 19 07:50:14 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B08128959 for ; Fri, 19 May 2017 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 kdYxMoDsNs5H for ; Fri, 19 May 2017 07:50:10 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F4F12869B for ; Fri, 19 May 2017 07:50:10 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id g126so47860953ith.0 for ; Fri, 19 May 2017 07:50:10 -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=pNMK11PTibcm8fa3DZKk470VwvP2s5nKv8CdvjlGW0o=; b=iwSwFpQ09JboCRFWaa+ub7lrY6FKHOostvGwFjF2dIx/g7/jmxS0nK53cEkLgcgfHQ 71Yq29xunuyUnZ5ApnYeJ803y1wu2O4FNa0GAncp1t5c31RpLAJV/odr0mhmaAWpW7LI qGHlX8r8KIGuCGSXOt1BEXe9FfeYO+w4hFfgQQqwyYygKH2OmfZmqw+rJq6Bbj2RZA5a k3bKMtERBWvYmAuiFt1GvKo6R089r9xY5p8WtRomFtemw5lV3Cv68nD6CEw3LTaNjn03 tNwWSbseMcONumI5hbsAl7YmgT6jai32TSJa7WvnME3xsEiV3w0pJI+ZP4txo9Xr52p0 DL1A== 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=pNMK11PTibcm8fa3DZKk470VwvP2s5nKv8CdvjlGW0o=; b=Ms2uSKTNStKrmknh14kEo7GXSsnERQeDlZWVz3o+etUf6CyV0GI9VbMlmY7+MOON4J 2N/Q57shelgqr3HcwKjtS8Ed3q2v+uPgecSeI0Pu5CdiLJRlQ9R/B/R6zsiJdaJBSZn9 blhz4nWAcxn8N/j3WmpkL7DS41h6yMtsM0gjd6YscwlHP4WhSxWVepFCm4CnB8OWxziO uuhg3lCvLgv9M6r/NA2Aoe6uBokGY1PTnHLx4s4uyEY4T0VuDA+uwMpUwTkIzcwqszdz QvsgNE3Au76bAlRVCp2le5xn86T+vGfwMQlJMmy2E9xGnjKsWOWbVbxCZrU2nZu/2KVy 1hrA== X-Gm-Message-State: AODbwcCXAnl5kwW8Z8Ho3OaLGYou7zbfIf10T3C0kOKC9h4yso2lt9S/ ldkwoX/84ODKTVuJRxeRPeBhhiynddxS1fhDcA== X-Received: by 10.36.55.149 with SMTP id r143mr27728740itr.53.1495205409630; Fri, 19 May 2017 07:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Fri, 19 May 2017 07:49:38 -0700 (PDT) In-Reply-To: <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> From: Eran Messeri Date: Fri, 19 May 2017 15:49:38 +0100 Message-ID: To: Andrew Ayer Cc: Linus Nordberg , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1140c8384f3f28054fe1a3b2" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 19 May 2017 14:50:13 -0000 --001a1140c8384f3f28054fe1a3b2 Content-Type: text/plain; charset="UTF-8" Following an out-of-band discussion with Andrew (summarized below), I propose the following, to make progress on 6962-bis: * Add get-sths as a mandatory API. * Defer discussion on chaining of STHs to a follow-up document: It's evident that we need to do more thinking about it. Since we have an STH extensions mechanism, an extension including a reference to a past STHs can be added in a later document. It seems to me that STH chaining is set out to achieve a goal that's different than how CT currently operates; I'm also not confident it can achieve this goal. Because further discussion on both topics is necessary, I don't think it's right to add this feature to 6962-bis yet or gate 6962-bis on it. CT's current design aims to detect a single log presenting different views (i.e. different trees) to different parties by exchanging STHs between observers. A variant with stronger security guarantees aims to have individual clients have the entire STH history so they cannot be presented with inclusion proofs to different trees at different times. Chaining STHs aims to achieve that (as far as I understand). However it seems to me chaining STHs does not prevent a client, that fetches STHs individually, from being tricked into accepting inclusion proofs to different trees presented by the same log: A log could produce the following chain of STHs: STH 1 with root hash Z, then STH 2 with root hash Y = HASH(Z || hash(entry_1)), prev_hash = Z, then STH 3 with root hash X = HASH(Z || hash(entry_2)), prev_hash = Y (assuming the tree size with STH1 is an exact power of 2, just for simplicity, as the new root hash would be exactly HASH(0x01 || Z || hash(new entry))). STH 1 chains to STH 2 that chains to STH 3, but STH 2 and STH 3 each have, as their root hash, hash of Z, appending a different entry every time (the tree is forked at root hash Z). To the rest of the world, the log would present a chain of hashes that is STH 1 and STH 3' - which has the same root hash as STH 3 but prev_hash = Z. The client could not know that it's being presented with a chain of STHs that are for different trees unless it has consistency proofs between (STH1, STH2) and (STH2, STH3). It seems to me that: - Clients still need to get (via push or pull) consistency proofs between STHs and validate them. - STHs still have to be gossiped for a single entity (monitor) to be in possession of STHs that cannot be proven consistent. But maybe there are other ways to chain STHs, so I'd like to follow up on that independently of 6962-bis. Eran On Wed, May 17, 2017 at 6:17 AM, Andrew Ayer wrote: > On Mon, 15 May 2017 17:18:22 +0100 > Eran Messeri wrote: > > > As it has been pointed out to me, the STH history API, even with the > > proposed changes of adding a sequence number to issued STHs, or > > requiring an STH refers to a previous STH, would not prevent > > backdating of STHs in a meaningful way - see explanation below. > > This is not the only reason for a get-sths API. The other reason is that > it facilitates the prospective auditing model favored by Mozilla, which is > why Richard Barnes has asked for it[1]. > > There seems to be a general agreement that in the long term, TLS > servers should send inclusion proofs due to the difficulty of auditing > SCTs robustly and privately. 6962-bis already provides a way to embed > inclusion proofs in the certificate, OCSP response, or TLS handshake. > However, this is just shifting the problem to auditing STHs. > Unfortunately, gossiping STHs or requesting consistency proofs has > similar privacy problems[2]. > > An alternative to auditing STHs on-the-fly is for clients to download and > cache batches of every STH the log has produced. An inclusion proof would > be considered valid as long as it is based on one of the cached STHs. > > Currently, there are two obstacles to doing this: > > 1. Getting the STHs. Calling get-sth repeatedly isn't robust, because an > STH might be missed. A get-sths endpoint allows all STHs to be obtained > so they can be cached. > > 2. Auditing the STHs. Obtaining consistency proofs for every STH would > require a lot of bandwidth. For this reason, Richard Barnes called > for the use of a Haber-Stornetta hash chain[3], which would be a rather > drastic change to the protocol. > > I have a simpler proposal: have each STH contain the hash of the previous > STH. This provides the same properties as a Haber-Stornetta hash chain > while making only a modest, backwards-compatible change to the protocol. > Clients need only gossip the latest STH to be confident that everyone > has the same view of the log, including its entire STH history. Therefore, > there is no need for clients to audit the consistency of each STH, as this > job can be left to auditors who are guaranteed to have the same view of > the log's STH history. > > A get-sths endpoint, plus embedding the hash of the previous STH in each > STH, plus the existing ability to embed inclusion proofs, will permit > RFC6962-bis to be used with a robust, privacy-preserving, and prospective > auditing model, while remaining conceptually backwards compatible with > the auditing model of RFC6962. This seems like a win-win to me. > > Regards, > Andrew > > > [1] https://mailarchive.ietf.org/arch/msg/trans/ > Zm4NqyRc7LDsOtV56EchBIT9r4c > > [2] Although an STH doesn't uniquely identify a certificate like an SCT > does, in practice a client auditing or gossiping a particular STH may > be a very strong indicator that it just saw a particular certificate. > For example, if 10 certificates embed an inclusion proof to STH X, > but 9 of those certificates are expired or aren't used on the public > Internet, then a client auditing STH X probably just connected to the > server identified by the 10th certificate. > > [3] https://mailarchive.ietf.org/arch/msg/trans/gO_ > DFW3v9FmBCOek_hifZ6KL368 > --001a1140c8384f3f28054fe1a3b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following an out-of-band discussion with Andrew (summarize= d below), I propose the following, to make progress on 6962-bis:
* Add = get-sths as a mandatory API.
* Defer discussion on chaining of ST= Hs to a follow-up document: It's evident that we need to do more thinki= ng about it. Since we have an STH extensions mechanism, an extension includ= ing a reference to a past STHs can be added in a later document.
=
It seems to me that STH chaining is set out to achieve a goa= l that's different than how CT currently operates; I'm also not con= fident it can achieve this goal. Because further discussion on both topics = is necessary, I don't think it's right to add this feature to 6962-= bis yet or gate 6962-bis on it.

CT's current d= esign aims to detect a single log presenting different views (i.e. differen= t trees) to different parties by exchanging STHs between observers.
A variant with stronger security guarantees aims to have individual clie= nts have the entire STH history so they cannot be presented with inclusion = proofs to different trees at different times. Chaining STHs aims to achieve= that (as far as I understand).

However it seems t= o me chaining STHs does not prevent a client, that fetches STHs individuall= y, from being tricked into accepting inclusion proofs to different trees pr= esented by the same log:

A log could produce the f= ollowing chain of STHs:
STH 1 with root hash Z, then STH 2 w= ith root hash Y =3D HASH(Z || hash(entry_1)), prev_hash =3D Z, then STH 3 w= ith root hash X =3D HASH(Z || hash(entry_2)), prev_hash =3D Y (assuming the= tree size with STH1 is an exact power of 2, just for simplicity, as the ne= w root hash would be exactly HASH(0x01 || Z || hash(new entry))).
STH 1 chains to STH 2 that chains to STH 3, but STH 2 and STH 3 each have,= as their root hash, hash of Z, appending a different entry every time (the= tree is forked at root hash Z).
To the rest of the world, the lo= g would present a chain of hashes that is STH 1 and =C2=A0STH 3' - whic= h has the same root hash as STH 3 but prev_hash =3D Z.
= The client could not know that it's being presented with a chain of STH= s that are for different trees unless it has consistency proofs between (ST= H1, STH2) and (STH2, STH3).

It seems to me that:
- Clients still need to get (via push or pull) consistency proofs = between STHs and validate them.
- STHs still have to be gossiped = for a single entity (monitor) to be in possession of STHs that cannot be pr= oven consistent.

But maybe there are other ways to= chain STHs, so I'd like to follow up on that independently of 6962-bis= .

Eran


On Wed, May 17, 2017 at 6:17 AM, A= ndrew Ayer <agwa@andrewayer.name> wrote:
On Mon, 15 May 2017 17:18:22 +0100
Eran Messeri <eranm@google.com&g= t; wrote:

> As it has been pointed out to me, the STH history API, even with the > proposed changes of adding a sequence number to issued STHs, or
> requiring an STH refers to a previous STH, would not prevent
> backdating of STHs in a meaningful way - see explanation below.

This is not the only reason for a get-sths API.=C2=A0 The other reas= on is that
it facilitates the prospective auditing model favored by Mozilla, which is<= br> why Richard Barnes has asked for it[1].

There seems to be a general agreement that in the long term, TLS
servers should send inclusion proofs due to the difficulty of auditing
SCTs robustly and privately.=C2=A0 6962-bis already provides a way to embed=
inclusion proofs in the certificate, OCSP response, or TLS handshake.
However, this is just shifting the problem to auditing STHs.
Unfortunately, gossiping STHs or requesting consistency proofs has
similar privacy problems[2].

An alternative to auditing STHs on-the-fly is for clients to download and cache batches of every STH the log has produced.=C2=A0 An inclusion proof w= ould
be considered valid as long as it is based on one of the cached STHs.

Currently, there are two obstacles to doing this:

1. Getting the STHs.=C2=A0 Calling get-sth repeatedly isn't robust, bec= ause an
STH might be missed.=C2=A0 A get-sths endpoint allows all STHs to be obtain= ed
so they can be cached.

2. Auditing the STHs.=C2=A0 Obtaining consistency proofs for every STH woul= d
require a lot of bandwidth.=C2=A0 For this reason, Richard Barnes called for the use of a Haber-Stornetta hash chain[3], which would be a rather
drastic change to the protocol.

I have a simpler proposal: have each STH contain the hash of the previous STH.=C2=A0 This provides the same properties as a Haber-Stornetta hash chai= n
while making only a modest, backwards-compatible change to the protocol. Clients need only gossip the latest STH to be confident that everyone
has the same view of the log, including its entire STH history.=C2=A0 There= fore,
there is no need for clients to audit the consistency of each STH, as this<= br> job can be left to auditors who are guaranteed to have the same view of
the log's STH history.

A get-sths endpoint, plus embedding the hash of the previous STH in each STH, plus the existing ability to embed inclusion proofs, will permit
RFC6962-bis to be used with a robust, privacy-preserving, and prospective auditing model, while remaining conceptually backwards compatible with
the auditing model of RFC6962. This seems like a win-win to me.

Regards,
Andrew


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

[2] Although an STH doesn't uniquely identify a certificate like an SCT=
does, in practice a client auditing or gossiping a particular STH may
be a very strong indicator that it just saw a particular certificate.
For example, if 10 certificates embed an inclusion proof to STH X,
but 9 of those certificates are expired or aren't used on the public Internet, then a client auditing STH X probably just connected to the
server identified by the 10th certificate.

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

--001a1140c8384f3f28054fe1a3b2-- From nobody Fri May 19 09:19: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 951AC1294E1 for ; Fri, 19 May 2017 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX1TbKklWZwr for ; Fri, 19 May 2017 09:19:08 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 6EED1129447 for ; Fri, 19 May 2017 09:19:08 -0700 (PDT) Received: (qmail 19264 invoked by uid 1004); 19 May 2017 16:19:05 -0000 Received: from rmdccgwarp2.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.83) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 19 May 2017 17:19:05 +0100 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 201705191719032842; Fri, 19 May 2017 17:19:03 +0100 To: Eran Messeri Cc: Linus Nordberg , trans@ietf.org References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> <8760h6i3h4.fsf@nordberg.se> From: Rob Stradling Message-ID: <76f9b826-6553-143a-4ff4-504022fc4354@comodo.com> Date: Fri, 19 May 2017 17:19:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <8760h6i3h4.fsf@nordberg.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 19 May 2017 16:19:14 -0000 On 12/05/17 14:55, Linus Nordberg wrote: > I like the single add-entry call idea together with the explicit > 'is_precertificate' indication. Would "submit-entry" be a better API name than "add-entry" (given that the Submitter can't guarantee that the log will accept the submission and add it to its tree)? (Attempt at future-proofing) Rather than an "is_precertificate" parameter, how about adding a "type" parameter that takes a VersionedTransType integer value? i.e., x509_entry_v2(1) or precert_entry_v2(2), for the two types of submission that 6962-bis cares about. > The naming here is a bit unfortunate though, at least when compared with > PR 256 [1] where 'submission' seems to mean end-entity-(pre)cert _and_ > chain. I suggest making the input to an add-entry call and the output > from the get-entries call identical, if at all possible. > > [1] https://github.com/google/certificate-transparency-rfcs/pull/256/files > > Eran Messeri wrote > Fri, 12 May 2017 14:27:04 +0100: > >> (follow-up from an out-of-band discussion with Andrew) >> The concern Andrew has raised,of some implementations accepting a null >> values, it is very valid. Fortunately, it's easy to check that logs do not >> behave that way. >> >> An alternative approach to unifying add-chain/add-pre-chain is to have a >> single add-entry call which takes, as inputs: >> 'submission' - base64-encoded DER certificate OR CMS Precertificate. >> 'chain' - chaining the submission to a root, like now. >> 'is_precertificate' - indicating whether the 'submission' parameter should >> be parsed as a DER-encoded certificate or CMS Precertificate. >> >> Any opinions on that? >> >> Personally I think the concern Andrew has raised is very valid and the spec >> should explicitly deal with it, forbidding the presence of an empty >> 'precertificate' parameter if a 'certificate' is being supplied, and vice >> versa, and logs can easily be checked for compliance with that requirement. >> >> However I'm also OK with leaving add-chain / add-pre-chain as separate >> methods. >> >> Eran >> >> On Thu, May 4, 2017 at 7:24 PM, Richard Barnes wrote: >> >>> TBH, I don't feel very strongly about this. Andrew's analysis seems >>> pretty sound. >>> >>> On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer wrote: >>> >>>> Regarding https://github.com/google/certificate-transparency-rfcs/pull>> /248 >>>> >>>> I do not think this is a good change. >>>> >>>> If an implementation wants to use a struct to represent the add-entry >>>> message (as Google's Golang CT library currently does), the struct would >>>> need to contain nullable variables for the certificate and >>>> precertificate fields. Nullable variables are error-prone and are best >>>> avoided if possible. >>>> >>>> For example, a client might accidentally send null as one of these >>>> fields instead of omitting it (with Go, this can easily happen if you >>>> forget to tag the struct field as omitempty). Although this would be a >>>> malformed add-entry message, I expect many servers would accept it >>>> because many JSON deserializers I've seen (such as Go's) do not >>>> distinguish between a null struct field and an omitted struct field. >>>> This risks causing interoperability problems. I expect the predominant >>>> 6962-bis log server will be Google's Trillian, which means clients will >>>> be interacting mostly with log servers which exhibit the lax >>>> deserialization behavior. The client's mistake won't be noticed until >>>> it tries to submit a chain to a rarer, stricter server, which might >>>> happen long after the client code has been deployed. >>>> >>>> Therefore, I favor keeping add-chain and add-pre-cert as separate >>>> endpoints. That way, the structure of the messages are rigid and >>>> clearly indicated by the name of the endpoint. The protocol will have >>>> only one joint (the endpoint name) instead of two (the endpoint name >>>> plus the presence or absence of the precertificate and certificate >>>> fields). >>>> >>>> Regards, >>>> Andrew >>>> >>>> _______________________________________________ >>>> 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> >>> >> _______________________________________________ >> 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 > -- 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 Fri May 19 10: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 1EF6F129AAA for ; Fri, 19 May 2017 10:44: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, 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 qsxnegIcYQqD for ; Fri, 19 May 2017 10:44:34 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 742B4129AB3 for ; Fri, 19 May 2017 10:44:33 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id 187so12933369ybg.0 for ; Fri, 19 May 2017 10:44:33 -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=+0wzOFjWX7k9q7QDmfakGVUDgKc58OJrQbdK5fEZYDs=; b=l5Teo2k02W0eETeeJpJ8Ot2i1cNwskB6IQ6m9iqZ8OSAozKmkyNbtbKKR/K6bIdN/I QUOZKV/7FzkHP4vnhyMxti4wBqvPDMLXXl915BL/mF4wrkNRiJu3zBdrFxaS6LySwnHh xo2oymbW4ty5a87DpJmkWEkZ9rhRkBFPatj58gFZN+y7V9YibgHOYDcbiylGyE8lmfWL HxksEHnOvQ5zD9k+kCdoVlmgXZaZpDjLp95ZsE91D0UB+1/6qHQyBaIsLaAb1g8L2rji Sb4WfYsF9U0+tamhAEEc7uhZz/R/JEMJ/nWxrJa4SJvfy57qjBJ8Dlqq7yGQQp+hcW7w +9aQ== 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=+0wzOFjWX7k9q7QDmfakGVUDgKc58OJrQbdK5fEZYDs=; b=GGqwLbCC14U+c4Z9bPG61T/lHc3wDSVvetSWKruCskO7CTe0bl1XveH9Rkns7YYpo9 LeLptZyKCCYrthyEnt0ogFAa1rEiCzi3bpgUP33qaMvLHpFlny2tdvOaaE4lOu6me30G L+1RBvSFVHtrGCTicMRek8WoWDnP7jIxxhInt1vGlcaWUQIpE5dAajDJkIwK/KGglEK5 qt3uxiy7njQeFUlwtHoLZy8yxi1yxsxvYE8cEvNTca3uTVxL8Mgycnn2okvdGzynMOXf Oj7ik4cjHxHzz5PCl/Dpt0f6GvHUWSdN9ZG8I6QbeeL3RtOQFS2p6x/eBxjkhkq3C7pI U8Sw== X-Gm-Message-State: AODbwcC06SEXe07zbCitQcoIGGrT9ZoZvCV5M6Q96pbc9kIOIJFVTkIY T1j0gFDU2xC+ynzg/TGVHVqPQVTNgUhu X-Received: by 10.37.108.212 with SMTP id h203mr9178978ybc.77.1495215872384; Fri, 19 May 2017 10:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.177.9 with HTTP; Fri, 19 May 2017 10:44:31 -0700 (PDT) In-Reply-To: References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> From: Al Cutter Date: Fri, 19 May 2017 18:44:31 +0100 Message-ID: To: Eran Messeri Cc: Andrew Ayer , "trans@ietf.org" , Linus Nordberg Content-Type: multipart/alternative; boundary="001a1148b060f0252f054fe41204" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 19 May 2017 17:44:37 -0000 --001a1148b060f0252f054fe41204 Content-Type: text/plain; charset="UTF-8" On Fri, May 19, 2017 at 3:49 PM, Eran Messeri wrote: > Following an out-of-band discussion with Andrew (summarized below), I > propose the following, to make progress on 6962-bis: > * Add get-sths as a mandatory API. > * Defer discussion on chaining of STHs to a follow-up document: It's > evident that we need to do more thinking about it. Since we have an STH > extensions mechanism, an extension including a reference to a past STHs can > be added in a later document. > In the ticket you said: "The problem it [get-sths API] solves is the lack of ability to verify that the log did not breach the MMD throughout its lifetime: A submission's timestamp is available via get-entries, but unless a monitor has observed STHs issued by the log around the time an entry was created for it, there's no proof that the entry was incorporated within the MMD." but you later acknowledged that a get-sths API without some extra sprinkles *somewhere* doesn't actually solve that problem because there's nothing stopping a Log from going back and creating a few extra "old" STHs to cover, say, a period when its signing infrastructure was down, which it'll happily return to you when you call get-sths at a later date. I admit I'm not really that familiar with process of defining RFCs, but it seems weird to me to add a mandatory API, which, as defined in the standard which makes it mandatory, doesn't solve the problem it was added to solve... > It seems to me that STH chaining is set out to achieve a goal that's > different than how CT currently operates; I'm also not confident it can > achieve this goal. Because further discussion on both topics is necessary, > I don't think it's right to add this feature to 6962-bis yet or gate > 6962-bis on it. > > CT's current design aims to detect a single log presenting different views > (i.e. different trees) to different parties by exchanging STHs between > observers. > A variant with stronger security guarantees aims to have individual > clients have the entire STH history so they cannot be presented with > inclusion proofs to different trees at different times. Chaining STHs aims > to achieve that (as far as I understand). > > However it seems to me chaining STHs does not prevent a client, that > fetches STHs individually, from being tricked into accepting inclusion > proofs to different trees presented by the same log: > > A log could produce the following chain of STHs: > STH 1 with root hash Z, then STH 2 with root hash Y = HASH(Z || > hash(entry_1)), prev_hash = Z, then STH 3 with root hash X = HASH(Z || > hash(entry_2)), prev_hash = Y (assuming the tree size with STH1 is an exact > power of 2, just for simplicity, as the new root hash would be exactly > HASH(0x01 || Z || hash(new entry))). > STH 1 chains to STH 2 that chains to STH 3, but STH 2 and STH 3 each have, > as their root hash, hash of Z, appending a different entry every time (the > tree is forked at root hash Z). > To the rest of the world, the log would present a chain of hashes that is > STH 1 and STH 3' - which has the same root hash as STH 3 but prev_hash = Z. > The client could not know that it's being presented with a chain of STHs > that are for different trees unless it has consistency proofs between > (STH1, STH2) and (STH2, STH3). > > It seems to me that: > - Clients still need to get (via push or pull) consistency proofs between > STHs and validate them. > - STHs still have to be gossiped for a single entity (monitor) to be in > possession of STHs that cannot be proven consistent. > The hash chaining is only a commitment to a claim of which blob is the immediate predecessor of this other blob, you still need to verify the correctness of the blobs in context, of course. At least for the monitoring-MMD use-case, it seems like a similar thing could be achieved by requiring Logs to also log their own STHs, even allowing for the vagaries of pending queues that'd put an MMD-sized window on how far back in time a log could create old STHs to cover up MMD-blown fails. The monitors wouldn't then need a get-sths call (although if there were other use cases for that API then the results from it would at least be verifiable by monitors). A thought is that you'd then have the ability to query a Log using get-proof-by-hash for an STH you're holding to see if it can prove it was logged, I'm not sure if that's useful at the moment, but my Friday evening brain finds it amusing for some reason. The obvious next step would be to require Logs to log their STHs with a quorum of other Logs. Assuming all Logs are not collaborating, that makes it quite a lot harder for anyone to pull off split views, and of course you can now do the same get-proof-by-hash call for your STH on other logs now, if you didn't mind trying a a number of logs (or if you already knew in which Logs to look*). *perhaps the set of target logs for a given STH could be defined by some function of the day or week that the STH timestamp corresponds to - something which changes infrequently enough that Logs can't simply not issue an STH during that period or they'd blow their MMD - the intention being to narrow the set of logs you'd have to look in, but also make it harder to to choose colluding Logs. > But maybe there are other ways to chain STHs, so I'd like to follow up on > that independently of 6962-bis. > > Eran > > > On Wed, May 17, 2017 at 6:17 AM, Andrew Ayer wrote: > >> On Mon, 15 May 2017 17:18:22 +0100 >> Eran Messeri wrote: >> >> > As it has been pointed out to me, the STH history API, even with the >> > proposed changes of adding a sequence number to issued STHs, or >> > requiring an STH refers to a previous STH, would not prevent >> > backdating of STHs in a meaningful way - see explanation below. >> >> This is not the only reason for a get-sths API. The other reason is that >> it facilitates the prospective auditing model favored by Mozilla, which is >> why Richard Barnes has asked for it[1]. >> >> There seems to be a general agreement that in the long term, TLS >> servers should send inclusion proofs due to the difficulty of auditing >> SCTs robustly and privately. 6962-bis already provides a way to embed >> inclusion proofs in the certificate, OCSP response, or TLS handshake. >> However, this is just shifting the problem to auditing STHs. >> Unfortunately, gossiping STHs or requesting consistency proofs has >> similar privacy problems[2]. >> >> An alternative to auditing STHs on-the-fly is for clients to download and >> cache batches of every STH the log has produced. An inclusion proof would >> be considered valid as long as it is based on one of the cached STHs. >> >> Currently, there are two obstacles to doing this: >> >> 1. Getting the STHs. Calling get-sth repeatedly isn't robust, because an >> STH might be missed. A get-sths endpoint allows all STHs to be obtained >> so they can be cached. >> >> 2. Auditing the STHs. Obtaining consistency proofs for every STH would >> require a lot of bandwidth. For this reason, Richard Barnes called >> for the use of a Haber-Stornetta hash chain[3], which would be a rather >> drastic change to the protocol. >> >> I have a simpler proposal: have each STH contain the hash of the previous >> STH. This provides the same properties as a Haber-Stornetta hash chain >> while making only a modest, backwards-compatible change to the protocol. >> Clients need only gossip the latest STH to be confident that everyone >> has the same view of the log, including its entire STH history. >> Therefore, >> there is no need for clients to audit the consistency of each STH, as this >> job can be left to auditors who are guaranteed to have the same view of >> the log's STH history. >> >> A get-sths endpoint, plus embedding the hash of the previous STH in each >> STH, plus the existing ability to embed inclusion proofs, will permit >> RFC6962-bis to be used with a robust, privacy-preserving, and prospective >> auditing model, while remaining conceptually backwards compatible with >> the auditing model of RFC6962. This seems like a win-win to me. >> >> Regards, >> Andrew >> >> >> [1] https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV5 >> 6EchBIT9r4c >> >> [2] Although an STH doesn't uniquely identify a certificate like an SCT >> does, in practice a client auditing or gossiping a particular STH may >> be a very strong indicator that it just saw a particular certificate. >> For example, if 10 certificates embed an inclusion proof to STH X, >> but 9 of those certificates are expired or aren't used on the public >> Internet, then a client auditing STH X probably just connected to the >> server identified by the 10th certificate. >> >> [3] https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek >> _hifZ6KL368 >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a1148b060f0252f054fe41204 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 19, 2017 at 3:49 PM, Eran Messeri <eranm@google.com>= wrote:
Following an out-of-band discussion with Andrew (summarized below= ), I propose the following, to make progress on 6962-bis:
* Add get-sth= s as a mandatory API.
* Defer discussion on chaining o= f STHs to a follow-up document: It's evident that we need to do more th= inking about it. Since we have an STH extensions mechanism, an extension in= cluding a reference to a past STHs can be added in a later document.
<= /div>

In the ticket you said:
"The problem it = [get-sths API] solves is the lack of ability to verify that the log did not= breach the MMD throughout its lifetime: A submission's timestamp is av= ailable via get-entries, but unless a monitor has observed STHs issued by t= he log around the time an entry was created for it, there's no proof th= at the entry was incorporated within the MMD."

but you later acknowledged that a get-sths API without some extra = sprinkles somewhere=C2=A0doesn't actually solve that problem bec= ause there's nothing stopping a Log from going back and creating a few = extra "old" STHs to cover, say, a period when its signing infrast= ructure was down, which it'll happily return to you when you call get-s= ths at a later date.

I admit I'm not rea= lly that familiar with process of defining RFCs, but it seems weird to me t= o add a mandatory API, which, as defined in the standard which makes it man= datory, doesn't solve the problem it was added to solve...
=

It seems to me that STH chaining is set out to achieve = a goal that's different than how CT currently operates; I'm also no= t confident it can achieve this goal. Because further discussion on both to= pics is necessary, I don't think it's right to add this feature to = 6962-bis yet or gate 6962-bis on it.

CT= 's current design aims to detect a single log presenting different view= s (i.e. different trees) to different parties by exchanging STHs between ob= servers.
A variant with stronger security guarantees aims to have= individual clients have the entire STH history so they cannot be presented= with inclusion proofs to different trees at different times. Chaining STHs= aims to achieve that (as far as I understand).

Ho= wever it seems to me chaining STHs does not prevent a client, that fetches = STHs individually, from being tricked into accepting inclusion proofs to di= fferent trees presented by the same log:

A log cou= ld produce the following chain of STHs:
STH 1 with root hash= Z, then STH 2 with root hash Y =3D HASH(Z || hash(entry_1)), prev_hash =3D= Z, then STH 3 with root hash X =3D HASH(Z || hash(entry_2)), prev_hash =3D= Y (assuming the tree size with STH1 is an exact power of 2, just for simpl= icity, as the new root hash would be exactly HASH(0x01 || Z || hash(new ent= ry))).
STH 1 chains to STH 2 that chains to STH 3, but STH 2 and = STH 3 each have, as their root hash, hash of Z, appending a different entry= every time (the tree is forked at root hash Z).
To the rest of t= he world, the log would present a chain of hashes that is STH 1 and =C2=A0S= TH 3' - which has the same root hash as STH 3 but prev_hash =3D Z.
<= /div>
The client could not know that it's being presented wit= h a chain of STHs that are for different trees unless it has consistency pr= oofs between (STH1, STH2) and (STH2, STH3).

=
It seems to me that:
- Clients still need to get (via push o= r pull) consistency proofs between STHs and validate them.
- STHs= still have to be gossiped for a single entity (monitor) to be in possessio= n of STHs that cannot be proven consistent.
The hash chaining is only a commitment to a claim of which blo= b is the immediate predecessor of this other blob, you still need to verify= the correctness of the blobs in context, of course.
=C2=A0
=
At least for the monitoring-MMD use-case, it seems like a similar= thing could be achieved by requiring Logs to also log their own STHs, even= allowing for the vagaries of pending queues that'd put an MMD-sized wi= ndow on how far back in time a log could create old STHs to cover up MMD-bl= own fails.

The monitors wouldn't then need a g= et-sths call (although if there were other use cases for that API then the = results from it would at least=C2=A0be verifiable by monitors).
A= thought is that you'd then have the ability to query a Log using get-p= roof-by-hash for an STH you're holding to see if it can prove it was lo= gged, I'm not sure if that's useful at the moment, but my Friday ev= ening brain finds it amusing for some reason.

The = obvious next step would be to require Logs to log their STHs with a quorum = of other Logs. Assuming all Logs are not collaborating, that makes it quite= a lot harder for anyone to pull off split views, and of course you can now= do the same get-proof-by-hash call for your STH on other logs now, if you = didn't mind trying a a number of logs (or if you already knew in which = Logs to look*).

*perhaps the set of target logs fo= r a given STH could be defined by some function of the day or week that the= STH timestamp corresponds to - something which changes infrequently enough= that Logs can't simply not issue an STH during that period or they'= ;d blow their MMD - the intention being to narrow the set of logs you'd= have to look in, but also make it harder to to choose colluding Logs.
<= /div>



But maybe t= here are other ways to chain STHs, so I'd like to follow up on that ind= ependently of 6962-bis.

Eran


On Wed, May 17, 2017 at 6:17 AM, Andr= ew Ayer <agwa@andrewayer.name> wrote:
On Mon, 15 May 2017 17:18:22 +0100<= br> Eran Messeri <eran= m@google.com> wrote:

> As it has been pointed out to me, the STH history API, even with the > proposed changes of adding a sequence number to issued STHs, or
> requiring an STH refers to a previous STH, would not prevent
> backdating of STHs in a meaningful way - see explanation below.

This is not the only reason for a get-sths API.=C2=A0 The other reas= on is that
it facilitates the prospective auditing model favored by Mozilla, which is<= br> why Richard Barnes has asked for it[1].

There seems to be a general agreement that in the long term, TLS
servers should send inclusion proofs due to the difficulty of auditing
SCTs robustly and privately.=C2=A0 6962-bis already provides a way to embed=
inclusion proofs in the certificate, OCSP response, or TLS handshake.
However, this is just shifting the problem to auditing STHs.
Unfortunately, gossiping STHs or requesting consistency proofs has
similar privacy problems[2].

An alternative to auditing STHs on-the-fly is for clients to download and cache batches of every STH the log has produced.=C2=A0 An inclusion proof w= ould
be considered valid as long as it is based on one of the cached STHs.

Currently, there are two obstacles to doing this:

1. Getting the STHs.=C2=A0 Calling get-sth repeatedly isn't robust, bec= ause an
STH might be missed.=C2=A0 A get-sths endpoint allows all STHs to be obtain= ed
so they can be cached.

2. Auditing the STHs.=C2=A0 Obtaining consistency proofs for every STH woul= d
require a lot of bandwidth.=C2=A0 For this reason, Richard Barnes called for the use of a Haber-Stornetta hash chain[3], which would be a rather
drastic change to the protocol.

I have a simpler proposal: have each STH contain the hash of the previous STH.=C2=A0 This provides the same properties as a Haber-Stornetta hash chai= n
while making only a modest, backwards-compatible change to the protocol. Clients need only gossip the latest STH to be confident that everyone
has the same view of the log, including its entire STH history.=C2=A0 There= fore,
there is no need for clients to audit the consistency of each STH, as this<= br> job can be left to auditors who are guaranteed to have the same view of
the log's STH history.

A get-sths endpoint, plus embedding the hash of the previous STH in each STH, plus the existing ability to embed inclusion proofs, will permit
RFC6962-bis to be used with a robust, privacy-preserving, and prospective auditing model, while remaining conceptually backwards compatible with
the auditing model of RFC6962. This seems like a win-win to me.

Regards,
Andrew


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

[2] Although an STH doesn't uniquely identify a certificate like an SCT=
does, in practice a client auditing or gossiping a particular STH may
be a very strong indicator that it just saw a particular certificate.
For example, if 10 certificates embed an inclusion proof to STH X,
but 9 of those certificates are expired or aren't used on the public Internet, then a client auditing STH X probably just connected to the
server identified by the 10th certificate.

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


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


--001a1148b060f0252f054fe41204-- From nobody Fri May 19 13: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 1CB7812945A for ; Fri, 19 May 2017 13:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 qLnwKXfb552m for ; Fri, 19 May 2017 13:23:19 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A59124BFA for ; Fri, 19 May 2017 13:23:19 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e65so53068895ita.1 for ; Fri, 19 May 2017 13:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nRMETg/U7TmHGh+7YrNQtEeJJp0Rm2Qookx4e+K1Crw=; b=h4KGWCQu89JLlyOl22qFVrGapZ9ihqRkUWVQATtnURDPSuC8ejVA0ZYoylVo4bEFv/ aqmRS12QSpgYyz5ir2v4BRgZ/p1XQazD1BmvvyWFkCPnGPMQzhv1MY6kHi9LVbOhj33S 8bgK5HnDvmAUiXHMhLI7r60G8ib3L3Px/6/x/zcKyQomgnUfg0rJF01q+s5gYijjc+0s 0MrzciTbPGSqWzRxm76GCqRzBeRTlWxWUIszvvwnWMCZUi1liyb87t1jUKbV2ejApUfw ERIe4fW4LtquGZAOzqm3IrPfvBPfSElz7teqZToACses923Z3sZsFYPT/tUNBEXLVq0f 6idg== 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=nRMETg/U7TmHGh+7YrNQtEeJJp0Rm2Qookx4e+K1Crw=; b=DIJzHEjDBzLRESfZsH11jAye6mnVurNZBIxX+2uVYOjpVLNPXgNzEWkTeNIki6AXDW 0obY/ri5TTXSvvIL36mA2i4Jx7gv01d94eI6cwjcwXL6N3ReEL+EncnMK7Ip+etZQ9PK eO5H+fmGiSDn7qgEFlLnrU4idrNpbC8qido969jrgx5Hf78vF9AACsNKFSiTm6e1f+XW FmPvXZ9YWL1UK1ywB4NxN/aDZ6Y2V75HvaIoiApYQpVd/u11s70tpCUKQgil/nQLQEFc kQ62+NnrRVuzZsMxsVIxKg8YUwVs64EhPeW7QQqv0T4spZLhekE9mnEpFkNxKOI7JvWW Kr4A== X-Gm-Message-State: AODbwcBCYcEJFH+TRZJGrEHtkETjLP07u5I5iFq7E3sPxufwjSZvepsN v7oNg0xoVrNCDXBZsLqld+lA8qGBgUIu X-Received: by 10.36.77.211 with SMTP id l202mr12824116itb.74.1495225398804; Fri, 19 May 2017 13:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.47.146 with HTTP; Fri, 19 May 2017 13:23:18 -0700 (PDT) In-Reply-To: References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> From: Brian Smith Date: Fri, 19 May 2017 10:23:18 -1000 Message-ID: To: Al Cutter Cc: Eran Messeri , Linus Nordberg , "trans@ietf.org" , Andrew Ayer Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 19 May 2017 20:23:21 -0000 On Fri, May 19, 2017 at 7:44 AM, Al Cutter wrote: > I admit I'm not really that familiar with process of defining RFCs, but it > seems weird to me to add a mandatory API, which, as defined in the standard > which makes it mandatory, doesn't solve the problem it was added to solve... I agree with this. This is an extra hoop for logs to jump through that doesn't add significant value. There are lots of ways to improve CT beyond this RFC. Things like this, if they should be standardized at all, should go into their own RFCs that update or even obsolete 6962-bis. Perhaps a 6962-bis-bis. Cheers, Brian -- https://briansmith.org/ From nobody Fri May 19 13:45: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 03A59129AC1 for ; Fri, 19 May 2017 13:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 LgyxHgqTLdaz for ; Fri, 19 May 2017 13:45:12 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 92F871294C4 for ; Fri, 19 May 2017 13:45:12 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p85so17968925vkd.3 for ; Fri, 19 May 2017 13:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Kppqq/RdiauK//yODrVZUTLewqT7yrjpaiMI4v10h0=; b=Pc2gYyG7GwA+tEcp416waSeqSwY0aRWYOQI4p5DTvlihpcZsGPAe+Ms6e/Xynoa6vO pSDAG1AJIKheui6ebhbGkYGll6B8nq2KWn5mPlkG4PP6e82lG6AzYjlJvN0YX8ihF0FD eSm4plpOPS/8WuL+wMsuMWzmhN6hj8T+rDhd78C5aSWDIwY50hYkbanzKDsgW3oWjJC2 skxD8jHxRBuYpzrmO47M8zkaamtwlpmqMe5Uq2KwT4bRkBGyMpk0kcgMk4/TVMpdadh2 9KdAabGd5rAQYvh/jdJ80CNreLNzhhnCkbNVxlxreo4xY5iF6y1vfOjTd0e5sHWochd0 rwgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Kppqq/RdiauK//yODrVZUTLewqT7yrjpaiMI4v10h0=; b=mhPY5WXeziZ8FObndN8IccjPqdybrWjhGh4ZJncYVNoEA2tjcLQWjN4Z6ES7d8sIKD uN2O0uAb6PL1sGp7msZ3qB2IbDuw5KWBb9vETcc6wYoyGCTJcWAc/HhtiWA1/4q+GzPB f4I9gVvBiHirBaO/EDf38IUkPwnLVSZpiNMx8x/1NGsyRcPoU3kTM5L6hb++ljV0AelL JtGh0Zigcv8icg38qT2seWIED8ZHAFa/l1xapIoTCgGX/NYx9FdsDtiSLDEgV4yK09vb WiO3sEbEH/r0tAhSmkg2U6Sy//rvqtVK2tG95tPQ8wcIqWs8vFYccZux8+X7P1E/N6XU O2+A== X-Gm-Message-State: AODbwcCIvna9hIgr3NrE/K7Q5w2oRFTkGEya/8sXj9dsgMKpYYsfwuUL vPMy95V9mXfeoaNBPn6G7D7QL7Cvag== X-Received: by 10.31.157.132 with SMTP id g126mr2654973vke.60.1495226711652; Fri, 19 May 2017 13:45:11 -0700 (PDT) MIME-Version: 1.0 References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> In-Reply-To: From: Nick Sullivan Date: Fri, 19 May 2017 20:45:00 +0000 Message-ID: To: Al Cutter , Eran Messeri Cc: Linus Nordberg , "trans@ietf.org" , Andrew Ayer Content-Type: multipart/alternative; boundary="001a11425fc401bf37054fe699a5" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 19 May 2017 20:45:16 -0000 --001a11425fc401bf37054fe699a5 Content-Type: text/plain; charset="UTF-8" On Fri, May 19, 2017 at 10:44 AM Al Cutter wrote: > On Fri, May 19, 2017 at 3:49 PM, Eran Messeri wrote: > >> Following an out-of-band discussion with Andrew (summarized below), I >> propose the following, to make progress on 6962-bis: >> * Add get-sths as a mandatory API. >> > * Defer discussion on chaining of STHs to a follow-up document: It's >> evident that we need to do more thinking about it. Since we have an STH >> extensions mechanism, an extension including a reference to a past STHs can >> be added in a later document. >> > > In the ticket you said: > "The problem it [get-sths API] solves is the lack of ability to verify > that the log did not breach the MMD throughout its lifetime: A submission's > timestamp is available via get-entries, but unless a monitor has observed > STHs issued by the log around the time an entry was created for it, there's > no proof that the entry was incorporated within the MMD." > > but you later acknowledged that a get-sths API without some extra > sprinkles *somewhere* doesn't actually solve that problem because there's > nothing stopping a Log from going back and creating a few extra "old" STHs > to cover, say, a period when its signing infrastructure was down, which > it'll happily return to you when you call get-sths at a later date. > This is prevented by requiring the get STHs endpoint to provide a consistent sequence of entries over time and making sure that auditors track it. Alternatively, the chaining idea also achieves this, and so does logging STHs as you suggest. > > I admit I'm not really that familiar with process of defining RFCs, but it > seems weird to me to add a mandatory API, which, as defined in the standard > which makes it mandatory, doesn't solve the problem it was added to solve... > > >> It seems to me that STH chaining is set out to achieve a goal that's >> different than how CT currently operates; I'm also not confident it can >> achieve this goal. Because further discussion on both topics is necessary, >> I don't think it's right to add this feature to 6962-bis yet or gate >> 6962-bis on it. >> > >> CT's current design aims to detect a single log presenting different >> views (i.e. different trees) to different parties by exchanging STHs >> between observers. >> A variant with stronger security guarantees aims to have individual >> clients have the entire STH history so they cannot be presented with >> inclusion proofs to different trees at different times. Chaining STHs aims >> to achieve that (as far as I understand). >> >> However it seems to me chaining STHs does not prevent a client, that >> fetches STHs individually, from being tricked into accepting inclusion >> proofs to different trees presented by the same log: >> >> A log could produce the following chain of STHs: >> STH 1 with root hash Z, then STH 2 with root hash Y = HASH(Z || >> hash(entry_1)), prev_hash = Z, then STH 3 with root hash X = HASH(Z || >> hash(entry_2)), prev_hash = Y (assuming the tree size with STH1 is an exact >> power of 2, just for simplicity, as the new root hash would be exactly >> HASH(0x01 || Z || hash(new entry))). >> STH 1 chains to STH 2 that chains to STH 3, but STH 2 and STH 3 each >> have, as their root hash, hash of Z, appending a different entry every time >> (the tree is forked at root hash Z). >> To the rest of the world, the log would present a chain of hashes that is >> STH 1 and STH 3' - which has the same root hash as STH 3 but prev_hash = Z. >> The client could not know that it's being presented with a chain of STHs >> that are for different trees unless it has consistency proofs between >> (STH1, STH2) and (STH2, STH3). >> > >> It seems to me that: >> - Clients still need to get (via push or pull) consistency proofs between >> STHs and validate them. >> - STHs still have to be gossiped for a single entity (monitor) to be in >> possession of STHs that cannot be proven consistent. >> > > The hash chaining is only a commitment to a claim of which blob is the > immediate predecessor of this other blob, you still need to verify the > correctness of the blobs in context, of course. > > At least for the monitoring-MMD use-case, it seems like a similar thing > could be achieved by requiring Logs to also log their own STHs, even > allowing for the vagaries of pending queues that'd put an MMD-sized window > on how far back in time a log could create old STHs to cover up MMD-blown > fails. > > The monitors wouldn't then need a get-sths call (although if there were > other use cases for that API then the results from it would at least be > verifiable by monitors). > A thought is that you'd then have the ability to query a Log using > get-proof-by-hash for an STH you're holding to see if it can prove it was > logged, I'm not sure if that's useful at the moment, but my Friday evening > brain finds it amusing for some reason. > > The obvious next step would be to require Logs to log their STHs with a > quorum of other Logs. Assuming all Logs are not collaborating, that makes > it quite a lot harder for anyone to pull off split views, and of course you > can now do the same get-proof-by-hash call for your STH on other logs now, > if you didn't mind trying a a number of logs (or if you already knew in > which Logs to look*). > > *perhaps the set of target logs for a given STH could be defined by some > function of the day or week that the STH timestamp corresponds to - > something which changes infrequently enough that Logs can't simply not > issue an STH during that period or they'd blow their MMD - the intention > being to narrow the set of logs you'd have to look in, but also make it > harder to to choose colluding Logs. > > > >> But maybe there are other ways to chain STHs, so I'd like to follow up on >> that independently of 6962-bis. >> >> Eran >> >> >> On Wed, May 17, 2017 at 6:17 AM, Andrew Ayer >> wrote: >> >>> On Mon, 15 May 2017 17:18:22 +0100 >>> Eran Messeri wrote: >>> >>> > As it has been pointed out to me, the STH history API, even with the >>> > proposed changes of adding a sequence number to issued STHs, or >>> > requiring an STH refers to a previous STH, would not prevent >>> > backdating of STHs in a meaningful way - see explanation below. >>> >>> This is not the only reason for a get-sths API. The other reason is that >>> it facilitates the prospective auditing model favored by Mozilla, which >>> is >>> why Richard Barnes has asked for it[1]. >>> >>> There seems to be a general agreement that in the long term, TLS >>> servers should send inclusion proofs due to the difficulty of auditing >>> SCTs robustly and privately. 6962-bis already provides a way to embed >>> inclusion proofs in the certificate, OCSP response, or TLS handshake. >>> However, this is just shifting the problem to auditing STHs. >>> Unfortunately, gossiping STHs or requesting consistency proofs has >>> similar privacy problems[2]. >>> >>> An alternative to auditing STHs on-the-fly is for clients to download and >>> cache batches of every STH the log has produced. An inclusion proof >>> would >>> be considered valid as long as it is based on one of the cached STHs. >>> >>> Currently, there are two obstacles to doing this: >>> >>> 1. Getting the STHs. Calling get-sth repeatedly isn't robust, because an >>> STH might be missed. A get-sths endpoint allows all STHs to be obtained >>> so they can be cached. >>> >>> 2. Auditing the STHs. Obtaining consistency proofs for every STH would >>> require a lot of bandwidth. For this reason, Richard Barnes called >>> for the use of a Haber-Stornetta hash chain[3], which would be a rather >>> drastic change to the protocol. >>> >>> I have a simpler proposal: have each STH contain the hash of the previous >>> STH. This provides the same properties as a Haber-Stornetta hash chain >>> while making only a modest, backwards-compatible change to the protocol. >>> Clients need only gossip the latest STH to be confident that everyone >>> has the same view of the log, including its entire STH history. >>> Therefore, >>> there is no need for clients to audit the consistency of each STH, as >>> this >>> job can be left to auditors who are guaranteed to have the same view of >>> the log's STH history. >>> >>> A get-sths endpoint, plus embedding the hash of the previous STH in each >>> STH, plus the existing ability to embed inclusion proofs, will permit >>> RFC6962-bis to be used with a robust, privacy-preserving, and prospective >>> auditing model, while remaining conceptually backwards compatible with >>> the auditing model of RFC6962. This seems like a win-win to me. >>> >>> Regards, >>> Andrew >>> >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/trans/Zm4NqyRc7LDsOtV56EchBIT9r4c >>> >>> [2] Although an STH doesn't uniquely identify a certificate like an SCT >>> does, in practice a client auditing or gossiping a particular STH may >>> be a very strong indicator that it just saw a particular certificate. >>> For example, if 10 certificates embed an inclusion proof to STH X, >>> but 9 of those certificates are expired or aren't used on the public >>> Internet, then a client auditing STH X probably just connected to the >>> server identified by the 10th certificate. >>> >>> [3] >>> https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368 >>> >> >> >> _______________________________________________ >> 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 > --001a11425fc401bf37054fe699a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , May 19, 2017 at 10:44 AM Al Cutter <a= l@google.com> wrote:
On Fri, May= 19, 2017 at 3:49 PM, Eran Messeri <eranm@google.com> wrote:<= br>
Follo= wing an out-of-band discussion with Andrew (summarized below), I propose th= e following, to make progress on 6962-bis:
* Add get-sths as a mandator= y API.
* Defer discussion on chaining of STHs to a fol= low-up document: It's evident that we need to do more thinking about it= . Since we have an STH extensions mechanism, an extension including a refer= ence to a past STHs can be added in a later document.

In the ticket you said:
"The problem it [= get-sths API] solves is the lack of ability to verify that the log did not = breach the MMD throughout its lifetime: A submission's timestamp is ava= ilable via get-entries, but unless a monitor has observed STHs issued by th= e log around the time an entry was created for it, there's no proof tha= t the entry was incorporated within the MMD."

but you later acknowledged that a get-sths API without some extra s= prinkles somewhere=C2=A0doesn't actually solve that problem beca= use there's nothing stopping a Log from going back and creating a few e= xtra "old" STHs to cover, say, a period when its signing infrastr= ucture was down, which it'll happily return to you when you call get-st= hs at a later date.

This is prevented by requiring the get STHs endpoint to provide a co= nsistent sequence of entries over time and making sure that auditors track = it. Alternatively, the chaining idea also achieves this, and so does loggin= g STHs as you suggest.

=
I admit I'm not really that familiar with process of defining RFCs= , but it seems weird to me to add a mandatory API, which, as defined in the= standard which makes it mandatory, doesn't solve the problem it was ad= ded to solve...


It seems to m= e that STH chaining is set out to achieve a goal that's different than = how CT currently operates; I'm also not confident it can achieve this g= oal. Because further discussion on both topics is necessary, I don't th= ink it's right to add this feature to 6962-bis yet or gate 6962-bis on = it.

CT's current design aims to det= ect a single log presenting different views (i.e. different trees) to diffe= rent parties by exchanging STHs between observers.
A variant with= stronger security guarantees aims to have individual clients have the enti= re STH history so they cannot be presented with inclusion proofs to differe= nt trees at different times. Chaining STHs aims to achieve that (as far as = I understand).

However it seems to me chaining STH= s does not prevent a client, that fetches STHs individually, from being tri= cked into accepting inclusion proofs to different trees presented by the sa= me log:

A log could produce the following chain of= STHs:
STH 1 with root hash Z, then STH 2 with root hash Y = =3D HASH(Z || hash(entry_1)), prev_hash =3D Z, then STH 3 with root hash X = =3D HASH(Z || hash(entry_2)), prev_hash =3D Y (assuming the tree size with = STH1 is an exact power of 2, just for simplicity, as the new root hash woul= d be exactly HASH(0x01 || Z || hash(new entry))).
STH 1 chains to= STH 2 that chains to STH 3, but STH 2 and STH 3 each have, as their root h= ash, hash of Z, appending a different entry every time (the tree is forked = at root hash Z).
To the rest of the world, the log would present = a chain of hashes that is STH 1 and =C2=A0STH 3' - which has the same r= oot hash as STH 3 but prev_hash =3D Z.
The client could= not know that it's being presented with a chain of STHs that are for d= ifferent trees unless it has consistency proofs between (STH1, STH2) and (S= TH2, STH3).

It seems to me that:
<= div>- Clients still need to get (via push or pull) consistency proofs betwe= en STHs and validate them.
- STHs still have to be gossiped for a= single entity (monitor) to be in possession of STHs that cannot be proven = consistent.

The h= ash chaining is only a commitment to a claim of which blob is the immediate= predecessor of this other blob, you still need to verify the correctness o= f the blobs in context, of course.
=C2=A0
At least= for the monitoring-MMD use-case, it seems like a similar thing could be ac= hieved by requiring Logs to also log their own STHs, even allowing for the = vagaries of pending queues that'd put an MMD-sized window on how far ba= ck in time a log could create old STHs to cover up MMD-blown fails.

The monitors wouldn't then need a get-sths call (alth= ough if there were other use cases for that API then the results from it wo= uld at least=C2=A0be verifiable by monitors).
A thought is that y= ou'd then have the ability to query a Log using get-proof-by-hash for a= n STH you're holding to see if it can prove it was logged, I'm not = sure if that's useful at the moment, but my Friday evening brain finds = it amusing for some reason.

The obvious next step = would be to require Logs to log their STHs with a quorum of other Logs. Ass= uming all Logs are not collaborating, that makes it quite a lot harder for = anyone to pull off split views, and of course you can now do the same get-p= roof-by-hash call for your STH on other logs now, if you didn't mind tr= ying a a number of logs (or if you already knew in which Logs to look*).

*perhaps the set of target logs for a given STH coul= d be defined by some function of the day or week that the STH timestamp cor= responds to - something which changes infrequently enough that Logs can'= ;t simply not issue an STH during that period or they'd blow their MMD = - the intention being to narrow the set of logs you'd have to look in, = but also make it harder to to choose colluding Logs.

=


But maybe there= are other ways to chain STHs, so I'd like to follow up on that indepen= dently of 6962-bis.

Eran=


On Wed, May 17, 2017 at 6:17 AM, Andrew Ayer <agw= a@andrewayer.name> wrote:
On Mon, 15 May 2017 17:18:22 +0100
Eran Messeri <eran= m@google.com> wrote:

> As it has been pointed out to me, the STH history API, even with the > proposed changes of adding a sequence number to issued STHs, or
> requiring an STH refers to a previous STH, would not prevent
> backdating of STHs in a meaningful way - see explanation below.

This is not the only reason for a get-sths API.=C2=A0 The other reas= on is that
it facilitates the prospective auditing model favored by Mozilla, which is<= br> why Richard Barnes has asked for it[1].

There seems to be a general agreement that in the long term, TLS
servers should send inclusion proofs due to the difficulty of auditing
SCTs robustly and privately.=C2=A0 6962-bis already provides a way to embed=
inclusion proofs in the certificate, OCSP response, or TLS handshake.
However, this is just shifting the problem to auditing STHs.
Unfortunately, gossiping STHs or requesting consistency proofs has
similar privacy problems[2].

An alternative to auditing STHs on-the-fly is for clients to download and cache batches of every STH the log has produced.=C2=A0 An inclusion proof w= ould
be considered valid as long as it is based on one of the cached STHs.

Currently, there are two obstacles to doing this:

1. Getting the STHs.=C2=A0 Calling get-sth repeatedly isn't robust, bec= ause an
STH might be missed.=C2=A0 A get-sths endpoint allows all STHs to be obtain= ed
so they can be cached.

2. Auditing the STHs.=C2=A0 Obtaining consistency proofs for every STH woul= d
require a lot of bandwidth.=C2=A0 For this reason, Richard Barnes called for the use of a Haber-Stornetta hash chain[3], which would be a rather
drastic change to the protocol.

I have a simpler proposal: have each STH contain the hash of the previous STH.=C2=A0 This provides the same properties as a Haber-Stornetta hash chai= n
while making only a modest, backwards-compatible change to the protocol. Clients need only gossip the latest STH to be confident that everyone
has the same view of the log, including its entire STH history.=C2=A0 There= fore,
there is no need for clients to audit the consistency of each STH, as this<= br> job can be left to auditors who are guaranteed to have the same view of
the log's STH history.

A get-sths endpoint, plus embedding the hash of the previous STH in each STH, plus the existing ability to embed inclusion proofs, will permit
RFC6962-bis to be used with a robust, privacy-preserving, and prospective auditing model, while remaining conceptually backwards compatible with
the auditing model of RFC6962. This seems like a win-win to me.

Regards,
Andrew


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

[2] Although an STH doesn't uniquely identify a certificate like an SCT=
does, in practice a client auditing or gossiping a particular STH may
be a very strong indicator that it just saw a particular certificate.
For example, if 10 certificates embed an inclusion proof to STH X,
but 9 of those certificates are expired or aren't used on the public Internet, then a client auditing STH X probably just connected to the
server identified by the 10th certificate.

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


_______________________________________________
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
--001a11425fc401bf37054fe699a5-- From nobody Fri May 19 18:56: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 9243F12894A for ; Fri, 19 May 2017 18:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 1y9HAvqB55aC for ; Fri, 19 May 2017 18:56:01 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id 741131204DA for ; Fri, 19 May 2017 18:56:01 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-f982-e571-272c-4738.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:f982:e571:272c:4738]) by mail.hezmatt.org (Postfix) with ESMTPSA id 744E1BC021 for ; Sat, 20 May 2017 01:55:58 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 593EFA05F3; Sat, 20 May 2017 11:55:56 +1000 (AEST) Date: Sat, 20 May 2017 11:55:56 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20170520015556.GU13247@hezmatt.org> References: <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 20 May 2017 01:56:04 -0000 On Fri, May 19, 2017 at 08:45:00PM +0000, Nick Sullivan wrote: > On Fri, May 19, 2017 at 10:44 AM Al Cutter wrote: > > but you later acknowledged that a get-sths API without some extra > > sprinkles *somewhere* doesn't actually solve that problem because there's > > nothing stopping a Log from going back and creating a few extra "old" STHs > > to cover, say, a period when its signing infrastructure was down, which > > it'll happily return to you when you call get-sths at a later date. > > This is prevented by requiring the get STHs endpoint to provide a > consistent sequence of entries over time and making sure that auditors > track it. Alternatively, the chaining idea also achieves this, and so does > logging STHs as you suggest. If you're already requiring auditors to remember what they've seen before, why not just get them to remember the STHs they've seen, rather than having to remember that they've seen an additive sequence of previous STHs and verified that nothing's magically appeared? I think the proposal to log STHs is a good one. It provides several advantages: * it prevents the need to have a separate "enumerate all prior STHs" (because you can get them all by walking the log); * it naturally discourages a log from issuing huge numbers of STHs (for tracking purposes) because it bloats the log, and is extremely visible; * it provides cryptographic proof of malfeasance (attempted tracking) if someone can provide an STH that isn't in the log; * it provides cryptographic proof of blowing an MMD if the difference between the STH timestamp in the logged entry and the first STH that includes that entry are too far apart. - Matt -- "I'm a manager. I don't do maths." -- Jeff Waugh, DebSIG From nobody Sat May 20 15:48: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 CE0E11200F1 for ; Sat, 20 May 2017 15:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 BPXMBHcUkWUk for ; Sat, 20 May 2017 15:48:44 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 80E0312717E for ; Sat, 20 May 2017 15:48:44 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o12so64400727iod.3 for ; Sat, 20 May 2017 15:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MnBH6xbR8fxWDN0eUCBi3EtUdFncnDGLrB8CkFqAcSk=; b=gya9hLMCgMfFiZu4BeiSQ6A3l4wxQTn1h74Lf6pDcCq6unATwJ+c5BzdlTFOt3iSrc Do5yen5RJ2cyP5waxBAcLDyPqcLG1sqLHF/hLOkIOYwdc8Qdlj5rcgjRJHA8BX2pwHMJ 6jLeja8rICa2/hYXsdeUwiDCLenZABkCFJUG+hjz/QVynsbWvewdZ8feXOe9LEVyW4Xr ClC92k1t4sgVs5EEy2cK6V+FpxkViLOwX3KiSd5YqgjdFfXLNKl0AEEcpcU1fgsTiT0V /d5nug4yXFDtfMk2xjpbUxRdi/6umo9zrfi8DgVEzhMcZUrpcW2O9n4i4fZ2WwNoEW6m ve6w== 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=MnBH6xbR8fxWDN0eUCBi3EtUdFncnDGLrB8CkFqAcSk=; b=SvUAbXueJnEeHQo44Vvsy+4JGFruW9hgpJVyecFeVEzEWgcvDBr6xqCMmlkPgfcKO4 CcCKghkSPMTFWIE/JkbCqFEa9DTANKriZ6qks0jpwgaGfY54wAwIDBtxtGQ1m+NqPWdz PkT8c1TwSbOM5KYK6kt2P1Y6FLHcUpvFdKhOSw/QwahJi3Wg/LC+R0+X7cURlBivvHJQ Ojv4BWmFCC/ud7LkCQmw6yYAYI09XoR51W0zQhL2nlXpZ1qoFz3pxr/sXgBhRSvmLoSo +3uswbJwXRH/Sqa8LJGh4eo40s2jSDqFrKFEE2ROFwMW7w+iyDtLPjP6GoDOJKxKGdcQ P0sQ== X-Gm-Message-State: AODbwcCaEVxc2rQpkSSF+E/n3JscIe1zYQWTB1R6NxCOy6ZV0nWhsgoU h0/+crczHkGYic1PGW5D1VLqTpiOSb1r X-Received: by 10.107.5.143 with SMTP id 137mr18342440iof.152.1495320523906; Sat, 20 May 2017 15:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.47.146 with HTTP; Sat, 20 May 2017 15:48:43 -0700 (PDT) In-Reply-To: <20170520015556.GU13247@hezmatt.org> References: <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> <20170520015556.GU13247@hezmatt.org> From: Brian Smith Date: Sat, 20 May 2017 12:48:43 -1000 Message-ID: To: Matt Palmer Cc: "trans@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 20 May 2017 22:48:46 -0000 On Fri, May 19, 2017 at 3:55 PM, Matt Palmer wrote: > If you're already requiring auditors to remember what they've seen before, > why not just get them to remember the STHs they've seen, rather than having > to remember that they've seen an additive sequence of previous STHs and > verified that nothing's magically appeared? In CT, CAs issue certificates that certify a binding of a name to a public key. From the CT logs' perspective, the CAs are untrusted and so we don't rely on them to provide a log of certificates they've issued. Instead, we have CT logs maintain such logs. Similarly, a CT log issues STHs that certify the state of the log. >From the auditors' perspective, the CT log is untrusted. Thus, the auditors' shouldn't rely on the CT logs to log all their STHs. Instead, the auditors should maintain such logs. In other words, the CT auditors should operate CT logs that operate on "certificates" that are actually STHs. Cheers, Brian -- https://briansmith.org/ From nobody Mon May 22 03:15: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 AC994129BEC for ; Mon, 22 May 2017 03:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 QnPfp8cddvGz for ; Mon, 22 May 2017 03:14:56 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4AA129BDD for ; Mon, 22 May 2017 03:14:56 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id a10so3280539itg.1 for ; Mon, 22 May 2017 03:14:56 -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=OYYKOyOsr7HBfe0jOfJwYk6jBiq1+pIAgNXQPuSXyMc=; b=if/briD88/V6Lvqd1KJR1Lc0WK3CN8JOqpG0mK0JpObgn0sf94GwKFap9FHaTMhoDz fA3GAQa9utueCyY5pLYKFIFIv1hPhTFkieyXVW296CxUMYvFUrz8chJkfAe10+jlwk4j LRD5goSOTl7DtsyJHR54lXG8YZl/eYV9i6CzFl2DbTbI6k772S/PrzHRNd0wgaucMYWH 9XnMXFCxame5AQC43iLnsTL72+6kuxWSo3PJ1y6SuRFEg6DdgToxqU+RcC+wn+D14sGs N1zjQUe0hgpd+6oy5SmD+TPGXE+tFtSQ36r3iYeaydGCNlOUXrddrEdk+jZdy/3embtt zNeA== 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=OYYKOyOsr7HBfe0jOfJwYk6jBiq1+pIAgNXQPuSXyMc=; b=b9wlAkgY7g+k9hTbCNusfIHFxJguhBgzPi1PX/AWwJwscd2VHLRbFOHy0872MR1YK4 12GiOLASgrNUE2SVzz5ebRQLixLq8nKEF71fLEfKam0A1veneu0DzHqHLV6bHhe7ljtm 1i3B6hElAzHoST3VHcZYtT40bfQ37S9XaOcV4jjv7vVg8tpNlx3cNLcryDHMNoDkgl7G w8DvLRpPn+IcWpykSQjTwW3GdqXqTRfWd4pbkQ8zm+hzWQpVjE9xdtMv1l9tWQuU7boG siuEKBX0GdS+ca/OXqUFJ6ZV+3lCaWzEwHkRb6G2H1DTuYVla+dsy8CAwxDwBDEclvqZ exVw== X-Gm-Message-State: AODbwcDnOTfgmtK3/J1WFe2eUXI0RQC16cNg2qH3aJ+w0e5LyavuUhQZ OLyv1+BxugYrbzyp7V5Lur9CPJ0KfgSF X-Received: by 10.36.117.140 with SMTP id y134mr20918546itc.53.1495448095796; Mon, 22 May 2017 03:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Mon, 22 May 2017 03:14:25 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Mon, 22 May 2017 11:14:25 +0100 Message-ID: To: Richard Barnes Cc: Brian Smith , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a114aac4488178505501a24fe" Archived-At: Subject: Re: [Trans] Drop RSA PKCS#1 1.5 signatures; maybe replace with RSA PSS 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, 22 May 2017 10:14:59 -0000 --001a114aac4488178505501a24fe Content-Type: text/plain; charset="UTF-8" +1 for switching to RSA PSS. I don't have any insight into why RSA was originally in 6962, so can't argue strongly in favour of keeping it. On Fri, May 12, 2017 at 8:18 PM, Richard Barnes wrote: > +1 > > > On Fri, May 12, 2017 at 2:51 PM, Brian Smith wrote: > >> Hi, >> >> PKCS#1 1.5 signatures are obsolete. New specifications should not >> mandate support for them. >> >> RSA signatures in general are difficult for some devices to process >> due to their large size. It would be frustrating to have used a pure >> ECC infrastructure with no RSA involved at all, only to need to >> implement RSA for the purpose of verifying signatures from logs. Thus >> I think the group should consider dropping any mention of RSA >> signatures from section 10.4.so that log clients do not have to >> implement RSA. >> >> If it really is important to have RSA signatures, then RSA PSS should >> be used instead. In particular, it would be good to require the same >> restricted form specified for TLS, where the same digest algorithm >> must be used for all parts of the signature. Note that RSA PSS can be >> made deterministic by using a fixed salt, and most implementations of >> RSA PSS seem to support fixed salts if the salt length is set to zero. >> As mentioned in the RSA PSS specification, PSS signatures are more >> secure than PKCS#1 1.5 signatures even with a zero-length salt. >> >> Cheers, >> Brian >> -- >> https://briansmith.org/ >> >> _______________________________________________ >> 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 > > --001a114aac4488178505501a24fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for switching to RSA PSS.
I don't have any insi= ght into why RSA was originally in 6962, so can't argue strongly in fav= our of keeping it.

On Fri, May 12, 2017 at 8:18 PM, Richard Barnes <rlb@ipv.sx><= /span> wrote:
+1


On Fri, May 12, 2017 at 2:5= 1 PM, Brian Smith <brian@briansmith.org> wrote:
Hi,

PKCS#1 1.5 signatures are obsolete. New specifications should not
mandate support for them.

RSA signatures in general are difficult for some devices to process
due to their large size. It would be frustrating to have used a pure
ECC infrastructure with no RSA involved at all, only to need to
implement RSA for the purpose of verifying signatures from logs. Thus
I think the group should consider dropping any mention of RSA
signatures from section 10.4.so that log clients do not have to
implement RSA.

If it really is important to have RSA signatures, then RSA PSS should
be used instead. In particular, it would be good to require the same
restricted form specified for TLS, where the same digest algorithm
must be used for all parts of the signature. Note that RSA PSS can be
made deterministic by using a fixed salt, and most implementations of
RSA PSS seem to support fixed salts if the salt length is set to zero.
As mentioned in the RSA PSS specification, PSS signatures are more
secure than PKCS#1 1.5 signatures even with a zero-length salt.

Cheers,
Brian
--
ht= tps://briansmith.org/

_______________________________________________
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


--001a114aac4488178505501a24fe-- From nobody Mon May 22 03:24:06 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 9C14C129BDB for ; Mon, 22 May 2017 03:24:05 -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 cTCDvODgt7jC for ; Mon, 22 May 2017 03:24:03 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 096A2129BDA for ; Mon, 22 May 2017 03:24:03 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id r63so20310320itc.1 for ; Mon, 22 May 2017 03:24:02 -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=N2TieIsBl0pFmvDHnzzuzp4H7e6+mzkv+qdKKzIppZk=; b=McrtllifQ69sFgy6/+14iowwq0IxfuRxecl65SqufNztAPQ4OtpFkJJaSYu2veKIH4 yaoGpim6vjEJu9rnRwrrhHtjkMQcqK3fyBUl+xOl+culpmAKfJMAG798CROEflnGALIh 3ZbpMMJlMFgOkWCnGMC1r0wayVS4Y7zXDWuYj6fHOpfBEz4japk4ZHeRZxQfxYH2nBD1 WyYN5x60bDy2m8Kdh7a3qheu/Ygaf1OBpNqHS8d2rwu1MhoLMrMsxa4iipa/2Z/GHwVi HQHWfm15oGQpAQqdrCEiUxN7ATiJKLhcLVbWS9bQqjKPP82nfH8vB209Cv7x/kJX15Os QVRw== 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=N2TieIsBl0pFmvDHnzzuzp4H7e6+mzkv+qdKKzIppZk=; b=P4Bgp8PgEFY7+glwsm5lsbm/BjcRLNn3EitlwO3xAo/104PV4V+FC1hHU+5OSlyXoW L9YzGdCm8F/rEUgWWJ4kM3MBn8JPg1aAP0x4rX6kJqk2l/rD5wEjbcHN1znBBFvraqOu myvDKp/lMPBMweMNzIvr62eWME6f8k8zaoir2U1NebDp/3RbPOx2XEgWpifJz0ndpGcx 33V+ohx/LMgp62f1NLi8TdXx0bmdFai+kSJ8SyKNYbj5agMcQ/AhexEejo4/sJEnVoT/ UfwrIsjkq6o53yl1G0NFGmu2JJjw8tqcEzDVymK4rHTopG67qmyZHPd8sgqAJx9zn+wv atyw== X-Gm-Message-State: AODbwcDomL5Rg+WsxfoUJ+UB/leQi/6yh2a2xeg6J3ciIRLdTnMB301F SdabqCV89L73izZEXkqaLbJYc2omdvSe X-Received: by 10.36.162.72 with SMTP id o8mr22018109iti.42.1495448642206; Mon, 22 May 2017 03:24:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Mon, 22 May 2017 03:23:31 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Mon, 22 May 2017 11:23:31 +0100 Message-ID: To: "Salz, Rich" Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="f403045fc05c19b7c305501a4510" Archived-At: Subject: Re: [Trans] Removal of the use of digitally-signed (issue #174) 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, 22 May 2017 10:24:06 -0000 --f403045fc05c19b7c305501a4510 Content-Type: text/plain; charset="UTF-8" FYI I think we can get away by simply mentioning the SignatureScheme enumeration from TLS 1.3 without forcing its use: As Rob Stradling pointed out in the PR, one of the log's parameters is the signature algorithm, so there's no point in repeating in every structure the log signs. What I propose in PR #260 is then to remove the algorithm parameter, leaving only the signature, in the SignedTreeHeadDataV2 and SignedCertificateTimestampDataV2. In the Signature Algorithms section, the enum value for each signature algorithm is referred, to uniquely identify it. On Mon, May 15, 2017 at 5:51 PM, Salz, Rich wrote: > > Are there any opinions on the matter? Personally I don't mind either; > generally, digitally-signed unambiguously specifies what data the signature > is over, but in 6962-bis it's always over a well-defined data structure > (defined somewhere else). > > No objection. > --f403045fc05c19b7c305501a4510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI I think we can get away by simply mentioning the Signa= tureScheme enumeration from TLS 1.3 without forcing its use:
As Rob Str= adling pointed out in the PR, one of the log's parameters is the signat= ure algorithm, so there's no point in repeating in every structure the = log signs.

What I propose in PR #260 is then to re= move the algorithm parameter, leaving only the signature, in the SignedTree= HeadDataV2 and SignedCertificateTimestampDataV2. In the Signature Algorithm= s section, the enum value for each signature algorithm is referred, to uniq= uely identify it.

On Mon, May 15, 2017 at 5:51 PM, Salz, Rich &= lt;rsalz@akamai.com> wrote:
>= ; Are there any opinions on the matter? Personally I don't mind either;= generally, digitally-signed unambiguously specifies what data the signatur= e is over, but in 6962-bis it's always over a well-defined data structu= re (defined somewhere else).

No objection.

--f403045fc05c19b7c305501a4510-- From nobody Mon May 22 05:23: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 3D452129C5A for ; Mon, 22 May 2017 05:23:47 -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 yKztLtWvyqix for ; Mon, 22 May 2017 05:23:44 -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 6E8471293FD for ; Mon, 22 May 2017 05:23:44 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id o5so150525748ith.1 for ; Mon, 22 May 2017 05:23:44 -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=t4Fxi0/lcqExHrOfmtuCx/WJWH4ZZnBZU16xlpUqP2Y=; b=rShHHZcQDbXxrEpODuOc4n7ow5uKrVpgGzdKpi1dZvXHehPCwwuCtoegFWLffk/Xx+ PS0mM62D10vO0RDndYZCwZNzZJXtBsmw6rzPUXAMqDcjqIng9DsGJdKJr/Pa/Dp1TeCj qWwAQxK73+7HMtLlbrKSL5gi7AbtTBLOBa257jWQ9PGC6H5tU91NhE75acP2ViZjXkk1 aGnLsOZPwNmImZYKZlg7UP5tfmmeNIxFxnbCYCRrFFOVQS9dCUPd6IqH6p3z2KqanAJG r8SjEw2NSR8XzsImAtadWd6Z6H4fibEdX5UL3sqrioVtmQO57b8/smkQuU5Cyy0hpUir H6pw== 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=t4Fxi0/lcqExHrOfmtuCx/WJWH4ZZnBZU16xlpUqP2Y=; b=XNdUoaTT6WmO/CpswQefOCdgDK4TuHZUq3rVJrxB0J0OeU3XxoaT/BWKxd+/4zLdya Dw8J5KHb6hjNdwd3aVn08ffnEn68lwOmkvRvlhRQdeR/Twru9YLPAvIZLgohoZDJKPPS bzEA49FI+h4d37/ECvQ+Kg25uJGyaAaliTTCeGul94b9punT+WlI1sB/LZbbg3k6GZrf OCDdUqATHHLKScPkBMbNaDw/H3rKGXWxpuIkI6y7t3C27Wp79tIjAFLAwG0jqu4iyFpq 71hET1iTZHHWd/8R/Da7GteI5NhnaUbg4xYAiCkcWu4o9kwzhArlSnD9EuDXy3cjFFjM 94WA== X-Gm-Message-State: AODbwcDLV0G6+2h9um8pnaDCazMoKmW57W7knPMLoNNFx+8c61CqBxHu WEegGGJpT/u+msDUojwHxnb6xJw+53JQ45F7Tw== X-Received: by 10.36.50.66 with SMTP id j63mr40709701ita.42.1495455823477; Mon, 22 May 2017 05:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Mon, 22 May 2017 05:23:12 -0700 (PDT) In-Reply-To: References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> From: Eran Messeri Date: Mon, 22 May 2017 13:23:12 +0100 Message-ID: To: Linus Nordberg Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a114a8eec2388c205501bf116" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 22 May 2017 12:23:47 -0000 --001a114a8eec2388c205501bf116 Content-Type: text/plain; charset="UTF-8" FYI I'm proposing changes per this discussion in https://github.com/google/certificate-transparency-rfcs/pull/261. Comments welcome. Eran On Mon, May 15, 2017 at 12:35 PM, Eran Messeri wrote: > > > On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg wrote: > >> Eran Messeri wrote >> Fri, 12 May 2017 14:36:04 +0100: >> >> > Thanks for the feedback. It helped me realize deterministic signatures >> > could be achieved not only by using a deterministic signature scheme, >> but >> > also by logs storing the produced signatures and returning them instead >> of >> > re-signing SCTs, for example. >> > >> > That's my understanding of the discussion so far: >> > * Requiring the use of RFC6979 is bad, for the reasons Brian has >> mentioned. >> > * It is not yet clear where deterministic signatures may be more >> important >> > (SCTs or STHs) because it's not clear what TLS clients will gossip and >> how. >> >> Not to argue against that statement but I think that it's clear that >> gossiping about STHs would become more problematic for a client caring >> about privacy if logs were allowed to send different strings of bits to >> different clients for a given pair of `log_id` and `tree_head` in an >> STH. >> >> I completely agree - it would be more difficult for clients caring about > privacy (which should be all TLS clients used by end-users these days, > really) to exchange STHs they've obtained themselves, if logs were allowed > to use unique signatures. > I'm not saying the reasoning is wrong - it is very solid as far as I can > tell - but that we don't know if we need it yet, see below. > > >> > * It is not necessary to require the use of a deterministic signature >> > scheme - only that the same signature is present in all instances of a >> > particular SCT (note that different SCTs for the same submission, with >> > different timestamps, which the log may issue, cannot have the same >> > signature). >> >> This sounds like a requirement, i.e. a MUST, which is not reflected in >> the reasoning below ("MUST->SHOULD" and "Mention that"). >> >> Also, this talks about SCTs specifically. What do you think the story is >> for STHs? >> > Seems to me like the same reasoning applies to both - sorry, wasn't clear > about it. > >> >> >> > Also, in 6962-bis, my focus is on correct operation of the log & Merkle >> > Tree - and deterministic signatures are not strictly necessary for that. >> >> While I think it's fair to try to limit the scope I think it would be >> bad to make it hard to gossip since that's supposed to protect against >> attacks on the ability to audit the correctness of said >> operation. Admittedly, one problem here is that "hard to gossip" is far >> from well defined. >> >> Also, does this imply that the limitation on STH issuance frequency >> should be removed too? >> > I'd leave that, as it has several benefits beyond gossip (for example, the > ability to cache STHs and their consistency proofs or coordinating > selection of an SCT). > >> >> >> > To make progress on this issue, I propose the following: >> > * Remove references to 6979. >> > * Remove the strong requirement to use deterministic signature schemes >> > (MUST -> SHOULD), so implementations can use non-deterministic signature >> > schemes and still be compliant with the spec. >> > * Add reference to EdDSA, which includes a deterministic signature >> scheme >> > variant. >> > * Mention that deterministic signatures can be achieved by storing the >> > produced signatures. >> > >> > Any objections? >> >> I think that 6962bis should mandate that the same bits are sent over the >> wire to every client asking for a given piece of signed data. (This can >> be accomplished by either using a deterministic signing scheme or by >> storing the data under a unique key for later use.) >> >> The main reason for this requirement is to make it possible for log >> clients to gossip about STHs -- limiting the number of outstanding STHs >> that a log can have at any given time is important in order to limit the >> ability for a log to fingerprint its clients, as described in >> draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the >> log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that >> the same bits are sent over the wire to everyone asking for a given STH. >> >> The privacy argument for imposing this same-bits-for-same-data rule for >> SCTs too seems weaker since SCTs carry much more privacy sensitive data >> but I'm not convinced that this holds for all gossip >> scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to >> linking an SCT to a user of an HTTPS client. I think this is reason >> enough to not separate STHs and SCTs with regard to this requirement. >> > > Overall I agree with the sentiment. However I'm trying to balance the > attempt to make SCTs & STHs non-identifying as much as possible with ease > of implementation and the current deployment: > - As Melinda said on a separate post, 6962-bis has to be correct but it > doesn't have to be complete. We could add the stricter requirement of > producing consistent signatures for the same data later on. > - There's an added cost for implementations: Either more storage (storing > produced signatures) or reliance on features that are not widely supported > in crypto libraries (deterministic signatures). > - Right now, how the gossip is going to take place is unclear: The only > thing currently operating (AFAIK) is STH exchange between several monitors. > I don't know of any TLS client implementation that intends to fetch STHs > directly (we've actually removed this capability > > from Chrome recently). Even if there was such an implementation, because > it's not clear who it will be exchanging STHs with, it's unclear what's the > threat model - who has to collude to compromise a client's privacy by > tracking it. > > To put it simply, I don't know yet if we'll need it - which is why I > suggest we strongly recommend deterministic signatures, but not mandate it. > > What do you think? > --001a114a8eec2388c205501bf116 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, May 15, 2017 at 12:35 PM, Eran Mes= seri <eranm@google.com> wrote:


On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <= span dir=3D"ltr"><li= nus@sunet.se> wrote:
Eran M= esseri <eranm@goog= le.com> wrote
Fri, 12 May 2017 14:36:04 +0100:

> Thanks for the feedback. It helped me realize deterministic signatures=
> could be achieved not only by using a deterministic signature scheme, = but
> also by logs storing the produced signatures and returning them instea= d of
> re-signing SCTs, for example.
>
> That's my understanding of the discussion so far:
> * Requiring the use of RFC6979 is bad, for the reasons Brian has menti= oned.
> * It is not yet clear where deterministic signatures may be more impor= tant
> (SCTs or STHs) because it's not clear what TLS clients will gossip= and how.

Not to argue against that statement but I think that it's clear = that
gossiping about STHs would become more problematic for a client caring
about privacy if logs were allowed to send different strings of bits to
different clients for a given pair of `log_id` and `tree_head` in an
STH.

I completely agree - it would be = more difficult for clients caring about privacy (which should be all TLS cl= ients used by end-users these days, really) to exchange STHs they've ob= tained themselves, if logs were allowed to use unique signatures.
I'm not saying the reasoning is wrong - it is very solid as far as I c= an tell - but that we don't know if we need it yet, see below.


> * It is not necessary to require the use of a deterministic signature<= br> > scheme - only that the same signature is present in all instances of a=
> particular SCT (note that different SCTs for the same submission, with=
> different timestamps, which the log may issue, cannot have the same > signature).

This sounds like a requirement, i.e. a MUST, which is not reflected = in
the reasoning below ("MUST->SHOULD" and "Mention that&quo= t;).

Also, this talks about SCTs specifically. What do you think the story is for STHs?
Seems to me like the same reasoning a= pplies to both - sorry, wasn't clear about it.=C2=A0


> Also, in 6962-bis, my focus is on correct operation of the log & M= erkle
> Tree - and deterministic signatures are not strictly necessary for tha= t.

While I think it's fair to try to limit the scope I think it wou= ld be
bad to make it hard to gossip since that's supposed to protect against<= br> attacks on the ability to audit the correctness of said
operation. Admittedly, one problem here is that "hard to gossip" = is far
from well defined.

Also, does this imply that the limitation on STH issuance frequency
should be removed too?
I'd leave that, as i= t has several benefits beyond gossip (for example, the ability to cache STH= s and their consistency proofs or coordinating selection of an SCT).=C2=A0<= /div>


> To make progress on this issue, I propose the following:
> * Remove references to 6979.
> * Remove the strong requirement to use deterministic signature schemes=
> (MUST -> SHOULD), so implementations can use non-deterministic sign= ature
> schemes and still be compliant with the spec.
> * Add reference to EdDSA, which includes a deterministic signature sch= eme
> variant.
> * Mention that deterministic signatures can be achieved by storing the=
> produced signatures.
>
> Any objections?

I think that 6962bis should mandate that the same bits are sent over= the
wire to every client asking for a given piece of signed data. (This can
be accomplished by either using a deterministic signing scheme or by
storing the data under a unique key for later use.)

The main reason for this requirement is to make it possible for log
clients to gossip about STHs -- limiting the number of outstanding STHs
that a log can have at any given time is important in order to limit the ability for a log to fingerprint its clients, as described in
draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the
log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that the same bits are sent over the wire to everyone asking for a given STH.
The privacy argument for imposing this same-bits-for-same-data rule for
SCTs too seems weaker since SCTs carry much more privacy sensitive data
but I'm not convinced that this holds for all gossip
scenarios. Fingerprinting of a gossip peer doesn't necessarily relate t= o
linking an SCT to a user of an HTTPS client. I think this is reason
enough to not separate STHs and SCTs with regard to this requirement.

Overall= I agree with the sentiment. However I'm trying to balance the attempt = to make SCTs & STHs non-identifying as much as possible with ease of im= plementation and the current deployment:
- = As Melinda said on a separate post, 6962-bis has to be correct but it doesn= 't have to be complete. We could add the stricter requirement of produc= ing consistent signatures for the same data later on.
- There's an added cost for implementations: Either more sto= rage (storing produced signatures) or reliance on features that are not wid= ely supported in crypto libraries (deterministic signatures).
- Right now, how the gossip is going to take place is un= clear: The only thing currently operating (AFAIK) is STH exchange between s= everal monitors. I don't know of any TLS client implementation that int= ends to fetch STHs directly (we've actually removed this capability from Chrome recently). Even i= f there was such an implementation, because it's not clear who it will = be exchanging STHs with, it's unclear what's the threat model - who= has to collude to compromise a client's privacy by tracking it.
<= div class=3D"gmail_extra">
To put it si= mply, I don't know yet if we'll need it - which is why I suggest we= strongly recommend deterministic signatures, but not mandate it.

What do you thi= nk?

--001a114a8eec2388c205501bf116-- From nobody Mon May 22 05:46: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 4487912DFE0 for ; Mon, 22 May 2017 05:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsK3ImuLlAXE; Mon, 22 May 2017 05:46:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC7129C66; Mon, 22 May 2017 05:46:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 22 May 2017 12:46:18 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/190#comment:1 Message-ID: <043.7addf545c3cd620f3e54e14bc9b892d4@ietf.org> References: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> X-Trac-Ticket-ID: 190 In-Reply-To: <028.ab68de0a691c5c1318c07706fa749a67@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #190: Simplify data structures in 6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:46:19 -0000 #190: Simplify data structures in 6962-bis -------------------------+---------------------- Reporter: eranm@… | Owner: eranm@… Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+---------------------- Comment (by eranm@…): A proposed change is out for review: https://github.com/google/certificate-transparency-rfcs/pull/256 -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Mon May 22 06:49: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 1DBF112E04F for ; Mon, 22 May 2017 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se 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 sjIhKdx5Dvjg for ; Mon, 22 May 2017 06:49:44 -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 EE127129329 for ; Mon, 22 May 2017 06:49:43 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MDna28000466 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 15:49:37 +0200 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4MDnWVS009475 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 13:49:35 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495460976; bh=wJNLXShIFr6+StGgCEPQkCE7zkOyU13ks/3+D8Q9EPY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ejquaYZXKB91iaNwLe+E/yOymBrjVhmnj0uYcu5VMLAMwSDHflCjdaTRDO5hK7s4a gJKc/LFTE/YAtA3UcD0Qm90ZbuoRSV1Bw7iJ3uc8uHx+p8A62flKAdPerLu5sv8+BU a0q5wk9I1rCobfy0jflRo9o+hCoozTxI6RkloDY0= From: Linus Nordberg To: Al Cutter Cc: Eran Messeri , "trans\@ietf.org" , Andrew Ayer Organization: Sunet References: <20170504082636.dd0212e34e17949eb69b2fed@andrewayer.name> <20170504123447.41d957a88bd65417e714be78@andrewayer.name> <20170505100910.f3da472d9ad71d1d540b8b62@andrewayer.name> <87lgq7j6a3.fsf@nordberg.se> <20170516221717.c05a62d681ecd64322bdc682@andrewayer.name> Date: Mon, 22 May 2017 15:49:50 +0200 In-Reply-To: (Al Cutter's message of "Fri, 19 May 2017 18:44:31 +0100") Message-ID: <8760gtvw5d.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) on 192.36.171.202 X-Scanned-By: MIMEDefang 2.74 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.111.32; 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: 0aTnpNBhD - 579dd72b1ea3 - 20170522 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: Subject: Re: [Trans] Providing the history of STHs a log has issued (in 6962-bis) 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, 22 May 2017 13:49:48 -0000 Al Cutter wrote Fri, 19 May 2017 18:44:31 +0100: > On Fri, May 19, 2017 at 3:49 PM, Eran Messeri wrote: > >> Following an out-of-band discussion with Andrew (summarized below), I >> propose the following, to make progress on 6962-bis: >> * Add get-sths as a mandatory API. >> > * Defer discussion on chaining of STHs to a follow-up document: It's >> evident that we need to do more thinking about it. Since we have an STH >> extensions mechanism, an extension including a reference to a past STHs can >> be added in a later document. >> > > In the ticket you said: > "The problem it [get-sths API] solves is the lack of ability to verify that > the log did not breach the MMD throughout its lifetime: A submission's > timestamp is available via get-entries, but unless a monitor has observed > STHs issued by the log around the time an entry was created for it, there's > no proof that the entry was incorporated within the MMD." > > but you later acknowledged that a get-sths API without some extra sprinkles > *somewhere* doesn't actually solve that problem because there's nothing > stopping a Log from going back and creating a few extra "old" STHs to > cover, say, a period when its signing infrastructure was down, which it'll > happily return to you when you call get-sths at a later date. > > I admit I'm not really that familiar with process of defining RFCs, but it > seems weird to me to add a mandatory API, which, as defined in the standard > which makes it mandatory, doesn't solve the problem it was added to solve... +1 >> It seems to me that STH chaining is set out to achieve a goal that's >> different than how CT currently operates; I'm also not confident it can >> achieve this goal. Because further discussion on both topics is necessary, >> I don't think it's right to add this feature to 6962-bis yet or gate >> 6962-bis on it. >> > >> CT's current design aims to detect a single log presenting different views >> (i.e. different trees) to different parties by exchanging STHs between >> observers. >> A variant with stronger security guarantees aims to have individual >> clients have the entire STH history so they cannot be presented with >> inclusion proofs to different trees at different times. Chaining STHs aims >> to achieve that (as far as I understand). >> >> However it seems to me chaining STHs does not prevent a client, that >> fetches STHs individually, from being tricked into accepting inclusion >> proofs to different trees presented by the same log: >> >> A log could produce the following chain of STHs: >> STH 1 with root hash Z, then STH 2 with root hash Y = HASH(Z || >> hash(entry_1)), prev_hash = Z, then STH 3 with root hash X = HASH(Z || >> hash(entry_2)), prev_hash = Y (assuming the tree size with STH1 is an exact >> power of 2, just for simplicity, as the new root hash would be exactly >> HASH(0x01 || Z || hash(new entry))). >> STH 1 chains to STH 2 that chains to STH 3, but STH 2 and STH 3 each have, >> as their root hash, hash of Z, appending a different entry every time (the >> tree is forked at root hash Z). >> To the rest of the world, the log would present a chain of hashes that is >> STH 1 and STH 3' - which has the same root hash as STH 3 but prev_hash = Z. >> The client could not know that it's being presented with a chain of STHs >> that are for different trees unless it has consistency proofs between >> (STH1, STH2) and (STH2, STH3). >> > >> It seems to me that: >> - Clients still need to get (via push or pull) consistency proofs between >> STHs and validate them. >> - STHs still have to be gossiped for a single entity (monitor) to be in >> possession of STHs that cannot be proven consistent. >> > > The hash chaining is only a commitment to a claim of which blob is the > immediate predecessor of this other blob, you still need to verify the > correctness of the blobs in context, of course. > > At least for the monitoring-MMD use-case, it seems like a similar thing > could be achieved by requiring Logs to also log their own STHs, even > allowing for the vagaries of pending queues that'd put an MMD-sized window > on how far back in time a log could create old STHs to cover up MMD-blown > fails. What about requiring logs to add an entry containing the timestamp of the STH they're about to issue? This can be thought of as a "pre-STH" and could also include the tree size of the STH to be issued (even if that's implied by the entries position in the log) but obviously not tree head, nor signature. (It could include the tree size of the previous "pre-STH" as well, for efficient retrieval of all (information regarding) STH's.) A reason for requiring this is that it makes the log commit to each and every STH it's issuing, helping clients to make sure a log doesn't violate its STH frequency count. At the time of receiving the STH, no less. A reason for at least _allowing_ this is that it makes it possible for log implemenations to not have to remember another piece of data across disk crashes, network failures, etc. In our particular case, the only data we can remember with certainty are submitted cert chains and the tree, besides log configuration. This can of course be combined with adding the whole STH, including the actual signature, _after_ it has been minted and published through get-sth, if that's useful. > The monitors wouldn't then need a get-sths call (although if there were > other use cases for that API then the results from it would at least be > verifiable by monitors). > A thought is that you'd then have the ability to query a Log using > get-proof-by-hash for an STH you're holding to see if it can prove it was > logged, I'm not sure if that's useful at the moment, but my Friday evening > brain finds it amusing for some reason. > > The obvious next step would be to require Logs to log their STHs with a > quorum of other Logs. Assuming all Logs are not collaborating, that makes > it quite a lot harder for anyone to pull off split views, and of course you > can now do the same get-proof-by-hash call for your STH on other logs now, > if you didn't mind trying a a number of logs (or if you already knew in > which Logs to look*). > > *perhaps the set of target logs for a given STH could be defined by some > function of the day or week that the STH timestamp corresponds to - > something which changes infrequently enough that Logs can't simply not > issue an STH during that period or they'd blow their MMD - the intention > being to narrow the set of logs you'd have to look in, but also make it > harder to to choose colluding Logs. Requiring STH's to be logged in other logs is interesting. It would change a bunch of things for logs, like adding another configuration item as well as require logs to make outbound connections. Possibly neglectable, but in need of analysis also from an operations perspective. While useful, none of the above is strictly required for 6962bis in my opinion. From nobody Mon May 22 07:21: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 5151A129B4F for ; Mon, 22 May 2017 07:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se 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 k0WWW5Tm4lk1 for ; Mon, 22 May 2017 07:21:42 -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 05BDB129329 for ; Mon, 22 May 2017 07:21:41 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MELccx016153 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 16:21:38 +0200 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4MELYHQ027491 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 14:21:37 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495462898; bh=OsPxA3L21o91wxYb+kOD+7YxsS+jdPV2JDe/jY5ZOj8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=YAeYMMvo8kG4U+eRyE7MI9X+VqPl2hBhKy9MuIvi68Hz9SvVs33USoFbpfuyRAlux kVUGdl7Tu+PtxXMKwWKgV2+tKuTOR3TFZ9SrNiq36pQKk96qBgLxbp9VPi5aKOABGK OGAnM1mknSAhlMWe2XkhiUp9hJIXhAe9F9dEqWsI= From: Linus Nordberg To: Eran Messeri Cc: "trans\@ietf.org" Organization: Sunet References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> Date: Mon, 22 May 2017 16:21:54 +0200 In-Reply-To: (Eran Messeri's message of "Mon, 22 May 2017 13:23:12 +0100") Message-ID: <871srhvunx.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) on 192.36.171.202 X-Scanned-By: MIMEDefang 2.74 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.111.32; 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: 0aTnqlC7d - 0c0d54b24ca0 - 20170522 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 22 May 2017 14:21:45 -0000 Hi, It should be clear by now that I'd be sad if 6962bis would allow logs to return a different stream of bytes for the same ingoing parameters, for SCTs and STHs, but more interesting would be to hear other wg members views on the balance we're trying to strike. Regarding current deployment, are there any 6269bis logs deployed yet? Regarding correctness vs. completeness, what in -24 is incorrect with this regard? Regarding added cost of implementation, using RSA is an option. Regarding gossip unclearity, the suggested change risks making it harder to get STH gossip going. Eran Messeri wrote Mon, 22 May 2017 13:23:12 +0100: > FYI I'm proposing changes per this discussion in > https://github.com/google/certificate-transparency-rfcs/pull/261. Comments > welcome. > > Eran > > On Mon, May 15, 2017 at 12:35 PM, Eran Messeri wrote: > >> >> >> On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg wrote: >> >>> Eran Messeri wrote >>> Fri, 12 May 2017 14:36:04 +0100: >>> >>> > Thanks for the feedback. It helped me realize deterministic signatures >>> > could be achieved not only by using a deterministic signature scheme, >>> but >>> > also by logs storing the produced signatures and returning them instead >>> of >>> > re-signing SCTs, for example. >>> > >>> > That's my understanding of the discussion so far: >>> > * Requiring the use of RFC6979 is bad, for the reasons Brian has >>> mentioned. >>> > * It is not yet clear where deterministic signatures may be more >>> important >>> > (SCTs or STHs) because it's not clear what TLS clients will gossip and >>> how. >>> >>> Not to argue against that statement but I think that it's clear that >>> gossiping about STHs would become more problematic for a client caring >>> about privacy if logs were allowed to send different strings of bits to >>> different clients for a given pair of `log_id` and `tree_head` in an >>> STH. >>> >>> I completely agree - it would be more difficult for clients caring about >> privacy (which should be all TLS clients used by end-users these days, >> really) to exchange STHs they've obtained themselves, if logs were allowed >> to use unique signatures. >> I'm not saying the reasoning is wrong - it is very solid as far as I can >> tell - but that we don't know if we need it yet, see below. >> >> >>> > * It is not necessary to require the use of a deterministic signature >>> > scheme - only that the same signature is present in all instances of a >>> > particular SCT (note that different SCTs for the same submission, with >>> > different timestamps, which the log may issue, cannot have the same >>> > signature). >>> >>> This sounds like a requirement, i.e. a MUST, which is not reflected in >>> the reasoning below ("MUST->SHOULD" and "Mention that"). >>> >>> Also, this talks about SCTs specifically. What do you think the story is >>> for STHs? >>> >> Seems to me like the same reasoning applies to both - sorry, wasn't clear >> about it. >> >>> >>> >>> > Also, in 6962-bis, my focus is on correct operation of the log & Merkle >>> > Tree - and deterministic signatures are not strictly necessary for that. >>> >>> While I think it's fair to try to limit the scope I think it would be >>> bad to make it hard to gossip since that's supposed to protect against >>> attacks on the ability to audit the correctness of said >>> operation. Admittedly, one problem here is that "hard to gossip" is far >>> from well defined. >>> >>> Also, does this imply that the limitation on STH issuance frequency >>> should be removed too? >>> >> I'd leave that, as it has several benefits beyond gossip (for example, the >> ability to cache STHs and their consistency proofs or coordinating >> selection of an SCT). >> >>> >>> >>> > To make progress on this issue, I propose the following: >>> > * Remove references to 6979. >>> > * Remove the strong requirement to use deterministic signature schemes >>> > (MUST -> SHOULD), so implementations can use non-deterministic signature >>> > schemes and still be compliant with the spec. >>> > * Add reference to EdDSA, which includes a deterministic signature >>> scheme >>> > variant. >>> > * Mention that deterministic signatures can be achieved by storing the >>> > produced signatures. >>> > >>> > Any objections? >>> >>> I think that 6962bis should mandate that the same bits are sent over the >>> wire to every client asking for a given piece of signed data. (This can >>> be accomplished by either using a deterministic signing scheme or by >>> storing the data under a unique key for later use.) >>> >>> The main reason for this requirement is to make it possible for log >>> clients to gossip about STHs -- limiting the number of outstanding STHs >>> that a log can have at any given time is important in order to limit the >>> ability for a log to fingerprint its clients, as described in >>> draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the >>> log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that >>> the same bits are sent over the wire to everyone asking for a given STH. >>> >>> The privacy argument for imposing this same-bits-for-same-data rule for >>> SCTs too seems weaker since SCTs carry much more privacy sensitive data >>> but I'm not convinced that this holds for all gossip >>> scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to >>> linking an SCT to a user of an HTTPS client. I think this is reason >>> enough to not separate STHs and SCTs with regard to this requirement. >>> >> >> Overall I agree with the sentiment. However I'm trying to balance the >> attempt to make SCTs & STHs non-identifying as much as possible with ease >> of implementation and the current deployment: >> - As Melinda said on a separate post, 6962-bis has to be correct but it >> doesn't have to be complete. We could add the stricter requirement of >> producing consistent signatures for the same data later on. >> - There's an added cost for implementations: Either more storage (storing >> produced signatures) or reliance on features that are not widely supported >> in crypto libraries (deterministic signatures). >> - Right now, how the gossip is going to take place is unclear: The only >> thing currently operating (AFAIK) is STH exchange between several monitors. >> I don't know of any TLS client implementation that intends to fetch STHs >> directly (we've actually removed this capability >> > from Chrome recently). Even if there was such an implementation, because >> it's not clear who it will be exchanging STHs with, it's unclear what's the >> threat model - who has to collude to compromise a client's privacy by >> tracking it. >> >> To put it simply, I don't know yet if we'll need it - which is why I >> suggest we strongly recommend deterministic signatures, but not mandate it. >> >> What do you think? >> > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Mon May 22 07:27: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 4F01812EACC for ; Mon, 22 May 2017 07:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se 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 HKJmi1E8lldI for ; Mon, 22 May 2017 07:27:37 -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 20D3112EACA for ; Mon, 22 May 2017 07:27:36 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MERWZt018638 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 16:27:32 +0200 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4MERSkG024247 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 14:27:31 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495463251; bh=Hw1Wp9uuwJY4fwA1Y9OXdu7rws30YbxDDRNjir86wN4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=dkLE+dzRqao+K8+YihRePD3xuMF+m7GoyO+AYFapocrdTxt/xE6z2iAHsi1i3PZZp l6QlxOiwPQtwHSl6LcMTay9R3uBLIORKuNxRKE5RV48b3GL7zJgh2vdBEhiJx5na+W Q/CLGw5sYwuIIhddtgSL673lWbZ60lHbE8Z5n5ok= From: Linus Nordberg To: Rob Stradling Cc: Eran Messeri , trans@ietf.org Organization: Sunet References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> <8760h6i3h4.fsf@nordberg.se> <76f9b826-6553-143a-4ff4-504022fc4354@comodo.com> Date: Mon, 22 May 2017 16:27:48 +0200 In-Reply-To: <76f9b826-6553-143a-4ff4-504022fc4354@comodo.com> (Rob Stradling's message of "Fri, 19 May 2017 17:19:03 +0100") Message-ID: <87vaotuftn.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) on 192.36.171.202 X-Scanned-By: MIMEDefang 2.74 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.111.32; 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: 0aTnqrweG - 0d5c2dce6751 - 20170522 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: Subject: Re: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 22 May 2017 14:27:39 -0000 Rob Stradling wrote Fri, 19 May 2017 17:19:03 +0100: > On 12/05/17 14:55, Linus Nordberg wrote: >> I like the single add-entry call idea together with the explicit >> 'is_precertificate' indication. > > Would "submit-entry" be a better API name than "add-entry" (given that > the Submitter can't guarantee that the log will accept the submission > and add it to its tree)? No objection. > (Attempt at future-proofing) > Rather than an "is_precertificate" parameter, how about adding a > "type" parameter that takes a VersionedTransType integer value? > i.e., x509_entry_v2(1) or precert_entry_v2(2), for the two types of > submission that 6962-bis cares about. Support. From gbelvin@google.com Mon May 22 08:16: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 CA37812422F for ; Mon, 22 May 2017 08:16:40 -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 f4PBAaag3wbK for ; Mon, 22 May 2017 08:16:36 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F272120046 for ; Mon, 22 May 2017 08:16:36 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id e28so61246796uah.0 for ; Mon, 22 May 2017 08:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V/Pjv4pjIeGsm0a8V+JQ/HPfeitJ4/45UdaA0wrCJgY=; b=AQPsIAojErkbRCO1DGtwLtFFy9rLIkt9Y3P/twYPjXJLQ9hFpFar4V0pV6E956/L3n pYl+WTe0J43homMG9xK1gqXgzCbpvHogbI3Ng8P1SsWdby2IABwyjYe9X2lOMTi7zKnp KoLsMlkAgcgjOK5b/5rb3eH7gP6Dx9YxoTx0KA/EorbkvuZcYinV9dfY1i3HqVVEOk3N dcK1E3DNhgVq4w14FWt8QeWUipR5FC8LgclJwOfnXbwxWsaRnZYWVPEWJGe2ydbXJ4xE 43Yo2sXGVZpybBOohP/cRKMAdSxJoGE5DmDCvApmi/QDuYMFGDjPcTEVyJ9yM5OYADbr wA1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V/Pjv4pjIeGsm0a8V+JQ/HPfeitJ4/45UdaA0wrCJgY=; b=IW+WIwKU9fUVPsjcPp6Y9RySiqV3DmJWexRyoho1rRihLEZiKXV1YJ7ZknlyE3kdZE pBnQJfJ9LmloqJsRKDrppecKwLmDDH/1gOCS1Ikb0obJGQtzfYJUGGGTd1fIxwzN8HoD qZVt5p/MLh1ZHrcFl9/muiINXIaR26mA7+RvhsjOBQokEbf11eV3vv9OxqDtc/HAysWW XDVBfZaNfprZ2nAeEOyJ1pOmIm+SPpmtxGCQmu5AzrRnuyYqIgWg0xeHPMizzvR9yKEi yNb2Xx+y6val/RRHc4E/qMmB+2BwEbLinvX0pZp4GPRR+l0k+xmmM1RkkwyvHEUoGlSO cV7w== X-Gm-Message-State: AODbwcCpGBwE5rU6nqemz44FaFM0SLt824tvd3ecv0H6MlT3y0Kv43wl DnH3+QZV45JoyfeNjCdzNuldtwwBM9Rj X-Received: by 10.159.36.194 with SMTP id 60mr12657631uar.112.1495466195003; Mon, 22 May 2017 08:16:35 -0700 (PDT) MIME-Version: 1.0 References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> In-Reply-To: <871srhvunx.fsf@nordberg.se> From: Gary Belvin Date: Mon, 22 May 2017 15:16:24 +0000 Message-ID: To: Linus Nordberg , Eran Messeri Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11352ac254867605501e5bc0" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 22 May 2017 15:18:04 -0000 --001a11352ac254867605501e5bc0 Content-Type: text/plain; charset="UTF-8" > return a different stream of bytes for the same ingoing parameters, for SCTs and STHs. In addition to fixing signature randomization, wouldn't one also need to fix the inputs to the signature? Timestamps in particular and any server supplied data that wasn't directly tied to the leaves themselves would seem to be a problem. -G On Mon, May 22, 2017 at 10:21 AM Linus Nordberg wrote: > Hi, > > It should be clear by now that I'd be sad if 6962bis would allow logs to > return a different stream of bytes for the same ingoing parameters, for > SCTs and STHs, but more interesting would be to hear other wg members > views on the balance we're trying to strike. > > Regarding current deployment, are there any 6269bis logs deployed yet? > > Regarding correctness vs. completeness, what in -24 is incorrect with > this regard? > > Regarding added cost of implementation, using RSA is an option. > > Regarding gossip unclearity, the suggested change risks making it harder > to get STH gossip going. > > > Eran Messeri wrote > Mon, 22 May 2017 13:23:12 +0100: > > > FYI I'm proposing changes per this discussion in > > https://github.com/google/certificate-transparency-rfcs/pull/261. > Comments > > welcome. > > > > Eran > > > > On Mon, May 15, 2017 at 12:35 PM, Eran Messeri wrote: > > > >> > >> > >> On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg > wrote: > >> > >>> Eran Messeri wrote > >>> Fri, 12 May 2017 14:36:04 +0100: > >>> > >>> > Thanks for the feedback. It helped me realize deterministic > signatures > >>> > could be achieved not only by using a deterministic signature scheme, > >>> but > >>> > also by logs storing the produced signatures and returning them > instead > >>> of > >>> > re-signing SCTs, for example. > >>> > > >>> > That's my understanding of the discussion so far: > >>> > * Requiring the use of RFC6979 is bad, for the reasons Brian has > >>> mentioned. > >>> > * It is not yet clear where deterministic signatures may be more > >>> important > >>> > (SCTs or STHs) because it's not clear what TLS clients will gossip > and > >>> how. > >>> > >>> Not to argue against that statement but I think that it's clear that > >>> gossiping about STHs would become more problematic for a client caring > >>> about privacy if logs were allowed to send different strings of bits to > >>> different clients for a given pair of `log_id` and `tree_head` in an > >>> STH. > >>> > >>> I completely agree - it would be more difficult for clients caring > about > >> privacy (which should be all TLS clients used by end-users these days, > >> really) to exchange STHs they've obtained themselves, if logs were > allowed > >> to use unique signatures. > >> I'm not saying the reasoning is wrong - it is very solid as far as I can > >> tell - but that we don't know if we need it yet, see below. > >> > >> > >>> > * It is not necessary to require the use of a deterministic signature > >>> > scheme - only that the same signature is present in all instances of > a > >>> > particular SCT (note that different SCTs for the same submission, > with > >>> > different timestamps, which the log may issue, cannot have the same > >>> > signature). > >>> > >>> This sounds like a requirement, i.e. a MUST, which is not reflected in > >>> the reasoning below ("MUST->SHOULD" and "Mention that"). > >>> > >>> Also, this talks about SCTs specifically. What do you think the story > is > >>> for STHs? > >>> > >> Seems to me like the same reasoning applies to both - sorry, wasn't > clear > >> about it. > >> > >>> > >>> > >>> > Also, in 6962-bis, my focus is on correct operation of the log & > Merkle > >>> > Tree - and deterministic signatures are not strictly necessary for > that. > >>> > >>> While I think it's fair to try to limit the scope I think it would be > >>> bad to make it hard to gossip since that's supposed to protect against > >>> attacks on the ability to audit the correctness of said > >>> operation. Admittedly, one problem here is that "hard to gossip" is far > >>> from well defined. > >>> > >>> Also, does this imply that the limitation on STH issuance frequency > >>> should be removed too? > >>> > >> I'd leave that, as it has several benefits beyond gossip (for example, > the > >> ability to cache STHs and their consistency proofs or coordinating > >> selection of an SCT). > >> > >>> > >>> > >>> > To make progress on this issue, I propose the following: > >>> > * Remove references to 6979. > >>> > * Remove the strong requirement to use deterministic signature > schemes > >>> > (MUST -> SHOULD), so implementations can use non-deterministic > signature > >>> > schemes and still be compliant with the spec. > >>> > * Add reference to EdDSA, which includes a deterministic signature > >>> scheme > >>> > variant. > >>> > * Mention that deterministic signatures can be achieved by storing > the > >>> > produced signatures. > >>> > > >>> > Any objections? > >>> > >>> I think that 6962bis should mandate that the same bits are sent over > the > >>> wire to every client asking for a given piece of signed data. (This can > >>> be accomplished by either using a deterministic signing scheme or by > >>> storing the data under a unique key for later use.) > >>> > >>> The main reason for this requirement is to make it possible for log > >>> clients to gossip about STHs -- limiting the number of outstanding STHs > >>> that a log can have at any given time is important in order to limit > the > >>> ability for a log to fingerprint its clients, as described in > >>> draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the > >>> log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring > that > >>> the same bits are sent over the wire to everyone asking for a given > STH. > >>> > >>> The privacy argument for imposing this same-bits-for-same-data rule for > >>> SCTs too seems weaker since SCTs carry much more privacy sensitive data > >>> but I'm not convinced that this holds for all gossip > >>> scenarios. Fingerprinting of a gossip peer doesn't necessarily relate > to > >>> linking an SCT to a user of an HTTPS client. I think this is reason > >>> enough to not separate STHs and SCTs with regard to this requirement. > >>> > >> > >> Overall I agree with the sentiment. However I'm trying to balance the > >> attempt to make SCTs & STHs non-identifying as much as possible with > ease > >> of implementation and the current deployment: > >> - As Melinda said on a separate post, 6962-bis has to be correct but it > >> doesn't have to be complete. We could add the stricter requirement of > >> producing consistent signatures for the same data later on. > >> - There's an added cost for implementations: Either more storage > (storing > >> produced signatures) or reliance on features that are not widely > supported > >> in crypto libraries (deterministic signatures). > >> - Right now, how the gossip is going to take place is unclear: The only > >> thing currently operating (AFAIK) is STH exchange between several > monitors. > >> I don't know of any TLS client implementation that intends to fetch STHs > >> directly (we've actually removed this capability > >> < > https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db710c49c47d0db087>> > from Chrome recently). Even if there was such an implementation, because > >> it's not clear who it will be exchanging STHs with, it's unclear what's > the > >> threat model - who has to collude to compromise a client's privacy by > >> tracking it. > >> > >> To put it simply, I don't know yet if we'll need it - which is why I > >> suggest we strongly recommend deterministic signatures, but not mandate > it. > >> > >> What do you think? > >> > > _______________________________________________ > > 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 > --001a11352ac254867605501e5bc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> return a dif= ferent stream of bytes for the same ingoing parameters, for=C2=A0SCTs and STHs.
In addition to fixing signature randomization, wouldn't o= ne also need to fix the inputs to the signature? Timestamps in particular a= nd any server supplied data that wasn't directly tied to the leaves the= mselves would seem to be a problem.=C2=A0

-G
<= div>


On Mon, May 22, 2017 at 10:21 AM Linus Nordberg <linus@sunet.se> wrote:
Hi,

It should be clear by now that I'd be sad if 6962bis would allow logs t= o
return a different stream of bytes for the same ingoing parameters, for
SCTs and STHs, but more interesting would be to hear other wg members
views on the balance we're trying to strike.

Regarding current deployment, are there any 6269bis logs deployed yet?

Regarding correctness vs. completeness, what in -24 is incorrect with
this regard?

Regarding added cost of implementation, using RSA is an option.

Regarding gossip unclearity, the suggested change risks making it harder to get STH gossip going.


Eran Messeri <eran= m@google.com> wrote
Mon, 22 May 2017 13:23:12 +0100:

> FYI I'm proposing changes per this discussion in
> https://github.com/google/certi= ficate-transparency-rfcs/pull/261. Comments
> welcome.
>
> Eran
>
> On Mon, May 15, 2017 at 12:35 PM, Eran Messeri <eranm@google.com> wrote:
>
>>
>>
>> On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <linus@sunet.se> wrote:
>>
>>> Eran Messeri <eranm@google.com> wrote
>>> Fri, 12 May 2017 14:36:04 +0100:
>>>
>>> > Thanks for the feedback. It helped me realize determinist= ic signatures
>>> > could be achieved not only by using a deterministic signa= ture scheme,
>>> but
>>> > also by logs storing the produced signatures and returnin= g them instead
>>> of
>>> > re-signing SCTs, for example.
>>> >
>>> > That's my understanding of the discussion so far:
>>> > * Requiring the use of RFC6979 is bad, for the reasons Br= ian has
>>> mentioned.
>>> > * It is not yet clear where deterministic signatures may = be more
>>> important
>>> > (SCTs or STHs) because it's not clear what TLS client= s will gossip and
>>> how.
>>>
>>> Not to argue against that statement but I think that it's = clear that
>>> gossiping about STHs would become more problematic for a clien= t caring
>>> about privacy if logs were allowed to send different strings o= f bits to
>>> different clients for a given pair of `log_id` and `tree_head`= in an
>>> STH.
>>>
>>> I completely agree - it would be more difficult for clients ca= ring about
>> privacy (which should be all TLS clients used by end-users these d= ays,
>> really) to exchange STHs they've obtained themselves, if logs = were allowed
>> to use unique signatures.
>> I'm not saying the reasoning is wrong - it is very solid as fa= r as I can
>> tell - but that we don't know if we need it yet, see below. >>
>>
>>> > * It is not necessary to require the use of a determinist= ic signature
>>> > scheme - only that the same signature is present in all i= nstances of a
>>> > particular SCT (note that different SCTs for the same sub= mission, with
>>> > different timestamps, which the log may issue, cannot hav= e the same
>>> > signature).
>>>
>>> This sounds like a requirement, i.e. a MUST, which is not refl= ected in
>>> the reasoning below ("MUST->SHOULD" and "Men= tion that").
>>>
>>> Also, this talks about SCTs specifically. What do you think th= e story is
>>> for STHs?
>>>
>> Seems to me like the same reasoning applies to both - sorry, wasn&= #39;t clear
>> about it.
>>
>>>
>>>
>>> > Also, in 6962-bis, my focus is on correct operation of th= e log & Merkle
>>> > Tree - and deterministic signatures are not strictly nece= ssary for that.
>>>
>>> While I think it's fair to try to limit the scope I think = it would be
>>> bad to make it hard to gossip since that's supposed to pro= tect against
>>> attacks on the ability to audit the correctness of said
>>> operation. Admittedly, one problem here is that "hard to = gossip" is far
>>> from well defined.
>>>
>>> Also, does this imply that the limitation on STH issuance freq= uency
>>> should be removed too?
>>>
>> I'd leave that, as it has several benefits beyond gossip (for = example, the
>> ability to cache STHs and their consistency proofs or coordinating=
>> selection of an SCT).
>>
>>>
>>>
>>> > To make progress on this issue, I propose the following:<= br> >>> > * Remove references to 6979.
>>> > * Remove the strong requirement to use deterministic sign= ature schemes
>>> > (MUST -> SHOULD), so implementations can use non-deter= ministic signature
>>> > schemes and still be compliant with the spec.
>>> > * Add reference to EdDSA, which includes a deterministic = signature
>>> scheme
>>> > variant.
>>> > * Mention that deterministic signatures can be achieved b= y storing the
>>> > produced signatures.
>>> >
>>> > Any objections?
>>>
>>> I think that 6962bis should mandate that the same bits are sen= t over the
>>> wire to every client asking for a given piece of signed data. = (This can
>>> be accomplished by either using a deterministic signing scheme= or by
>>> storing the data under a unique key for later use.)
>>>
>>> The main reason for this requirement is to make it possible fo= r log
>>> clients to gossip about STHs -- limiting the number of outstan= ding STHs
>>> that a log can have at any given time is important in order to= limit the
>>> ability for a log to fingerprint its clients, as described in<= br> >>> draft-ietf-trans-gossip-04 section 10.5.4. This is done by lim= iting the
>>> log STH issuance frequency (6962bis-24 section 4.8) _and_ requ= iring that
>>> the same bits are sent over the wire to everyone asking for a = given STH.
>>>
>>> The privacy argument for imposing this same-bits-for-same-data= rule for
>>> SCTs too seems weaker since SCTs carry much more privacy sensi= tive data
>>> but I'm not convinced that this holds for all gossip
>>> scenarios. Fingerprinting of a gossip peer doesn't necessa= rily relate to
>>> linking an SCT to a user of an HTTPS client. I think this is r= eason
>>> enough to not separate STHs and SCTs with regard to this requi= rement.
>>>
>>
>> Overall I agree with the sentiment. However I'm trying to bala= nce the
>> attempt to make SCTs & STHs non-identifying as much as possibl= e with ease
>> of implementation and the current deployment:
>> - As Melinda said on a separate post, 6962-bis has to be correct b= ut it
>> doesn't have to be complete. We could add the stricter require= ment of
>> producing consistent signatures for the same data later on.
>> - There's an added cost for implementations: Either more stora= ge (storing
>> produced signatures) or reliance on features that are not widely s= upported
>> in crypto libraries (deterministic signatures).
>> - Right now, how the gossip is going to take place is unclear: The= only
>> thing currently operating (AFAIK) is STH exchange between several = monitors.
>> I don't know of any TLS client implementation that intends to = fetch STHs
>> directly (we've actually removed this capability
>> <https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db= 710c49c47d0db087>> from Chrome recently). Even if there was such = an implementation, because
>> it's not clear who it will be exchanging STHs with, it's u= nclear what's the
>> threat model - who has to collude to compromise a client's pri= vacy by
>> tracking it.
>>
>> To put it simply, I don't know yet if we'll need it - whic= h is why I
>> suggest we strongly recommend deterministic signatures, but not ma= ndate it.
>>
>> What do you think?
>>
> _______________________________________________
> 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
--001a11352ac254867605501e5bc0-- From nobody Mon May 22 09:35: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 4F44612EB2D for ; Mon, 22 May 2017 09:35:14 -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 bC84C-g4o1vq for ; Mon, 22 May 2017 09:35:12 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 5E20512EB2B for ; Mon, 22 May 2017 09:35:12 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b84so984648wmh.0 for ; Mon, 22 May 2017 09:35:12 -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=mZXDvM0/eKzxsEmczoSRAgBxu7RSITbL93S033SJ5Nk=; b=cKXyVUv0LIhUHkDkNZICFRag6IEb0ao9XHrdy2TpG7U5KpseH3cnYVWMJ0z33sRCV6 Zlowm6ZeHP6g3SghGeolvID0F7gHdnkQJolAhwyUEramY+n001gFwTOIBo9C5Y17YcbE 9UUuSg/Nryod+ErRQ/AQ51bLDvMMrQvmvWEdgeGLtdLyW3FPHFGZ1HsF2uXRfFtqguKh +QVE4mWiRAdJgWNe5xVV2Zo3GZqezeU/9yPfCED5rS+qL5Dg5r6DgkzyYNjY8YWqA6UH XO8cpjgD7PuWF0AMNV9rP5mQdtDiy0FTtnN1t01FW888B11fT+p5KARAX2E3BVEiXoqb i4vA== 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=mZXDvM0/eKzxsEmczoSRAgBxu7RSITbL93S033SJ5Nk=; b=ObcuId01bprrrSDJywu+bqZOaqHR7cwxrjnDX24De//r0hKgxTgVdzclTkCHylvqlK hnqoZTwGmHZIVFymScRhfOltq4LEhOYnKbuKE3dX5ZxSu0+t1M7Sa1SQ9kx0MvBw8OOh 3jCBaAtJHfc0hJhFTHcfKq9jlHZ918veRcpwBJM9pNMtXLTGVA8AB7suqDbkqf7Sdyxs 8qIf9NDcUDc7M4jEOpA62YMvQ/oecs0B8MYOBe3e/IGcWT4xfsBBt8zW/LOXXTa8AN+n N4/ZPamstJm1DbWRs773GdOAYIEka2M5snIb0P3Z/N1lwI/c3gGK5rbez17lFIalO3Dz zm8Q== X-Gm-Message-State: AODbwcCQZGAgJnMrGpKDWR8ipE+bbd1PhDo46EkM5pw1NwMxcS9k+8NG 480r6SSxPvuE0MuzeyorHrOrvlqhRiXc X-Received: by 10.28.157.74 with SMTP id g71mr27046364wme.74.1495470910785; Mon, 22 May 2017 09:35:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.149 with HTTP; Mon, 22 May 2017 09:35:09 -0700 (PDT) In-Reply-To: <87vaotuftn.fsf@nordberg.se> References: <20170504082553.9840d8b8a750f87509e75b43@andrewayer.name> <8760h6i3h4.fsf@nordberg.se> <76f9b826-6553-143a-4ff4-504022fc4354@comodo.com> <87vaotuftn.fsf@nordberg.se> From: Richard Barnes Date: Mon, 22 May 2017 12:35:09 -0400 Message-ID: To: Linus Nordberg Cc: Rob Stradling , Eran Messeri , Trans Content-Type: multipart/alternative; boundary="001a114baa5e68e3ce05501f747a" Archived-At: Subject: Re: [Trans] Consolidating add-chain and add-pre-chain endpoints 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, 22 May 2017 16:35:14 -0000 --001a114baa5e68e3ce05501f747a Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2017 at 10:27 AM, Linus Nordberg wrote: > Rob Stradling wrote > Fri, 19 May 2017 17:19:03 +0100: > > > On 12/05/17 14:55, Linus Nordberg wrote: > >> I like the single add-entry call idea together with the explicit > >> 'is_precertificate' indication. > > > > Would "submit-entry" be a better API name than "add-entry" (given that > > the Submitter can't guarantee that the log will accept the submission > > and add it to its tree)? > > No objection. > > > > (Attempt at future-proofing) > > Rather than an "is_precertificate" parameter, how about adding a > > "type" parameter that takes a VersionedTransType integer value? > > i.e., x509_entry_v2(1) or precert_entry_v2(2), for the two types of > > submission that 6962-bis cares about. > > Support. > This all sounds fine to me. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114baa5e68e3ce05501f747a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 22, 2017 at 10:27 AM, Linus Nordberg <= linus@sunet.se><= /span> wrote:
Rob Stradling <rob.stradling@comodo.com> wrote=
Fri, 19 May 2017 17:19:03 +0100:

> On 12/05/17 14:55, Linus Nordberg wrote:
>> I like the single add-entry call idea together with the explicit >> 'is_precertificate' indication.
>
> Would "submit-entry" be a better API name than "add-ent= ry" (given that
> the Submitter can't guarantee that the log will accept the submiss= ion
> and add it to its tree)?

No objection.


> (Attempt at future-proofing)
> Rather than an "is_precertificate" parameter, how about addi= ng a
> "type" parameter that takes a VersionedTransType integer val= ue?
> i.e., x509_entry_v2(1) or precert_entry_v2(2), for the two types of > submission that 6962-bis cares about.

Support.

This all sounds fine to= me.

=C2=A0

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

--001a114baa5e68e3ce05501f747a-- From nobody Mon May 22 10:38: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 CFAA512EAEE for ; Mon, 22 May 2017 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se 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 OU9rD702ejAB for ; Mon, 22 May 2017 10:38:15 -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 51F09126C2F for ; Mon, 22 May 2017 10:38:15 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MHcCfr010961 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 19:38:12 +0200 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4MHc4Ys024373 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 17:38:10 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495474692; bh=gxQlTm8LaN2fCQxAOlnfBdJrKe8intReJFnHc2AOg7g=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Wlr7VcJAwg3sSR+7y9b6m0h6ou+WAadl3X9xz7ltxcZhlYvpW0k78myM/M6DU4Rjg AVvI3DqSwri9R5uHskI89fF8qEHfY+DJiUt5ca8nIwrsT1AfqKQA1vj7muNjSzaDUX xgNZdzjd+rWF/PJR1RTYxhUZsFnmFXw6muwzMRyM= From: Linus Nordberg To: Gary Belvin Cc: Eran Messeri , "trans\@ietf.org" Organization: Sunet References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> Date: Mon, 22 May 2017 19:38:24 +0200 In-Reply-To: (Gary Belvin's message of "Mon, 22 May 2017 15:16:24 +0000") Message-ID: <87shjwu6zz.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) on 192.36.171.202 X-Scanned-By: MIMEDefang 2.74 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.111.32; 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: 0aTntCcCM - 5d3335abbd65 - 20170522 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 22 May 2017 17:38:18 -0000 Gary Belvin wrote Mon, 22 May 2017 15:16:24 +0000: >> return a different stream of bytes for the same ingoing parameters, for SCTs > and STHs. > In addition to fixing signature randomization, wouldn't one also need to > fix the inputs to the signature? Timestamps in particular and any server > supplied data that wasn't directly tied to the leaves themselves would seem > to be a problem. Yes. My understanding is that they are all under control. For STH's: The log id is fixed. The number of timestamps, the tree size and the root hash are limited by the STH frequency count. The extensions field is unused. For SCT's: The log id is fixed. Timestamps are limited by the visibility in the log and the cost of storage forever. The extensions field is unused. None of issuer key hash and (pre-) certificate in the timestamped entry are server supplied. Please let us know if we're missing something. From nobody Tue May 23 02:42: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 EB2A4129432 for ; Tue, 23 May 2017 02:42: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 oiWBC_xnLkBQ for ; Tue, 23 May 2017 02:42:21 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D75124C27 for ; Tue, 23 May 2017 02:42:21 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id r63so16187089itc.1 for ; Tue, 23 May 2017 02:42:21 -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=TEknQ54OAF4AcEGLMDYv1qKLZNUUc78OgMRG8DN0VrE=; b=SuXsep3uYPOsFS81OegvXBUXIegOJaMvfWp3wnJlH0yGemPEBQB6udOena8Yg85SKg 25Hf462UTc9UQGqY1BA10wCIdtBiWUpZAGmWNTqx51CXaVI7WyU/eITnB9ZhUUzhp2lt GE7QkP6XM6q1HDWSi/ek0k6osSCUOTYDQnrEgok5p/LMVqWXCe53AK9WlObi9rLQayxt K+akIqr2EH2nWL4n1js4Etqg9mRqDRmPEOuRDmdx0eXqtCcqBG1GCyWrNMLzoKoTgcIi n7py0eN7Y/0ebI0eOuwCEgiXwcqVQ6RPgcHaK7eLMeCAwt9TWdfyA8+jnvkHude9AWBC 6JMg== 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=TEknQ54OAF4AcEGLMDYv1qKLZNUUc78OgMRG8DN0VrE=; b=CtnH76mrDhDkFPB/kQA2FmdmyvOmL95+nptvh3PyEaORgERlHAcDhahvI2edEa26fA wZjYGkkkzcBznXlpy8rOhlp1Ef/3R1uxvQeDX4jsAF7TzdViQ5E9lFvihEFtyvOVR3N8 fK1H/bUsxL4ls1M7b28Q7zXqhIOa1SSSuoveW6FpHSQkcKaB7hcK9R/hsMk4YUdQK2v6 1Iu2MXo3zdz7nHahCFXuHkqbAup3lKO8CZJr0dIxSTxuQQsf1jh8gmFomfebtPMZkX45 kMRWv9PUnvg4htFI3BiklXlTKPvyrCcoNhr4/0etEVnR6lzwXkGSHpDiT9WFFq5ug0oE FfYQ== X-Gm-Message-State: AODbwcD3HsQZK5ylmS4xyeqXrXhBlnWPBsqhvoQ0lOowUay7Pee8ym1Y 0QIxZ2ln50jrBDWl7tc7T3emy4htMK37 X-Received: by 10.36.29.204 with SMTP id 195mr1761651itj.112.1495532540558; Tue, 23 May 2017 02:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Tue, 23 May 2017 02:41:49 -0700 (PDT) In-Reply-To: <87shjwu6zz.fsf@nordberg.se> References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> <87shjwu6zz.fsf@nordberg.se> From: Eran Messeri Date: Tue, 23 May 2017 10:41:49 +0100 Message-ID: To: Linus Nordberg Cc: Gary Belvin , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1135b764d4faf605502dcdfd" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 23 May 2017 09:42:23 -0000 --001a1135b764d4faf605502dcdfd Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2017 at 6:38 PM, Linus Nordberg wrote: > Gary Belvin wrote > Mon, 22 May 2017 15:16:24 +0000: > > >> return a different stream of bytes for the same ingoing parameters, for > SCTs > > and STHs. > > In addition to fixing signature randomization, wouldn't one also need to > > fix the inputs to the signature? Timestamps in particular and any server > > supplied data that wasn't directly tied to the leaves themselves would > seem > > to be a problem. > > Yes. My understanding is that they are all under control. > > For STH's: The log id is fixed. The number of timestamps, the tree size > and the root hash are limited by the STH frequency count. The extensions > field is unused. > (1) while the STH frequency is bound, a log is not required to produce STHs at that frequency - it can (and I suspect most operators will) issue STHs at a lower frequency. So it's still possible for the log to issue a few STHs which a few "select" clients will see - it all depends on the operational model of STH distribution / fetching. (2) while the extensions field is currently unused, clients are required to ignore any extension they do not understand, so a log may put arbitrary data there. > > For SCT's: The log id is fixed. Timestamps are limited by the visibility > in the log and the cost of storage forever. The extensions field is > unused. None of issuer key hash and (pre-) certificate in the > timestamped entry are server supplied. > The timestamp is chosen by the log, and a log may choose to create several entries, with different timestamps, for a single submission (useful if a log and server collude). Again, the usefulness of this for tracking a client depends on the SCT reporting/gossip model. My point is that even with fully deterministic signatures, it's very hard to defend against this vector of client fingerprinting, particularly in the face of unknown operational/threat model. Furthermore, there are other ways to track a client - even today, with 6962 and Expect-CT: A server may simply collect SCTs from multiple logs and serve a unique subset of SCTs to the client it wants to track, setting the Expect-CT header for reporting only. But a server that wants to track clients has many, many ways that are more straightforward. > > Please let us know if we're missing something. > --001a1135b764d4faf605502dcdfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 22, 2017 at 6:38 PM, Linus Nordberg <<= a href=3D"mailto:linus@sunet.se" target=3D"_blank">linus@sunet.se> wrote:
Gary Belvin <gdb@google.com> wrote
Mon, 22 May 2017 15:16:24 +0000:

>> return a different stream of bytes for the same ingoing parameters= , for SCTs
> and STHs.
> In addition to fixing signature randomization, wouldn't one also n= eed to
> fix the inputs to the signature? Timestamps in particular and any serv= er
> supplied data that wasn't directly tied to the leaves themselves w= ould seem
> to be a problem.

Yes. My understanding is that they are all under control.

For STH's: The log id is fixed. The number of timestamps, the tree size=
and the root hash are limited by the STH frequency count. The extensions field is unused.
(1) while the STH frequency is bound,= a log is not required to produce STHs at that frequency - it can (and I su= spect most operators will) issue STHs at a lower frequency. So it's sti= ll possible for the log to issue a few STHs which a few "select" = clients will see - it all depends on the operational model of STH distribut= ion / fetching.
(2) while the extensions field is currently unuse= d, clients are required to ignore any extension they do not understand, so = a log may put arbitrary data there.

For SCT's: The log id is fixed. Timestamps are limited by the visibilit= y
in the log and the cost of storage forever. The extensions field is
unused. None of issuer key hash and (pre-) certificate in the
timestamped entry are server supplied.
The timestamp i= s chosen by the log, and a log may choose to create several entries, with d= ifferent timestamps, for a single submission (useful if a log and server co= llude). Again, the usefulness of this for tracking a client depends on the = SCT reporting/gossip model.

My point is that even = with fully deterministic signatures, it's very hard to defend against t= his vector of client fingerprinting, particularly in the face of unknown op= erational/threat model.=C2=A0
Furthermore, there are other ways t= o track a client - even today, with 6962 and Expect-CT: A server may simply= collect SCTs from multiple logs and serve a unique subset of SCTs to the c= lient it wants to track, setting the Expect-CT header for reporting only. B= ut a server that wants to track clients has many, many ways that are more s= traightforward.

Please let us know if we're missing something.

--001a1135b764d4faf605502dcdfd-- From nobody Tue May 23 03:00: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 4DBB3129A92 for ; Tue, 23 May 2017 03:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se 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 Hd7gOBa5j4hS for ; Tue, 23 May 2017 03:00:36 -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 E5D291296D2 for ; Tue, 23 May 2017 03:00:35 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4NA0WmW019733 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 May 2017 12:00:32 +0200 Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4NA0Nkr020373 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 May 2017 10:00:29 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495533632; bh=LmbwjPrFvYPXjC8nQGYXbtXo6AmRRJN19s0yENBVrtk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=N2/haq29Q8HWpw/FzCKMqiqJs0hJqNazPPLEYb2EputDQNxru0bBmoBZfpP0zf2yf wKScS7mYFfncETXdkJfdbARTXK1CEjDq4NZIX5V36wHc+efzJVc44qLloIGcWKB0B5 ZH+hmyh8EtLcJDtxcqqlpRRavMD+5l46mmyqcOXQ= From: Linus Nordberg To: Eran Messeri Cc: "trans\@ietf.org" , Gary Belvin Organization: Sunet References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> <87shjwu6zz.fsf@nordberg.se> Date: Tue, 23 May 2017 12:00:44 +0200 In-Reply-To: (Eran Messeri's message of "Tue, 23 May 2017 10:41:49 +0100") Message-ID: <87poezq4dv.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) on 192.36.171.202 X-Scanned-By: MIMEDefang 2.74 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.111.32; 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: 0aTnK0w81 - 7552954de9d6 - 20170523 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 23 May 2017 10:00:38 -0000 Eran Messeri wrote Tue, 23 May 2017 10:41:49 +0100: > (2) while the extensions field is currently unused, clients are required to > ignore any extension they do not understand, so a log may put arbitrary > data there. You're right. So it's not impossible to track clients using the extension field but at least it's visible. From nobody Tue May 23 05:43: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 3024D129B2C for ; Tue, 23 May 2017 05:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ZEXVpwh6OBQq for ; Tue, 23 May 2017 05:43:10 -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 20D12129B2B for ; Tue, 23 May 2017 05:43:10 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id g126so18660461ith.0 for ; Tue, 23 May 2017 05:43:10 -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=3vH3v5gVYrSwP9rbQEjJgR8TYS4TSY3cUfBMwvvzK1E=; b=gIbDRtYEg6C3fT7PCJPGI/MpKoRJ8yvucdrVRHs90fLRWUcKoOH/LunxXYHZ8fOVCZ QITCVQAWIppiGI+cGBr4ywUW0cfD8P20cSR3cdsKTVtH6RJjTux0nwe9pMoqra0mWTIr bNvORSpRtMKbTQ5RTDvPqjdW/A+fyOdsiD7/NWmCSesGYkQbQudEjhzfO5r7q3NwaC58 12IvfgVUOlv3glsTQ9jdzTIWsnRtq7U4dsYm6SYM4/KotG+Z83fx3yoTR15OSmFuCDOa oN4jedCeiZxJSEiKyZR9XJ6yXaQm6Zaxf/b7BO3Q9xSxrmMvlckHxRazlzzCfo8zi1X/ 0bBg== 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=3vH3v5gVYrSwP9rbQEjJgR8TYS4TSY3cUfBMwvvzK1E=; b=j1HMipPqwTCWU73CQ+fknXmjmPMUf4N0XutNKbqR1tr8utS6Sy9+4Op1ikOXcNrDjM 3usdMQ21foUQaWnGLOaf/zengmZaevIKOpkfxU4ouwZkBPQQ069xMlF4yV+AbuylYdIs Ill+1Ya35bQQuI94kwtKYdbGVUtcD29ND2FIfUfUb/6ti/c3qlzec1DryKB3jDGMT3cr R0X4HnWo9SCU1uuRPDUsbK5/vIQDSnTp8xDbMWFri2hJqbxSRd75J6/b+NEYyyKyukR8 PUH1i5mgL4lHx/US+abdTNKiWVGcq3tV+ydq0b+9e+rvZIyCyBvFD4k+epRea2cG4xCJ 8nqQ== X-Gm-Message-State: AODbwcAM1kySxKLA97q0KtvIz21MGD/OLyzOQPt/qcm1nOXag1MCGAPD AYr21FDXe5kyiQA+ZNEQRiGKKPuOkYWcYiB5YA== X-Received: by 10.36.29.204 with SMTP id 195mr2482027itj.112.1495543389020; Tue, 23 May 2017 05:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Tue, 23 May 2017 05:42:38 -0700 (PDT) From: Eran Messeri Date: Tue, 23 May 2017 13:42:38 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1135b76473b9a10550305459" Archived-At: Subject: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 12:43:12 -0000 --001a1135b76473b9a10550305459 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Below is a write up of the =E2=80=9CStrict CT=E2=80=9D variant, based on Mo= zilla=E2=80=99s suggestion. The goal of this write-up is to serve as a foundation for a document that will describe the deployment of CT needed to operate with stronger guarantees for TLS clients, as well as the protocol extensions necessary to deploy it. *Goal*: Provide TLS clients with proof of inclusion to a tree state they already know (save clients the need to audit logs themselves). *Overview*: - UA vendor ("auditor") periodically collects an STH (denoted "official" STH [1]) from each log, distributes it to its UAs ("clients"). Clients a= re expected to cache all STHs. - CA/Site Owner ("submitter") submits (pre)certificate to the log, gets SCT [2]. - Submitter waits until the next official STH that includes the certificate, gets an inclusion proof to be served alongside the certific= ate + SCT. - In the TLS handshake, clients get certificate + SCT + inclusion proof to an official STH they know about [5]. The purpose of the UA vendor sending down the official STH is to provide third-party verification of the consensus. The purpose of the submitter bundling the STH + inclusion proof is to avoid the client having to retrieve it via some other protocol Options for dealing with the delayed usability of certificates: - Submitter waits until an inclusion proof to an =E2=80=9Cofficial=E2=80= =9D STH becomes available, only starts serving that certificate then (could take up to 2= x MMD - two days, typically). - The CA could wait until the proof becomes available and only issue the final certificate then - delay issuance by up to MMD. - The requester could get the certificate immediately but only start using it once it=E2=80=99s able to obtain an inclusion proof to an official STH [3]. - Certificate is used immediately, only with SCT: Clients accept certificates only with SCTs for a limited duration; after that an inclus= ion proof must be accompanied [4]. - Opt-in: servers requires presence of proofs via header / X.509 extension [6]. - Certificate is used after the client can fetch an inclusion proof and an STH the log has produced; if it=E2=80=99s an unknown STH the client s= ends it to the auditor for reconciliation. Footnotes: [1] The "official" STH does not have to be explicitly marked: Assuming daily STH push cycle, a log could mint one marked STH every day, to be distributed to clients. Alternatively, if STH issuance frequency (which 6962-bis requires specifying) is not too high (e.g. hourly) then the "official" STH could be the first one issued after midnight UTC (synchronizing on the clock). [2] An intermediate improvement is to return, rather than just SCT, the SCT + STH issued immediately afterwards (~seconds) + inclusion proof to that STH. Effectively, this would rid of SCTs - the STHs issued that way will have the same privacy properties of SCTs, but it will simplify the system by removing the requirement to deal with inclusion proofs, only consistency proofs (clients would still have to know how to check an inclusion proof to those intermediate STHs, but not have to fetch them). If this variant can be successfully deployed using 6962-bis, in 6962-bis-bis we could get rid of SCTs completely. [3] The web server only has to do this once for each new certificate since clients are expected to cache all STHs indefinitely. [4] That requires auditing logs asynchronously, since an attacker with persistent access could keep getting new SCTs issued, or some clients may not have fresh STHs because they missed some updates. [5] There will be a time period where a submitter serves an official STH that the client doesn=E2=80=99t yet know about because it wasn=E2=80=99t di= stributed, or received, yet. Clients could send these for reconciliation, or the submitter required to not serve it yet until it was distributed to clients. [6] In theory, a new certificate, with the inclusion proof embedded, could be issued - but it may run afoul of the restriction on issuing different certificates with the same serial number. Eran --001a1135b76473b9a10550305459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Below is a write up of the =E2=80=9CStrict CT=E2=80= =9D variant, based on Mozilla=E2=80=99s suggestion.
The goal of t= his write-up is to serve as a foundation for a document that will describe = the deployment of CT needed to operate with stronger guarantees for TLS cli= ents, as well as the protocol extensions necessary to deploy it.
= =C2=A0
Goal: Provide TLS clients with proof of inclusion t= o a tree state they already know (save clients the need to audit logs thems= elves).
=C2=A0
Overview:
  • UA ve= ndor ("auditor") periodically collects an STH (denoted "offi= cial" STH [1]) from each log, distributes it to its UAs ("clients= "). Clients are expected to cache all STHs.
  • CA/Site Owner (&qu= ot;submitter") submits (pre)certificate to the log, gets SCT [2].
    • =
  • Submitter waits until the next official STH that includes the certifica= te, gets an inclusion proof to be served alongside the certificate =C2=A0+ = SCT.
  • In the TLS handshake, clients get certificate + SCT + inclusio= n proof to an official STH they know about [5].
=C2=A0<= /div>
The purpose of the UA vendor sending down the official STH is to = provide third-party verification of the consensus.
The purpose of= the submitter bundling the STH + inclusion proof is to avoid the client ha= ving to retrieve it via some other protocol
=C2=A0
=C2= =A0
Options for dealing with the delayed usability of certificate= s:
  • Submitter waits until an inclusion proof to an =E2=80= =9Cofficial=E2=80=9D STH becomes available, only starts serving that certif= icate then (could take up to 2 x MMD - two days, typically).
    • Th= e CA could wait until the proof becomes available and only issue the final = certificate then - delay issuance by up to MMD.
    • The requester could= get the certificate immediately but only start using it once it=E2=80=99s = able to obtain an inclusion proof to an official STH [3].
  • Cert= ificate is used immediately, only with SCT: Clients accept certificates onl= y with SCTs for a limited duration; after that an inclusion proof must be a= ccompanied [4].
  • Opt-in: servers requires presence of proofs via hea= der / X.509 extension [6].
  • Certificate is used after the client can= fetch an inclusion proof and an STH the log has produced; if it=E2=80=99s = an unknown STH the client sends it to the auditor for reconciliation.
    • <= /ul>
=C2=A0
Footnotes:
=C2=A0
[1] T= he "official" STH does not have to be explicitly marked: Assuming= daily STH push cycle, a log could mint one marked STH every day, to be dis= tributed to clients. Alternatively, if STH issuance frequency (which 6962-b= is requires specifying) is not too high (e.g. hourly) then the "offici= al" STH could be the first one issued after midnight UTC (synchronizin= g on the clock).
=C2=A0
[2] An intermediate improvement= is to return, rather than just SCT, the SCT + STH issued immediately after= wards (~seconds) + inclusion proof to that STH. Effectively, this would rid= of SCTs - the STHs issued that way will have the same privacy properties o= f SCTs, but it will simplify the system by removing the requirement to deal= with inclusion proofs, only consistency proofs =C2=A0(clients would still = have to know how to check an inclusion proof to those intermediate STHs, bu= t not have to =C2=A0fetch them).
If this variant can be successfu= lly deployed using 6962-bis, in 6962-bis-bis we could get rid of SCTs compl= etely.
=C2=A0
[3] The web server only has to do this on= ce for each new certificate since clients are expected to cache all STHs in= definitely.
=C2=A0
[4] That requires auditing logs asyn= chronously, since an attacker with persistent access could keep getting new= SCTs issued, or some clients may not have fresh STHs because they missed s= ome updates.
=C2=A0
[5] There will be a time period whe= re a submitter serves an official STH that the client doesn=E2=80=99t yet k= now about because it wasn=E2=80=99t distributed, or received, yet. Clients = could send these for reconciliation, or the submitter required to not serve= it yet until it was distributed to clients.
=C2=A0
[6]= In theory, a new certificate, with the inclusion proof embedded, could be = issued - but it may run afoul of the restriction on issuing different certi= ficates with the same serial number.

Eran

--001a1135b76473b9a10550305459-- From nobody Tue May 23 06:20: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 8D740129B35 for ; Tue, 23 May 2017 06:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W99X7RU5lalC for ; Tue, 23 May 2017 06:20:04 -0700 (PDT) Received: from homiemail-a106.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 892D0129B33 for ; Tue, 23 May 2017 06:20:04 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 0A7E530002924 for ; Tue, 23 May 2017 06:20:04 -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=Jb6U/YTIvKmFJwHloDx0hMBboZk=; b= VIoUimmApbaKlv6IiMskcHX8frDmMmufys+ZmKZWaZpYYSq80fp2SuRD/3muXX6a YRi9ms0zfPNnOuqYhUuswNc5kf0nO8i0MyKeOCs7eLz1rj082jT2LYniVuF84Cxe KV76fulwatWjIPyeOtovvAAS2MxZ0e4TvHhD0Xn6YeQ= Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.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-a106.g.dreamhost.com (Postfix) with ESMTPSA id B6E5B30002925 for ; Tue, 23 May 2017 06:20:03 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id m7so14597854wmg.0 for ; Tue, 23 May 2017 06:20:03 -0700 (PDT) X-Gm-Message-State: AODbwcBT337Ru7dD8zXI0sBy9RGdaexgnBa8alRikQZrjgAgwD+4LnZV gze9fx0Nw0nRVDGf5M0S0c0ZBMr3ig== X-Received: by 10.223.136.165 with SMTP id f34mr415818wrf.134.1495545602219; Tue, 23 May 2017 06:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.164 with HTTP; Tue, 23 May 2017 06:20:01 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Tue, 23 May 2017 09:20:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eran Messeri Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11491f7a5db2fb055030d829" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 13:20:07 -0000 --001a11491f7a5db2fb055030d829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2017 at 8:42 AM, Eran Messeri wrote: > Below is a write up of the =E2=80=9CStrict CT=E2=80=9D variant, based on = Mozilla=E2=80=99s > suggestion. > The goal of this write-up is to serve as a foundation for a document that > will describe the deployment of CT needed to operate with stronger > guarantees for TLS clients, as well as the protocol extensions necessary = to > deploy it. > > *Goal*: Provide TLS clients with proof of inclusion to a tree state they > already know (save clients the need to audit logs themselves). > > *Overview*: > > - UA vendor ("auditor") periodically collects an STH (denoted > "official" STH [1]) from each log, distributes it to its UAs ("clients= "). > Clients are expected to cache all STHs. > - CA/Site Owner ("submitter") submits (pre)certificate to the log, > gets SCT [2]. > - Submitter waits until the next official STH that includes the > certificate, gets an inclusion proof to be served alongside the certif= icate > + SCT. > - In the TLS handshake, clients get certificate + SCT + inclusion > proof to an official STH they know about [5]. > > > The purpose of the UA vendor sending down the official STH is to provide > third-party verification of the consensus. > The purpose of the submitter bundling the STH + inclusion proof is to > avoid the client having to retrieve it via some other protocol > > > Options for dealing with the delayed usability of certificates: > > - Submitter waits until an inclusion proof to an =E2=80=9Cofficial=E2= =80=9D STH > becomes available, only starts serving that certificate then (could ta= ke up > to 2 x MMD - two days, typically). > - The CA could wait until the proof becomes available and only > issue the final certificate then - delay issuance by up to MMD. > - The requester could get the certificate immediately but only > start using it once it=E2=80=99s able to obtain an inclusion proof = to an official > STH [3]. > - Certificate is used immediately, only with SCT: Clients accept > certificates only with SCTs for a limited duration; after that an incl= usion > proof must be accompanied [4]. > - Opt-in: servers requires presence of proofs via header / X.509 > extension [6]. > - Certificate is used after the client can fetch an inclusion proof > and an STH the log has produced; if it=E2=80=99s an unknown STH the cl= ient sends it > to the auditor for reconciliation. > > > Footnotes: > > [1] The "official" STH does not have to be explicitly marked: Assuming > daily STH push cycle, a log could mint one marked STH every day, to be > distributed to clients. Alternatively, if STH issuance frequency (which > 6962-bis requires specifying) is not too high (e.g. hourly) then the > "official" STH could be the first one issued after midnight UTC > (synchronizing on the clock). > Note: A 'daily' cycle is a generous assumption. While this captures publication, it does not measure client update. For example, it presumes the UA is awake and listening and able to receive such an update, but in situations of mobile devices, weekend home devices, etc, this doesn't hold. > [2] An intermediate improvement is to return, rather than just SCT, the > SCT + STH issued immediately afterwards (~seconds) + inclusion proof to > that STH. Effectively, this would rid of SCTs - the STHs issued that way > will have the same privacy properties of SCTs, but it will simplify the > system by removing the requirement to deal with inclusion proofs, only > consistency proofs (clients would still have to know how to check an > inclusion proof to those intermediate STHs, but not have to fetch them). > If this variant can be successfully deployed using 6962-bis, in > 6962-bis-bis we could get rid of SCTs completely. > > [3] The web server only has to do this once for each new certificate sinc= e > clients are expected to cache all STHs indefinitely. > Was this part of Mozilla's proposal? I probably misunderstood, but this would seem to be an effective non-starter. Indefinite, unbounded caching, on billions of clients of a variety of form factors, doesn't really seem like a solution at all :) > [4] That requires auditing logs asynchronously, since an attacker with > persistent access could keep getting new SCTs issued, or some clients may > not have fresh STHs because they missed some updates. > > [5] There will be a time period where a submitter serves an official STH > that the client doesn=E2=80=99t yet know about because it wasn=E2=80=99t = distributed, or > received, yet. Clients could send these for reconciliation, or the > submitter required to not serve it yet until it was distributed to client= s. > > [6] In theory, a new certificate, with the inclusion proof embedded, coul= d > be issued - but it may run afoul of the restriction on issuing different > certificates with the same serial number. > Isn't that the whole reason 6962-bis moved to the (terrible) CMS structure? :) That CAs were concerned that precerts & certs constituted two logically distinct X.509 certificates? If that was to be introduced, it would make sense to simply return to the critical extension, since we'd have lost the main argument for using CMS :) --001a11491f7a5db2fb055030d829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 8:42 AM, Eran Messeri <eranm@google.com>= wrote:
Belo= w is a write up of the =E2=80=9CStrict CT=E2=80=9D variant, based on Mozill= a=E2=80=99s suggestion.
The goal of this write-up is to serve as = a foundation for a document that will describe the deployment of CT needed = to operate with stronger guarantees for TLS clients, as well as the protoco= l extensions necessary to deploy it.
=C2=A0
Goal= : Provide TLS clients with proof of inclusion to a tree state they already = know (save clients the need to audit logs themselves).
=C2=A0
Overview:
  • UA vendor ("auditor") p= eriodically collects an STH (denoted "official" STH [1]) from eac= h log, distributes it to its UAs ("clients"). Clients are expecte= d to cache all STHs.
  • CA/Site Owner ("submitter") submits = (pre)certificate to the log, gets SCT [2].
  • Submitter waits until th= e next official STH that includes the certificate, gets an inclusion proof = to be served alongside the certificate =C2=A0+ SCT.
  • In the TLS hand= shake, clients get certificate + SCT + inclusion proof to an official STH t= hey know about [5].
=C2=A0
The purpose of the= UA vendor sending down the official STH is to provide third-party verifica= tion of the consensus.
The purpose of the submitter bundling the = STH + inclusion proof is to avoid the client having to retrieve it via some= other protocol
=C2=A0
=C2=A0
Options for dea= ling with the delayed usability of certificates:
  • Submitte= r waits until an inclusion proof to an =E2=80=9Cofficial=E2=80=9D STH becom= es available, only starts serving that certificate then (could take up to 2= x MMD - two days, typically).
    • The CA could wait until the proo= f becomes available and only issue the final certificate then - delay issua= nce by up to MMD.
    • The requester could get the certificate immediate= ly but only start using it once it=E2=80=99s able to obtain an inclusion pr= oof to an official STH [3].
  • Certificate is used immediately, o= nly with SCT: Clients accept certificates only with SCTs for a limited dura= tion; after that an inclusion proof must be accompanied [4].
  • Opt-in= : servers requires presence of proofs via header / X.509 extension [6].
  • Certificate is used after the client can fetch an inclusion proof and = an STH the log has produced; if it=E2=80=99s an unknown STH the client send= s it to the auditor for reconciliation.
=C2=A0
Footnotes:
=C2=A0
[1] The "official" STH do= es not have to be explicitly marked: Assuming daily STH push cycle, a log c= ould mint one marked STH every day, to be distributed to clients. Alternati= vely, if STH issuance frequency (which 6962-bis requires specifying) is not= too high (e.g. hourly) then the "official" STH could be the firs= t one issued after midnight UTC (synchronizing on the clock).

Note: A 'daily' cycle is a generous = assumption. While this captures publication, it does not measure client upd= ate. For example, it presumes the UA is awake and listening and able to rec= eive such an update, but in situations of mobile devices, weekend home devi= ces, etc, this doesn't hold.
=C2=A0
[2] An intermediate improvement is to retu= rn, rather than just SCT, the SCT + STH issued immediately afterwards (~sec= onds) + inclusion proof to that STH. Effectively, this would rid of SCTs - = the STHs issued that way will have the same privacy properties of SCTs, but= it will simplify the system by removing the requirement to deal with inclu= sion proofs, only consistency proofs =C2=A0(clients would still have to kno= w how to check an inclusion proof to those intermediate STHs, but not have = to =C2=A0fetch them).
If this variant can be successfully deploye= d using 6962-bis, in 6962-bis-bis we could get rid of SCTs completely.
=C2=A0
[3] The web server only has to do this once for each= new certificate since clients are expected to cache all STHs indefinitely.=

Was this part of Mozilla's= proposal? I probably misunderstood, but this would seem to be an effective= non-starter. Indefinite, unbounded caching, on billions of clients of a va= riety of form factors, doesn't really seem like a solution at all :)
=C2=A0
[4= ] That requires auditing logs asynchronously, since an attacker with persis= tent access could keep getting new SCTs issued, or some clients may not hav= e fresh STHs because they missed some updates.
=C2=A0
[= 5] There will be a time period where a submitter serves an official STH tha= t the client doesn=E2=80=99t yet know about because it wasn=E2=80=99t distr= ibuted, or received, yet. Clients could send these for reconciliation, or t= he submitter required to not serve it yet until it was distributed to clien= ts.
=C2=A0
[6] In theory, a new certificate, with the i= nclusion proof embedded, could be issued - but it may run afoul of the rest= riction on issuing different certificates with the same serial number.

Isn't that the whole reason 696= 2-bis moved to the (terrible) CMS structure? :) That CAs were concerned tha= t precerts & certs constituted two logically distinct X.509 certificate= s? If that was to be introduced, it would make sense to simply return to th= e critical extension, since we'd have lost the main argument for using = CMS :)=C2=A0
--001a11491f7a5db2fb055030d829-- From nobody Tue May 23 06:26: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 4DCD5129B31 for ; Tue, 23 May 2017 06:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 ELlPqmaaktAa for ; Tue, 23 May 2017 06:26:03 -0700 (PDT) Received: from homiemail-a34.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 154E9129B2B for ; Tue, 23 May 2017 06:26:03 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 96112A004F14 for ; Tue, 23 May 2017 06:26:02 -0700 (PDT) Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.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-a34.g.dreamhost.com (Postfix) with ESMTPSA id 66369A004F12 for ; Tue, 23 May 2017 06:26:02 -0700 (PDT) Received: by mail-wm0-f46.google.com with SMTP id m7so14642979wmg.0 for ; Tue, 23 May 2017 06:26:02 -0700 (PDT) X-Gm-Message-State: AODbwcDYMUfhK4I5JmFUUCA5ChjgnB+uLgnluFp4x3kJUfkUsdEdLbKo +NafMjBD7bzyF6Onec456t9LYudnUA== X-Received: by 10.223.134.97 with SMTP id 30mr15876470wrw.161.1495545960933; Tue, 23 May 2017 06:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.164 with HTTP; Tue, 23 May 2017 06:26:00 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Tue, 23 May 2017 09:26:00 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eran Messeri Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1147d27abf2edf055030ed83" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 13:26:04 -0000 --001a1147d27abf2edf055030ed83 Content-Type: text/plain; charset="UTF-8" A variation of this to consider: - CAs already MUST update their OCSP responses on a 3.5 day interval (by virtue of Microsoft's program requirements), which I'm working on codifying with the Baseline Requirements since they are, effectively, a baseline that Microsoft has defined A UA could define that: - CAs MUST include the SCT and an inclusion proof from that SCT to one of the 'blessed' STHs - There is a rolling two week window of 'blessed' STHs (using whatever selection scheme appropriate) Whether this is the opt-in server basis or for all connections, this could provide a privacy-preserving proof-of-inclusion with stronger guarantees. This is built on existing 6962-bis primitives (AIUI), and simply an exercise in UA policy. Further, this does not inhibit nor substantially change the implementation story for other user agents - which could still support other forms of SCT delivery (e.g. precerts, TLS) with asynchronous inclusion proof checking. --001a1147d27abf2edf055030ed83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A variation of this to consider= :

- CA= s already MUST update their OCSP responses on a 3.5 day interval (by virtue= of Microsoft's program requirements), which I'm working on codifyi= ng with the Baseline Requirements since they are, effectively, a baseline t= hat Microsoft has defined

A UA could define that:<= /div>
- CAs MUST include the SCT and an inclusion= proof from that SCT to one of the 'blessed' STHs
- There is a rolling two week window of 'blessed= 9; STHs (using whatever selection scheme appropriate)

<= /div>
Whether this is the opt-in server basis or for all connections, t= his could provide a privacy-preserving proof-of-inclusion with stronger gua= rantees. This is built on existing 6962-bis primitives (AIUI), and simply a= n exercise in UA policy. Further, this does not inhibit nor substantially c= hange the implementation story for other user agents - which could still su= pport other forms of SCT delivery (e.g. precerts, TLS) with asynchronous in= clusion proof checking.
--001a1147d27abf2edf055030ed83-- From nobody Tue May 23 06:43: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 E216B129B31 for ; Tue, 23 May 2017 06:43:43 -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 KBNUvDUC-nJV for ; Tue, 23 May 2017 06:43:41 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001: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 F168F129AAA for ; Tue, 23 May 2017 06:43:40 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id o12so97602988iod.3 for ; Tue, 23 May 2017 06:43: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=JOcXXIZoovU25BH8TcIb76NZtPAXkZS9oW9GShqvYeE=; b=mnDX3CkrfQhp15KrThikA7RHYfjGoK21qIFGguopp7W72geHgl/aSrAT5XtUXLhIXJ 4pyYLKORfjg+3mMCiHqlVPrmdaVMA6iB6sEwGnpBbuJOPoa60Vf4klN7+CP1M5E85JuS I9DBGIrLvvv9oqiBMs2mGUma5zj735v+Y3w2sRWuZs0ltZt7clDKtxdvRgxf4xYzw3X7 BLB8NrAYq/rb+Lq2TQClEauK3PuN4M0J9MFY/qFagTNyVbOq/5UCXBnrZB0S11kzG5lV OOUOf9+bLs8B+UysZ+ESRrJykln1ptI5rr9vmmVlanwqbP1WbEWkgSC23fJYdsksXK+v 0+kA== 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=JOcXXIZoovU25BH8TcIb76NZtPAXkZS9oW9GShqvYeE=; b=PzO7TML99yiNh6/dAtLY3EhBb1KVqv6klnA4zf4GEOJ6K54y9PchuoyMcmi7waxjCt Tzm0+JPLHISP+sH01g+5ZujAJOb+P8Xz5DMB0hI3/IpK3lD/2CbtDL+4zp+mzgMyVCsh E/Ks/5umGumaK76mCpw7JOkzLwBaTsRod2OmJm7ZVd3E7a1Vu0uFwVLTAURJUvIizexr t/twsO4dTt2xrebe0vPj2me4C4sqqZTcy2pl5GhhiIGqJT39w73c+Jle3nF11OAkd3su 8XlUqPap4B/ocV80kJUYtcLYy4IVyjZ9D0EJLT0PeOabVBjHpUr2k2yloJmNk+LX+5pR 4aPw== X-Gm-Message-State: AODbwcBOt/1s9XAgVra9a4BfIhd+ftzbIRZAoXqS7udoUXQbUP1V8xwT zyCuZcmXr7ucql01509U/tfOOM3sDaZKBbo= X-Received: by 10.107.128.98 with SMTP id b95mr25817422iod.25.1495547019915; Tue, 23 May 2017 06:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Tue, 23 May 2017 06:43:09 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Tue, 23 May 2017 14:43:09 +0100 Message-ID: To: Ryan Sleevi Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a113dfdaede7b4d0550312c6b" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 13:43:44 -0000 --001a113dfdaede7b4d0550312c6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 23, 2017 at 2:20 PM, Ryan Sleevi wrote: > > > On Tue, May 23, 2017 at 8:42 AM, Eran Messeri wrote: > >> Below is a write up of the =E2=80=9CStrict CT=E2=80=9D variant, based on= Mozilla=E2=80=99s >> suggestion. >> The goal of this write-up is to serve as a foundation for a document tha= t >> will describe the deployment of CT needed to operate with stronger >> guarantees for TLS clients, as well as the protocol extensions necessary= to >> deploy it. >> >> *Goal*: Provide TLS clients with proof of inclusion to a tree state they >> already know (save clients the need to audit logs themselves). >> >> *Overview*: >> >> - UA vendor ("auditor") periodically collects an STH (denoted >> "official" STH [1]) from each log, distributes it to its UAs ("client= s"). >> Clients are expected to cache all STHs. >> - CA/Site Owner ("submitter") submits (pre)certificate to the log, >> gets SCT [2]. >> - Submitter waits until the next official STH that includes the >> certificate, gets an inclusion proof to be served alongside the certi= ficate >> + SCT. >> - In the TLS handshake, clients get certificate + SCT + inclusion >> proof to an official STH they know about [5]. >> >> >> The purpose of the UA vendor sending down the official STH is to provide >> third-party verification of the consensus. >> The purpose of the submitter bundling the STH + inclusion proof is to >> avoid the client having to retrieve it via some other protocol >> >> >> Options for dealing with the delayed usability of certificates: >> >> - Submitter waits until an inclusion proof to an =E2=80=9Cofficial=E2= =80=9D STH >> becomes available, only starts serving that certificate then (could t= ake up >> to 2 x MMD - two days, typically). >> - The CA could wait until the proof becomes available and only >> issue the final certificate then - delay issuance by up to MMD. >> - The requester could get the certificate immediately but only >> start using it once it=E2=80=99s able to obtain an inclusion proof= to an official >> STH [3]. >> - Certificate is used immediately, only with SCT: Clients accept >> certificates only with SCTs for a limited duration; after that an inc= lusion >> proof must be accompanied [4]. >> - Opt-in: servers requires presence of proofs via header / X.509 >> extension [6]. >> - Certificate is used after the client can fetch an inclusion proof >> and an STH the log has produced; if it=E2=80=99s an unknown STH the c= lient sends it >> to the auditor for reconciliation. >> >> >> Footnotes: >> >> [1] The "official" STH does not have to be explicitly marked: Assuming >> daily STH push cycle, a log could mint one marked STH every day, to be >> distributed to clients. Alternatively, if STH issuance frequency (which >> 6962-bis requires specifying) is not too high (e.g. hourly) then the >> "official" STH could be the first one issued after midnight UTC >> (synchronizing on the clock). >> > > Note: A 'daily' cycle is a generous assumption. While this captures > publication, it does not measure client update. For example, it presumes > the UA is awake and listening and able to receive such an update, but in > situations of mobile devices, weekend home devices, etc, this doesn't hol= d. > I agree, this is a major concern and I haven't yet heard a proposal how to address it. > > >> [2] An intermediate improvement is to return, rather than just SCT, the >> SCT + STH issued immediately afterwards (~seconds) + inclusion proof to >> that STH. Effectively, this would rid of SCTs - the STHs issued that way >> will have the same privacy properties of SCTs, but it will simplify the >> system by removing the requirement to deal with inclusion proofs, only >> consistency proofs (clients would still have to know how to check an >> inclusion proof to those intermediate STHs, but not have to fetch them)= . >> If this variant can be successfully deployed using 6962-bis, in >> 6962-bis-bis we could get rid of SCTs completely. >> >> [3] The web server only has to do this once for each new certificate >> since clients are expected to cache all STHs indefinitely. >> > > Was this part of Mozilla's proposal? I probably misunderstood, but this > would seem to be an effective non-starter. Indefinite, unbounded caching, > on billions of clients of a variety of form factors, doesn't really seem > like a solution at all :) > As far as I understand, it was. Old STHs can be disposed of: if for example, clients knew that the log that issued them only admits certificates that are valid for at most a year, then STHs that are more than a year older are not going to be received anymore. > > >> [4] That requires auditing logs asynchronously, since an attacker with >> persistent access could keep getting new SCTs issued, or some clients ma= y >> not have fresh STHs because they missed some updates. >> >> [5] There will be a time period where a submitter serves an official STH >> that the client doesn=E2=80=99t yet know about because it wasn=E2=80=99t= distributed, or >> received, yet. Clients could send these for reconciliation, or the >> submitter required to not serve it yet until it was distributed to clien= ts. >> >> [6] In theory, a new certificate, with the inclusion proof embedded, >> could be issued - but it may run afoul of the restriction on issuing >> different certificates with the same serial number. >> > > Isn't that the whole reason 6962-bis moved to the (terrible) CMS > structure? :) That CAs were concerned that precerts & certs constituted t= wo > logically distinct X.509 certificates? If that was to be introduced, it > would make sense to simply return to the critical extension, since we'd > have lost the main argument for using CMS :) > Yes :( I mention that as an unlikely option. I'd like to return to the critical extension too, the main concern brought against it (AFAIK) is some TLS libraries that would accept precerts as valid X.509 certificates. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a113dfdaede7b4d0550312c6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 2:20 PM, Ryan Sleevi <ryan-ietf@sleevi.com<= /a>> wrote:

On Tue, May 23, 2017 at 8:42 AM, Eran Messeri <eranm@google.com> wrote:
Below = is a write up of the =E2=80=9CStrict CT=E2=80=9D variant, based on Mozilla= =E2=80=99s suggestion.
The goal of this write-up is to serve as a= foundation for a document that will describe the deployment of CT needed t= o operate with stronger guarantees for TLS clients, as well as the protocol= extensions necessary to deploy it.
=C2=A0
Goal:= Provide TLS clients with proof of inclusion to a tree state they already k= now (save clients the need to audit logs themselves).
=C2=A0
Overview:
  • UA vendor ("auditor") pe= riodically collects an STH (denoted "official" STH [1]) from each= log, distributes it to its UAs ("clients"). Clients are expected= to cache all STHs.
  • CA/Site Owner ("submitter") submits (= pre)certificate to the log, gets SCT [2].
  • Submitter waits until the= next official STH that includes the certificate, gets an inclusion proof t= o be served alongside the certificate =C2=A0+ SCT.
  • In the TLS hands= hake, clients get certificate + SCT + inclusion proof to an official STH th= ey know about [5].
=C2=A0
The purpose of the = UA vendor sending down the official STH is to provide third-party verificat= ion of the consensus.
The purpose of the submitter bundling the S= TH + inclusion proof is to avoid the client having to retrieve it via some = other protocol
=C2=A0
=C2=A0
Options for deal= ing with the delayed usability of certificates:
  • Submitter= waits until an inclusion proof to an =E2=80=9Cofficial=E2=80=9D STH become= s available, only starts serving that certificate then (could take up to 2 = x MMD - two days, typically).
    • The CA could wait until the proof= becomes available and only issue the final certificate then - delay issuan= ce by up to MMD.
    • The requester could get the certificate immediatel= y but only start using it once it=E2=80=99s able to obtain an inclusion pro= of to an official STH [3].
  • Certificate is used immediately, on= ly with SCT: Clients accept certificates only with SCTs for a limited durat= ion; after that an inclusion proof must be accompanied [4].
  • Opt-in:= servers requires presence of proofs via header / X.509 extension [6].
    • =
  • Certificate is used after the client can fetch an inclusion proof and a= n STH the log has produced; if it=E2=80=99s an unknown STH the client sends= it to the auditor for reconciliation.
=C2=A0
Footnotes:
=C2=A0
[1] The "official" STH doe= s not have to be explicitly marked: Assuming daily STH push cycle, a log co= uld mint one marked STH every day, to be distributed to clients. Alternativ= ely, if STH issuance frequency (which 6962-bis requires specifying) is not = too high (e.g. hourly) then the "official" STH could be the first= one issued after midnight UTC (synchronizing on the clock).

Note: A 'daily' cycle is a gen= erous assumption. While this captures publication, it does not measure clie= nt update. For example, it presumes the UA is awake and listening and able = to receive such an update, but in situations of mobile devices, weekend hom= e devices, etc, this doesn't hold.
=
I agree, this is a major concern and I haven't yet heard a proposa= l how to address it.=C2=A0
=C2=A0
[2] = An intermediate improvement is to return, rather than just SCT, the SCT + S= TH issued immediately afterwards (~seconds) + inclusion proof to that STH. = Effectively, this would rid of SCTs - the STHs issued that way will have th= e same privacy properties of SCTs, but it will simplify the system by remov= ing the requirement to deal with inclusion proofs, only consistency proofs = =C2=A0(clients would still have to know how to check an inclusion proof to = those intermediate STHs, but not have to =C2=A0fetch them).
If th= is variant can be successfully deployed using 6962-bis, in 6962-bis-bis we = could get rid of SCTs completely.
=C2=A0
[3] The web se= rver only has to do this once for each new certificate since clients are ex= pected to cache all STHs indefinitely.

Was this part of Mozilla's proposal? I probably misunder= stood, but this would seem to be an effective non-starter. Indefinite, unbo= unded caching, on billions of clients of a variety of form factors, doesn&#= 39;t really seem like a solution at all :)
As far as I understand, it was. Old STHs can be disposed of: if fo= r example, clients knew that the log that issued them only admits certifica= tes that are valid for at most a year, then STHs that are more than a year = older are not going to be received anymore.
=C2=A0
[4] That requires auditing logs asynchronously, since an atta= cker with persistent access could keep getting new SCTs issued, or some cli= ents may not have fresh STHs because they missed some updates.
= =C2=A0
[5] There will be a time period where a submitter serves a= n official STH that the client doesn=E2=80=99t yet know about because it wa= sn=E2=80=99t distributed, or received, yet. Clients could send these for re= conciliation, or the submitter required to not serve it yet until it was di= stributed to clients.
=C2=A0
[6] In theory, a new certi= ficate, with the inclusion proof embedded, could be issued - but it may run= afoul of the restriction on issuing different certificates with the same s= erial number.

Isn't = that the whole reason 6962-bis moved to the (terrible) CMS structure? :) Th= at CAs were concerned that precerts & certs constituted two logically d= istinct X.509 certificates? If that was to be introduced, it would make sen= se to simply return to the critical extension, since we'd have lost the= main argument for using CMS :)=C2=A0
<= div>Yes :( I mention that as an unlikely option.
I'd like to = return to the critical extension too, the main concern brought against it (= AFAIK) is some TLS libraries that would accept precerts as valid X.509 cert= ificates.

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


--001a113dfdaede7b4d0550312c6b-- From nobody Tue May 23 06:50: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 365BE129B31 for ; Tue, 23 May 2017 06:50:26 -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 xMd9IlrOwLlZ for ; Tue, 23 May 2017 06:50:21 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B986C128DF6 for ; Tue, 23 May 2017 06:50:21 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id c15so19576064ith.0 for ; Tue, 23 May 2017 06:50:21 -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=NsATOp+D2DgopDBog2IAAoNHzS3ZUGnuTb77L6E0VtY=; b=oBOAVtgHe4V1bPcCmJtp02GGccndGOP8GGxhc32mo8h+TuI2tmodSwlkeEXZUoxr1y WoHTroGfuO9nXH45y51WA6zT6/bWKvFxOZVlhpf7/T+QddXNm+uENbVFtPsSxxP9OjlE znvfccDwpxqRhKU+GB0Mbxx0JxB36cNDg1ODSLImvBpQtV5+Xb3X+GiVjNjFqdp4B301 PFrE310bMfssM2s8XMSuEwldyOe8ScA253cE70zPrhOHY5nm+LJwsgUuJ/mi2OSdR3NQ Eb30R4VDzrAl6JaOCFQTYkkV7u9AXKk65puJKuxuqeq3IaqYlnsVjHiHZxkDJ+vSeQn+ 6tcg== 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=NsATOp+D2DgopDBog2IAAoNHzS3ZUGnuTb77L6E0VtY=; b=l3R2pP34xIwnqPirpC4ib+hmu8gUFbmmRiUQQiJ+kS5GnLrynWcytkf2+ApxFTemCG TggCOX/DtHHTR5Z9VpMfGOyzvL0hQdyqTCcKBKjIFR6aHzxscBbGhLB2qz9xxsvgjjI5 1Qc7Gg4uQHoPB5mWrL9aTRjmSE0khhda2wt8VCZcfxW2Qy002IsGGcJY7Hj76Vci+yDR MTuUjkY9S3tT854HnlAmj3Qg0IDhOW+bpBRRoCKvN4ffvafNT0MUmaTVyYesGR1Xs8Zk uaRHUrg907Dwzl1g9aYQmfm3LbgXXCX/PEs+cOvvCSBBfpGbMuuvwb4ITpsLUafg5Mbf T0EA== X-Gm-Message-State: AODbwcDbeO7pm+a7Sr6ebz79XLExES4iuRkXSRKO4bF9Lyx7jbc+lHlA 2Zz8QqBSvRJ70B36aH5eODGk/gU2jtWY X-Received: by 10.36.29.204 with SMTP id 195mr2840822itj.112.1495547420935; Tue, 23 May 2017 06:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.6 with HTTP; Tue, 23 May 2017 06:49:50 -0700 (PDT) In-Reply-To: References: From: Eran Messeri Date: Tue, 23 May 2017 14:49:50 +0100 Message-ID: To: Ryan Sleevi Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1135b764c59d0f05503144b5" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 13:50:26 -0000 --001a1135b764c59d0f05503144b5 Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 2:26 PM, Ryan Sleevi wrote: > A variation of this to consider: > > - CAs already MUST update their OCSP responses on a 3.5 day interval (by > virtue of Microsoft's program requirements), which I'm working on codifying > with the Baseline Requirements since they are, effectively, a baseline that > Microsoft has defined > > A UA could define that: > - CAs MUST include the SCT and an inclusion proof from that SCT to one of > the 'blessed' STHs > In the OCSP response, I assume? > - There is a rolling two week window of 'blessed' STHs (using whatever > selection scheme appropriate) > > Whether this is the opt-in server basis or for all connections, this could > provide a privacy-preserving proof-of-inclusion with stronger guarantees. > This is built on existing 6962-bis primitives (AIUI), and simply an > exercise in UA policy. Further, this does not inhibit nor substantially > change the implementation story for other user agents - which could still > support other forms of SCT delivery (e.g. precerts, TLS) with asynchronous > inclusion proof checking. > Seems to me like a simpler way to achieve the same requirements, and so favourable. It does depend on clients fetching OCSP responses / OCSP stapling by servers, correct? --001a1135b764c59d0f05503144b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 2:26 PM, Ryan Sleevi <ryan-ietf@sleevi.com<= /a>> wrote:
A variation of this to consider:

- CAs already MUST up= date their OCSP responses on a 3.5 day interval (by virtue of Microsoft'= ;s program requirements), which I'm working on codifying with the Basel= ine Requirements since they are, effectively, a baseline that Microsoft has= defined
A UA could define that:
- CAs MUST include the SCT and an inclusion proof from tha= t SCT to one of the 'blessed' STHs
In the OCSP response, I assume?=C2=A0

Seems to me like a simpler way to achieve the same requi= rements, and so favourable. It does depend on clients fetching OCSP respons= es / OCSP stapling by servers, correct?
--001a1135b764c59d0f05503144b5-- From nobody Tue May 23 07:32: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 43509129B53 for ; Tue, 23 May 2017 07:32:07 -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 t94M1lAcVFNT for ; Tue, 23 May 2017 07:32:06 -0700 (PDT) Received: from homiemail-a106.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 E9F34126DFF for ; Tue, 23 May 2017 07:32:05 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 6B13630002925 for ; Tue, 23 May 2017 07:32:05 -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=pE5tLs7XAJygn1VT/A8cI91m37U=; b= JR1VmrX4S8/kBCVzPZeQQcTQUh6aZaNDHClnk6R4zCsLnqJmMs9q2D/+Frl4SIsf mz3CML1zInz2qnwbM3t58dngyUMviYYdpSb9B93DBaOcL8b/3KN7TaXA7a7iBRq4 MTgnOsPEVlsnJx5KPn24uW+rrtacMU2czBxET215ueE= Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.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-a106.g.dreamhost.com (Postfix) with ESMTPSA id 4529A30002924 for ; Tue, 23 May 2017 07:32:05 -0700 (PDT) Received: by mail-wm0-f42.google.com with SMTP id b84so27186312wmh.0 for ; Tue, 23 May 2017 07:32:05 -0700 (PDT) X-Gm-Message-State: AODbwcCTT/fCmHgtMGnEIQYZtbhDdC8DkeJsdtLcpBr1Hf3z5WElUta+ qVLLsnOuFMXjI4hpNyBjoqWCX6PV9w== X-Received: by 10.223.136.165 with SMTP id f34mr655134wrf.134.1495549923816; Tue, 23 May 2017 07:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.164 with HTTP; Tue, 23 May 2017 07:32:03 -0700 (PDT) In-Reply-To: References: From: Ryan Sleevi Date: Tue, 23 May 2017 10:32:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eran Messeri Cc: Ryan Sleevi , "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a11491f7af4045b055031d976" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 23 May 2017 14:32:07 -0000 --001a11491f7af4045b055031d976 Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 9:49 AM, Eran Messeri wrote: > > > On Tue, May 23, 2017 at 2:26 PM, Ryan Sleevi wrote: > >> A variation of this to consider: >> >> - CAs already MUST update their OCSP responses on a 3.5 day interval (by >> virtue of Microsoft's program requirements), which I'm working on codifying >> with the Baseline Requirements since they are, effectively, a baseline that >> Microsoft has defined >> >> A UA could define that: >> - CAs MUST include the SCT and an inclusion proof from that SCT to one of >> the 'blessed' STHs >> > In the OCSP response, I assume? > Yes, apologies :) > - There is a rolling two week window of 'blessed' STHs (using whatever >> selection scheme appropriate) >> >> Whether this is the opt-in server basis or for all connections, this >> could provide a privacy-preserving proof-of-inclusion with stronger >> guarantees. This is built on existing 6962-bis primitives (AIUI), and >> simply an exercise in UA policy. Further, this does not inhibit nor >> substantially change the implementation story for other user agents - which >> could still support other forms of SCT delivery (e.g. precerts, TLS) with >> asynchronous inclusion proof checking. >> > Seems to me like a simpler way to achieve the same requirements, and so > favourable. It does depend on clients fetching OCSP responses / OCSP > stapling by servers, correct? > Right. It leverages the existing update infrastructure for OCSP responses on stapling-supporting servers (or potentially in clients), and externalizes the cost of tracking the 'blessed' STH onto the CA, rather than to the millions of site operators. This keeps relative consistency with the original design of CT, which was to find the points in the Web PKI ecosystem most flexible to change (CAs) and deploying the robust fixes there. This certainly increases the friction to change - servers supporting robust OCSP stapling becomes a potential necessity - but it allows UAs to make those tradeoffs using the appropriate building blocks, based on their (or the site's) risk profile. This makes it even more of a preventative measure, at greater cost, but some UAs may feel that tradeoff is appropriate. --001a11491f7af4045b055031d976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 23, 2017 at 9:49 AM, Eran Messeri <eranm@google.com>= wrote:


On Tu= e, May 23, 2017 at 2:26 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
A variation of this to consider:

- CAs already MUST update their= OCSP responses on a 3.5 day interval (by virtue of Microsoft's program= requirements), which I'm working on codifying with the Baseline Requir= ements since they are, effectively, a baseline that Microsoft has defined

A UA could define that:
- CAs MUST include the SCT and an inclusion proof from that SCT to one= of the 'blessed' STHs
In= the OCSP response, I assume?=C2=A0

Yes, apologies :)
=C2=A0
=
- There is a rol= ling two week window of 'blessed' STHs (using whatever selection sc= heme appropriate)

Whether this is the opt-in= server basis or for all connections, this could provide a privacy-preservi= ng proof-of-inclusion with stronger guarantees. This is built on existing 6= 962-bis primitives (AIUI), and simply an exercise in UA policy. Further, th= is does not inhibit nor substantially change the implementation story for o= ther user agents - which could still support other forms of SCT delivery (e= .g. precerts, TLS) with asynchronous inclusion proof checking.
<= /div>
Seems to me like a simpler way to achieve the sam= e requirements, and so favourable. It does depend on clients fetching OCSP = responses / OCSP stapling by servers, correct?

Right. It leverages= the existing update infrastructure for OCSP responses on stapling-supporti= ng servers (or potentially in clients), and externalizes the cost of tracki= ng the 'blessed' STH onto the CA, rather than to the millions of si= te operators. This keeps relative consistency with the original design of C= T, which was to find the points in the Web PKI ecosystem most flexible to c= hange (CAs) and deploying the robust fixes there.

This certainly increases the fr= iction to change - servers supporting robust OCSP stapling becomes a potent= ial necessity - but it allows UAs to make those tradeoffs using the appropr= iate building blocks, based on their (or the site's) risk profile. This= makes it even more of a preventative measure, at greater cost, but some UA= s may feel that tradeoff is appropriate.
--001a11491f7af4045b055031d976-- From nobody Wed May 24 11:43: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 80AA3126DC2 for ; Wed, 24 May 2017 11:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, 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 hL7k05gtqFcK for ; Wed, 24 May 2017 11:42:57 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 7B7921201F2 for ; Wed, 24 May 2017 11:42:57 -0700 (PDT) Received: (qmail 12867 invoked by uid 1004); 24 May 2017 18:42:54 -0000 Received: from rmdccgwarp2.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.83) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 24 May 2017 19:42:54 +0100 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 201705241942524573; Wed, 24 May 2017 19:42:52 +0100 To: Eran Messeri , Richard Barnes Cc: "trans@ietf.org" , Brian Smith References: From: Rob Stradling Message-ID: <9547a2b2-f33f-eb86-b207-9ec1972ce34c@comodo.com> Date: Wed, 24 May 2017 19:42:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Drop RSA PKCS#1 1.5 signatures; maybe replace with RSA PSS 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, 24 May 2017 18:43:02 -0000 On 22/05/17 11:14, Eran Messeri wrote: > +1 for switching to RSA PSS. > I don't have any insight into why RSA was originally in 6962, so can't > argue strongly in favour of keeping it. I think RSA PKCS#1 v1.5 was permitted by RFC6962 simply because the authors believed (and were proven correct) that some log operators might not be able to use ECDSA. I'm in favour of dropping RSA PKCS#1 v1.5 from 6962-bis. In 2017, it's not unreasonable to expect all log operators to be able to use ECDSA. I'm _not_ in favour of adding RSA PSS, for the reasons Brian mentioned... "RSA signatures in general are difficult for some devices to process due to their large size. It would be frustrating to have used a pure ECC infrastructure with no RSA involved at all, only to need to implement RSA for the purpose of verifying signatures from logs." ...and because I'm pretty sure that, today, ECDSA is supported more widely (by deployed OSes and crypto toolkits) than RSA PSS. > On Fri, May 12, 2017 at 8:18 PM, Richard Barnes > wrote: > > +1 > > > On Fri, May 12, 2017 at 2:51 PM, Brian Smith > wrote: > > Hi, > > PKCS#1 1.5 signatures are obsolete. New specifications should not > mandate support for them. > > RSA signatures in general are difficult for some devices to process > due to their large size. It would be frustrating to have used a pure > ECC infrastructure with no RSA involved at all, only to need to > implement RSA for the purpose of verifying signatures from logs. > Thus > I think the group should consider dropping any mention of RSA > signatures from section 10.4.so that log > clients do not have to > implement RSA. > > If it really is important to have RSA signatures, then RSA PSS > should > be used instead. In particular, it would be good to require the same > restricted form specified for TLS, where the same digest algorithm > must be used for all parts of the signature. Note that RSA PSS > can be > made deterministic by using a fixed salt, and most > implementations of > RSA PSS seem to support fixed salts if the salt length is set to > zero. > As mentioned in the RSA PSS specification, PSS signatures are more > secure than PKCS#1 1.5 signatures even with a zero-length salt. > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ > 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 > > > > > > _______________________________________________ > 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 Wed May 24 12:33: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 649D61293F5 for ; Wed, 24 May 2017 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 qjm6mYlvUnoC for ; Wed, 24 May 2017 12:33:50 -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 E3C3F12422F for ; Wed, 24 May 2017 12:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1495654429; bh=1BeHlC7yB7j/pnCOZbBLgRs/EvtTjYouZ8gi9N9uogY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=OA//EfTDRK0/DjdosSWT7mObt+GKNnzNRbBaIn2QoNz/w4jybmwUZ4cHp86cf8mh1 mlSRe7Bicm36qrYMv5Ts2co3UMbOJDQ0STFH+81Ek6i6UoFJXlgLinFnzKo99GNqw/ 1bYU1QehSGkIA8VkJlYqOJwGnfWRYAcogp2dHNYCx+ILmUGvlOBxnvcd7VzrFj3UI7 EoK2y0eZGgPJ6YE2Nwkegj4JtQcacq7k+0PFU+ckkvZZGgrWotNEPZyuYryFIVJlKf eiGkt1kp5U+DSJwC85jUlswG8EjTXHTU33nvuFMP97YgnBnqzx2ePlw5MGDd7vbHBn mljjHeA6Xo8KA== Date: Wed, 24 May 2017 12:33:47 -0700 From: Andrew Ayer To: Linus Nordberg Cc: Eran Messeri , "trans@ietf.org" Message-Id: <20170524123347.a149b03ded187d3188906713@andrewayer.name> In-Reply-To: <871srhvunx.fsf@nordberg.se> References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 24 May 2017 19:33:51 -0000 On Mon, 22 May 2017 16:21:54 +0200 Linus Nordberg wrote: > Hi, > > It should be clear by now that I'd be sad if 6962bis would allow logs to > return a different stream of bytes for the same ingoing parameters, for > SCTs and STHs, but more interesting would be to hear other wg members > views on the balance we're trying to strike. I would also be sad - particularly in the case of STHs. I may be willing to give up mandatory consistent SCT signatures, since privacy with SCTs might be a lost cause anyways, and because it's hard for logs to ensure consistent SCT signatures without using deterministic signatures (due to the need to issue SCTs from many different frontends). However, it doesn't seem hard for logs to have consistent STH signatures. > Regarding current deployment, are there any 6269bis logs deployed yet? I don't know of any. However, it may be interesting to note that of the 31 publicly-known RFC6962 logs[1], all but two (Clicky and Behind the Sofa) return the same signature for repeated get-sth requests, which suggests that this is not a difficult requirement for STHs. The two logs which return a new signature for each get-sth request are running Trillian. It would be interesting to hear from the Trillian developers why Trillian behaves this way and whether it would be difficult to persist STH signatures as other implementations do. > Regarding correctness vs. completeness, what in -24 is incorrect with > this regard? > > Regarding added cost of implementation, using RSA is an option. > > Regarding gossip unclearity, the suggested change risks making it harder > to get STH gossip going. Agreed. We may never know how necessary consistent STH signatures are if attempts to experiment with STH gossip are stillborn due to privacy concerns. It would make more sense to start out with a strong requirement, and loosen it later if it turns out to be unnecessary. Regards, Andrew [1] https://sslmate.com/labs/ct_ecosystem/ecosystem.html From nobody Wed May 24 12:34: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 16E3B129435 for ; Wed, 24 May 2017 12:34:38 -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 AJIVrqKqdwl2 for ; Wed, 24 May 2017 12:34:36 -0700 (PDT) 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 E55121270AC for ; Wed, 24 May 2017 12:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1495654476; bh=ResJ6oiWo3Di8kjBQjH9icbmUQ+/aZ6JpFBsHFlnQIs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=kCfzvH3WObICWh3xRiIH3aWoZoNeMN1BcwZiUPYzUiW/PEqBRPFutqi5G1mRMHLKS 9pgWyv73T2Y1XVYJBvYGOHLi8eQxo0nmSO1JQbwCONFdsiS/8cvwV3Zc55GBkgHaZY OAZaykYVTnFgKAqRKRWntsZSumm/xpirOKp/C9QeCEMA3yHPxcQR5mAqmA+trq98t0 CsHkPKF0EWtUiAvOb9nAjTIkfypzqvG96OvsafhTbdTUejuZQZFBQZ8XvhbIJlTNvZ 8FdZ4GIyPumYWdlpwvk+oYx9loWbISMxX8ki5LPxBnH/ySck4EwaO3iCtxh38KT44M 585amCRtJ5IDg== Date: Wed, 24 May 2017 12:34:35 -0700 From: Andrew Ayer To: Ryan Sleevi Cc: Eran Messeri , "trans@ietf.org" Message-Id: <20170524123435.7f2d84779947938eebc63b27@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] Write-up of the "Strict CT" variant 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, 24 May 2017 19:34:38 -0000 On Tue, 23 May 2017 09:26:00 -0400 Ryan Sleevi wrote: > A variation of this to consider: > > - CAs already MUST update their OCSP responses on a 3.5 day interval (by > virtue of Microsoft's program requirements), which I'm working on codifying > with the Baseline Requirements since they are, effectively, a baseline that > Microsoft has defined > > A UA could define that: > - CAs MUST include the SCT and an inclusion proof from that SCT to one of > the 'blessed' STHs > - There is a rolling two week window of 'blessed' STHs (using whatever > selection scheme appropriate) > > Whether this is the opt-in server basis or for all connections, this could > provide a privacy-preserving proof-of-inclusion with stronger guarantees. > This is built on existing 6962-bis primitives (AIUI), and simply an > exercise in UA policy. Further, this does not inhibit nor substantially > change the implementation story for other user agents - which could still > support other forms of SCT delivery (e.g. precerts, TLS) with asynchronous > inclusion proof checking. I really like this idea. Note that RFC6962-bis needs one additional primitive to make this work: the get-sths endpoint. Otherwise there is no robust way to gather the blessed STHs for distribution to clients - one could always be missed if you are relying on calling get-sth repeatedly. This is why I think the get-sths endpoint is important. Regards, Andrew From nobody Wed May 24 12:41: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 316F7126C23 for ; Wed, 24 May 2017 12:41:12 -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 SAwDtI1m1hRd for ; Wed, 24 May 2017 12:41:11 -0700 (PDT) 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 235601270FC for ; Wed, 24 May 2017 12:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1495654870; bh=cmjyo+EatRmgE5QfFclH7o+tpdTlM5PvDvVTCK330p0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=bK2yGFYYa3Gv92KzD7auW9oNIeSMapwiYTRwACJlTZG7q1Ungtcykbzbq+iMjbXb7 L/ocG+2jxWdsIVscrWJdECqxMGRopSmDmfkd+RZvaHtF7cEkzdUyRNJZ6YODv4ab+A 6/Q8dws3AKPlrmIxe/4mTyXrVoIccZgedlb97HIIlKehQwsVjAx3Y00E1A+41e4py/ uyDoHIo3VN4EHCM7Jot50trYv3OmOPP2QgjtYyy09X/lijdU6E0V+1y+/KKes0+wLc WmnlLpKbZZfpy69wOvA8hvOf1QMjHBxfVRnE5rPhqLDNjHFNnwasxx63+EXz3ctHCY kNEfysRjZU5dA== Date: Wed, 24 May 2017 12:41:09 -0700 From: Andrew Ayer To: Eran Messeri Cc: Ryan Sleevi , "trans@ietf.org" Message-Id: <20170524124109.52359e9ed92cdb5cf4be5833@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] Write-up of the "Strict CT" variant 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, 24 May 2017 19:41:12 -0000 On Tue, 23 May 2017 14:43:09 +0100 Eran Messeri wrote: > >> [6] In theory, a new certificate, with the inclusion proof embedded, > >> could be issued - but it may run afoul of the restriction on issuing > >> different certificates with the same serial number. > >> > > > > Isn't that the whole reason 6962-bis moved to the (terrible) CMS > > structure? :) That CAs were concerned that precerts & certs constituted two > > logically distinct X.509 certificates? If that was to be introduced, it > > would make sense to simply return to the critical extension, since we'd > > have lost the main argument for using CMS :) > > > Yes :( I mention that as an unlikely option. > I'd like to return to the critical extension too, the main concern brought > against it (AFAIK) is some TLS libraries that would accept precerts as > valid X.509 certificates. Is that such a bad thing? RFC6962 and RFC6962-bis are both quite clear that a pre-certificate is a binding commitment by the CA to issue the final certificate, and that misissuance of a pre-certificate is equivalent to misissuance of the final certificate. So what's the difference between a client accepting a pre-certificate and a client accepting the final certificate which the CA is bound to issue anyways? The only difference I see is that one has embedded CT information and the other doesn't. The pre-certificate is not inherently untrustworthy. CT would be simpler and more flexible if it didn't have pre-certificates, and instead CAs were permitted to re-issue certificates with duplicate serial numbers as long as the only change was the addition/modification of the Transparency Information extension. I suggest keeping this in mind for RFC6962-bis-bis. Regards, Andrew From map@kth.se Thu May 25 04:01: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 B3B0A12945E for ; Thu, 25 May 2017 04:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 9kkr30B-mCld for ; Thu, 25 May 2017 04:01:07 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) (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 BB44B129434 for ; Thu, 25 May 2017 04:01:07 -0700 (PDT) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 5612D3A8D; Thu, 25 May 2017 13:01:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7Fo5aoCm7jIH; Thu, 25 May 2017 13:01:04 +0200 (CEST) Received: from [IPv6:::1] (s17.lan.kth.se [IPv6:2001:6b0:1:1d20:214:c2ff:fe3a:5eec]) by smtp-3.sys.kth.se (Postfix) with ESMTPS id CDC143A8B; Thu, 25 May 2017 13:01:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Magnus Ahltorp In-Reply-To: Date: Thu, 25 May 2017 13:01:03 +0200 Cc: "trans@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3FECD8A3-4B3E-471D-9F2D-3524A87694B6@kth.se> References: To: Eran Messeri X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 25 May 2017 11:02:36 -0000 > 23 May 2017 14:42 Eran Messeri wrote: >=20 > *Overview*: >=20 > - UA vendor ("auditor") periodically collects an STH (denoted = "official" > STH [1]) from each log, distributes it to its UAs ("clients"). = Clients are > expected to cache all STHs. > - CA/Site Owner ("submitter") submits (pre)certificate to the log, = gets > SCT [2]. > - Submitter waits until the next official STH that includes the > certificate, gets an inclusion proof to be served alongside the = certificate > + SCT. > - In the TLS handshake, clients get certificate + SCT + inclusion = proof > to an official STH they know about [5]. >=20 >=20 > The purpose of the UA vendor sending down the official STH is to = provide > third-party verification of the consensus. > The purpose of the submitter bundling the STH + inclusion proof is to = avoid > the client having to retrieve it via some other protocol I may have misunderstood something, but why would the STH not always be = included with the inclusion proof? What is the reason for all this extra = complexity (UA vendor distributing the STH, inclusion proof not = self-contained)? /Magnus From nobody Thu May 25 07: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 46250129AD7 for ; Thu, 25 May 2017 07:46:14 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo0EJIw0DRoO for ; Thu, 25 May 2017 07:46:13 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAF71294F7 for ; Thu, 25 May 2017 07:46:12 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id k74so179073416qke.1 for ; Thu, 25 May 2017 07:46:12 -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; bh=1MPP0XnhGtHSA34KZCp9ILRE2A0osry4QNdd38waf9E=; b=h4AfEYiptDqSRPnE9xKRtXAta7Npry/ROdcwotai2HL0CG77Tx+ZttzZNThJXHNCKI ysoBOlVcSW3iot7VLb8kvy0E7V7h+fAPGKkQUWnxB6RhqP9ZawLjgBCH1e3Y/eR3rtGQ DtqmEgAbbcZT6287oK7yYSurQB1pmK42U5OiI= 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=1MPP0XnhGtHSA34KZCp9ILRE2A0osry4QNdd38waf9E=; b=uII3MEhXUyhHAg6DhzPcSM8k823lqpQFwGzXKx501a2b/4oOwCkyCJ4HsNiHda2Jne 7144yH9nRdMUFxc/Fhc6vKaIj2jozrgUYo/thHBfWVrQWqKjU1e9WItDjbZeGZC8ln4k BdabtoaG9YQNPERv5CUepSdvgqXz1WQRZONDc/QOl4/N7g1qBfgFMnZ/AaAj28o1GfUn n8ucMBLZFn34SgJLXd6Ug/R79UWn/xGnbN9ffFKVFDCfTydoyDEjCPMPPG/FyHqpyFjX BP18+dCQbOVNlIMiQRKjSwZ3XkoLkHKCLHcLKrhunvvPjNbG849lyK9uXHqtlcat2q7e XPeA== X-Gm-Message-State: AODbwcAYWu4ZfxiFRxFNmXFqzDXAZjsT9MXwqf9PQsgwGtWq9f3yM6kF ysoAX6ovyYNTUPfqwGEBbzqT4WDi9mP3 X-Received: by 10.233.216.194 with SMTP id u185mr38843563qkf.105.1495723571973; Thu, 25 May 2017 07:46:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.101.148 with HTTP; Thu, 25 May 2017 07:45:51 -0700 (PDT) In-Reply-To: <3FECD8A3-4B3E-471D-9F2D-3524A87694B6@kth.se> References: <3FECD8A3-4B3E-471D-9F2D-3524A87694B6@kth.se> From: Tom Ritter Date: Thu, 25 May 2017 09:45:51 -0500 Message-ID: To: Magnus Ahltorp Cc: Eran Messeri , "trans@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Trans] Write-up of the "Strict CT" variant 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, 25 May 2017 14:46:14 -0000 On 25 May 2017 at 06:01, Magnus Ahltorp wrote: > > I may have misunderstood something, but why would the STH not always be included with the inclusion proof? What is the reason for all this extra complexity (UA vendor distributing the STH, inclusion proof not self-contained)? The inclusion proof does contain the STH. But we don't trust it. It might represent a split view of the log. There's no way to know without comparing our view of the log with other people's. By having the UA vendor provide it's view of the log (or rather, a specific subset of it in the form of specific STHs), we can confirm that this STH we got is in the known set of STHs the UA vendor got. Our view is the same as theirs. And since theirs is the same sent to every browser client, we can be pretty sure that we and everyone - who uses this browser at least - has the same view of the log and we are not being presented a split view. -tom From nobody Thu May 25 08:29: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 16B841294C8 for ; Thu, 25 May 2017 08:29:53 -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 E1twt4rIh8xB for ; Thu, 25 May 2017 08:29:51 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 067CF127873 for ; Thu, 25 May 2017 08:29:50 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id e193so170571729pfh.0 for ; Thu, 25 May 2017 08:29: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=74yzqQvDnBSFnMXJMIZr7XKxed/nddMz60I7bNnDjcs=; b=g4WUHj33vLtKt6oNbtl89C2fjB5PXo5ArIEskr1BjNsLjwUEnZjlEItJiOlJN7mKOz Je8Jquwq68+Y3rBHyLsD4HLVMGCPrcx8lbtJlCdTJ6YesYlBdEJlPNDtBazbzmySYaGA /TBatkOFegZmSJSLHiIrMGXkmIiscbHETp9UIDkbePezJugRLhbAu9r8/bBTw3LGgAwi ek39D6g19bTPZklYmTpWNUw6U+oaLke26LkGgUxs333NtDF2Zu71TQXpB+S9uFyITvJO SC1zeTUWkN1pOxvDiDOw7uEqnDT3hLWlnBn4eEaHOa48cTRfe7tgU7MyxMF6iFi5E2GL tSSw== 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=74yzqQvDnBSFnMXJMIZr7XKxed/nddMz60I7bNnDjcs=; b=K+oEoXCU4j7oTtf7YLwYbO5RGBmSSSGodg9qDCqEp9UhIAhtGVzv+79pOcYrjeSKqT DbP+2yq2j7iZTDMBUCIdyD1PA4mXeTL8E5iAVztccqzgCLCyEXixdfrXDZMZ/1xre6lm aqt9DlB5/lNeWLnCHhJzg1rSLo9E+0sYTb2vQhA76swMc41PwKV3F56NVpGsWTsLBGso ORoyJbQ+4rGpL8lBQSOTyScPZTE8sL7brkSHEmrq8T173EbsxNL28OxaoKyfHcwamy4o QhHFQ7mfXrtXSEBJBY+CkHf25/ZmRSD22Gg5kViQE8BfZ8OPbiaIukwL/8XNmzuCCukt +c4w== X-Gm-Message-State: AODbwcApVps0tf3Sgx3n9YxRhe7hLU1i8sKu9coqEukWhwjr8KZl5pVi nZEKG6nTwu9E1iemZlB2Q9iZy8JYSHjy X-Received: by 10.84.173.195 with SMTP id p61mr51246632plb.83.1495726190368; Thu, 25 May 2017 08:29:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.170.133 with HTTP; Thu, 25 May 2017 08:29:49 -0700 (PDT) In-Reply-To: <20170524123347.a149b03ded187d3188906713@andrewayer.name> References: <87pofiif6g.fsf@nordberg.se> <87inl25r8l.fsf@nordberg.se> <871srhvunx.fsf@nordberg.se> <20170524123347.a149b03ded187d3188906713@andrewayer.name> From: Al Cutter Date: Thu, 25 May 2017 16:29:49 +0100 Message-ID: To: Andrew Ayer Cc: Linus Nordberg , Eran Messeri , "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11959c42aae805505ae434" Archived-At: Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad 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, 25 May 2017 15:29:53 -0000 --94eb2c11959c42aae805505ae434 Content-Type: text/plain; charset="UTF-8" On 24 May 2017 8:33 pm, "Andrew Ayer" wrote: On Mon, 22 May 2017 16:21:54 +0200 Linus Nordberg wrote: > Hi, > > It should be clear by now that I'd be sad if 6962bis would allow logs to > return a different stream of bytes for the same ingoing parameters, for > SCTs and STHs, but more interesting would be to hear other wg members > views on the balance we're trying to strike. I would also be sad - particularly in the case of STHs. I may be willing to give up mandatory consistent SCT signatures, since privacy with SCTs might be a lost cause anyways, and because it's hard for logs to ensure consistent SCT signatures without using deterministic signatures (due to the need to issue SCTs from many different frontends). However, it doesn't seem hard for logs to have consistent STH signatures. > Regarding current deployment, are there any 6269bis logs deployed yet? I don't know of any. However, it may be interesting to note that of the 31 publicly-known RFC6962 logs[1], all but two (Clicky and Behind the Sofa) return the same signature for repeated get-sth requests, which suggests that this is not a difficult requirement for STHs. The two logs which return a new signature for each get-sth request are running Trillian. It would be interesting to hear from the Trillian developers why Trillian behaves this way and whether it would be difficult to persist STH signatures as other implementations do. The short answer is because we've not built any support for doing that yet :) The slightly longer answer is that Trillian is a General Transparency implementation, rather than a CT implementation, and there are some divisions of responsibility in there: - Trillian maintains the trees of opaque blobs, updating them with batches of new entries, and creates Trillian Tree Heads (signed with Trillian tenant keys) for each update. - Then there's a CT 'personality' layer in front which uses Trillian APIs to build a CT log, and that, currently, has no distributed state, so each instance of this personality creates a CT STH from the data in the latest Trillian Tree Head, and signs that with the CT log's key. The CT personality layer could certainly be extended to somehow select and "bless" STHs in some fashion. This idea of logging STHs would also provide a nice mechanism for doing that, as it happens :) > Regarding correctness vs. completeness, what in -24 is incorrect with > this regard? > > Regarding added cost of implementation, using RSA is an option. > > Regarding gossip unclearity, the suggested change risks making it harder > to get STH gossip going. Agreed. We may never know how necessary consistent STH signatures are if attempts to experiment with STH gossip are stillborn due to privacy concerns. It would make more sense to start out with a strong requirement, and loosen it later if it turns out to be unnecessary. Regards, Andrew [1] https://sslmate.com/labs/ct_ecosystem/ecosystem.html _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --94eb2c11959c42aae805505ae434 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On 24 May 2017 8:33 pm, "Andrew Ayer" = <agwa@andreway= er.name> wrote:
On Mon, 22 May 2017 16:21:54 +0200
Linus Nordberg <linu= s@sunet.se> wrote:

> Hi,
>
> It should be clear by now that I'd be sad if 6962bis would allow l= ogs to
> return a different stream of bytes for the same ingoing parameters, fo= r
> SCTs and STHs, but more interesting would be to hear other wg members<= br> > views on the balance we're trying to strike.

I would also be sad - particularly in the case of STHs.=C2=A0 I may b= e
willing to give up mandatory consistent SCT signatures, since
privacy with SCTs might be a lost cause anyways, and because it's
hard for logs to ensure consistent SCT signatures without using
deterministic signatures (due to the need to issue SCTs from many
different frontends).=C2=A0 However, it doesn't seem hard for logs to h= ave
consistent STH signatures.

> Regarding current deployment, are there any 6269bis logs deployed yet?=

I don't know of any.=C2=A0 However, it may be interesting to note= that of
the 31 publicly-known RFC6962 logs[1], all but two (Clicky and Behind
the Sofa) return the same signature for repeated get-sth requests, which suggests that this is not a difficult requirement for STHs.=C2=A0 The two logs which return a new signature for each get-sth request are running
Trillian. It would be interesting to hear from the Trillian developers
why Trillian behaves this way and whether it would be difficult to
persist STH signatures as other implementations do.
<= /div>

The short answer is because we&= #39;ve not built any support for doing that yet :)
<= br>
The slightly longer answer is that Trillian is a General Tran= sparency implementation, rather than a CT implementation, and there are som= e divisions of responsibility in there:
=C2=A0 - Trillian maintai= ns the trees of opaque blobs, updating them with batches of new entries, an= d creates Trillian Tree Heads (signed with Trillian tenant keys) for each u= pdate.
=C2=A0- Then there's a CT 'personalit= y' layer in front which uses Trillian APIs to build a CT log, and that,= currently, has no distributed state, so each instance of this personality = creates a CT STH from the data in the latest Trillian Tree Head, and signs = that with the CT log's key.

T= he CT personality layer could certainly be extended to somehow select and &= quot;bless" STHs in some fashion.=C2=A0 This idea of logging STHs woul= d also provide a nice mechanism for doing that, as it happens :)


> Regarding correctness vs. completeness, what in -24 is incorrect with<= br> > this regard?
>
> Regarding added cost of implementation, using RSA is an option.
>
> Regarding gossip unclearity, the suggested change risks making it hard= er
> to get STH gossip going.

Agreed.=C2=A0 We may never know how necessary consistent STH signatur= es are
if attempts to experiment with STH gossip are stillborn due to privacy
concerns.=C2=A0 It would make more sense to start out with a strong
requirement, and loosen it later if it turns out to be unnecessary.

Regards,
Andrew

[1] https://sslmate.com/labs/ct_ecosystem/e= cosystem.html

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

--94eb2c11959c42aae805505ae434-- From nobody Fri May 26 18:59: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 B2C1E129BE0 for ; Fri, 26 May 2017 18:59: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, 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 nQuBmGkyL7hE for ; Fri, 26 May 2017 18:59:37 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 73870129B44 for ; Fri, 26 May 2017 18:59:37 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id n23so24508741pfb.2 for ; Fri, 26 May 2017 18:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=w2OPLV6mWq1EorFwP5zD8ta04L9Y9ZxUSUg8WSkKRA4=; b=d5jgT2PzWtUwiVn7oSW+LhAeaBHebxEMwqYB8N6pWRZcOKF8feS54CAQqOwiV09UZ0 n6emqRot4EHikezyFN5XP8hw8x0ZfDoKifq1s1Vtoe8KWTCX8ozyiCxFVHQUq4SP9VCi JVwibBSXB6FLG3RtxuL6FsfLUsWhLrF/FtZPSFmN6z+aYF2tWrgpZ8DKHrfSKCv3UPVn Uvl8vOkxd8jnjUD0T80H+xUwKgzv2fsATDQnsXamNv0XUBc3ko/aLo8Ip1+AZ77bKQfL XdLj0npAcdBqkQXpPAzSZu4OZPGdiEo/z+kD3Lc6j25OZjYx26ed7pWTUWctxr9icmxr Pc/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=w2OPLV6mWq1EorFwP5zD8ta04L9Y9ZxUSUg8WSkKRA4=; b=Ijx8nabSD4BhNSfsejRZiFjMDSMkNOMDYQUX4j2RJwNnYMqzGyVAFV0QwSSHn+qIhL QPyqZvBUw6/h2JMqT4H58w5wV0E24kzNTKSitZd/dhzIFpgV7qq2+3AxsMy+iilMBw9h wINg7CRfp9/V/84R485rfqMAMQWzYnUPfo/AjSbwqh/Lc00LiACRZYYDMzPmHg+wOFy1 uPAGcY9axdMK1k6CfbyUcKc9P9IbdgpyJbNGOv9XR5b94oNtqAKGViNiagPFzbWbgba7 ki6Mvhnf9E+BrTbLkyIL1gSxsPa5htwhCJmVk4rmYpIUUpL2o76bXezu/uVL39ckYSNT cXMQ== X-Gm-Message-State: AODbwcAx++WjcJZ8b6UAAYRSNccCsTCAuJoJxvnNPuPsIZMJmgeZUHT5 7r8WwubH212bR4Gq X-Received: by 10.99.3.16 with SMTP id 16mr6077059pgd.159.1495850376661; Fri, 26 May 2017 18:59:36 -0700 (PDT) Received: from Melindas-Mac-mini.local (216-67-88-210-radius.dynamic.acsalaska.net. [216.67.88.210]) by smtp.gmail.com with ESMTPSA id o76sm5330146pfi.119.2017.05.26.18.59.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 18:59:35 -0700 (PDT) References: To: trans@ietf.org From: Melinda Shore X-Forwarded-Message-Id: Message-ID: <7fc9dbc4-f7f2-c270-e7d3-c124a48e0b67@gmail.com> Date: Fri, 26 May 2017 17:59:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nSJ9JaWV3dMceJBVUceOpcUCicOaUMQjg" Archived-At: Subject: [Trans] Fwd: Side meetings experiment at IETF 99 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, 27 May 2017 01:59:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nSJ9JaWV3dMceJBVUceOpcUCicOaUMQjg Content-Type: multipart/mixed; boundary="5VBjtgcwgdxtxoQTamxkwD6wslbH357dP"; protected-headers="v1" From: Melinda Shore To: trans@ietf.org Message-ID: <7fc9dbc4-f7f2-c270-e7d3-c124a48e0b67@gmail.com> Subject: Fwd: Side meetings experiment at IETF 99 References: In-Reply-To: --5VBjtgcwgdxtxoQTamxkwD6wslbH357dP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI for the upcoming meeting. Melinda -------- Forwarded Message -------- Subject: Side meetings experiment at IETF 99 Date: Fri, 26 May 2017 16:24:32 -0400 From: Suresh Krishnan To: IETF Discussion CC: IESG Hi all, The IESG has discussed how to improve the path for potential new topics to be discussed transparently in the IETF community. For some cross-area topics, it is quite useful to have active conversation among a group of people to work on defining the potential work and how it interacts with existing efforts. As the IETF week is quite busy, it can be a challenge to arrange these side-meetings to avoid conflicts. To facilitate the scheduling of these conversational side-meetings, the IESG has decided to provide a meeting room at IETF 99 in Prague for around 30 people, with a U-shaped table, that will be available for first-come first-served (FCFS) signup online as soon as the final IETF meeting agenda is published. This experiment will be conducted for IETF 99 in Prague and will replace AD approval for rooms for side-meetings for potential new topics. Proponents of potential new topics are reminded that the BoF deadline is June 2; this includes non-WG forming BoFs. The on-site signup FCFS room (seats about 16) will continue to be available at IETF 99. Thanks Suresh (on behalf of the IESG) --5VBjtgcwgdxtxoQTamxkwD6wslbH357dP-- --nSJ9JaWV3dMceJBVUceOpcUCicOaUMQjg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZKN2GAAoJELiGRpM6HoEubPIP/3wSnMTb55ob+ZvdJCFs3zsd Gvm5SRLkJcu5CfNbDKEqYka6ZWPvjhxKfV72A/H54UG5ZAqymVpfGKd3gp893l3g yLqqFerVuUK4Lr6dG0p42Dty/O5fq+leg/GIyixBFsQGVkqdkB5M/oetj/1zfZCQ H5zHkiJxRjFlFdzSGMuFh/kvBqhPZoNvm6NqRXyPL9j4p3B7S1QR0K7UtVZ4QbZ6 xuQjeMOv16gKLLoGyUyTHXkNgsSAMUwqDX25QkdTXDZzXU1hy9tHnINBTtiq9P3R XAPzJki5/KOaQZbYpoo9L7b0aYBGFLfDyh1lHXwSZIH1Wl2sHqTB9P0dTuKRL51p y/OmS4J+9tixBwZp5JfJImp1jsCjtO4DZ5XG2cXJlXnJA19vv5p4YGmaBfLnYfPB rQ+upxdIXntYdu2rwu5u3sRU2JR97U14NG2Du6mrwG1zFOXS+zAfv92J+54e592M jEodcre/y0JPnFypDWIrkreUNlrUtXYPrC8qnBaHmYa4r/fnjTPMa/6T9I2L2N5m b2ALkARg5Q9hVayRZfgRD6Gi49WgYPGoUgn2nUFerJZCzdvEhwWDoM4toqY+CRWs tk+nA4/uzJC54Y5TrSYA2So9DCJvcvfZ3bty/F5JNkvHpU298tNEgG7IzN/cP2CM 6Gf0bBkTHB42HR5c5h/R =klc2 -----END PGP SIGNATURE----- --nSJ9JaWV3dMceJBVUceOpcUCicOaUMQjg-- From nobody Sun May 28 04:09: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 C3DEB128CD5 for ; Sun, 28 May 2017 04:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_20=-0.001, MISSING_HEADERS=1.021, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rW5Fqsn0_w8; Sun, 28 May 2017 04:09:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0871242F5; Sun, 28 May 2017 04:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Sun, 28 May 2017 11:09:21 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/181#comment:9 Message-ID: <037.976c220f50b8cb1cd1d38457a4247801@ietf.org> References: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <022.03abd9c04b8c06be35fbc83cf6689bdc@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 11:09:23 -0000 #181: Consolidate "Add Chain" and "Add PreCertChain" endpoints -------------------------+----------------------- Reporter: rlb@… | Owner: eranm@… Type: defect | Status: reopened Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Changes (by eranm@…): * milestone: => review Comment: Please review the solution Rob has implemented in https://github.com/google/certificate-transparency-rfcs/pull/262. This was supported on the list by: * Linus Nordberg https://www.ietf.org/mail- archive/web/trans/current/msg02972.html * Richard Barnes: https://www.ietf.org/mail- archive/web/trans/current/msg02974.html (and I support it too, obviously) -- Ticket URL: Public Notary Transparency Wiki My example project From nobody Sun May 28 19:10: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 587AD127419 for ; Sun, 28 May 2017 19:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gxAE-vYUg-KQ for ; Sun, 28 May 2017 19:10:31 -0700 (PDT) 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 E9014127078 for ; Sun, 28 May 2017 19:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1496023830; bh=iWp43rtHfNvUhL/YfUSUHOwLq4jm1SUrNqmMqIU/QZ0=; h=Date:From:To:Subject; b=ZTWBGn4FuSVM5WkRXbmmyEfQ9wq7tdDJulT9BleiLsyyzgiuDHDqEgYYQ36rUO4ci 91y9FVpCarBPht0dwG+weqvFuLqOWbH+hjklgmP42xOrawn6x4CL3gX76mYa44DeQw 7xQ9e0yFnZm/Mer1hFrFz2TwQtMkZLdZNeYJk1/s00bzSjd4bO+mFAQ6HY+W+SgJ/c JJer7uN4mZqKIvcnC5c9NhKkjJZa3RSNO/1DIsZqKUa6rXACwW3ptvUCDzQS3386p3 ZTpsI5rbNr6j9OkgJcFEG2Qzc6hpVV21KQb77TPmewxO7cc88THfS60NM4mx8tG0p9 gCyfuKpzh4Vuw== Date: Sun, 28 May 2017 19:10:28 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20170528191028.20f285073eea33a3f23b6b5a@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Mutability of Certificate Signatures 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, 29 May 2017 02:10:32 -0000 In RFC6962-bis, the input to the Merkle Tree leaf hash includes the TBSCertificate and the hash of the issuer key. The certificate signature is not included in the leaf hash. Consequentially, it is possible for a log to alter or remove the signature without violating the append-only property of the log. The tree's root hash would remain the same, and the log could still produce valid inclusion proofs for the corresponding SCT. This enables the following attack: if a misissued certificate is included in a log, an attacker could compromise or collude with the log operator to alter or remove the certificate's signature. Then the log no longer contains cryptographic proof that the CA misissued the certificate. The CA indicated by issuer_key_hash could plausibly claim that it didn't issue the certificate. Meanwhile, the log operator could claim the invalid signature came from a submitter, and blame its presence on a bug in the log's certificate acceptance code, something which has already happened with two RFC6962 logs and was not considered sufficiently bad by Chrome to warrant distrust[1]. Note that this problem also exists in RFC6962 with pre-certificates, but not with certificates as the Merkle Tree leaf hash includes the full certificate. This could be fixed without changing the protocol by adding language that says that if a log cannot produce a full (pre-)certificate with a valid signature that matches the TBSCertificate and issuer_key_hash in the Merkle Tree leaf, then it must be considered misbehavior equivalent to violating the append-only property. However, it seems unfortunate that we can't simply rely on the Merkle Tree to ensure the immutability of crucial data - that is the whole point of a Merkle Tree, after all. Auditors would need to perform an additional, complicated step. Furthermore, if a log has a legitimate bug that causes certificates with invalid signatures to be accepted by accident, the log would have to be distrusted. Unfortunately, we can't simply include a whole pre-certificate in the Merkle Tree leaf hash, as it is impossible to reconstruct from the final certificate. (We could put the pre-certificate signature in an extension in the final certificate, but that seems undesirable.) Any thoughts? Since this is a correctness issue, I think it needs a resolution before RFC6962-bis is finalized. Regards, Andrew [1] https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/Itoq0YUZTlA From nobody Mon May 29 04: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 4D8C31294EC for ; Mon, 29 May 2017 04:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2moP8Y1nYQTb; Mon, 29 May 2017 04:35:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ED8129407; Mon, 29 May 2017 04:35:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 1.0.10 Precedence: bulk Cc: trans@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 1.0.10, by Edgewall Software X-Trac-Project: Public Notary Transparency Wiki Date: Mon, 29 May 2017 11:35:41 -0000 X-URL: X-Trac-Ticket-URL: https://trac.ietf.org/trac/trans/ticket/189#comment:1 Message-ID: <051.fed6a0c4b0aeaff36d2fb1fbf9fe27e9@ietf.org> References: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <036.0d5f9d9469341d54f42d6a36bef19485@ietf.org> Archived-At: Subject: Re: [Trans] [Public Notary Transparency Wiki] #189: Permit logs to use EdDSA X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 11:35:42 -0000 #189: Permit logs to use EdDSA -----------------------------+--------------------------------------------- Reporter: rob.stradling@… | Owner: draft-ietf-trans-rfc6962-bis@… Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -----------------------------+--------------------------------------------- Comment (by eranm@…): From what I understand (consulting with a few Google engineers who actually know crypto), EdDSA is supported in BoringSSL and there's no reason not to support it in 6962-bis. -- Ticket URL: Public Notary Transparency Wiki My example project