From nobody Mon Jun 2 09:09:09 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2A1A0254 for ; Mon, 2 Jun 2014 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0om0oR-ZoRP for ; Mon, 2 Jun 2014 09:09:04 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2851A0141 for ; Mon, 2 Jun 2014 09:09:04 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id10so5363650vcb.13 for ; Mon, 02 Jun 2014 09:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pZ6dsrU9gHT7JfJ9E1ecXR+ryoLtvVOfN5EnTsU8Z0Q=; b=e6gTVzKocpIPUZfQIaspnYbs2EKzkPyU9F1eA1nyhNiU2GlWTIZ5Np2CU8BR1VMpWB KkMcSKw8LT5nUWuwTTR99MrM8hnjUkory1fkQeKtNGeY+WzwHe9+BLA8aRp3GDgOrgJ6 +7bwCA8sdQk7HuB8J5vZlY1ZBaIN1zyTb+JsLhjYmPhevu1rD0UOyMUWI5Tw6IZW9bFv Imy3wgs/vMsuhw0/Y8GPIQKxdKHKBPlvN4KIQA4DBjkbXQhBy+h6Ghhmk5hC9D17BnDR yLTTLMWGsrk0hd2IFs4MBtXdFNz9jlFfilyfTXfCBoiyiyiM9onK32D5jSzJl/dDrTAR k74A== MIME-Version: 1.0 X-Received: by 10.58.186.207 with SMTP id fm15mr31481790vec.4.1401725337913; Mon, 02 Jun 2014 09:08:57 -0700 (PDT) Received: by 10.52.245.40 with HTTP; Mon, 2 Jun 2014 09:08:57 -0700 (PDT) Date: Mon, 2 Jun 2014 18:08:57 +0200 Message-ID: From: Erwann Abalea To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=047d7b67594cd6d02a04fadc9ceb Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ufuyhwHqSPkqkqiUiq43WbEoQiY Subject: [Trans] Relaxed X.509 validation rules X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:09:07 -0000 --047d7b67594cd6d02a04fadc9ceb Content-Type: text/plain; charset=UTF-8 Bonjour, For security reasons, our online CAs have a critical BC extension with pathLenConstraint set to 0. For security+compliance reasons (RFC5280/X.509), our CA system doesn't allow for duplicate serial numbers under a CA, so we're going to issue a "Precertificate Signing Certificate" under our different issuing CAs for precertificate generation. Of course, a compliant X.509 third party MUST fail to validate the precertificate (because of the pathLenConstraint=0 issuing something that acts as a CA without being declared as is). How will this case be handled by log servers? RFC6962 in section 3.1 states that "the log may relax standard validation rules to allow this, so long as the issued certificate will be valid", without any detail on relaxed rules. Will it be mandatory to re-issue pathLenConstraint=1 CA certificates and relax our security rules? -- Erwann. --047d7b67594cd6d02a04fadc9ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Bonjour,

For security reasons, our onli= ne CAs have a critical BC extension with pathLenConstraint set to 0.

<= div>For security+compliance reasons (RFC5280/X.509), our CA system doesn= 9;t allow for duplicate serial numbers under a CA, so we're going to is= sue a "Precertificate Signing Certificate" under our different is= suing CAs for precertificate generation.

Of course, a compliant X.509 third party MUST fail to v= alidate the precertificate (because of the pathLenConstraint=3D0 issuing so= mething that acts as a CA without being declared as is).

How will this case be handled by log servers? RFC6962 in section 3.1 s= tates that "the log may relax standard validation rules to allow this,= so long as the issued certificate will be valid", without any detail = on relaxed rules.

Will it be mandatory to re-issue pathLenConstraint=3D1 = CA certificates and relax our security rules?

--
Erwa= nn.

--047d7b67594cd6d02a04fadc9ceb-- From nobody Mon Jun 2 09:57:27 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BA1A023A for ; Mon, 2 Jun 2014 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfHgmHw4YFLQ for ; Mon, 2 Jun 2014 09:57:25 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D75211A024F for ; Mon, 2 Jun 2014 09:57:25 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 9161D200B9993 for ; Mon, 2 Jun 2014 09:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=j+2E4QuQb/iY8u1a/Kyn+zDDplw=; b=KkzsVew5CdR a5Gx3/k0/u/Ld6pbYRiC5Y/s/ZDIh1UsoQwO1hF6vKHjBTw1INr/tGg19E9rqyBc gmMtUrhT2T+vEYvGtCpipSr8MNlOPWB0Qr6PpwmeNP5mfLDHAwOSAITgznG5HlQm VJuzcOzjaU2LM42a46dTeXWluRxMq46E= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 40C45200B9990 for ; Mon, 2 Jun 2014 09:57:20 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so5571055wes.0 for ; Mon, 02 Jun 2014 09:57:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr23781816wic.5.1401728239055; Mon, 02 Jun 2014 09:57:19 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 2 Jun 2014 09:57:19 -0700 (PDT) Date: Mon, 2 Jun 2014 11:57:19 -0500 Message-ID: From: Nico Williams To: Dmitry Belyavsky Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wQ9a2VmIkCb7E6vCWGCpkrHboE4 Cc: Melinda Shore , "trans@ietf.org" Subject: [Trans] Log checking should be asynchronous (Re: Volunteer opportunity! (was Re: DNSSEC also needs CT)) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:57:27 -0000 On Tue, May 13, 2014 at 3:41 AM, Dmitry Belyavsky wrote: > Here are my ideas about "strict" behaviour of the TLS client: > > [...] IMO log checking should be mostly asynchronous. This means that CT couldn't detect MITMing CAs in real-time, but that's OK because CT is about CA reputation, and all we care about is that when we detect lying CAs we can report them. This means that clients mostly should only reject TLS connections when there's no evidence of server certs being logged in an acceptable log. It also means we need some mechanism for reporting lying CAs. Thus far reporting via blogs, news outlets, and trust anchor set managers, has been good enough, and I'm not sure that we need anything more than any async notification to users (and upstreams) by browsers (and other clients). There are privacy protection considerations in reporting lying CAs: report the name about which they lied, just the log entry(ies) that are missing, or just an assertion that they lied? Again, as I see it CT is purely a reputation-based system. Reputation is established (and blemished/destroyed) asynchronously. This is important: we cannot be adding too much latency to TLS. By doing log checking asynchronously we won't be. Nico -- From nobody Mon Jun 2 10:12:13 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D701A01ED for ; Mon, 2 Jun 2014 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5xP-r3fNkLS for ; Mon, 2 Jun 2014 10:12:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F6B1A007B for ; Mon, 2 Jun 2014 10:12:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51199 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WrVmE-000P4I-T5; Mon, 02 Jun 2014 13:12:03 -0400 Message-ID: <538CB061.5070403@bbn.com> Date: Mon, 02 Jun 2014 13:12:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/749VOEx3bo1wFfucL2akBo98GE8 Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:12:11 -0000 PHB, ... >> is that really more "serve" than an ability to issue a credential >> for ANY name, as in the Web PKI? > At least that is a temporary condition. If CT is successful, yes. > Any trust infrastructure that ultimately rests on the common sense of > the US Congress and President is doomed in the long run. And there > isn't a better political solution on offer either. common sense an the U.S. Congress, that's an uncommon pairing :-). > Finding a technical mechanism that reduces the dependence on the > political/policy dimension makes it much easier to address that layer. > If it is possible it is always far easier to eliminate a single point > of failure than to work out policy level controls to prevent abuse. agreed. > ... > If they already have a PKI then they are probably not interested in > DNSSEC at all because that problem is already solved and DNSSEC is the > red herring. agreed, unless someone convinces them that the shiny new DNSSEC approach to PKI is better, ... > Unless that is there is an interesting way to use DNSSEC as an > extension of the enterprise PKI. In which case it is critical that the > DNSSEC PKI does not introduce a new point of failure. agreed, That's a very confusing last phrase. > DNSSEC is still raw technology. Saying that it does not need feature X > before the full set of potential applications is premature. We don't > know what it is useful for yet. That is what we should find out. Thanks for the clarification. >> I understand their concerns. But the lack of a well-articulated architecture >> for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether >> this is a good idea. > I find that looking at an additional field of application is often a > very good way to improve an underspecified architecture. I guess so, but I'd really prefer a fully-specified architecture for what purports to be the motivating case, before we claim its a good basis for solving other problems. I think the potential DNSSEC mis-issuance problems are different enough to merit a separate analysis and design proposal. > Trans is rather too closely designed to solve one problem and it is > not even clear that it does that particularly well. There is a lot of > fuzziness in the process by which a relying party decides that a > particular value is the true Merkle tree apex of a particular log. I agree. Steve From nobody Mon Jun 2 10:20:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39A21A0253 for ; Mon, 2 Jun 2014 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By_v8VSy6K6n for ; Mon, 2 Jun 2014 10:20:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EC21A01ED for ; Mon, 2 Jun 2014 10:20:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36785 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WrVuD-000PHc-8j for trans@ietf.org; Mon, 02 Jun 2014 13:20:17 -0400 Message-ID: <538CB250.6080201@bbn.com> Date: Mon, 02 Jun 2014 13:20:16 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: trans@ietf.org References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> <537E467C.7010405@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dFBFyhdgm_QrmIQPvu9LJsRUoAA Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:20:24 -0000 Nico, > On Thu, May 22, 2014 at 1:48 PM, Stephen Kent wrote: >>>> That's a very confusing last phrase. >>> I had no problem reading it. >>> >> a literal reading of it is as sarcasm. If that's PHB's intent, fine, but >> I just wanted to verify that there was no typo. > I saw no sarcasm in it. I was just confused, as I said. PHB's reply was helpful. > >>> In other words, your concern is about CT in general, not DNSSEC in >>> particular. Sounds like a separable issue to me. But if CT makes sense then >>> it makes sense for DNSSEC. >>> >> yes, my complaint about a lack of a doc describing CT architecture is not >> specific to the CT for DNSSEC discussion. > We agree. OK. > >> CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC. > I take it you concede that lack of name constraints isn't the only > reason to want CT. agreed. > I'll concede that CT for DNSSEC might not be a good idea. Did I ever > say it is? I started the discussion with an inference: CT is for > PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss. I thought you did. I think CT for the Web PKI needs is missing an arch doc, and absent that doc it's now clear how good CT is for that case. This I consider it premature to suggest CT for DNSSEC si an obvious next step, as some have suggested. > >> Until we have a doc that describes the architecture, we can't evaluate how >> good >> it is in either context. > We have a doc; it's missing important things. I agree. But I think > we can have some of this discussion given what we know now. Indeed, > we've been having this discussion, and important things have come up > (privacy protection, spam). The experimental RFC does not provide a comprehensive problem statement, a clear description of all of the elements of a proposed solution, an explicit discussion of all of the assumptions that appear to underlie the design, i.e., what must happen for CT achieve its goals, and an analysis of what happens if some (implicit) assumptions are not satisfied. I'm going to develop what I see as the missing arch doc, to elicit feedback from the WG and the RFC authors. The WG can decide whether this is necessary, but I believe the exercise will, in any case, be useful. Steve From nobody Mon Jun 2 13:47:59 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BC51A0459 for ; Mon, 2 Jun 2014 13:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWDyv78MbWnA for ; Mon, 2 Jun 2014 13:47:53 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5151A0448 for ; Mon, 2 Jun 2014 13:47:53 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id um1so4592032pbc.32 for ; Mon, 02 Jun 2014 13:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=TQvBPej2MzuQG5c2joL/g/JeW4CDyuUGSQxdYHgOzGs=; b=KMa8kO28XuoOG3UB5q82EO7eX8z88Olc+T3PRbQRG+0fUP8pEjsmlZzRk2UvVNEa4j 9pzSl5++7nyGSUENwxxm/vglXjOo3dH/ssd97T6S5yU27kQqSxNKaFfTQ9sfbEPZ0A4X P2UhJ4MOMVF6mEaX1WPc2Yc25O2hgectMuotSZF57TsdJn04FTI0HR8qUj6311n0Nj1h cY3fmJER/SQmuSmkWNPiVzTIs6/4JYjrqr61wZ+pkC32l/xQB1MrfcrXRHd2gbNr/Y32 OsdcaXrS4mTOJA7LPf5lqHHuu1nx/zfdaJJKK04S1tEhXrNNrw0n2mlqwlPBdc0+Pd8k yjtQ== X-Received: by 10.66.226.172 with SMTP id rt12mr43494471pac.101.1401742067891; Mon, 02 Jun 2014 13:47:47 -0700 (PDT) Received: from spandex.local (209-112-137-188-rb2.fai.dsl.dynamic.acsalaska.net. [209.112.137.188]) by mx.google.com with ESMTPSA id om6sm21958941pbc.43.2014.06.02.13.47.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 13:47:47 -0700 (PDT) Message-ID: <538CE2F1.8020905@gmail.com> Date: Mon, 02 Jun 2014 12:47:45 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ITEQMhc4f-x8iJfpbYX0a9H39GA Subject: [Trans] Starting to think about IETF 90 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:47:56 -0000 With IETF 90 lurching into view many of you are starting to think about how to get time on the agenda in Toronto. This is a reminder that the purpose of meetings is face-to-face discussion of issues that haven't been able to make progress on the mailing list, and to progress deliverables. The IETF is somewhat different from other standards bodies in that meeting time is generally not used for presentation of new material, and that the work of the organization is primarily done via working group mailing lists. The most reliable way to get time on a meeting agenda is to have a lively discussion on the mailing list prior to the meeting. So, if you've got a document that you're trying to progress, now's a very good time to post to the mailing list with a pointer to the document, a quick summary of what you're trying to do, and what you think the open issues are or areas that need discussion. Thanks! Melinda & Paul From nobody Mon Jun 2 16:15:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1414A1A00C9 for ; Mon, 2 Jun 2014 16:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCr8CQSL7i0s for ; Mon, 2 Jun 2014 16:14:57 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5361A00AF for ; Mon, 2 Jun 2014 16:14:57 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 9B016202022 for ; Mon, 2 Jun 2014 16:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xveepVevWQ5fIDkXpd8G B6DB2fk=; b=aD/HFQ5A7hPkf3ZJWsbzIFR7rKIELCjb6KA1DX7HWlq1UOW3i4Hx S+45/y32hs83aKbYK+lU9eh1HHjx1kijVkLO2pm+oQdR68Fqy3IG81sd65nUZ6jk 3LQRqEuG1ZEklVJdNfze8tT1g1QqduIDa33a7fNMzQ8OVOyqZTsch8k= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 48BCB202018 for ; Mon, 2 Jun 2014 16:14:51 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so5787047wgh.4 for ; Mon, 02 Jun 2014 16:14:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.12.135 with SMTP id y7mr26714882wib.39.1401750890056; Mon, 02 Jun 2014 16:14:50 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 2 Jun 2014 16:14:49 -0700 (PDT) In-Reply-To: <538CB250.6080201@bbn.com> References: <537E3229.4070402@bbn.com> <537E3E17.8000901@bbn.com> <537E467C.7010405@bbn.com> <538CB250.6080201@bbn.com> Date: Mon, 2 Jun 2014 18:14:49 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FQrceY32OQ3Oknuh5gbC68gIhUI Cc: "trans@ietf.org" Subject: Re: [Trans] DNSSEC also needs CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 23:14:58 -0000 On Mon, Jun 2, 2014 at 12:20 PM, Stephen Kent wrote: >> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent wrote: >> I take it you concede that lack of name constraints isn't the only >> reason to want CT. > > agreed. > >> I'll concede that CT for DNSSEC might not be a good idea. Did I ever >> say it is? I started the discussion with an inference: CT is for >> PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss. > > I thought you did. I think CT for the Web PKI needs is missing an arch > doc, and absent that doc it's now clear how good CT is for that case. > This I consider it premature to suggest CT for DNSSEC si an obvious next > step, > as some have suggested. I posted today providing my take as to one aspect of the CT architecture: http://www.ietf.org/mail-archive/web/trans/current/msg00315.html As I've understood it CT is partly about CA reputation. As such CA failures [to not MITM] should be handled asynchronously. I think this is an important consideration because it speaks to when the client (and domain owners, and auditors) should do the hard work of checking the CT logs. > The experimental RFC does not provide a comprehensive problem statement, > a clear description of all of the elements of a proposed solution, an > explicit discussion of all of the assumptions that appear to underlie the > design, i.e., what must happen for CT achieve its goals, and an > analysis of what happens if some (implicit) assumptions are not satisfied. > > I'm going to develop what I see as the missing arch doc, to elicit feedback > from > the WG and the RFC authors. The WG can decide whether this is necessary, but > I > believe the exercise will, in any case, be useful. I agree that CT is missing this. That doesn't (and shouldn't) keep one from asking if CT is applicable to DNSSEC, and if so what that might look like. Hand-waving a bit, if a) CT is a keep-CAs-honest mechanism in addition to enabling domain owners to find out about erroneous certificate issuance for their domains, b) CT applies to PKI in general (not just PKI as in RFC5280), and c) DNSSEC is a PKI, then d) it's a fair inference that CT ought to apply to DNSSEC. The three conditions seem to be true. It's not a fair inference that CT ought to be applied to DNSSEC, of course. Even if CT can be applied to DNSSEC and even if it is desirable to do so for many, there are still possibly strong arguments to make against it. For example, domain owners might object to yet another "tax" on them: there's domain registrar fees, CA fees, and now log fees paid indirectly. And then auditing costs (probably outsourced). I'm sympathetic to such an argument. Add to that a proper the benefit side of a proper cost/benefit analysis... For the TLS PKI case the benefit is: - mitigates the lack of name constraints - detects MITMing CAs For DNSSEC the only benefit is the MITM detection one. Assuming that detections will be of a) errors by registrars, and b) political/legal actions that we can't do much more about than detect... is this enough value to justify the additional costs? This is a value judgement to be made by the market. Nico -- From nobody Tue Jun 3 04:36:21 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0101A01C4 for ; Tue, 3 Jun 2014 04:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVzXuhUX2mtp for ; Tue, 3 Jun 2014 04:36:17 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091711A0190 for ; Tue, 3 Jun 2014 04:36:16 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id 29so4944216yhl.37 for ; Tue, 03 Jun 2014 04:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w9MPxzGEyqKAtvT5fjd08PXV0WMYsFsU7Xyri/3ArXo=; b=b7T4yIZsOcYhBbonEPxrxPLKRT147FGd4VA2ZVtHBH34y0k5uQol1RRrpSObn/U7nM Diwwa1x1EaYnMjxYxTMOu0q46ZohVoX7KqH0gSt6+qmKmtajEqpO7zcjg5Rw2GA+puXm xk82BauOPkljGsVcd1vIfkjgRsd5/dARdA73hmeqr7gXgeMFxwrD+V18GfBrWQ1ouhko ehFsXjoYLO3dhPaEcCAUjBfphzSaEq07V/5czQPK0A+rPgQ+ercPV+VydeGaHKcXOCd9 PR8gFB8pKQOBxPinsFJt3aM7BbkruFT/SBkd4M+Bbrayy1yy3TAF1oHiCsUatBmAXv0u 0FdA== MIME-Version: 1.0 X-Received: by 10.236.46.5 with SMTP id q5mr61410431yhb.21.1401795370983; Tue, 03 Jun 2014 04:36:10 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 3 Jun 2014 04:36:10 -0700 (PDT) In-Reply-To: <538CE2F1.8020905@gmail.com> References: <538CE2F1.8020905@gmail.com> Date: Tue, 3 Jun 2014 15:36:10 +0400 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=047d7b5d839122a75e04faeceb98 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/N3UgvbbfZTroMpyasd1xtqm9U2Y Cc: "trans@ietf.org" Subject: Re: [Trans] Starting to think about IETF 90 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:36:19 -0000 --047d7b5d839122a75e04faeceb98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Melinda, On Tue, Jun 3, 2014 at 12:47 AM, Melinda Shore wrote: > > So, if you've got a document that you're trying to progress, > now's a very good time to post to the mailing list with a > pointer to the document, a quick summary of what you're > trying to do, and what you think the open issues are or > areas that need discussion. > Unfortunately, I will not be present in Toronto. So I think there are the following problems that are the subject to solve for putting the CT into real world. 1. The behaviour of CT-supporting clients is underspecified. There are a lot of corner cases that should be a subject for clarification. I have sent the draft of my vision mixed with mostly Ben=E2=80=99s answers about the cl= ient behaviour to the Trans list some time ago. As there is no objections or agreements, I think that my suggestions should be either ignored and replaced by a specification written from scratch or adopted as a part of RFC after discussion. Also the absence of the gossip protocol description disturbs me too. 2. There is a lack of understanding of infrastructure which is necessary for the deployment of CT. If we get a hundred of logs, it is not better than a hundred of CAs we have now. If we found a misbehaviour of log or of a CA, it should be reported to - where? As far as I understand, this is out of scope for IETF, but who will establish the rules here? The adoption of the CT to operate together with DNSSec seems to be a separate topic and I think, there should be a separate document covering it= . Thank you! --=20 SY, Dmitry Belyavsky --047d7b5d839122a75e04faeceb98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Melinda,

On Tue, Jun 3, 2014 at 12:47 AM, Melinda Shore <m= elinda.shore@gmail.com> wrote:

So, if you've got a document that you're trying to progress,
now's a very good time to post to the mailing list with a
pointer to the document, a quick summary of what you're
trying to do, and what you think the open issues are or
areas that need discussion.

=C2=A0

Unfortunately,= I will not be present in Toronto.=C2=A0

So= I think there are the following problems that are the subject to solve for= putting the CT into real world.

1. The behaviour of CT-supporting clients is underspecified. There are = a lot of corner cases that should be a subject for clarification. I have se= nt the draft of my vision mixed with mostly Ben=E2=80=99s answers about the= client behaviour to the Trans list some time ago. As there is no objection= s or agreements, I think that my suggestions should be either ignored and r= eplaced by a specification written from scratch or adopted as a part of RFC= after discussion.
Also the absence of the gossip protocol description disturbs me too.
2. There is a lack of understanding of infrastructure which is necessary f= or the deployment of CT. If we get a hundred of logs, it is not better than= a hundred of CAs we have now. If we found a misbehaviour of log or of a CA= , it should be reported to - where? As far as I understand, this is out of = scope for IETF, but who will establish the rules here?

The adoption of the CT to operate together with DNSSec seems to be a se= parate topic and I think, there should be a separate document covering it.<= br>

Thank you!

--
SY, Dmitry Belyavsky

--047d7b5d839122a75e04faeceb98-- From nobody Tue Jun 3 11:14:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5861A0241 for ; Tue, 3 Jun 2014 11:13: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkMbQNmvr2NX for ; Tue, 3 Jun 2014 11:13:55 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686091A027F for ; Tue, 3 Jun 2014 11:13:54 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id v10so5018122pde.9 for ; Tue, 03 Jun 2014 11:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G814hv6A0Zha4tCLtiGLUq6uazM6t3m2/9/Z5a5Vmqw=; b=b5PP4WbpV0WIEwpIzGZMDXNibAqkza7+so7ywtgoAIFw0lzhyInQvY8iBH7+U++Sv4 sDqglFNu0RuoStSfoC62rS2uCJPiiIWc4w2HvBogYPGdyQ1rbXkz7EVckoMtF1yPNnzl 5EgmJsaDXn0KEl0iX/t0YqD0b2j/uVn0pt3Jc5zO7B4KGoqU0qv9T+UvKwVRvXIO3aou v1wNSUfDoV3ZOC1eEy4kgE2AlkYEaC2ECV7CBozLWAArhJH+5dG0qb/8BRcA1W0PUtSk 0/XkqQoMp3Ho+T2TpaTfhSEr9ZV3Vjan4oyUB8AsqXyI3qnsCyBiYrK9q6wftEuyhnLk mcUw== X-Received: by 10.68.215.3 with SMTP id oe3mr52708836pbc.109.1401819228626; Tue, 03 Jun 2014 11:13:48 -0700 (PDT) Received: from spandex.local (63-140-85-79.nwc.dsl.dynamic.acsalaska.net. [63.140.85.79]) by mx.google.com with ESMTPSA id og3sm30667395pbc.48.2014.06.03.11.13.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 11:13:48 -0700 (PDT) Message-ID: <538E1059.6030907@gmail.com> Date: Tue, 03 Jun 2014 10:13:45 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dmitry Belyavsky References: <538CE2F1.8020905@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cy2az2A-jhsl6Oggt4tI_8WMops Cc: "trans@ietf.org" Subject: Re: [Trans] Starting to think about IETF 90 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:13:57 -0000 On 6/3/14 3:36 AM, Dmitry Belyavsky wrote: > The adoption of the CT to operate together with DNSSec seems to be a > separate topic and I think, there should be a separate document covering it. The best way to make that happen is to write one yourself - that will start a discussion. Writing an internet draft should not be seen as a big deal - they are by their nature not mature documents, and it's fine to put something out there that's very rough around the edges. We have requested Meetecho support for remote participants. Melinda From nobody Tue Jun 3 12:43:33 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9831A0332 for ; Tue, 3 Jun 2014 12:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZRSPqHNGvu6 for ; Tue, 3 Jun 2014 12:43:31 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7181A0309 for ; Tue, 3 Jun 2014 12:43:30 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 10so5325867ykt.29 for ; Tue, 03 Jun 2014 12:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=66vipOOHtLP5KQ6TE/G4QUadw/yJZdBVo485kcxd/Fs=; b=sbvO6ClxtE0sxjPnixCc8cJrWNh0OaV/DvhihmKMY+2cZ4oQ3eLJcDqn2BNL/HS7Md dc+jqozDA788lHW9/A/0HjygycXneYkEeX2zB67JvTpK9OEhAUxVKPW3XB528TrPuCBa Y2fwjpVdowHGNaIZLQqkW50fJXkJsxiN8ucJwZ+cwFNzCaxuuQ3ZJKqJfdJFlI/V9b2e 693Cazxvq2fEd7VtJN5WGegUFe6H2QrQcvFyvtR271RJq0kxy/1zIYWIDjCTmsxXpWQF /EEe8cWNUUk8DYMvUqPrh7dN/OO0jlEi+Jg6IcMvmUkvXjlg4jF2N86Czsv0OVyAZgdh IOZg== MIME-Version: 1.0 X-Received: by 10.236.46.5 with SMTP id q5mr65221406yhb.21.1401824604671; Tue, 03 Jun 2014 12:43:24 -0700 (PDT) Received: by 10.170.91.85 with HTTP; Tue, 3 Jun 2014 12:43:24 -0700 (PDT) In-Reply-To: <538E1059.6030907@gmail.com> References: <538CE2F1.8020905@gmail.com> <538E1059.6030907@gmail.com> Date: Tue, 3 Jun 2014 23:43:24 +0400 Message-ID: From: Dmitry Belyavsky To: Melinda Shore Content-Type: multipart/alternative; boundary=047d7b5d839199549c04faf3b978 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RP2utVPsl4N5TorFh3GAg7PTUUc Cc: "trans@ietf.org" Subject: Re: [Trans] Starting to think about IETF 90 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:43:32 -0000 --047d7b5d839199549c04faf3b978 Content-Type: text/plain; charset=UTF-8 Hello Melinda, On Tue, Jun 3, 2014 at 10:13 PM, Melinda Shore wrote: > On 6/3/14 3:36 AM, Dmitry Belyavsky wrote: > > The adoption of the CT to operate together with DNSSec seems to be a > > separate topic and I think, there should be a separate document covering > it. > > The best way to make that happen is to write one yourself - > that will start a discussion. Writing an internet draft should > not be seen as a big deal - they are by their nature not mature > documents, and it's fine to put something out there that's > very rough around the edges. > Well, I'm not the person who can write such a draft because I do not understand how we can improve security this way. > > We have requested Meetecho support for remote participants. > Thank you! -- SY, Dmitry Belyavsky --047d7b5d839199549c04faf3b978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Melinda,

On Tue, Jun 3, 2014 at 10:13 PM, Melinda Shore <melinda.shore@gmail.com> wrote:

On 6/3/14 3:36 AM, Dmitry Be= lyavsky wrote:
> The adoption of the CT to operate together with DNSSec seems to be a > separate topic and I think, there should be a separate document coveri= ng it.

The best way to make that happen is to write one yourself -
that will start a discussion. =C2=A0Writing an internet draft should
not be seen as a big deal - they are by their nature not mature
documents, and it's fine to put something out there that's
very rough around the edges.

Well, I= 9;m not the person who can write such a draft because I do not understand h= ow we can improve security this way.

=C2=A0

We have requested Meetecho support for remote participants.

Thank you!=C2=A0

--
SY, Dmitry Belyavsky

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207010603050706050803" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/gLWNQQ90wd2-9juMQddZjwrr0ng Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:08:01 -0000 This is a multi-part message in MIME format. --------------060207010603050706050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dmitry, My replies are inline. sorry that my mail program renumbered each of your bullets as I inserted my replies :-(. > Hello Stephen, > > Here is my understanding of the question you asked. > Let Ben or Rob fix me if I'm wrong. > > 1. > > Anybody is allowed to operate log. But there should be a procedure > (similar to CA/Browser forum) which is determined to register log > as "important" (we need a better word). There should be not many > "important" log servers, I suppose --- otherwise we are to get the > same problem as we have with many CAs. > As you note, the notion of establishing some logs as "important" would borrow from the CABF, but we're the IETF and this is intended to be an IETF standard. So, I think this doc needs to address this issue in a fashion consistent with IETF procedures. > > 1. > > Any log-server can select the list of acceptable CAs. I think that > "important logs" should cover all the CAs supported by major browsers. > The doc suggests this, but again, this has a CABF feel to it. IETF standards do not endorse implementations and use decisions by vendors to drive standards. > > 1. > > Any log server can select the algorithm of hash for Merkle Tree > and for its key signing the SCTs. > That's not what the doc says; it establishes two MTI algs that all clients must support, while log operators are allowed to pick form between the two. This seems a bit backwards to me, in that it imposes the greater burden on the larger # of implementations. > > 1. > > Each browser should provide an editable way of managing logs. By > default it should be a reasonable subset of "important" logs. > The set of "important" logs might not include a CA that is important for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set. > > 1. > > Each CA can be accepted by more than one log. > "Might be" is the more accurate characterization, based on the current doc. There is no requirement that any log operator accept submissions from a specific CA. Each log operator indicates what CAs/TAs it supports. > > 1. > > Browsers should > > 1. > > allow user to accept the cert without CT providing warning > about absence of CT > > 2. > > allow user to specify absence of log for this or that domain > (non-public suffix) > > 3. > > allow user to a particular log for this or that domain and > return an error if there is no SCT for id provided by this log. > > 4. > > there should be a procedure of report about log misbehaviour > in case of invalid log records > These seem like reasonable suggestions, at least to begin, but none of them appear in the doc. I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment. > > 1. > > I think that warning is acceptable in case of an absence of SCTs, > but in case of cryptographic errors the error should be generated. > I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right? Steve --------------060207010603050706050803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dmitry,

My replies are inline. sorry that my mail program renumbered each of your bullets as I inserted my replies :-(.

Hello Stephen,

Here is my understanding of the question you asked.

Let Ben or Rob fix me if I'm wrong.

Anybody is allowed to operate log. But there should be a procedure (similar to CA/Browser forum) which is determined to register log as “important” (we need a better word). There should be not many “important” log servers, I suppose — otherwise we are to get the same problem as we have with many CAs.

As you note, the notion of establishing some logs as "important" would borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. So, I think this
doc needs to address this issue in a fashion consistent with IETF procedures.

Any log-server can select the list of acceptable CAs. I think that “important logs” should cover all the CAs supported by major browsers.

The doc suggests this, but again, this has a CABF feel to it. IETF standards do not endorse
implementations and use decisions by vendors to drive standards.

Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs.

That's not what the doc says; it establishes two MTI algs that all clients must support, while log operators are allowed to pick form between the two. This seems a bit backwards to me, in that it imposes the greater burden on the larger # of implementations.

Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of “important” logs.

The set of "important" logs might not include a CA that is important for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set.

Each CA can be accepted by more than one log.

"Might be" is the more accurate characterization, based on the current doc. There is no requirement that any log operator accept submissions from a specific CA. Each log operator indicates what CAs/TAs it supports.

Browsers should

allow user to accept the cert without CT providing warning about absence of CT

allow user to specify absence of log for this or that domain (non-public suffix)

allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

there should be a procedure of report about log misbehaviour in case of invalid log records

These seem like reasonable suggestions, at least to begin, but none of them appear in the doc.
I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment.

I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right?

Steve
--------------060207010603050706050803-- From nobody Tue Jun 17 01:10:54 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F361A030D for ; Tue, 17 Jun 2014 01:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEn4-ZVLkeU2 for ; Tue, 17 Jun 2014 01:10:41 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B795D1A030A for ; Tue, 17 Jun 2014 01:10:41 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so5228449yha.3 for ; Tue, 17 Jun 2014 01:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ODyUeSVq3hksgg1EN6HLGo5c/kQcjs9RKLKA/WzbHrA=; b=MYexrMPRhe8641yZK9xUC/CIVX2DKSGdUDzsDKu2VqlNja0EajXzSD2JSFiOQQbQbk 0Dxk+h03uZk9IQrFfQzysKVjiF6QiJR44l3bvXdnChXGiyTEZVz5pgbcN1bV/wMsa2y+ Vtws4/UQL/1Rt64vh+YoAH4wgCxHwGy4pgXeQ8oVPfPIRZNo5VYFC4IZ06g1gbaIza2u SUyv18gftngRRnyEEra16ttbctk3g4TXsY3pVietU3ks4CmgLtI0I3nuYXEHRM3F4076 8BMwYBZ47tImu5bLbZCqpxNGOuTU54mCexfW99HzUeRReYEZvZtjpenoB5tIFBt1w1v3 bFPA== MIME-Version: 1.0 X-Received: by 10.236.26.72 with SMTP id b48mr42144467yha.59.1402992641025; Tue, 17 Jun 2014 01:10:41 -0700 (PDT) Received: by 10.170.120.2 with HTTP; Tue, 17 Jun 2014 01:10:40 -0700 (PDT) In-Reply-To: <539F408B.5050600@bbn.com> References:

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <539F408B.5050600@bbn.com> Date: Tue, 17 Jun 2014 12:10:40 +0400 Message-ID: From: Dmitry Belyavsky To: Stephen Kent Content-Type: multipart/alternative; boundary=089e01495296fdad2104fc03ad16 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YYH4sWfpyg4ZNUjlpMtbglGqzyw Cc: "trans@ietf.org" Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 08:10:44 -0000 --089e01495296fdad2104fc03ad16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Stephen, Thank you for your reply! My letter was composed as an answer questions you asked, so not all of my points are in the scope of IETF. On Mon, Jun 16, 2014 at 11:07 PM, Stephen Kent wrote: > Dmitry, > > My replies are inline. sorry that my mail program renumbered each of your > bullets as I inserted my replies :-(. > > > Hello Stephen, > > Here is my understanding of the question you asked. > Let Ben or Rob fix me if I'm wrong. > > > 1. > > Anybody is allowed to operate log. But there should be a procedure > (similar to CA/Browser forum) which is determined to register log as > =E2=80=9Cimportant=E2=80=9D (we need a better word). There should be n= ot many =E2=80=9Cimportant=E2=80=9D > log servers, I suppose =E2=80=94 otherwise we are to get the same prob= lem as we > have with many CAs. > > As you note, the notion of establishing some logs as "important" would > borrow from the > CABF, but we're the IETF and this is intended to be an IETF standard. So, > I think this > doc needs to address this issue in a fashion consistent with IETF > procedures. > > > 1. > > Any log-server can select the list of acceptable CAs. I think that > =E2=80=9Cimportant logs=E2=80=9D should cover all the CAs supported by= major browsers. > > The doc suggests this, but again, this has a CABF feel to it. IETF > standards do not endorse > implementations and use decisions by vendors to drive standards. > > > 1. > > Any log server can select the algorithm of hash for Merkle Tree and > for its key signing the SCTs. > > That's not what the doc says; it establishes two MTI algs that all > clients must support, while log operators are allowed to pick form betwee= n > the two. This seems a bit backwards to me, in that it imposes the greater > burden on the larger # of implementations. > I think that the document should be corrected and optional algorithms should be taken into account too. > > > 1. > > Each browser should provide an editable way of managing logs. By > default it should be a reasonable subset of =E2=80=9Cimportant=E2=80= =9D logs. > > The set of "important" logs might not include a CA that is important for > a set of clients 9since log operators have complete discretion as to whic= h > CAs they accept) so it ought to be possible for a client to include a > pointer to logs outside the default set. > Yes. > > > > 1. > > Each CA can be accepted by more than one log. > > "Might be" is the more accurate characterization, based on the current > doc. There is no requirement that any log operator accept submissions fro= m > a specific CA. Each log operator indicates what CAs/TAs it supports. > Yes. > > > 1. > > Browsers should > 1. > > allow user to accept the cert without CT providing warning about > absence of CT > 2. > > allow user to specify absence of log for this or that domain > (non-public suffix) > 3. > > allow user to a particular log for this or that domain and return > an error if there is no SCT for id provided by this log. > 4. > > there should be a procedure of report about log misbehaviour in > case of invalid log records > > These seem like reasonable suggestions, at least to begin, but none of > them appear in the doc. > I worry that, absent a description of minimum browser management > interfaces for CT, we have no sense of whether users will be able to deal > with incremental deployment. > So we need to specify these browser interface requirements, don't we? > > > 1. > > I think that warning is acceptable in case of an absence of SCTs, but > in case of cryptographic errors the error should be generated. > > I presume you mean that if there is a crypto error, the cert should be > rejected, a hard fail, right? > Yes, thank you for a correct wording. IMHO, The cert MUST be rejected if any of SCTs is signed incorrectly. If --=20 SY, Dmitry Belyavsky --089e01495296fdad2104fc03ad16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Stephen,

Thank you for your reply!=

My letter was composed as an answer question= s you asked, so not all of my points are in the scope of IETF.

On Mon, Jun 16, 2014 at 11:07 PM, Stephen Ke= nt <= kent@bbn.com> wrote:

=20 =20 =20
Dmitry,

My replies are inline. sorry that my mail program renumbered each of your bullets as I inserted my replies :-(.

Hello Stephen,

Here is my understanding of the question you asked.

Let Ben or Rob fix me if I'm wrong.

Anybody is allowed to operate log. But there should be a procedure (similar to CA/Browser forum) which is determined to register log as =E2=80=9Cimportant=E2=80=9D (= we need a better word). There should be not many =E2=80=9Cimportant= =E2=80=9D log servers, I suppose =E2=80=94 otherwise we are to get the sa= me problem as we have with many CAs.

As you note, the notion of establishing some logs as "important&qu= ot; would borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. So, I think this
doc needs to address this issue in a fashion consistent with IETF procedures.

Any log-server can select the list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D should cover al= l the CAs supported by major browsers.

The doc suggests this, but again, this has a CABF feel to it. IETF standards do not endorse
implementations and use decisions by vendors to drive standards.

Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs.

That's not what the doc says; it establishes two MTI algs that all clients must support, while log operators are allowed to pick form between the two. This seems a bit backwards to me, in that it imposes the greater burden on the larger # of implementations.

I think that the document should be corrected= and optional algorithms should be taken into account too.

Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D logs.

The set of "important" logs might not include a CA that is im= portant for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set.

Yes.
=C2=A0

Each CA can be accepted by more than one log.

"Might be" is the more accurate characterization, based on th= e current doc. There is no requirement that any log operator accept submissions from a specific CA. Each log operator indicates what CAs/TAs it supports.

Yes.

Browsers should

allow user to accept the cert without CT providing warning about absence of CT

allow user to specify absence of log for this or that domain (non-public suffix)

allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

there should be a procedure of report about log misbehaviour in case of invalid log records

These seem like reasonable suggestions, at least to begin, but none of them appear in the doc.
I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment.

So we need to specify these browser interface requirements, don't we?<= br>=C2=A0

I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right?

<= div>Yes, thank you for a correct wording. IMHO, The cert MUST be rejected i= f any of SCTs is signed incorrectly. If

--
SY, Dmitry Belyavsky --089e01495296fdad2104fc03ad16-- From nobody Tue Jun 17 02:34:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8151A033D for ; Tue, 17 Jun 2014 02:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzJiisMqvEK1 for ; Tue, 17 Jun 2014 02:34:07 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D811A033C for ; Tue, 17 Jun 2014 02:34:07 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id il7so6046787vcb.41 for ; Tue, 17 Jun 2014 02:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ipAiUqbINAUz3So3vjGcoB/aYdKGWrC915KDytk8JoQ=; b=T5lFWj09Iu6WKMwuRu6tkpipQcVSBki65IvP/ct1ufv6Obx2pRlzNZH0gtF8z8Hf2o lXXSyJGf1b78vWBrlguWmGzW8SqNI2TTckKdAJgJkHB+bRIvVeTtO+cpHDuUfdThcOVK OWT7vBAG2sYbCKriQrVA+TAdSX+NrVmPg2MK4rnaxFTITe+8szbcTsWdTrl6gByuKRLN y4pzXHe6Y6snv+Nj8bUfK9b29/9Hx2AyJHcZN9xh06hzbzNRaDXIy9WJneetdEzKzKTX 8yz3HbfpzzToGjlSQZJ1HmDhpbugCcGJUczUT9y8nhUpelFVaIYdXTaTcAGs4WGuUrkq cUAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ipAiUqbINAUz3So3vjGcoB/aYdKGWrC915KDytk8JoQ=; b=UsCjjVbMXMYjGogLW1Sj5wHiMQYPd+OZ7t53wTsshJJWq+Ek6pXGR9yPtikTC0HAlj H1ul5eg71hZqbWnUhEkuFjWSpFjwkr/aNc+D4XytQAF6hhvZfLK026WERP4q0cLa8U4e vVM0geEFSO4Oz/w8Z8tZaLQAqV9OiwE/L+ElO8j/q6yvsooQ9rSRG1VP6r/m4RDHnuc5 rNhG9/NFpdIWUp8k08Ch08/HAf448svFLt1o1wfSYUgMU5y6WeoBj4ScINrKjj6JVkql iLRETTPs7UHn5sMIQsxJvVd/YZRXoFQk/J9w+9tCBZdowS7/k9Egy8/abWLbhR3pBb1n 9OWw== X-Gm-Message-State: ALoCoQnuaWCEkbN4hmWafwzYZcWtF0PfvhaptjzH1tmX/svUy5AZSv4LbvtuHmOtWRcoaWujTUeg MIME-Version: 1.0 X-Received: by 10.220.80.70 with SMTP id s6mr4243vck.44.1402997646279; Tue, 17 Jun 2014 02:34:06 -0700 (PDT) Received: by 10.52.29.179 with HTTP; Tue, 17 Jun 2014 02:34:06 -0700 (PDT) In-Reply-To: <539F408B.5050600@bbn.com> References:

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <539F408B.5050600@bbn.com> Date: Tue, 17 Jun 2014 10:34:06 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7b3a8f8453e85e04fc04d814 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qNqb5xY7fMqkURYphVVodAalFog Cc: "trans@ietf.org" , Dmitry Belyavsky Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:34:10 -0000 --047d7b3a8f8453e85e04fc04d814 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 June 2014 20:07, Stephen Kent wrote: > Dmitry, > > My replies are inline. sorry that my mail program renumbered each of your > bullets as I inserted my replies :-(. > > > Hello Stephen, > > Here is my understanding of the question you asked. > Let Ben or Rob fix me if I'm wrong. > > > 1. > > Anybody is allowed to operate log. But there should be a procedure > (similar to CA/Browser forum) which is determined to register log as > =E2=80=9Cimportant=E2=80=9D (we need a better word). There should be n= ot many =E2=80=9Cimportant=E2=80=9D > log servers, I suppose =E2=80=94 otherwise we are to get the same prob= lem as we > have with many CAs. > > As you note, the notion of establishing some logs as "important" would > borrow from the > CABF, but we're the IETF and this is intended to be an IETF standard. So, > I think this > doc needs to address this issue in a fashion consistent with IETF > procedures. > How would this work? From my POV it seems that users choose the logs they pay attention to, probably mostly via choices made by their browser vendor. How would the IETF get involved in that process? > > > 1. > > Any log-server can select the list of acceptable CAs. I think that > =E2=80=9Cimportant logs=E2=80=9D should cover all the CAs supported by= major browsers. > > The doc suggests this, but again, this has a CABF feel to it. IETF > standards do not endorse > implementations and use decisions by vendors to drive standards. > Again, what do you suggest as an alternative? > > > 1. > > Any log server can select the algorithm of hash for Merkle Tree and > for its key signing the SCTs. > > That's not what the doc says; it establishes two MTI algs that all > clients must support, while log operators are allowed to pick form betwee= n > the two. This seems a bit backwards to me, in that it imposes the greater > burden on the larger # of implementations. > This seems like physics to me. You might want it to be the other way around (we could debate the burden, but that seems beside the point), but I don't see how it can be. > > > > 1. > > Each browser should provide an editable way of managing logs. By > default it should be a reasonable subset of =E2=80=9Cimportant=E2=80= =9D logs. > > The set of "important" logs might not include a CA that is important for > a set of clients 9since log operators have complete discretion as to whic= h > CAs they accept) so it ought to be possible for a client to include a > pointer to logs outside the default set. > I agree. However, there is a security risk here: a client that includes a log that is not audited has opened themselves up to abuse via mis-issue. > > > 1. > > Each CA can be accepted by more than one log. > > "Might be" is the more accurate characterization, based on the current > doc. There is no requirement that any log operator accept submissions fro= m > a specific CA. Each log operator indicates what CAs/TAs it supports. > Again, I don't see how you propose the IETF involves itself in this. Clearly we can't say "logs must accept all CAs" because that defeats the anti-spam objective of limiting the list of CAs. > > > > 1. > > Browsers should > 1. > > allow user to accept the cert without CT providing warning about > absence of CT > 2. > > allow user to specify absence of log for this or that domain > (non-public suffix) > 3. > > allow user to a particular log for this or that domain and return > an error if there is no SCT for id provided by this log. > 4. > > there should be a procedure of report about log misbehaviour in > case of invalid log records > > These seem like reasonable suggestions, at least to begin, but none of > them appear in the doc. > I worry that, absent a description of minimum browser management > interfaces for CT, we have no sense of whether users will be able to deal > with incremental deployment. > The IETF is far too slow-moving to get involved in browser UI, at least for new/experimental features. Nor do I get much sense that we have the necessary expertise in this WG. > > > 1. > > I think that warning is acceptable in case of an absence of SCTs, but > in case of cryptographic errors the error should be generated. > > I presume you mean that if there is a crypto error, the cert should be > rejected, a hard fail, right? > For EV certificates, there will be no warning in Chromium: instead, there will be no EV indication. We have not yet decided exactly how things will work when we start requiring CT for all certificates. > > Steve > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --=20 Certificate Transparency is hiring! Let me know if you're interested. --047d7b3a8f8453e85e04fc04d814 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 16 June 2014 20:07, Stephen Kent <kent@bbn.com> wrot= e:

=20 =20 =20
Dmitry,

My replies are inline. sorry that my mail program renumbered each of your bullets as I inserted my replies :-(.

Hello Stephen,

Here is my understanding of the question you asked.

Let Ben or Rob fix me if I'm wrong.

Anybody is allowed to operate log. But there should be a procedure (similar to CA/Browser forum) which is determined to register log as =E2=80=9Cimportant=E2=80=9D (= we need a better word). There should be not many =E2=80=9Cimportant= =E2=80=9D log servers, I suppose =E2=80=94 otherwise we are to get the sa= me problem as we have with many CAs.

As you note, the notion of establishing some logs as "important&qu= ot; would borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. So, I think this
doc needs to address this issue in a fashion consistent with IETF procedures.

How would this work? = >From my POV it seems that users choose the logs they pay attention to, prob= ably mostly via choices made by their browser vendor. How would the IETF ge= t involved in that process?

=C2=A0

Any log-server can select the list of acceptable CAs. I think that =E2=80=9Cimportant logs=E2=80=9D should cover al= l the CAs supported by major browsers.

The doc suggests this, but again, this has a CABF feel to it. IETF standards do not endorse
implementations and use decisions by vendors to drive standards.
<= /blockquote>

Again, what do you suggest as an alternativ= e?
=C2=A0

Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs.

That's not what the doc says; it establishes two MTI algs that all clients must support, while log operators are allowed to pick form between the two. This seems a bit backwards to me, in that it imposes the greater burden on the larger # of implementations.

This seems like physics to me. You might want= it to be the other way around (we could debate the burden, but that seems = beside the point), but I don't see how it can be.

=C2=A0

Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D logs.

The set of "important" logs might not include a CA that is im= portant for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set.

I agree. However, there is a security risk here: a cli= ent that includes a log that is not audited has opened themselves up to abu= se via mis-issue.

Each CA can be accepted by more than one log.

"Might be" is the more accurate characterization, based on th= e current doc. There is no requirement that any log operator accept submissions from a specific CA. Each log operator indicates what CAs/TAs it supports.

Again, I don= 't see how you propose the IETF involves itself in this. Clearly we can= 't say "logs must accept all CAs" because that defeats the an= ti-spam objective of limiting the list of CAs.

=C2=A0
=C2=A0

Browsers should

allow user to accept the cert without CT providing warning about absence of CT

allow user to specify absence of log for this or that domain (non-public suffix)

allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

there should be a procedure of report about log misbehaviour in case of invalid log records

These seem like reasonable suggestions, at least to begin, but none of them appear in the doc.
I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment.

The IETF is far too slow-moving to get involved in browser UI, at least fo= r new/experimental features. Nor do I get much sense that we have the neces= sary expertise in this WG.

=C2=A0

I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right?

<= div>For EV certificates, there will be no warning in Chromium: instead, the= re will be no EV indication.

We have not yet decid= ed exactly how things will work when we start requiring CT for all certific= ates.

=C2=A0

Steve

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

--
Certific= ate Transparency is hiring! Let me know if you're interested.
--047d7b3a8f8453e85e04fc04d814-- From nobody Tue Jun 17 02:55:11 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014131A033E for ; Tue, 17 Jun 2014 02:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu1vRP76_9vA for ; Tue, 17 Jun 2014 02:55:05 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF451A0337 for ; Tue, 17 Jun 2014 02:55:05 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id t59so5296830yho.37 for ; Tue, 17 Jun 2014 02:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F9y0ABK2vNNaHu/8GQhlZaaOt4aIdamuZM9A+6IZFI0=; b=XyBuJ3s2sxPpvY7Iv0nQashfmBZU22DdDScq4tsVE6o7krIZHLIy3fh6dZa7DaoMor rkhGylVhQEiDLjItHhlBjvzFGONlPLjN2TctzFdhWo+xQI3abILEh3e09prG/c48RCzZ rez7VAWNMEJu/w357jhnJwUTLhnWW8oxyvYaxvZZyGufkxvrrsuge4vlSAv8EkgxtXt4 fXMDuPa4hiO3knEYHq8OAoySm5l5Hqduf8tgJPGJJLh9e9CFM/fqaPVp31oapmN7rBCa wfcXjwZfGu+BtOQI7rizj0j2m/qLn2n2cm3r5HzoEgc5ruhLuideROTGZ0+SXSKb0ils GDtw== MIME-Version: 1.0 X-Received: by 10.236.113.69 with SMTP id z45mr43001032yhg.0.1402998904917; Tue, 17 Jun 2014 02:55:04 -0700 (PDT) Received: by 10.170.120.2 with HTTP; Tue, 17 Jun 2014 02:55:04 -0700 (PDT) In-Reply-To: References:

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <539F408B.5050600@bbn.com> Date: Tue, 17 Jun 2014 13:55:04 +0400 Message-ID: From: Dmitry Belyavsky To: Ben Laurie Content-Type: multipart/alternative; boundary=20cf3010eb11591af804fc05235d Archived-At: http://mailarchive.ietf.org/arch/msg/trans/F29HnpRQXsjsI332q6qhrBc7xsM Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:55:08 -0000 --20cf3010eb11591af804fc05235d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Ben, On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie wrote: > > > > On 16 June 2014 20:07, Stephen Kent wrote: >> >> >> >> >> 1. >> >> Each browser should provide an editable way of managing logs. By >> default it should be a reasonable subset of =E2=80=9Cimportant=E2=80= =9D logs. >> >> The set of "important" logs might not include a CA that is important >> for a set of clients 9since log operators have complete discretion as to >> which CAs they accept) so it ought to be possible for a client to includ= e a >> pointer to logs outside the default set. >> > > I agree. However, there is a security risk here: a client that includes a > log that is not audited has opened themselves up to abuse via mis-issue. > Well, now a client is able to add bad CA as trusted. I do not see extra security risks here. > > >> > >> >> 1. >> >> Browsers should >> 1. >> >> allow user to accept the cert without CT providing warning about >> absence of CT >> 2. >> >> allow user to specify absence of log for this or that domain >> (non-public suffix) >> 3. >> >> allow user to a particular log for this or that domain and return >> an error if there is no SCT for id provided by this log. >> 4. >> >> there should be a procedure of report about log misbehaviour in >> case of invalid log records >> >> These seem like reasonable suggestions, at least to begin, but none of >> them appear in the doc. >> I worry that, absent a description of minimum browser management >> interfaces for CT, we have no sense of whether users will be able to dea= l >> with incremental deployment. >> > > The IETF is far too slow-moving to get involved in browser UI, at least > for new/experimental features. Nor do I get much sense that we have the > necessary expertise in this WG. > I agree. But I think that it's a correct behavior of any CT-compliant client. Browsers, being interactive, can suggest an user to make a choice (yes, he will push the button "Add security exception" in 99%). Non-interactive software is to have command-line settings/config/etc. > >> >> >> 1. >> >> I think that warning is acceptable in case of an absence of SCTs, but >> in case of cryptographic errors the error should be generated. >> >> I presume you mean that if there is a crypto error, the cert should be >> rejected, a hard fail, right? >> > > For EV certificates, there will be no warning in Chromium: instead, there > will be no EV indication. > Even in case of invalid SCT? > > We have not yet decided exactly how things will work when we start > requiring CT for all certificates. > > >> >> Steve >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > > > -- > Certificate Transparency is hiring! Let me know if you're interested. > --=20 SY, Dmitry Belyavsky --20cf3010eb11591af804fc05235d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Ben,

On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie <benl@google.= com> wrote:

On 16 June 2014 20:0= 7, Stephen Kent <kent@bbn.com> wrote:

Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D logs.

The set of "important" logs might not include a CA that is im= portant for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set.

I agree. However, there is a security risk here:= a client that includes a log that is not audited has opened themselves up = to abuse via mis-issue.

Well, now a client is ab= le to add bad CA as trusted. I do not see extra security risks here.
=C2= =A0

=C2=A0

Browsers should

allow user to accept the cert without CT providing warning about absence of CT

allow user to specify absence of log for this or that domain (non-public suffix)

allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

there should be a procedure of report about log misbehaviour in case of invalid log records

These seem like reasonable suggestions, at least to begin, but none of them appear in the doc.
I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment.

The IETF is far too slow-moving to get involved in browser UI, at le= ast for new/experimental features. Nor do I get much sense that we have the= necessary expertise in this WG.

I agree. But I think tha= t it's a correct behavior of any CT-compliant client. Browsers, being i= nteractive, can suggest an user to make a choice (yes, he will push the but= ton "Add security exception" in 99%). Non-interactive software is= to have command-line settings/config/etc.

=C2=A0

I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right?

<= /div>
For EV certificates, there will be no warning in Chromium: instea= d, there will be no EV indication.

Even in case of invalid SCT?
=C2=A0

We have not yet decided exactly how things will work wh= en we start requiring CT for all certificates.

=C2=A0

Steve

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

--
Certificate Transparency is hiring! Let me know if you're= interested.

--
SY, Dmitry Belyavsky

--20cf3010eb11591af804fc05235d-- From nobody Tue Jun 17 03:15:14 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58DB1A0340 for ; Tue, 17 Jun 2014 03:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZRwT4ww9kLq for ; Tue, 17 Jun 2014 03:15:10 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1CA1A033D for ; Tue, 17 Jun 2014 03:15:10 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ik5so6130750vcb.35 for ; Tue, 17 Jun 2014 03:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=faZdNOXxc26gDkTXZQQv/U26oGX4KP09BDfUiUk+rME=; b=Q2qAU7m/ROO3WrhHhmnJCqt1fP8sjN5jbp85JHAuN8jnQ3OLQYqw3UYwkE+Lj7eV8D vww5bmd9z/+pKa/ij5U90bVckt9NYmtKKj9X6F3kBKCRIz4QnuwICd+1Cx8ZJTXhy8eU L+PRC2JkbHEC7R+PSl6dcfcBZpOJ/xMACCwdCVGEZ8XlJ/UbjBdESENYLz0bzO8YdDYT M5cg1rC0dddUm65HkxQxUqlsyfLHGrwrJid+zm5C+onwKqSmDD8zX9KAYiyWY6HHp2pT p4//zkGTzynC2jFlB/OeoG9gMkGCxp7OkE7zIy1cGxx6i0YR1y/u6lGUjy2gTZcjj72E QdPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=faZdNOXxc26gDkTXZQQv/U26oGX4KP09BDfUiUk+rME=; b=FRLpklLYFGTeFwn9XiN6A6ikdPMhbnhPp8decrOOkiv5LQKC3yKfcNukPB7bfvziB2 mk10TcYbG6i/nYj/SybsFJvwOYv/yj9jufVhGBhZJg+71udq6PDEQxfdaC4My1fAA73Z X6ADfLQcsYhiUywKw1z+U7S8ilwRv4EcZHx0gtezTAz8KOC/5yjpbrq1IHeM/2sRq5Xs HXa8W/DF/L+19OUIJ/zAPPBGH1Q1NGpVmYhbCGj9vv9ufXKfmwcLAtHoKWTxXkQ0ANsv bsQ9WJLHspNl0rJB+P9xNaIFeE3OXmUiO4u2sUd+HYwuc5zu5wATi7AVFTx9R8amCMHF ulzw== X-Gm-Message-State: ALoCoQn1uC7c+nNX5/1YfBri0H4AGwlCIt7OSSBatNLYxOiMGApbr30dUQqSbpXZtgvfbnOvyRt7 MIME-Version: 1.0 X-Received: by 10.220.81.194 with SMTP id y2mr7665118vck.29.1403000109589; Tue, 17 Jun 2014 03:15:09 -0700 (PDT) Received: by 10.52.29.179 with HTTP; Tue, 17 Jun 2014 03:15:09 -0700 (PDT) In-Reply-To: References:

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <539F408B.5050600@bbn.com>

Date: Tue, 17 Jun 2014 11:15:09 +0100 Message-ID: From: Ben Laurie To: Dmitry Belyavsky Content-Type: multipart/alternative; boundary=001a11c2d8602702af04fc056b90 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8pAqykmshYRNJ45T4PbhSd-u8f4 Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 10:15:12 -0000 --001a11c2d8602702af04fc056b90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 June 2014 10:55, Dmitry Belyavsky wrote: > Hello Ben, > > > On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie wrote: > >> >> >> >> On 16 June 2014 20:07, Stephen Kent wrote: >> >>> >>> >>> >>> 1. >>> >>> Each browser should provide an editable way of managing logs. By >>> default it should be a reasonable subset of =E2=80=9Cimportant=E2=80= =9D logs. >>> >>> The set of "important" logs might not include a CA that is important >>> for a set of clients 9since log operators have complete discretion as t= o >>> which CAs they accept) so it ought to be possible for a client to inclu= de a >>> pointer to logs outside the default set. >>> >> >> I agree. However, there is a security risk here: a client that includes = a >> log that is not audited has opened themselves up to abuse via mis-issue. >> > > Well, now a client is able to add bad CA as trusted. I do not see extra > security risks here. > Even if I agreed, which I don't (if you can't add extra logs, then the effect of adding bad CAs is reduced :-), this seems beside the point. It is a security risk that should be considered. > > >> >> >>> >> >>> >>> 1. >>> >>> Browsers should >>> 1. >>> >>> allow user to accept the cert without CT providing warning about >>> absence of CT >>> 2. >>> >>> allow user to specify absence of log for this or that domain >>> (non-public suffix) >>> 3. >>> >>> allow user to a particular log for this or that domain and return >>> an error if there is no SCT for id provided by this log. >>> 4. >>> >>> there should be a procedure of report about log misbehaviour in >>> case of invalid log records >>> >>> These seem like reasonable suggestions, at least to begin, but none of >>> them appear in the doc. >>> I worry that, absent a description of minimum browser management >>> interfaces for CT, we have no sense of whether users will be able to de= al >>> with incremental deployment. >>> >> >> The IETF is far too slow-moving to get involved in browser UI, at least >> for new/experimental features. Nor do I get much sense that we have the >> necessary expertise in this WG. >> > > I agree. But I think that it's a correct behavior of any CT-compliant > client. Browsers, being interactive, can suggest an user to make a choice > (yes, he will push the button "Add security exception" in 99%). > Non-interactive software is to have command-line settings/config/etc. > Yes, browsers can suggest a choice. Or they can choose not to. > > > >> >>> >>> >>> 1. >>> >>> I think that warning is acceptable in case of an absence of SCTs, >>> but in case of cryptographic errors the error should be generated. >>> >>> I presume you mean that if there is a crypto error, the cert should be >>> rejected, a hard fail, right? >>> >> >> For EV certificates, there will be no warning in Chromium: instead, ther= e >> will be no EV indication. >> > > Even in case of invalid SCT? > I think if the SCT is invalid, you will be able to tell in the connection information dropdown, but we will otherwise treat it in the same way as a missing SCT. > > >> >> We have not yet decided exactly how things will work when we start >> requiring CT for all certificates. >> >> >>> >>> Steve >>> >>> _______________________________________________ >>> Trans mailing list >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >>> >>> >> >> >> -- >> Certificate Transparency is hiring! Let me know if you're interested. >> > > > > -- > SY, Dmitry Belyavsky > --=20 Certificate Transparency is hiring! Let me know if you're interested. --001a11c2d8602702af04fc056b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 17 June 2014 10:55, Dmitry Belyavsky <beldmit@gmail.com>= wrote:

Hello Ben,

On Tue,= Jun 17, 2014 at 1:34 PM, Ben Laurie <benl@google.com> wrote:<= br>

On 16 Jun= e 2014 20:07, Stephen Kent <kent@bbn.com> wrote:

Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of =E2=80=9Cimportant=E2=80=9D logs.

The set of "important" logs might not include a CA that is im= portant for a set of clients 9since log operators have complete discretion as to which CAs they accept) so it ought to be possible for a client to include a pointer to logs outside the default set.

I agree. However, there is= a security risk here: a client that includes a log that is not audited has= opened themselves up to abuse via mis-issue.

Well, now a client= is able to add bad CA as trusted. I do not see extra security risks here.<= br>

Even if I agree= d, which I don't (if you can't add extra logs, then the effect of a= dding bad CAs is reduced :-), this seems beside the point. It is a security= risk that should be considered.

=C2=A0

=C2=A0

=C2=A0

Browsers should

allow user to accept the cert without CT providing warning about absence of CT

allow user to specify absence of log for this or that domain (non-public suffix)

allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

there should be a procedure of report about log misbehaviour in case of invalid log records

These seem like reasonable suggestions, at least to begin, but none of them appear in the doc.
I worry that, absent a description of minimum browser management interfaces for CT, we have no sense of whether users will be able to deal with incremental deployment.

The IETF is far too slow-moving to get involved in browser UI, at le= ast for new/experimental features. Nor do I get much sense that we have the= necessary expertise in this WG.

I agree. But I thi= nk that it's a correct behavior of any CT-compliant client. Browsers, b= eing interactive, can suggest an user to make a choice (yes, he will push t= he button "Add security exception" in 99%). Non-interactive softw= are is to have command-line settings/config/etc.

Yes, browsers can = suggest a choice. Or they can choose not to.

=C2=A0

=C2=A0

I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

I presume you mean that if there is a crypto error, the cert should be rejected, a hard fail, right?

<= /div>
For EV certificates, there will be no warning in Chromium: instea= d, there will be no EV indication.

Even in case of invalid SCT?

I think if the SCT is invalid, you = will be able to tell in the connection information dropdown, but we will ot= herwise treat it in the same way as a missing SCT.

=C2=A0

=C2=A0
<= /div>

=

We have not yet decided exactly how things will work wh= en we start requiring CT for all certificates.

=C2=A0

Steve

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

--
Certificate Transparency is hiring! Let me know if you're interested= .

--
SY, Dmitry Belyavsky

--
Certificate = Transparency is hiring! Let me know if you're interested.
--001a11c2d8602702af04fc056b90-- From nobody Fri Jun 20 11:29:10 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEAF1B28AF for ; Fri, 20 Jun 2014 11:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QplOD56-4FAR for ; Fri, 20 Jun 2014 11:29:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C54C1B28CC for ; Fri, 20 Jun 2014 11:28:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55768 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wy3Xr-0009Ex-Oc; Fri, 20 Jun 2014 14:28:15 -0400 Message-ID: <53A47D3F.7090301@bbn.com> Date: Fri, 20 Jun 2014 14:28:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References:

<5371ACFB.5020604@gmail.com> <537E3E13.30709@bbn.com> <539F408B.5050600@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Ixwq0JIu9wvnXWf6W0vnw0X1C6c Cc: "trans@ietf.org" Subject: [Trans] trans doc issues X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 18:29:07 -0000 Ben, I agree that some aspects of CT operation are procedural matters that fall outside the scope of what the IETF usually specifies when defining a protocol. But, readers cannot evaluate the effectiveness of a proposed system (CT is a system, not just a protocol) without a clear picture of what the system designers envision wrt to operational issues. You might want to look at the suite of RFCs published by the SIDR WG, defining the RPKI, as an example of how to address the full range of issues associated with a big, complex system. Most of the RFCs are standards track, but a few are informational; together they provide a fairly clear picture of what is expected of each element of the system, and how the elements are intended to work together. Topics such as key rollover were party of the initial set of RFCs, as well as discussion of the expected frequency with which relying parties would query repositories, etc. I don't agree that specifying behavior for browsers is out of scope for this WG. (Pardon me if I misunderstood part of your response.) To define the CT system one needs to specify behavior for TLS servers, TLS clients, Web PKI CAs, log operators, monitors, and Auditors. The current doc does some of this, but there are a number of gaps. If browser vendors are to play a major role in managing config info in support info for CT, e.g, providing pointers to log and public key for logs, then this should be stated explicitly. I've just completed a detailed analysis of the CT I-D and will begin posting my comments, questions, and suggested edits on Monday. No need to dump this on the list on a Friday :-). The analysis is about 18 pages, so I'll break it into separate messages, each dealing with a section of the I-D, plus a message offering overall comments. Steve From nobody Fri Jun 20 13:24:09 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5CB1B2904 for ; Fri, 20 Jun 2014 13:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiF99mV8wi-Z for ; Fri, 20 Jun 2014 13:24:02 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id CA2BF1B28FC for ; Fri, 20 Jun 2014 13:24:01 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id AD1B69A4402; Fri, 20 Jun 2014 16:23:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id NqFTKUJEZQvj; Fri, 20 Jun 2014 16:23:28 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2B79B9A43FB; Fri, 20 Jun 2014 16:23:28 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jun 2014 16:23:16 -0400 To: trans@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eQhTsQB4FR7EPbO_DNGnliFEcQQ Subject: [Trans] Comments on draft-ietf-trans-rfc6962-bis-03 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:24:05 -0000 I just got around to reading draft-ietf-trans-rfc6962-bis-03. I have 12 = comments. (1) I believe that the point of this document is to advance the = protocol from experimental to the standards track. However, the = Abstract still says that it is an experimental protocol. Please fix = this. (2) I find the Informal Introduction difficult to follow. It has not = changed since RFC 6962, and I hope that we can be more clear in this = document. I had to read this section more than once to figure out that = who the actors are in this protocol and what they are expected to do. Here are the points as I understand them... - Some CAs (Certification Authorities) are issuing certificates that = are surprising to the subject of those certificates. - Certificate transparency facilitates the detection of such = certificates using publicly auditable, append-only, untrusted logs of = all issued certificates. - Anyone can provide certificates to the logs, and it is expected that = public CAs will contribute all their newly issued certificates. - Logs will only accept (unexpired?) certificates that chain back to a = trust anchor in their configuration. Different logs can have a = different set of trust anchors. - Accepted certificate submissions will get a signed timestamped = response as evidence of the addition to the log. - Merkle Trees are used to provide the append-only property of each = log. Merkle Trees also help ensure honest operation of the log. - The logs provide a service to three entities in the overall PKI: -- The relying party (but only TLS clients are described) get = increased confidence in the peer's certificate if it is in a log. -- Submitter can used the signed timestamped message to demand a = proof of inclusion in the log. -- Certificate subjects can check the logs for unexpected = certificates, and if detected take some action that is beyond the scope = of this document. While I understand the reason for declaring the action beyond the scope = of the document, I think that some help can be provided to the reader. = Discovery of an unexpected certificate might lead to (1) work with the = CA to get the unexpected certificate revoked, or (2) work with = maintainers of trust anchor lists to get the CA removed if this is a = continual problem. This exercise helped me to understand the big picture for this protocol. = I hope that the author can use it to make this easier for the next = reader. I was looking at Figure 1 in RFC 5280 and wondering how the entities = might be shown in a similar figure. I'm not sure, but maybe the authors = have a figure in their heads. (3) Section 2.1 once again call this protocol experimental. Please fix = this. (4) In Section 2.1, this protocol only supports SHA-256. (This is = repeated in Section 3.5) For this protocol to move to the standards = track, I would like to see an algorithm identifier. I have great = confidence in SHA-256, but I am sure that a different hash function will = be needed in the distant future. Please make this transition easy by = including the identifier now. We have examples where the transition = away from SHA-1 was much harder because protocol work was needed to add = such an identifier. Please add it now. I think the impact is to the = structure defined in Section 3.3. Further, the digitally-signed = structure from TLS already makes use of a hash algorithm identifier, so = it should be no big deal to use the same identifier here. (5) In Section 2.1.4, this protocol supports two signature algorithms. = I do not think this raises any algorithm identifier concerns because the = digitally-signed structure from TLS is used. By reusing this structure, = you are accepting the IANA Registry rules for algorithm identifier = assignment. This leads to a question: will this protocol ever need a = hash algorithm identifier or a signature algorithm identifier that is = not already registered? I ask because the rules are strict (because the = number of identifiers is not very big)... - TLS SignatureAlgorithm Registry:=20 -- Values in the range 0-63 (decimal) inclusive are assigned via = Standards Action. -- Values in the range 64-223 (decimal) inclusive are assigned via = Specification Required. -- Values from 224-255 (decimal) inclusive are reserved for Private = Use. - TLS HashAlgorithm Registry:=20 -- Values in the range 0-63 (decimal) inclusive are assigned via = Standards Action. -- Values in the range 64-223 (decimal) inclusive are assigned via = Specification Required. -- Values from 224-255 (decimal) inclusive are reserved for Private = Use. (6) Since anyone can submit a certificate to the log, one can imagine = the same certificate being submitted from more than one source. It the = certificate added multiple times, or do subsequent submissions get a = pointer to the node in the tree associated with the first submission? = Section 3 should answer this question. (7) I find the mix of the Precertificate into Section 3.1 a bit = confusing. It says, "The Precertificate is an X.509v3 certificate for = simplicity, but, since it isn't used for anything but logging, could = equally be some other data structure." This standards-track document = should say what structure is used, and not go into the potential for = other structures. In fact, the described "special critical poison = extension" only works with X.509v3 certificates. (8) Section 3.1 says, "Logs MAY limit the length of chain they will = accept." I think they SHOULD do so to protect the log from denial of = service attacks. (9) In Section 3.1 the "certificate_chain" and "precertificate_chain" = include the trust anchor. The submitter must know which trust anchors = are supported by the log, so there does not seem to be value in = transmitting it. It is identified by the issuer field in the next = certificate in the chain anyway. Further, RFC 5280 does not require = trust anchors to have self-signed root certificates. (10) I do not understand the use of whitespace in Section 4. if I was = supposed to get meaning from this, it did not work.=20 (11) Section 5.4 talks about an auditor role. I got no hint of such a = role in the Introduction. Please update the introduction so that this = role is included. (12) In Section 6, if you want IANA to point to this document for the = definition of the signed_certificate_timestamp extension instead of RFC = 6962, you should say so here. Thanks, Russ From nobody Mon Jun 23 11:36:32 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33AE1B2C24 for ; Mon, 23 Jun 2014 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm9d045YbzuY for ; Mon, 23 Jun 2014 11:36:27 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FA11B2C25 for ; Mon, 23 Jun 2014 11:35:26 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id z10so6025383pdj.29 for ; Mon, 23 Jun 2014 11:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xeRPWzp32pFrP+ka+iqumgTDYJQt3WlWD1RSUt8oSRE=; b=ltbvigS49rjjh/VJM0hJdb3q4xja0FNk7+ZBXmoh3WssG0wnA9xrRuoMnML8UsB32V m98VBuBQ6Lg7gdX+Cvs1ocTGHJ57nFzxEk+EYRzr1mM/dmzGGuqqSOUnbHFJFtgeB7tU PlZprEkZ6g66HpgW68sJRn0FNE5reabOAE6L8EuKIIRJTc1Cs8KSh2eUS2Z5F4mG/Bo1 gRewEtoy9wLINH1kfm4tymFxFJ6xDOxkhdPK5sRfujbKKw9+DKY3fsutH5D28sLNVeTz 0cemdSZhLWWuhGP4gOfzYDZeD9wrpFGqLrBWMoaigkP4YfbU7WYKOsuWqz9A48GqaC8A 9yCQ== X-Received: by 10.69.31.138 with SMTP id km10mr31728569pbd.93.1403548525901; Mon, 23 Jun 2014 11:35:25 -0700 (PDT) Received: from spandex.local (63-140-98-123.dynamic.dsl.acsalaska.net. [63.140.98.123]) by mx.google.com with ESMTPSA id wp3sm28046286pbc.67.2014.06.23.11.35.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 11:35:25 -0700 (PDT) Message-ID: <53A8736B.4010307@gmail.com> Date: Mon, 23 Jun 2014 10:35:23 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <20140623183127.30660.30563.idtracker@ietfa.amsl.com> In-Reply-To: <20140623183127.30660.30563.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140623183127.30660.30563.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NGiVPQ2AzfvBMIc1KGXPDfPgMh4 Subject: [Trans] Fwd: trans - Requested session has been scheduled for IETF 90 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:36:29 -0000 We've been scheduled. Melinda -------- Original Message -------- Subject: trans - Requested session has been scheduled for IETF 90 Date: Mon, 23 Jun 2014 11:31:27 -0700 From: "IETF Secretariat" To: melinda.shore@gmail.com CC: trans-ads@tools.ietf.org, melinda.shore@gmail.com, paul@nohats.ca Dear Melinda Shore, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:30:00) Friday, Morning Session I 0900-1130 Room Name: Manitoba size: 75 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Public Notary Transparency Area Name: Security Area Session Requester: Melinda Shore Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: saag dane wpkops dnse websec tls opsawg Special Requests: Meetecho, to support remote participants (we have some authors who may not make the meeting). --------------------------------------------------------- From nobody Mon Jun 23 13:45:36 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042BB1B2B9A for ; Mon, 23 Jun 2014 13:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks_0HuyUfWbG for ; Mon, 23 Jun 2014 13:45:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40641B2B1D for ; Mon, 23 Jun 2014 13:45:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41864 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WzB7W-000F2e-53 for trans@ietf.org; Mon, 23 Jun 2014 16:45:42 -0400 Message-ID: <53A891E9.10400@bbn.com> Date: Mon, 23 Jun 2014 16:45:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------020506090902030107000809" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DtRlN3PQjQBWsXkvLhU4oK8SHpY Subject: [Trans] comments on the Abstract and the doc, overall X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:45:35 -0000 This is a multi-part message in MIME format. --------------020506090902030107000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Overall comments:* Throughout the document, "certificate authority" should be changed to "certification authority" as per RFC 5280 and its predecessors, X.509, and other PKIX RFCs. The OIDs used here appear to be from a private Google arc. This made sense for the experimental RFC, but since this is intended to become an IETF Standard, it might be better to use OIDs from the arc that Russ Housley manages. I think the document should consolidate the requirements established for each of the identified types of clients, so that both reader and developer can easily determine what is required. Also, there are a number of places where lowercase words probably need to become uppercase, to clearly indicate mandated, strongly suggested, and optional aspects of implementations. This might be an added section near the end, or even a normative appendix. In several places a lot of technical details are provided inline, as a concept is introduced, e.g., Merkle trees. This makes the document harder to read. I suggest moving such details to normative appendices, so that the document is easier to read. Many (most?) of the informative references seem normative, e.g., they define algorithms or data formats that are mandated by this document: SHA-256, RSA, DSS, JSON, base64 encoding, OCSP (for carrying the SCT extension), etc. please review the references and re-arrange them accordingly. *Abstract * I see Russ already noted that this version of the document is a standards track document, as indicated in the header. Thus starting by saying "This document describes an experimental protocol ..." should be changed. I also suggest that the separate, 1-sentence paragraph in the abstract should be merged with the first paragraph. I wonder if it might make sense to add a paragraph that describes the architecture for CT, something like: Certificate Transparency (CT) is a collection of mechanisms and procedures, designed to deter (and remedy?) mis-issuance of certificates in the Web PKI context. Its primary focus is certificates issued to web servers, used with TLS to secure client/server communications. CT is implemented by Web PKI Certification Authorities (CAs), TLS Clients (browsers using TLS), TLS Servers (web servers using TLS), Log Operators (LOs), Monitors, and Auditors. It enables anyone to audit certificates issued under the Web PKI, with the intent of detecting and remedying mis-issuance events. The architecture assumes that RPs will, over time, refuse to accept a certificate that does not include (or is not accompanied by) evidence that it appears in (one or more) logs, thus encouraging Web PKI CAs to adopt the CT paradigm. --------------020506090902030107000809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Overall comments:

Throughout the document, “certificate authority” should be changed to “certification authority” as per RFC 5280 and its predecessors, X.509, and other PKIX RFCs.

The OIDs used here appear to be from a private Google arc. This made sense for the experimental RFC, but since this is intended to become an IETF Standard, it might be better to use OIDs from the arc that Russ Housley manages.

I think the document should consolidate the requirements established for each of the identified types of clients, so that both reader and developer can easily determine what is required. Also, there are a number of places where lowercase words probably need to become uppercase, to clearly indicate mandated, strongly suggested, and optional aspects of implementations. This might be an added section near the end, or even a normative appendix.

In several places a lot of technical details are provided inline, as a concept is introduced, e.g., Merkle trees. This makes the document harder to read. I suggest moving such details to normative appendices, so that the document is easier to read.

Many (most?) of the informative references seem normative, e.g., they define algorithms or data formats that are mandated by this document: SHA-256, RSA, DSS, JSON, base64 encoding, OCSP (for carrying the SCT extension), etc. please review the references and re-arrange them accordingly.

Abstract

I see Russ already noted that this version of the document is a standards track document, as indicated in the header. Thus starting by saying “This document describes an experimental protocol …” should be changed. I also suggest that the separate, 1-sentence paragraph in the abstract should be merged with the first paragraph.

I wonder if it might make sense to add a paragraph that describes the architecture for CT, something like:

Certificate Transparency (CT) is a collection of mechanisms and procedures, designed to deter (and remedy?) mis-issuance of certificates in the Web PKI context. Its primary focus is certificates issued to web servers, used with TLS to secure client/server communications. CT is implemented by Web PKI Certification Authorities (CAs), TLS Clients (browsers using TLS), TLS Servers (web servers using TLS), Log Operators (LOs), Monitors, and Auditors. It enables anyone to audit certificates issued under the Web PKI, with the intent of detecting and remedying mis-issuance events. The architecture assumes that RPs will, over time, refuse to accept a certificate that does not include (or is not accompanied by) evidence that it appears in (one or more) logs, thus encouraging Web PKI CAs to adopt the CT paradigm.

--------------020506090902030107000809-- From nobody Tue Jun 24 09:15:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7161B2971 for ; Tue, 24 Jun 2014 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uENoOjQLnLb for ; Tue, 24 Jun 2014 09:15:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E2E1B2844 for ; Tue, 24 Jun 2014 09:15:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51219 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WzTNH-000L4b-Sr for trans@ietf.org; Tue, 24 Jun 2014 12:15:13 -0400 Message-ID: <53A9A402.5050205@bbn.com> Date: Tue, 24 Jun 2014 12:14:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------010503080105020708040209" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IRQoxO35I1vQ_2MZ4HmHjOAaEfM Subject: [Trans] comments on section 1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:15:10 -0000 This is a multi-part message in MIME format. --------------010503080105020708040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 1* The informal introduction seems too informal in places J. And there appears to be no more formal introduction later, so I have a number of suggestions for this section. It might be better if this section began with a description of the problem of Web PKI certificate mis-issuance. (The mechanisms are clearly focused on the Web PKI environment, so the problem should be described in that context.) For example, one might say that mis-issuance may arise due to an error by a well-meaning Web PKI CA, or as a result of an (undetected) attack on such a CA (c.f., DigiNotar), or as a result of malfeasance by a not-so-well-meaning CA. An analysis of how CT is expected to effectively address each of these three different forms of mis-issuance would help readers understand why CT is a good idea. That analysis could appear in the Security Considerations section, or maybe an appendix. I agree that CT is potentially more generally applicable than just the Web PKI and browsers, but it behooves us to describe a comprehensive solution for the context that has motivated CT development, before we addresses others. I suggest this document not mention broader applicability. We can re-charter and produce other documents when we get to that point. If the abstract text I offered above is not suitable for this document's abstract, maybe it, or some variant thereof, could be appear near the beginning of this section. "Correctness" of log operation is not defined here. It is discussed to some extent in the description of Monitor operation (Section 5.3). I suggest a forward pointer to that section. The focus here is on independent verification of log correctness. That seems to be a secondary matter; the first goal of the logs is to enable Subjects and RPs to determine if a certificate has been logged, right? Verifying that logs are being operated correctly is important only because of the primary goal of the logs. So, the 1^st paragraph here seems to place the log correctness cart before the certificate issuance transparency horse, so to speak. The second paragraph of Section 1 begins by saying that anyone can submit a certificate chain for logging. But it later states that not all certificate chains may be accepted by every log operator. These two statement are not contradictory, but they are a bit confusing; technically anyone can submit a certificate chain but not some certificate chains that are submitted may not be accepted. This should be reworded to be more precise. This paragraph says "Each log consists of certificate chains ..." Wouldn't it be more accurate to say that each log consists of a set of log entries; each log entry is a certificate chain. (This might also be a good place to explain why a log entry is a certificate chain, not just a certificate.) The entries in a log are grouped into epochs, based on the frequency at which the log operator issues a Signed Tree Head (STH). The structure of the log, based on the use of Merkle Trees [provide a cite, maybe the USENIX reference.], enables third parties to detect manipulation of a log by a log operator (or an external attacker), thus reducing the level of trust that clients must place in LOs. (Do you agree that this is a more precise characterization of a log?) The second paragraph also talks about "public CAs" but I think "Web PKI CAs" is a more accurate characterization. (After all, CAs that are "private" but which make use of the Web PKI are accommodated in Section 3.) The fact that Web PKI CAs and (Web PKI) certificate Subjects can both contribute certificate chains to logs is noted here, but without an explanation of why both need to be able to do this. I think readers will better understand the CT model if the rationale for this dual submission capacity is explained (especially since CA submissions based on pre-certificates add considerable complexity). The text refers to logs being "... spammed into uselessness ..." Since the certificate chain submission interface is via HTTP, not e-mail, the term "spam" seems inappropriate. Also, the sentence in which this phrase appears states that this DoS concern requires that each "chain be rooted in a known CA certificate." This is only part of the requirement, as described later, i.e., the root for the chain has to be one acceptable to the log operator in question. The text would be clearer if the two separate elements of the anti-DoS design were described, and justified. Also, there are other attacks that an adversary might employ to effect DoS against a log. They should be addressed somewhere in this document, to justify the decision to focus on this one avenue of attack. The term "clients" is introduced here, without definition. (I didn't count its use in the abstract since it is common to use terms there before defining them in the body of an RFC.) Perhaps a terminology section should be added, where the various classes of clients are defined, and a forward pointer to that definition could be inserted here. The end of this paragraph states: "TLS clients can thus require that all certificates they see have been logged." Later, in Section 3, there is analogous direction: " ... since certificates will not be accepted by TLS clients unless logged, ..." and later, using with normative text: "TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate." And in Section 7.1 the text says "In addition, if TLS clients will not accept unlogged certificates, ..." (I assume the first two sentences above are examples of the future optimistic tense J.) A tricky part of writing this RFC is to accurately express what one expects of a compliant, CT-enabled TLS client in a world where not all Web PKI CAs have elected to adopt CT. The RFC should address this topic up front; this section seems like a good place to discuss this non-trivial issue. The introduction should note that a client that implements CT will inform a server during the handshake, and that a CT-enabled server will send an SCT only if so informed. (This is described in 3.4.1, but that's rather late in the document.) But, that alone does not address the question of incremental deployment with respect to Web PKI CAs and servers. For example, is the plan to have users or system administrators specify which CAs, TAs, or web sites MUST provide SCTs? There needs to be a credible description of how CT will be incrementally deployed. (I doubt if a flag day would be viewed as credible.) Separate from the issue of when lack of a valid SCT becomes a basis for treating a certificate as invalid, the text in this paragraph says that "all newly-issued certificates" will be logged. Is it really _all certificates_ that are processed by TLS clients, or only EE (aka "leaf") certificates (as discussed in Section 3), or name-constrained intermediate CA certificates, or ...? If we ignore "private" certificates as described in Section 3.2, it seems that only EE certificates need to be logged for the mechanism to work. I was just wondering what the precise requirement is here. Also, I suggest replacing "they see" with "they accept as valid." The third paragraph of this section says: "Those who are concerned about mis-issue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect." This sounds like the function of a Monitor. If so, then a forward reference to Section 5.3 would make sense, and this would be a good place to introduce the term. "What they do with this information, particularly when they find that a mis-issuance has happened, is beyond the scope of this document, but broadly speaking, they can invoke existing business mechanisms for dealing with mis-issued certificates." This is an important statement about one aspect of the means by which CT is intended to remedy certificate mis-issuance. But, absent an exploration of the different ways that mis-issuance may occur (see my comment above), this statement is not very compelling. Perhaps an appendix is needed, in which you discuss different mis-issuance scenarios and then describe how CT addresses each of them. That sort of analysis may be needed to convince readers that CT is a good solution to the mis-issuance problem. There is a statement here about monitoring and remediation that seems redundant: "Of course, anyone who wants can monitor the logs and, if they believe a certificate is incorrectly issued, take action as they see fit." The previously quoted sentence already says that parties other that Web PKI certificate Subjects can monitor logs and seek redress, so what is this sentence intended to convey? The next paragraph notes that anyone who has received a signed timestamp _can_ request proof that the certificate in question was, in fact, logged. The principle recipients of SCTs seem to be TLS clients, so why not say that immediately? Also, this statement does not make it clear whether a TLS client MUST perform this check (asynchronously) or if it is merely optional. If a TLS client never performs the check, it will not detect a misbehaving log operator. I don't recall seeing a specification of how TLS clients would acquire information about bad logs from Monitors, so there does not seem to be a well-defined feedback path for dealing with this concern. (Stating that anyone who monitor logs and determines that a certificate has been mis-issued can "take action as they see fit" does not address this issue.) The next sentence refers to monitor's (not capitalized?) copies of logs. The description of a monitor says that it may (MAY?) choose to maintain a copy of logs that it watches. So, the statement here ought to be revised to be consistent with the text in Section 5.3 (or 5.3 should be revised). The next sentence says "The checking operation is asynchronous to allow TLS connections to proceed without delay, despite network connectivity issues and the vagaries of firewalls." This seems to confirm that a TLS client is presumed to be the primary entity checking that an SCT corresponds to an log entry. But it fails to say what the client is expected to do if there is no matching log entry. This seems like an important omission. This section ends with a paragraph that begins "The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version." Since the term "version" is used throughout this document to refer to versions of data structures, perhaps it would, be better to use the term "instance" above. I suggest the following rewording: "The append-only property of each log is achieved using Merkle Trees, which can be used to show that every instance of the log is a superset of every prior instance." --------------010503080105020708040209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 1

The informal introduction seems too informal in places J. And there appears to be no more formal introduction later, so I have a number of suggestions for this section.

It might be better if this section began with a description of the problem of Web PKI certificate mis-issuance. (The mechanisms are clearly focused on the Web PKI environment, so the problem should be described in that context.) For example, one might say that mis-issuance may arise due to an error by a well-meaning Web PKI CA, or as a result of an (undetected) attack on such a CA (c.f., DigiNotar), or as a result of malfeasance by a not-so-well-meaning CA. An analysis of how CT is expected to effectively address each of these three different forms of mis-issuance would help readers understand why CT is a good idea. That analysis could appear in the Security Considerations section, or maybe an appendix.

I agree that CT is potentially more generally applicable than just the Web PKI and browsers, but it behooves us to describe a comprehensive solution for the context that has motivated CT development, before we addresses others. I suggest this document not mention broader applicability. We can re-charter and produce other documents when we get to that point.

If the abstract text I offered above is not suitable for this document’s abstract, maybe it, or some variant thereof, could be appear near the beginning of this section.

“Correctness” of log operation is not defined here. It is discussed to some extent in the description of Monitor operation (Section 5.3). I suggest a forward pointer to that section. The focus here is on independent verification of log correctness. That seems to be a secondary matter; the first goal of the logs is to enable Subjects and RPs to determine if a certificate has been logged, right? Verifying that logs are being operated correctly is important only because of the primary goal of the logs. So, the 1^st paragraph here seems to place the log correctness cart before the certificate issuance transparency horse, so to speak.

The second paragraph of Section 1 begins by saying that anyone can submit a certificate chain for logging. But it later states that not all certificate chains may be accepted by every log operator. These two statement are not contradictory, but they are a bit confusing; technically anyone can submit a certificate chain but not some certificate chains that are submitted may not be accepted. This should be reworded to be more precise.

This paragraph says “Each log consists of certificate chains …” Wouldn’t it be more accurate to say that each log consists of a set of log entries; each log entry is a certificate chain. (This might also be a good place to explain why a log entry is a certificate chain, not just a certificate.) The entries in a log are grouped into epochs, based on the frequency at which the log operator issues a Signed Tree Head (STH). The structure of the log, based on the use of Merkle Trees [provide a cite, maybe the USENIX reference.], enables third parties to detect manipulation of a log by a log operator (or an external attacker), thus reducing the level of trust that clients must place in LOs. (Do you agree that this is a more precise characterization of a log?)

The second paragraph also talks about “public CAs” but I think “Web PKI CAs” is a more accurate characterization. (After all, CAs that are “private” but which make use of the Web PKI are accommodated in Section 3.) The fact that Web PKI CAs and (Web PKI) certificate Subjects can both contribute certificate chains to logs is noted here, but without an explanation of why both need to be able to do this. I think readers will better understand the CT model if the rationale for this dual submission capacity is explained (especially since CA submissions based on pre-certificates add considerable complexity).

The text refers to logs being “… spammed into uselessness …” Since the certificate chain submission interface is via HTTP, not e-mail, the term “spam” seems inappropriate. Also, the sentence in which this phrase appears states that this DoS concern requires that each “chain be rooted in a known CA certificate.” This is only part of the requirement, as described later, i.e., the root for the chain has to be one acceptable to the log operator in question. The text would be clearer if the two separate elements of the anti-DoS design were described, and justified. Also, there are other attacks that an adversary might employ to effect DoS against a log. They should be addressed somewhere in this document, to justify the decision to focus on this one avenue of attack.

The term ”clients” is introduced here, without definition. (I didn’t count its use in the abstract since it is common to use terms there before defining them in the body of an RFC.) Perhaps a terminology section should be added, where the various classes of clients are defined, and a forward pointer to that definition could be inserted here.

The end of this paragraph states: “TLS clients can thus require that all certificates they see have been logged.” Later, in Section 3, there is analogous direction: “ … since certificates will not be accepted by TLS clients unless logged, …” and later, using with normative text: “TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate.” And in Section 7.1 the text says “In addition, if TLS clients will not accept unlogged certificates, …” (I assume the first two sentences above are examples of the future optimistic tense J.) A tricky part of writing this RFC is to accurately express what one expects of a compliant, CT-enabled TLS client in a world where not all Web PKI CAs have elected to adopt CT. The RFC should address this topic up front; this section seems like a good place to discuss this non-trivial issue.

The introduction should note that a client that implements CT will inform a server during the handshake, and that a CT-enabled server will send an SCT only if so informed. (This is described in 3.4.1, but that’s rather late in the document.) But, that alone does not address the question of incremental deployment with respect to Web PKI CAs and servers. For example, is the plan to have users or system administrators specify which CAs, TAs, or web sites MUST provide SCTs? There needs to be a credible description of how CT will be incrementally deployed. (I doubt if a flag day would be viewed as credible.)

Separate from the issue of when lack of a valid SCT becomes a basis for treating a certificate as invalid, the text in this paragraph says that “all newly-issued certificates” will be logged. Is it really all certificates that are processed by TLS clients, or only EE (aka “leaf”) certificates (as discussed in Section 3), or name-constrained intermediate CA certificates, or …? If we ignore “private” certificates as described in Section 3.2, it seems that only EE certificates need to be logged for the mechanism to work. I was just wondering what the precise requirement is here. Also, I suggest replacing “they see” with “they accept as valid.”

The third paragraph of this section says: “Those who are concerned about mis-issue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect.” This sounds like the function of a Monitor. If so, then a forward reference to Section 5.3 would make sense, and this would be a good place to introduce the term.

“What they do with this information, particularly when they find that a mis-issuance has happened, is beyond the scope of this document, but broadly speaking, they can invoke existing business mechanisms for dealing with mis-issued certificates.” This is an important statement about one aspect of the means by which CT is intended to remedy certificate mis-issuance. But, absent an exploration of the different ways that mis-issuance may occur (see my comment above), this statement is not very compelling. Perhaps an appendix is needed, in which you discuss different mis-issuance scenarios and then describe how CT addresses each of them. That sort of analysis may be needed to convince readers that CT is a good solution to the mis-issuance problem.

There is a statement here about monitoring and remediation that seems redundant: “Of course, anyone who wants can monitor the logs and, if they believe a certificate is incorrectly issued, take action as they see fit.” The previously quoted sentence already says that parties other that Web PKI certificate Subjects can monitor logs and seek redress, so what is this sentence intended to convey?

The next paragraph notes that anyone who has received a signed timestamp can request proof that the certificate in question was, in fact, logged. The principle recipients of SCTs seem to be TLS clients, so why not say that immediately? Also, this statement does not make it clear whether a TLS client MUST perform this check (asynchronously) or if it is merely optional. If a TLS client never performs the check, it will not detect a misbehaving log operator. I don’t recall seeing a specification of how TLS clients would acquire information about bad logs from Monitors, so there does not seem to be a well-defined feedback path for dealing with this concern. (Stating that anyone who monitor logs and determines that a certificate has been mis-issued can “take action as they see fit” does not address this issue.)

The next sentence refers to monitor’s (not capitalized?) copies of logs. The description of a monitor says that it may (MAY?) choose to maintain a copy of logs that it watches. So, the statement here ought to be revised to be consistent with the text in Section 5.3 (or 5.3 should be revised). The next sentence says “The checking operation is asynchronous to allow TLS connections to proceed without delay, despite network connectivity issues and the vagaries of firewalls.” This seems to confirm that a TLS client is presumed to be the primary entity checking that an SCT corresponds to an log entry. But it fails to say what the client is expected to do if there is no matching log entry. This seems like an important omission.

This section ends with a paragraph that begins “The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version.” Since the term “version” is used throughout this document to refer to versions of data structures, perhaps it would, be better to use the term “instance” above. I suggest the following rewording: “The append-only property of each log is achieved using Merkle Trees, which can be used to show that every instance of the log is a superset of every prior instance.”

--------------010503080105020708040209-- From nobody Wed Jun 25 18:45:42 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A171B2EDB for ; Wed, 25 Jun 2014 18:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq4VWU3BqojM for ; Wed, 25 Jun 2014 18:45:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244501B2EDC for ; Wed, 25 Jun 2014 18:45:32 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43710 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wzykl-000Kyi-Bq for trans@ietf.org; Wed, 25 Jun 2014 21:45:31 -0400 Message-ID: <53AB7B3A.3070008@bbn.com> Date: Wed, 25 Jun 2014 21:45:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------070901010908040107020806" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1fzIRCmVMXNVWPjWB2B97EcTDr4 Subject: [Trans] Comments on Section 2 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:45:36 -0000 This is a multi-part message in MIME format. --------------070901010908040107020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 2* I suggest that most of Section 2 might be placed in an appendix. The details of hash trees will not be of interest to most readers, and having a lot of text in this document devoted to those details may distract many readers. The details are critical to ensure interoperability and security, but a high level description of Merkle hash trees, audit paths, consistency proofs, etc. would suffice to explain to most readers how CT works. Moving details to a normative appendix would make the document easier to read. Section 2.1.4 says that a log operator MUST use one of two specified signature algorithms with SHA-256. This implies that all clients MUST support both algorithms. I think it's important to justify this requirement, i.e., why are all clients forced to support both algorithms, while log operators get to choose which one they want to implement? Also, in many (thought not all) recent security area protocol designs, we have been separating the algorithm specs from the rest of the design, to accommodate algorithm agility. This document (or a companion) needs to address algorithm agility, irrespective of whether the algorithms are included here or elsewhere. I recall that the algorithm agility topic was raised but deferred in discussions on the list; I think it needs to be addressed, either here or in a companion document that is accepted by the WG as an essential element of the CT architecture. Also, there should be a discussion of how key rollover for logs is managed, once the topic of how to acquire log public keys is resolved. --------------070901010908040107020806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 2

I suggest that most of Section 2 might be placed in an appendix. The details of hash trees will not be of interest to most readers, and having a lot of text in this document devoted to those details may distract many readers. The details are critical to ensure interoperability and security, but a high level description of Merkle hash trees, audit paths, consistency proofs, etc. would suffice to explain to most readers how CT works. Moving details to a normative appendix would make the document easier to read.

Section 2.1.4 says that a log operator MUST use one of two specified signature algorithms with SHA-256. This implies that all clients MUST support both algorithms. I think it’s important to justify this requirement, i.e., why are all clients forced to support both algorithms, while log operators get to choose which one they want to implement? Also, in many (thought not all) recent security area protocol designs, we have been separating the algorithm specs from the rest of the design, to accommodate algorithm agility. This document (or a companion) needs to address algorithm agility, irrespective of whether the algorithms are included here or elsewhere. I recall that the algorithm agility topic was raised but deferred in discussions on the list; I think it needs to be addressed, either here or in a companion document that is accepted by the WG as an essential element of the CT architecture. Also, there should be a discussion of how key rollover for logs is managed, once the topic of how to acquire log public keys is resolved.

--------------070901010908040107020806-- From nobody Thu Jun 26 09:41:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F841B2CF0 for ; Thu, 26 Jun 2014 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_rjwEKx1twU for ; Thu, 26 Jun 2014 09:41:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1ECB1B2CF6 for ; Thu, 26 Jun 2014 09:20:21 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59279 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X0CPM-0006VX-13 for trans@ietf.org; Thu, 26 Jun 2014 12:20:20 -0400 Message-ID: <53AC483D.4000802@bbn.com> Date: Thu, 26 Jun 2014 12:20:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------040509020508080407000307" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zX8Xc1Hb4u3OQiAODdO-WqjbaOk Subject: [Trans] Section 3 + 3.1 comments X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:41:46 -0000 This is a multi-part message in MIME format. --------------040509020508080407000307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 3* Much of this section also should be moved to a normative appendix, as it describes details that are critical for interoperability, but which may distract a reader from gaining a solid understanding of the CT design. In this section the term log often refers to both a data structure and to the entity responsible for operating the logging service. I suggest using the phrase "log operator" for the second meaning, for clarity, throughout the document. The section begins by stating that "Anyone can submit certificates to certificate logs for public auditing; ..." Why is this a requirement? It's easy to see why a certificate Subject or the issuer of a certificate may wish to get an SCT. But why is it important for anyone to be able to do so? I think this requirement should be explained, preferably before this point in the document. (If a certificate could be submitted only by its issuers or by the Subject of the certificate, a log operator might be able to require a signed challenge/response as part of submission, and thus reject what might be a DoS attack.) A log operator MUST return an SCT "immediately." Is there a reasonable way to bound "immediately?" A MUST with such an imprecise description of a requirement is worrisome. The term "Maximum Merge Delay (MMD)" is introduced here, and cited in four other places. But, I didn't find an indication of how a log operator conveys to clients the MMD for a given log. What is the plan for making this information available to clients? (Also, will this document, or some other document, provide guidance for log operators with respect to suitable MMD choices?) Might the MMD become part of the STH? Also, the term "Auditor" is used here. A forward reference to the description of what an Auditor does should be included, or a back pointer to the definition of the term if a terminology section is added earlier. Again, the text uses the future optimistic tense when it says that "... clients MUST reject certificates that do not have a valid SCT for the end-entity certificate." (I am not concerned by the mandate for servers to include an SCT because a CT-enabled server will send this information only if a CT-enabled client asks during the handshake.) Also, the wording here is confusing. How about: ""... a client MUST reject an end-entity certificate that does not contain or is not accompanied by a valid SCT." Precisely which checks is a TLS client required to perform with respect to an SCT? Presumably it checks the signature on the SCT (using the public key for the log in question), decodes the SCT, checks the syntax, and then performs a comparison between the certificate being verified and the SCT signed entry. Is this correct? I think there is a need for a subsection that describes exactly what a TLS client does with an SCT. That text will need to deal with the simple end-entity certificate and stand alone SCT case, as well as the more complex cases involving an SCT computed on a pre-certificate, which may be an end-entity certificate or an intermediate CA certificate. It also needs to discuss how a client maps a LogID to a log pubic key, etc. There is a sentence here about how an Auditor can verify that a certificate was added to the log within the MMD. This probably should appear in the discussion of what an Auditor does, either in lieu of this mention, or in addition to it. (The description of the Auditor in 5.4 is very, very vague, so it needs this sort of concrete functional description. And, it might be better to use some normative text, e.g., make the MMD check a MUST or SHOULD.) The final sentence/paragraph of this section says "Log operators MUST NOT impose any conditions on retrieving or sharing data from the log." That leaves open the question of whether a log operator can discriminate when accepting requests to create log entries (i.e., generate an SCT).The next section suggests that a log operator is allowed to discriminate, i.e., it may choose to accept certificates issued by only some TAs. A quick rationale for this asymmetric, mandated aspect of log operator behavior would help here. *Section 3.1 * This section begins by repeating the opening sentence from 3, which seems redundant. There is a mandate to "... publish the list of acceptable root certificates ..." Section 4.7 describes the message used by a client to acquire the list of root certificates accepted by a log. This is not what I would call "publishing" the list; it is making it available upon request. The allusion to the "... union of root certificates trusted by major browser vendors" may not be appropriate.It begs the question of which browser vendors are "major." Also, the term "might" is not a good choice for a standard. Each log operator is free to choose which TAs is supports, and this document says how clients learn which TAs are supported; that's good. If you want to say that you expect most log operators to support the set of TAs accepted by the major browser vendors, then this sounds like a CABF issue, and a reference to that forum seems appropriate. You might even say that you expect the CABF to maintain a TA list so that log operators have a central reference point, rather than expecting each log operator to analyze the TA list in each of the "major" browsers. The notion of a Precertificate is introduced here. This is a fairly complex feature of CT, which seems to make life harder for clients and log operators. It sounds like an SCT issued for an existing certificate is computed on the TBS part of that certificate, in its entirety. An SCT issued from a precertificateis computed over the TBS certificate, minus the poison extension, and minus any other SCT's that have been included as extensions. Is this correct? It was not entirely clear (to me) from the text. Also, if an SCT is to be included as a certificate extension, or as an OCSP extension, it's syntax probably should to be defined in ASN.1. I do worry that a CA may find it difficult to issue a precertificate with a serial number and validity interval that is preserved when the final certificate is issued, with one ort more SCT extensions. For example, the FIPS 140-1 Level 3 HSM we used to sell assigned the serial number to each certificate that it signed, a nice security feature that would have enabled the DigiNotar folks to detect the attack they suffered, and revoke the bogus certificates. If a CA uses an analogous HSM capability, it would not be able to create a precerertificat5 and a final certificate with the same serial number. There may be other examples where analogous problems arise. A quick explanation of why the specific precertificate design was adopted might help readers understand the need for this complexity. Also, a more precise description of what certificate fields and extensions are signed is needed. For example, it's not completely clear whether the serial number and validity interval for the certificate must be the same in a precertificate vs. the final, issued certificate. (It might be hard for some CAs to make thiswork, given that the pre-certificate is not the final, issued certificate.) It seems that there are two separate reasons for the precertificate design. A CA can't know the value of the time stamp or the log operator signature that will be in the SCT when the pre-certificate is submitted; thus it cannot include an SCT extension in the submitted certificate. Also, if a CA wants to include SCTs from more than one log, the problem is even worse. This suggests that if the SCT were computed on a subset of the fields/extensions in a certificate, it might be possible to simplify the overall CT design. If the SCT signature was computed on a subset of the certificate content, a CA could submit that data to one or more log operators, and incorporate the resulting SCTs into the final certificate. This would avoid the need for some of the precertificate complexity. For example, in 3.2.2 it appears that an SCT for a redacted pre-certificate will not be compared against DNS name data in the Subject field (vs. the SubjectAltName extension). If that represents a safe exclusion, what other fields might be excluded and still preserve the security properties of CT? Why not go back, examine each field of a certificate (and the set of standard extensions), and say which ones need to be covered by an SCT. This might allow SCTs for certificates and precertificates to be processed uniformly (by clients). It might even do away with the need for the poison OID, e.g., by not having a CA submit the required data as a certificate. The comment that another data structure might equally well be used for a precertificate is inappropriate for a standards track document; this document is specifying the format. But, as I noted above, it might be good to revisit the precertificate design and ask whether an alternative format is needed. The text notes that the "poison" extension is included to ensure that the precertificate is not accepted as a legitimate certificate. It would help to explain what class of attacks arise if the precertificate lacked that extension. The text describing acceptable ways to sign the precertificate needs to be revised; a certificate is never used to sign anything; the private key corresponding to the public key in the certificate is used. You might substitute "issued under" for "signed with" to fix this problem. The text in this subsection says that a log MAY accept certificates that do not meet some X.509/PKIX validation criteria, to accommodate "... quirks of CA certificate-issuing software." First, it's not clear if the provided list of quirks is intended to be complete, or if the list is merely illustrative. Second, is accommodating broken CA software something that we want to codify in a standards track RFC? Finally, if different log operators adopt different policies with respect to what is and is not checked in a submitted (pre-) certificate, life becomes confusing for submitters. Specifically, a CA or certificate Subject may receive an SCT from one log operator, but be rejected by another because the latter was more stringent in its checking. That sort of inconsistent behavior is something we ought not encourage in a standard. The parenthetical comment about self-signed certificates and DANE suggests that the rationale for their exclusion is "spam." It would be good nice to discuss the rationale for excluding DANE certificates in greater depth. Also, since the document already said that a log operator publishes the list of root CAs for which it is willing to create log entries, it would appear that self-signed certificates are already excluded on that basis. Please clarify. In the log entry format discussion, the following sentence appears: "Future revisions of this protocol version may add new LogEntryType values." I presume this should say that "new versions of the protocol may add ..." One ought not revise an existing protocol version to add new stuff, right? The end of this subsection describes the precertificate chain, and says that the final certificate in the chain MUST be a root certificate accepted by the log. But at the beginning of this subsection the text said: "The root certificate itself MAY be omitted from the chain submitted to the log server." Please reconcile these two statements. The text notes that a Log operator may limit the length of the chains it accepts. I agree with Russ that this comment ought to be normative, e.g., a SHOULD.I suggest this limit become part of the data returned by the Retrieve Accepted Root Certificates message (perhaps renamed)? Any entity submitting a certificate chain would presumably want to fetch this information before submission, to avoid wasting time. --------------040509020508080407000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 3

Much of this section also should be moved to a normative appendix, as it describes details that are critical for interoperability, but which may distract a reader from gaining a solid understanding of the CT design.

In this section the term log often refers to both a data structure and to the entity responsible for operating the logging service. I suggest using the phrase “log operator” for the second meaning, for clarity, throughout the document.

The section begins by stating that “Anyone can submit certificates to certificate logs for public auditing; …” Why is this a requirement? It’s easy to see why a certificate Subject or the issuer of a certificate may wish to get an SCT. But why is it important for anyone to be able to do so? I think this requirement should be explained, preferably before this point in the document. (If a certificate could be submitted only by its issuers or by the Subject of the certificate, a log operator might be able to require a signed challenge/response as part of submission, and thus reject what might be a DoS attack.)

A log operator MUST return an SCT “immediately.” Is there a reasonable way to bound “immediately?” A MUST with such an imprecise description of a requirement is worrisome.

The term “Maximum Merge Delay (MMD)” is introduced here, and cited in four other places. But, I didn’t find an indication of how a log operator conveys to clients the MMD for a given log. What is the plan for making this information available to clients? (Also, will this document, or some other document, provide guidance for log operators with respect to suitable MMD choices?) Might the MMD become part of the STH? Also, the term “Auditor” is used here. A forward reference to the description of what an Auditor does should be included, or a back pointer to the definition of the term if a terminology section is added earlier.

Again, the text uses the future optimistic tense when it says that “… clients MUST reject certificates that do not have a valid SCT for the end-entity certificate.” (I am not concerned by the mandate for servers to include an SCT because a CT-enabled server will send this information only if a CT-enabled client asks during the handshake.) Also, the wording here is confusing. How about: ““… a client MUST reject an end-entity certificate that does not contain or is not accompanied by a valid SCT.”

Precisely which checks is a TLS client required to perform with respect to an SCT? Presumably it checks the signature on the SCT (using the public key for the log in question), decodes the SCT, checks the syntax, and then performs a comparison between the certificate being verified and the SCT signed entry. Is this correct? I think there is a need for a subsection that describes exactly what a TLS client does with an SCT. That text will need to deal with the simple end-entity certificate and stand alone SCT case, as well as the more complex cases involving an SCT computed on a pre-certificate, which may be an end-entity certificate or an intermediate CA certificate. It also needs to discuss how a client maps a LogID to a log pubic key, etc.

There is a sentence here about how an Auditor can verify that a certificate was added to the log within the MMD. This probably should appear in the discussion of what an Auditor does, either in lieu of this mention, or in addition to it. (The description of the Auditor in 5.4 is very, very vague, so it needs this sort of concrete functional description. And, it might be better to use some normative text, e.g., make the MMD check a MUST or SHOULD.)

The final sentence/paragraph of this section says “Log operators MUST NOT impose any conditions on retrieving or sharing data from the log.” That leaves open the question of whether a log operator can discriminate when accepting requests to create log entries (i.e., generate an SCT). The next section suggests that a log operator is allowed to discriminate, i.e., it may choose to accept certificates issued by only some TAs. A quick rationale for this asymmetric, mandated aspect of log operator behavior would help here.

Section 3.1

This section begins by repeating the opening sentence from 3, which seems redundant. There is a mandate to “… publish the list of acceptable root certificates …” Section 4.7 describes the message used by a client to acquire the list of root certificates accepted by a log. This is not what I would call “publishing” the list; it is making it available upon request.

The allusion to the “… union of root certificates trusted by major browser vendors” may not be appropriate. It begs the question of which browser vendors are “major.” Also, the term “might” is not a good choice for a standard. Each log operator is free to choose which TAs is supports, and this document says how clients learn which TAs are supported; that’s good. If you want to say that you expect most log operators to support the set of TAs accepted by the major browser vendors, then this sounds like a CABF issue, and a reference to that forum seems appropriate. You might even say that you expect the CABF to maintain a TA list so that log operators have a central reference point, rather than expecting each log operator to analyze the TA list in each of the “major” browsers.

The notion of a Precertificate is introduced here. This is a fairly complex feature of CT, which seems to make life harder for clients and log operators. It sounds like an SCT issued for an existing certificate is computed on the TBS part of that certificate, in its entirety. An SCT issued from a precertificate is computed over the TBS certificate, minus the poison extension, and minus any other SCT’s that have been included as extensions. Is this correct? It was not entirely clear (to me) from the text. Also, if an SCT is to be included as a certificate extension, or as an OCSP extension, it’s syntax probably should to be defined in ASN.1.

I do worry that a CA may find it difficult to issue a precertificate with a serial number and validity interval that is preserved when the final certificate is issued, with one ort more SCT extensions. For example, the FIPS 140-1 Level 3 HSM we used to sell assigned the serial number to each certificate that it signed, a nice security feature that would have enabled the DigiNotar folks to detect the attack they suffered, and revoke the bogus certificates. If a CA uses an analogous HSM capability, it would not be able to create a precerertificat5 and a final certificate with the same serial number. There may be other examples where analogous problems arise.

A quick explanation of why the specific precertificate design was adopted might help readers understand the need for this complexity. Also, a more precise description of what certificate fields and extensions are signed is needed. For example, it’s not completely clear whether the serial number and validity interval for the certificate must be the same in a precertificate vs. the final, issued certificate. (It might be hard for some CAs to make this work, given that the pre-certificate is not the final, issued certificate.)

It seems that there are two separate reasons for the precertificate design. A CA can’t know the value of the time stamp or the log operator signature that will be in the SCT when the pre-certificate is submitted; thus it cannot include an SCT extension in the submitted certificate. Also, if a CA wants to include SCTs from more than one log, the problem is even worse. This suggests that if the SCT were computed on a subset of the fields/extensions in a certificate, it might be possible to simplify the overall CT design.

If the SCT signature was computed on a subset of the certificate content, a CA could submit that data to one or more log operators, and incorporate the resulting SCTs into the final certificate. This would avoid the need for some of the precertificate complexity.

For example, in 3.2.2 it appears that an SCT for a redacted pre-certificate will not be compared against DNS name data in the Subject field (vs. the SubjectAltName extension). If that represents a safe exclusion, what other fields might be excluded and still preserve the security properties of CT? Why not go back, examine each field of a certificate (and the set of standard extensions), and say which ones need to be covered by an SCT. This might allow SCTs for certificates and precertificates to be processed uniformly (by clients). It might even do away with the need for the poison OID, e.g., by not having a CA submit the required data as a certificate.

The comment that another data structure might equally well be used for a precertificate is inappropriate for a standards track document; this document is specifying the format. But, as I noted above, it might be good to revisit the precertificate design and ask whether an alternative format is needed.

The text notes that the “poison” extension is included to ensure that the precertificate is not accepted as a legitimate certificate. It would help to explain what class of attacks arise if the precertificate lacked that extension.

The text describing acceptable ways to sign the precertificate needs to be revised; a certificate is never used to sign anything; the private key corresponding to the public key in the certificate is used. You might substitute “issued under” for “signed with” to fix this problem.

The text in this subsection says that a log MAY accept certificates that do not meet some X.509/PKIX validation criteria, to accommodate “… quirks of CA certificate-issuing software.” First, it’s not clear if the provided list of quirks is intended to be complete, or if the list is merely illustrative. Second, is accommodating broken CA software something that we want to codify in a standards track RFC? Finally, if different log operators adopt different policies with respect to what is and is not checked in a submitted (pre-) certificate, life becomes confusing for submitters. Specifically, a CA or certificate Subject may receive an SCT from one log operator, but be rejected by another because the latter was more stringent in its checking. That sort of inconsistent behavior is something we ought not encourage in a standard.

The parenthetical comment about self-signed certificates and DANE suggests that the rationale for their exclusion is “spam.” It would be good nice to discuss the rationale for excluding DANE certificates in greater depth. Also, since the document already said that a log operator publishes the list of root CAs for which it is willing to create log entries, it would appear that self-signed certificates are already excluded on that basis. Please clarify.

In the log entry format discussion, the following sentence appears: “Future revisions of this protocol version may add new LogEntryType values.” I presume this should say that “new versions of the protocol may add …” One ought not revise an existing protocol version to add new stuff, right?

The end of this subsection describes the precertificate chain, and says that the final certificate in the chain MUST be a root certificate accepted by the log. But at the beginning of this subsection the text said: “The root certificate itself MAY be

omitted from the chain submitted to the log server.” Please reconcile these two statements.

The text notes that a Log operator may limit the length of the chains it accepts. I agree with Russ that this comment ought to be normative, e.g., a SHOULD. I suggest this limit become part of the data returned by the Retrieve Accepted Root Certificates message (perhaps renamed)? Any entity submitting a certificate chain would presumably want to fetch this information before submission, to avoid wasting time.

--------------040509020508080407000307-- From nobody Mon Jun 30 07:40:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F090C1A036C for