From nobody Thu Jun 2 14:22:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127D012D605 for ; Thu, 2 Jun 2016 14:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsqH51JOqnlT for ; Thu, 2 Jun 2016 14:22:01 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCCE12D1BE for ; Thu, 2 Jun 2016 14:22:01 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id ec8so2550539pac.0 for ; Thu, 02 Jun 2016 14:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=8xNbmybH9Svvq6ZivRVhmjq4JolzfI+eMyTacNtxqac=; b=VZvkVZ+dWY4+Z+qhIgxtO7aHA+q7y76P0btFXamgWroCIzA8IR/8k8WvDSYUX+xpHL LfhvEDmOG5wSnehB6dY1G5txc9STgXpPST/x7cQzp9kdLq6qNQbLkYnol8Q+580M8wQW 0XQbI4SJUvofof3k7EbvosTWq4KfhQT+Rv1WX5So0O9Rzi+mFEQu8RyUocJip6RqhCb1 XsLgtykyau06/G29qrccteKDKtZV4K9yf1StHTilgINj7W0CXLO+iADllACyf6Ej8+eE EoQmwkGArcrpDoHKk0KuO+Fi8yk00hw1DTyxmuH7uCcAjvaGEKLcsjpaDtgSuzv+vFTJ cHzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=8xNbmybH9Svvq6ZivRVhmjq4JolzfI+eMyTacNtxqac=; b=IT0TuSxwg2xrfTcmWgfFBbOoCaA26/0tFxjOZhgRkms1tk2+niq5vhd3uNvmUOju// ZiQhHTGk6xPaH6Lf9vHLcOZ9kFNifKK2diA4mJ5rD6Fp1QsLuX5LETkPEDP9eilD8LA2 yHIpJCr2+diudPeYBnDCtyUnKU3IuM7xzCHz0DPlLMlmtt6DF7bwtDH7M8G+F3IYLKko rz+fbJb9bpD0J7EdT0LpqjGpNE2ZJ5H6xxH0yOdDHFWLMBony7dr3OppSRDmvmLd60X0 LzonBLFxFksV3GHGrq1TO/Orm/Wu2fWjW4hKluVb6VKeqNWtIDGQWSU+pbPByImhehnC nHtQ== X-Gm-Message-State: ALyK8tLB+3blvzNcoYwY75rDlf5RjY1Elcslq62lwC40E0nfVndLRan/YVfySsdquTRkUA== X-Received: by 10.66.166.78 with SMTP id ze14mr218851pab.149.1464902521229; Thu, 02 Jun 2016 14:22:01 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-113-132-radius.dynamic.acsalaska.net. [216.67.113.132]) by smtp.googlemail.com with ESMTPSA id bf4sm551382pac.4.2016.06.02.14.22.00 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 14:22:00 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Thu, 2 Jun 2016 13:21:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:22:04 -0000 Hi, all: We've put in a session request for the upcoming IETF meeting, but may choose to cancel it if we feel that there's not enough activity on the mailing list to justify it. If you feel you've got an issue that needs face-to-face discussion, 1) get a mailing list discussion going, and 2) let us know. We are in wg last call for the -bis document and will restart last call on the threat analysis when we get the go-ahead from the authors, and we would be grateful for review. It may be the case that something falls out of last call that needs face time to resolve. But we won't know if we don't get comments. Thanks, Melinda From nobody Fri Jun 3 04:02:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF612D5CF for ; Fri, 3 Jun 2016 04:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APZbEu7_Tpzf for ; Fri, 3 Jun 2016 04:02:13 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6EF12D0EF for ; Fri, 3 Jun 2016 04:02:12 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u53B260a022054 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jun 2016 13:02:06 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u53B1xgX018452 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 11:02:04 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1464951725; bh=W2kMr8cuP/uoWVZxkLv/ZIrLdXAGxAGoezG6J+2B8Cg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=q1rvD4Gl2c4tgPuZvNj/GBlm0ylxvbI5YD6u1SHRgWA6SqWowqhqA4kQuAfppKUDd Dvqg+6rpiVKMZQn1xlHfxPdI8G+mis0s7U+Nf0rzHvPXpIf2mdy3E2LhSvVXw31u+G 2UWPBZfqhEw0OWqwh76k5aVcNeeixBEwSa0LDXTI= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 3 Jun 2016 13:01:59 +0200 From: Linus Nordberg To: Eran Messeri Organization: NORDUnet A/S References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> <874m9uf64o.fsf@nordberg.se> Date: Fri, 03 Jun 2016 13:01:54 +0200 In-Reply-To: (Eran Messeri's message of "Thu, 19 May 2016 18:07:01 +0100") Message-ID: <874m9aedst.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aR2b26zI - f5f61ce9c41e - 20160603 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: Ben Laurie , "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:02:18 -0000 Hi, I like that -- if you're not gossiping SCT plus full chain, gossip SCT plus the input needed for producing the real unique key of the log, i.e. the merkle tree leaf. Making it mandatory should not complicate the gossip protocol much, but I'll investigate. Regarding your first point for why an SCT alone is not useful, I'm not sure that I understand how a log could drop such a reqeust. If a log doesn't reply to a request it's supposed to support it's misbehaving, isn't it? And SCT's are certainly signed so the log can indeed be held accountable. I agree that implementing a "best effort" get-entry-by-sct request is trivial -- try verifying the SCT against all entries until you find the match, return the match. Using the timestamp as a hint of where to start looking is probably a good optimisation. It might even be efficient. Eran Messeri wrote Thu, 19 May 2016 18:07:01 +0100: > Back to dkg's original question, I'd suggest gossiping the MerkleTreeLeaf > (RFC6962) / TransItem containing TimestampedCertificateEntryDataV2 > (RFC6962-bis). > > For each of the protocols, that's the data structure necessary to validate > the signature in the SCT *and* to audit the log (because these data > structures themselves are not signed they cannot be the only thing that's > gossiped). > > IMHO gossiping only the SCT is not very useful, even if logs offer > get-entry-by-sct: > * A log could deny / drop such a request (as it's not signed), in which > case the client's recourse is a download of the entire log. > * Without the data covered by the signature, there's no meaningful > auditing: the entity holding the SCT does not know which certificate hasn't > been incorporated into the log. > > Re get-entry-by-sct, as it does complicate implementation, one option is to > make this API optional (which is a particularly viable approach as it can > be implemented by a log mirror based on data from a log that does not > implement it). > > Eran > > > On Thu, May 19, 2016 at 3:56 PM, Linus Nordberg wrote: > >> Ben Laurie wrote >> Wed, 18 May 2016 18:30:37 +0100: >> >> | On 18 May 2016 at 17:23, Linus Nordberg wrote: >> | > Ben Laurie wrote >> | > Fri, 13 May 2016 15:56:44 +0100: >> | > >> | > | Actually, it seems to me that the simplest answer is to allow lookups >> | > | in logs based on SCT alone. Then the SCT can be validated using the >> | > | retrieved chain. >> | > >> | > That seems odd. From a logs point of view, an SCT is not a persistent >> | > object. >> | > >> | > I don't know about other implementations but catlfish would not be able >> | > to efficiently find an entry in the database given only an SCT. >> | >> | Are you saying there's some technical barrier to doing this, or just >> | that as it stands you wouldn't be able to? >> >> I was being inprecise. I should have said that it would require some >> redesign. >> >> >> | It seems to me that the log could easily save SCTs it issued alongside >> | the cert chains it issued them for. >> >> All SCT's for every chain, I presume, if there's going to be any point >> in offering a lookup with an SCT as input? This would complicate things >> at least in our design. I'm sure it could be solved at the price of more >> complexity. >> >> >> | And that it could easily create an index based on those SCTs. >> >> >> | Note that 6962-bis already requires you to return SCTs in some lookups... >> >> You meen get-entries? I don't see how that's relevant. An SCT can be >> generated given the data in leaf_input. No need to store it, unless you >> wanted to for caching of course (we do that on frontend nodes). There's >> a big difference between doing this and indexing on SCT's though. >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans> > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jun 3 04:06:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0AA12D654 for ; Fri, 3 Jun 2016 04:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FSRzPcCe0rQ for ; Fri, 3 Jun 2016 04:06:16 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2276A12D5D3 for ; Fri, 3 Jun 2016 04:06:15 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u53B6CYQ023427 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jun 2016 13:06:12 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u53B67fv019185 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 11:06:10 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1464951970; bh=wLMrTI6JvIhnBSSbxPSH2wE4V+nFySjq61P5ONmC9i0=; h=From:To:Cc:Subject:References:Date; b=Z2fatnwubAEd6sYBXlkU6OcWHecCQEzZ/rp60GII+ah+TZKSgGJd6j9zIQs+vQNIi 4Z3wOLbnDctf5qy6EglepjcH4lOr4djqrehKneQwsLAtYacaXJtnUeRP5SqEf+d6gq G0ED4+wbiNMXMUBXs7uyZ1GrZHCh5PSBqP8K2RkY= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 3 Jun 2016 13:06:06 +0200 From: Linus Nordberg To: Ben Laurie Organization: NORDUnet A/S References: <87wpn9322u.fsf@alice.fifthhorseman.net> <87lh37mj2m.fsf@nordberg.se> <874m9uf64o.fsf@nordberg.se> Date: Fri, 03 Jun 2016 13:06:03 +0200 Message-ID: <8737ouedlw.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aR2b6cDw - d4062bcdca36 - 20160603 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] evaluating an SCT in the absence of the cert's issuer key X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:06:18 -0000 Ben Laurie wrote Tue, 24 May 2016 11:25:15 +0100: > On 19 May 2016 at 15:56, Linus Nordberg wrote: >> Ben Laurie wrote >> Wed, 18 May 2016 18:30:37 +0100: >> >> | On 18 May 2016 at 17:23, Linus Nordberg wrote: >> | > Ben Laurie wrote >> | > Fri, 13 May 2016 15:56:44 +0100: >> | > >> | > | Actually, it seems to me that the simplest answer is to allow lookups >> | > | in logs based on SCT alone. Then the SCT can be validated using the >> | > | retrieved chain. >> | > >> | > That seems odd. From a logs point of view, an SCT is not a persistent >> | > object. >> | > >> | > I don't know about other implementations but catlfish would not be able >> | > to efficiently find an entry in the database given only an SCT. >> | >> | Are you saying there's some technical barrier to doing this, or just >> | that as it stands you wouldn't be able to? >> >> I was being inprecise. I should have said that it would require some >> redesign. >> >> >> | It seems to me that the log could easily save SCTs it issued alongside >> | the cert chains it issued them for. >> >> All SCT's for every chain, I presume, if there's going to be any point >> in offering a lookup with an SCT as input? This would complicate things >> at least in our design. I'm sure it could be solved at the price of more >> complexity. > > We were reviewing the spec for 6962-bis, and we believe it is not > possible to have more than one SCT for any particular log entry. I agree. There can be more than one log entry with the same chain though, each of which at submission returned a separate SCT. But that's beside the point so to answer my own question: Yes, all SCT's for every chain, one per entry. :) >> | And that it could easily create an index based on those SCTs. >> >> >> | Note that 6962-bis already requires you to return SCTs in some lookups... >> >> You meen get-entries? I don't see how that's relevant. An SCT can be >> generated given the data in leaf_input. No need to store it, unless you >> wanted to for caching of course (we do that on frontend nodes). There's >> a big difference between doing this and indexing on SCT's though. > > I agree there's a difference. I am curious what architecture makes it > a big difference, though! Here's why adding SCT's to the database is hard in our implementation. - SCT's can not be included in the entry stored in the database Our system doesn't trust its frontend nodes. Therefore our signing nodes refuse to produce an SCT for an entry until they know that the entry has been stored at a configured quorum of storage nodes. Once an entry has been stored it doesn't change. >From this follows that the SCT can not be included in the entry. - SCT's can not easily be added to the database, like in a new table or similar We don't have a database distribution mechanism for anything else than log entries that almost always already are present at all storage nodes. Adding a new type of data is doable but will take some redesign. - One a side note, good we require deterministic signature algorithms Using an SCT as a unique key seems hard at first, until you realise that 6962-bis mandates deterministic signatures. This is fortunate if your key-value store isn't multi-value, which ours is not (because complicated if you want to write once and never change, only append). Design documents for catlfish, the database and one of the database backends below. Happy to talk more about this. - https://git.nordu.net/?p=catlfish.git;a=blob;f=doc/design.txt - https://git.nordu.net/?p=plop.git;a=blob;f=doc/db.md - https://git.nordu.net/?p=plop.git;a=blob;f=doc/permdb.md From nobody Fri Jun 3 04:07:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA3A12D5D3 for ; Fri, 3 Jun 2016 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordu.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-LMGBGClELv for ; Fri, 3 Jun 2016 04:07:40 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3097312D5CF for ; Fri, 3 Jun 2016 04:07:40 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u53B7bFp024027 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Jun 2016 13:07:37 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.113.41]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id u53B7YqS001042 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jun 2016 11:07:37 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1464952057; bh=/XrN37M4euOCtctGuj2MwLBHyWRTGMrz8+Cb5vcprkU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=C1JRmjCfD0rcICT47Mv+KZ/oMm4Tj7pE8amCDnA/HepzhzrqnqJp0p6rgZM6Rvipg njxgjJo0iM+0mRUtoU2lJ08Cqj3C7powdfO4dW3HGZ/OWwiWS8O86+s55Xk2T8oISn MCFYottUQlr6sIveEOcp6kL5Qiq9dFxQc00nqqpc= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 3 Jun 2016 13:07:33 +0200 From: Linus Nordberg To: Melinda Shore Organization: NORDUnet A/S References: Date: Fri, 03 Jun 2016 13:07:30 +0200 In-Reply-To: (Melinda Shore's message of "Thu, 2 Jun 2016 13:21:54 -0800") Message-ID: <871t4eedjh.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.113.41; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aR2b7BF2 - fc63fbe40929 - 20160603 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.113.41 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.113.41; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 11:07:42 -0000 Melinda Shore wrote Thu, 2 Jun 2016 13:21:54 -0800: > We've put in a session request for the upcoming IETF meeting, > but may choose to cancel it if we feel that there's not enough > activity on the mailing list to justify it. If you feel you've > got an issue that needs face-to-face discussion, 1) get a > mailing list discussion going, and 2) let us know. CT Gossip will see an update before Berlin, hopefully removing enough TBD's to make it move towards last call. From nobody Sat Jun 4 12:01:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35612D629 for ; Sat, 4 Jun 2016 12:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnVpYco_FJ37 for ; Sat, 4 Jun 2016 12:01:21 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE37612D5BB for ; Sat, 4 Jun 2016 12:01:20 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id z189so14513567itg.0 for ; Sat, 04 Jun 2016 12:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=tQnMAcyuC9oFHkD+fLak71R2J6ox2b7aH+1Ws/dJUAo=; b=iCBe/g2qopfUHCW7yvoNgtZwcLfBjX36EkoAFzHCBAzLxANbnjM6fTUB1xW4Ykt77+ Iu136EhWD8QYuMFeRB/gQT0eqWipaBWDmAdLtNn1CCefT5gXe5Oc0OsOsTn6lpWKY2Bm 2OiG6Otg32wL+ihCoWZWPh5h8kVLpAT4bkM0RFwjumSIonYG62CFIaIwbKafurEi9U3V rQtVQ8RxOsx9NpIE1dPd6WztfgRIbiOi9mGf4J8IqBJLo9BdjFmuGWS9VUyxrP14LC7P 5EsRDf0j7rZdHg633JA63TNQxdWM7rPhalSgR8bzjOvaLs72+wjqyE9KpawueQHDGURL smWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tQnMAcyuC9oFHkD+fLak71R2J6ox2b7aH+1Ws/dJUAo=; b=ZCoCTiFM2N8Yf4kSEYv5kEJLiwwQewFMjPUkl7ZxeEc2BHCAelaM92E/j64Zq71Vv0 wM38+z7vSdgbqOWYV/ue1aADXc1iObY5E3Ej2Y0q6khzqIgRbr/ku/dwY93kRNrDqSAk DPKjgME5t8JMrHk21tRzIU7SMyJHAbAsyXY7fwHA0wIW+8/Lng4Q41Hyz8FpOOTD8nCC +lfkTa6loEZMX+kZ3UaLJbKPjEqQgWn2J5+8CPVAEtbVYxi3BjnGOzIn5CteVn2NA+Zh kIWu/+BcAcn5endt64J+hanemHE7q5DC5eRWO9rgcB0imC4A5/6zrRLlb5b2iPXLm/UN fgrw== X-Gm-Message-State: ALyK8tJ4SjYUFhDlEL0f1nMVhJwy8LTDZqIuPF2EdoIIPOOC1laZkiIPsbYMUm6heNWyZxgB6Emwd9E2lkY1Jg== X-Received: by 10.36.50.132 with SMTP id j126mr7048073ita.70.1465066880226; Sat, 04 Jun 2016 12:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.34.45 with HTTP; Sat, 4 Jun 2016 12:01:19 -0700 (PDT) From: Peter Bowen Date: Sat, 4 Jun 2016 12:01:19 -0700 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 19:01:23 -0000 Section 5.1 has a requirement that a log MUST only accept certificates (or precertificates) that include a full valid chain to a trusted root in the submission. This appears to exclude any option for a log to have a priori knowledge of intermediate CAs and accept submissions with incomplete chains. It also means that the log cannot decide to accept certificates that are incorrectly constructed by the CA. I would suggest the following alternative for the first paragraph of 5.1: Logs SHOULD verify that each submitted certificate or precertificate has a valid signature chain to an accepted trust anchor, using the chain of intermediate CA certificates provided by the submitter. Logs MUST accept certificates and precertificates that are fully valid according to RFC 5280 verification rules and are submitted with such a chain. Logs MAY accept certificates and precertificates that have expired, are not yet valid, have been revoked, or are otherwise not fully valid according to RFC 5280 verification rules in order to accommodate quirks of CA certificate-issuing software. However, logs MUST reject submissions without a known valid signature chain to an accepted trust anchor. Logs SHOULD also reject precertificates that do not conform to the requirements in . Logs MAY accept objects other than certificates and precertificates that have a known valid signature chain to an accepted trust anchor. Thanks, Peter From nobody Sat Jun 4 15:17:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0249A12D675 for ; Sat, 4 Jun 2016 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ6C6oToGK-Y for ; Sat, 4 Jun 2016 15:17:09 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C9D12D673 for ; Sat, 4 Jun 2016 15:17:08 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k19so97778386ioi.3 for ; Sat, 04 Jun 2016 15:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ODpkeJroV78P5c1lqnBMZ4dS0xxq8XP0RUkkQ6U2Qo=; b=pfEPKmPuM3xU+WFzEGOtIaYh8u4utMFzJvJgP/C0MT4mfc3xFrqoNMWPcPNOgMDNH5 mk1BFEPfXv2ll8PGKk22WSbICZwIMyoiY6quhbdfJzpmB+OlRcvAqspzeRyUDnCQOoCt NfyfpKHd4Qb2yMlDZ72Zccrl3TI3DVUpraHk39QLbyhOAujmxJmrC2XfqfCsN5QsZtWw WOaMCozmhfT+tZl15JBO8bP+tO6ShK7VvIY02ycAAyE/tASy+1/aRzoh4hkIScVfULlZ L3JVBKpUNjgIoj6E04xZZOT9KOWvJ0d23H+iQzOPaU43il7I05NwsyvfflpVsg0FyvnW CE2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8ODpkeJroV78P5c1lqnBMZ4dS0xxq8XP0RUkkQ6U2Qo=; b=k2d8DBCK5CP73zuUFvoxWQVzMUkp679mSCM6iquNm3omMgmSdrlviZMCMJl73MRCBr pcLCLBZyjYHG6myOhtXCLXtnVnyLpg/q6FGrIl1UGvJeBCy8KuIzRd70IeVvnVZptpxQ ut3gT34BYifuCIkRBRHrjH+ENG7suK+8JLBDZDz08uupDGUMK2HBYG6Lvaw0FTJfB8q8 cM8Yvvic8vtnktglv8hzNRlo9oTiA8P33xHTldx+BN4jkpWYdd22E/PF00U38esH1dpN MxnM/NjFP7Vnz9Cc4S4FWFcMmRjDUs3I9zpSTXMgn8lsxvT+Wspa3JjZSgKBVLY3sGis crkw== X-Gm-Message-State: ALyK8tKywsidMPC/0zhtAKDnO1oU7nH8tnRvrsp1aqpJj6XPa5/sWM6eeM0j7ppViws9KhiHRwCw2fzgoHGU0wIh X-Received: by 10.107.26.85 with SMTP id a82mr13575029ioa.13.1465078628104; Sat, 04 Jun 2016 15:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.72 with HTTP; Sat, 4 Jun 2016 15:17:07 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Sat, 4 Jun 2016 23:17:07 +0100 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=001a113fd58632914005347b33cd Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 22:17:11 -0000 --001a113fd58632914005347b33cd Content-Type: text/plain; charset=UTF-8 On 4 June 2016 at 20:01, Peter Bowen wrote: > Section 5.1 has a requirement that a log MUST only accept certificates > (or precertificates) that include a full valid chain to a trusted root > in the submission. This appears to exclude any option for a log to > have a priori knowledge of intermediate CAs and accept submissions > with incomplete chains. It also means that the log cannot decide to > accept certificates that are incorrectly constructed by the CA. > > I would suggest the following alternative for the first paragraph of 5.1: > > Logs SHOULD verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. Logs > MUST accept certificates and precertificates that are fully valid > according to RFC 5280 verification rules > and are submitted with such a chain. Logs MAY accept certificates and > precertificates that have expired, are not yet valid, have been > revoked, or are otherwise not fully valid according to RFC 5280 > verification rules in order to accommodate quirks of CA > certificate-issuing software. However, logs MUST reject submissions > without a known valid signature chain to an accepted trust anchor. > Logs SHOULD also reject precertificates that do not conform to the > requirements in . Logs MAY accept > objects other than certificates and precertificates that have a known > valid signature chain to an accepted trust anchor. > I think this is all getting too complicated and in the wrong direction. The intent of this section was that logs should have some mechanism to control spam. We (the authors) had decided that the mechanism was going to be "issued by a trusted CA" for some value of "trusted", which is fine, but should not have been enshrined. The intent is that logs should contain information that may or may not be of interest to you. They are not arbiters of truth or correctness (other than their own honesty). Spam makes logs difficult to use, so they need a spam control mechanism. But we should not mandate what that mechanism is. Yes, I am saying my own I-D is wrong. :-) I think the fix is to say that logs should take measures to limit their size, e.g. "chains up to a trusted CA", but not mandate what that mechanism is. Browsers, monitors, etc, can make up their own minds what a reasonable size for a log is. Presumably something not wildly different from the size of the set of certs they are interested in. > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a113fd58632914005347b33cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 June 2016 at 20:01, Peter Bowen <pzbowen@gmail.com>= wrote:
Section 5.1 has a requirement tha= t a log MUST only accept certificates
(or precertificates) that include a full valid chain to a trusted root
in the submission.=C2=A0 This appears to exclude any option for a log to have a priori knowledge of intermediate CAs and accept submissions
with incomplete chains.=C2=A0 It also means that the log cannot decide to accept certificates that are incorrectly constructed by the CA.

I would suggest the following alternative for the first paragraph of 5.1:
Logs SHOULD verify that each submitted certificate or precertificate
has a valid signature chain to an accepted trust anchor, using the
chain of intermediate CA certificates provided by the submitter. Logs
MUST accept certificates and precertificates that are fully valid
according to <xref target=3D"RFC5280">RFC 5280</xref>= verification rules
and are submitted with such a chain. Logs MAY accept certificates and
precertificates that have expired, are not yet valid, have been
revoked, or are otherwise not fully valid according to RFC 5280
verification rules in order to accommodate quirks of CA
certificate-issuing software. However, logs MUST reject submissions
without a known valid signature chain to an accepted trust anchor.
Logs SHOULD also reject precertificates that do not conform to the
requirements in <xref target=3D"Precertificates"/>.=C2=A0 L= ogs MAY accept
objects other than certificates and precertificates that have a known
valid signature chain to an accepted trust anchor.
I think this is all getting too complicated and in the wrong di= rection.

The intent of this section was that logs = should have some mechanism to control spam. We (the authors) had decided th= at the mechanism was going to be "issued by a trusted CA" for som= e value of "trusted", which is fine, but should not have been ens= hrined.

The intent is that logs should contain inf= ormation that may or may not be of interest to you. They are not arbiters o= f truth or correctness (other than their own honesty). Spam makes logs diff= icult to use, so they need a spam control mechanism. But we should not mand= ate what that mechanism is.

Yes, I am saying my ow= n I-D is wrong. :-)

I think the fix is to say that= logs should take measures to limit their size, e.g. "chains up to a t= rusted CA", but not mandate what that mechanism is.

Browsers, monitors, etc, can make up their own minds what a reasonab= le size for a log is. Presumably something not wildly different from the si= ze of the set of certs they are interested in.


Thanks,
Peter

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

--001a113fd58632914005347b33cd-- From nobody Sat Jun 4 15:20:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC03512D60B for ; Sat, 4 Jun 2016 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVem8BCBRAVa for ; Sat, 4 Jun 2016 15:20:06 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A975012D1BE for ; Sat, 4 Jun 2016 15:20:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rMb4N4mBLz5Bv; Sun, 5 Jun 2016 00:20:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id IkzwTYv-otSd; Sun, 5 Jun 2016 00:20:03 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 5 Jun 2016 00:20:03 +0200 (CEST) Received: from [193.111.228.70] (unknown [193.111.228.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 6EBEF677A63; Sat, 4 Jun 2016 18:20:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6EBEF677A63 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9F7802BA-0635-4600-9225-CD9038AC23CE@nohats.ca> X-Mailer: iPhone Mail (13F69) From: Paul Wouters Date: Sat, 4 Jun 2016 18:19:52 -0400 To: Peter Bowen Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 22:20:09 -0000 As long as it chains to a valid root, wouldn't we want to log it? So we beco= me aware of previously unknown intermediates? Paul Sent from my iPhone > On Jun 4, 2016, at 15:01, Peter Bowen wrote: >=20 > Section 5.1 has a requirement that a log MUST only accept certificates > (or precertificates) that include a full valid chain to a trusted root > in the submission. This appears to exclude any option for a log to > have a priori knowledge of intermediate CAs and accept submissions > with incomplete chains. It also means that the log cannot decide to > accept certificates that are incorrectly constructed by the CA. >=20 > I would suggest the following alternative for the first paragraph of 5.1: >=20 > Logs SHOULD verify that each submitted certificate or precertificate > has a valid signature chain to an accepted trust anchor, using the > chain of intermediate CA certificates provided by the submitter. Logs > MUST accept certificates and precertificates that are fully valid > according to RFC 5280 verification rules > and are submitted with such a chain. Logs MAY accept certificates and > precertificates that have expired, are not yet valid, have been > revoked, or are otherwise not fully valid according to RFC 5280 > verification rules in order to accommodate quirks of CA > certificate-issuing software. However, logs MUST reject submissions > without a known valid signature chain to an accepted trust anchor. > Logs SHOULD also reject precertificates that do not conform to the > requirements in . Logs MAY accept > objects other than certificates and precertificates that have a known > valid signature chain to an accepted trust anchor. >=20 > Thanks, > Peter >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Sat Jun 4 15:50:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1E12D66D for ; Sat, 4 Jun 2016 15:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voLox7G_Mq9Z for ; Sat, 4 Jun 2016 15:50:23 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5029712D0BB for ; Sat, 4 Jun 2016 15:50:23 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id p194so111976361iod.1 for ; Sat, 04 Jun 2016 15:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BnanAz0bEbIk6+oD/eyCd24Lmx3BzFY1kA6ZorXs6T8=; b=Uc2oN4kpbqFXtq5/A3c5HDIE6Lx5B9tlt7H/wMYQua4BXovDLhH5JcUXK2JFLG6Hnr gUOsb3qbCazJH/hwpSfeB0EOjMhLLfKHua6YVCtCC6+DKOKbgONgesX7oXnNBAjfwW+1 Ja14OzE0Z3tl02vZVVQ/cVdx+1I0SDPB6UlpMPY3V6BD4IRQijIgCXAe5ilZcFeW+1SR VhTrplnByxAXr5CaD4xbhHY+G+kCQqWjrOm2zd4BtZrevqca9gMV6zaUk/SUhMc0nQVH DTiVZBF282aOAMrHB+3FJlreXXUvjhRsQwMU543AAWKj3CqsgUt+sSgvO/pxg+0Ulg5z 5otA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BnanAz0bEbIk6+oD/eyCd24Lmx3BzFY1kA6ZorXs6T8=; b=Y5axK8hnULg6ptV0wlR3Q5dq7nznetntqAy5cFDbfxNmRwfYq9l/xJEKALy8AdXrO/ zCf9AKJmhrtUcusxZGs7Tw8+/glw1boCm+yWnQ7++Gm4S/149TlFwfRs7DJHkiIm+q5X sVuyikZD2p6g3rbRKGT+eWON9HzlkkMPQfK4aGPhGOS1Ju5cvjhMWYClyLfsdalV90AG aBadFcLTdqO+lFYrlBVzSUXbDdX1wsEXK+FlaDBLfPDpSUaRZ3e7MPusT//slS/fUF5J 67FsfbfQdDX+aoEe5BBMrUDbEQjqLNFqBc5LOtZPK4nUaDsIvsPbehknJBLfE3OhpLNG 65cQ== X-Gm-Message-State: ALyK8tKbDDGGYAFmcTgNO0kxphrgIBw2oIfnvgvFGy3xMTjKvO0OgSSQbdVQ18tN/t1yYabXmqfuQJtp2zqtYw== X-Received: by 10.107.170.94 with SMTP id t91mr12879338ioe.58.1465080622556; Sat, 04 Jun 2016 15:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.175 with HTTP; Sat, 4 Jun 2016 15:50:22 -0700 (PDT) In-Reply-To: References: From: Peter Bowen Date: Sat, 4 Jun 2016 15:50:22 -0700 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 22:50:27 -0000 On Sat, Jun 4, 2016 at 3:17 PM, Ben Laurie wrote: > > > On 4 June 2016 at 20:01, Peter Bowen wrote: >> >> Section 5.1 has a requirement that a log MUST only accept certificates >> (or precertificates) that include a full valid chain to a trusted root >> in the submission. This appears to exclude any option for a log to >> have a priori knowledge of intermediate CAs and accept submissions >> with incomplete chains. It also means that the log cannot decide to >> accept certificates that are incorrectly constructed by the CA. >> >> I would suggest the following alternative for the first paragraph of 5.1: >> >> Logs SHOULD verify that each submitted certificate or precertificate >> has a valid signature chain to an accepted trust anchor, using the >> chain of intermediate CA certificates provided by the submitter. Logs >> MUST accept certificates and precertificates that are fully valid >> according to RFC 5280 verification rules >> and are submitted with such a chain. Logs MAY accept certificates and >> precertificates that have expired, are not yet valid, have been >> revoked, or are otherwise not fully valid according to RFC 5280 >> verification rules in order to accommodate quirks of CA >> certificate-issuing software. However, logs MUST reject submissions >> without a known valid signature chain to an accepted trust anchor. >> Logs SHOULD also reject precertificates that do not conform to the >> requirements in . Logs MAY accept >> objects other than certificates and precertificates that have a known >> valid signature chain to an accepted trust anchor. > > > I think this is all getting too complicated and in the wrong direction. > > The intent of this section was that logs should have some mechanism to > control spam. We (the authors) had decided that the mechanism was going to > be "issued by a trusted CA" for some value of "trusted", which is fine, but > should not have been enshrined. > > The intent is that logs should contain information that may or may not be of > interest to you. They are not arbiters of truth or correctness (other than > their own honesty). Spam makes logs difficult to use, so they need a spam > control mechanism. But we should not mandate what that mechanism is. > > Yes, I am saying my own I-D is wrong. :-) > > I think the fix is to say that logs should take measures to limit their > size, e.g. "chains up to a trusted CA", but not mandate what that mechanism > is. > > Browsers, monitors, etc, can make up their own minds what a reasonable size > for a log is. Presumably something not wildly different from the size of the > set of certs they are interested in. Ah, good. My preference is that the I-D/RFC only discuss the technical details and leave policy to the log operator. Given that the doc is in last call, I was trying to take a compromise approach by leaving in most of the existing text. What about just removing the whole first paragraph? Thanks, Peter From nobody Mon Jun 6 10:29:39 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072312D10F for ; Mon, 6 Jun 2016 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.497 X-Spam-Level: * X-Spam-Status: No, score=1.497 tagged_above=-999 required=5 tests=[ADVANCE_FEE_3_NEW=3.499, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id japukpU0gTXM for ; Mon, 6 Jun 2016 10:29:37 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110D912B04B for ; Mon, 6 Jun 2016 10:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465234176; bh=nof7EdPyhrjiHwU+KceOjdgRPJm14Y9PBP7gxvCM1Q4=; h=Date:From:To:Subject; b=rwM6Q+wGFLBxSRB5hOYuorsmeVXWKUKzGQ6gY2n54VqBJ37I0ddiexNC3aonuCi6b cyBef4Nyp8pTxfhy+332XgFiP9PvqShRF+WWFMx+pXP6g3lhqYbRaBBB4kcVMIuNsg NpD5t/zEqpo6uHXJKDsaP1qjLQI190qjVWsk17/aA6DsccUlnk5WHeWkE4lKj6U9aI SFIQH0ShAfj7Qwbg91m3rioG7rcoZ+juewpASoyEuETu3sShIDbU6ow6nZYbzrXdoT 7SpSHnXt/GYVmLb6P08gQk5ckZz8FJ4AeBLOExUXPv2wu2fwgHsHEBWou7KlTkxhlh HXxW5gLdI3PIg== Date: Mon, 6 Jun 2016 10:29:35 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:29:38 -0000 When name redaction is used, certificates with different DNS names (but which are otherwise identical) can have the same reconstructed TBSCertificate, and can therefore be paired with an SCT for the same pre-certificate. This enables the following attack: 1. A CA issues a legitimate certificate for www1.example.com and logs a pre-certificate for ?.example.com. A monitor for example.com knows the pre-certificate is legitimate because it matches a known certificate for www1.example.com. 2. The CA misbehaves and issues an unauthorized certificate for www2.example.com which, except for the DNS name, has exactly the same details (including serial number and public key) as the certificate for www1.example.com. The CA does not log a certificate or pre-certificate. 3. An attacker serves the rogue certificate for www2.example.com along with the SCT for the ?.example.com pre-certificate. TLS clients accept it because the TBSCertificate that is reconstructed from the certificate matches the TBSCertificate of the pre-certificate. Monitors have no idea that there is a rogue certificate for www2.example.com. Although this attack is limited because it requires the rogue certificate to use the same key as the legitimate certificate, it's still a problem. The private key for the legitimate certificate might be controlled by a third party that is authorized to operate one sub-domain of example.com not not another. It also means that the compromise of one certificate's key could be used to attack other sub-domains. This should be fixed. I'm implementing a monitor that supports name redaction, and the only viable way I can find to handle name redacted pre-certificates is to match them against a database of known certificates. Otherwise, the domain owner is left uncertain what the redacted labels are. If a pre-certificate can correspond to more than one certificate, the uncertainty can never be eliminated. One fix is to replace redacted labels not with '?' but with a salted cryptographic hash of the label, with the salt specified in the Redacted Labels Certificate Extension. (This is similar to the proposal by Peter Bowen to use CRC-32 two years ago[1], except a cryptographic hash is used for pre-image resistance, and a salt is used to prevent dictionary attacks.) Unfortunately, this increases complexity. Regards, Andrew [1] https://mailarchive.ietf.org/arch/msg/trans/pbooERCZ9hAn8GmVVkWLKaDzq9Y From nobody Mon Jun 6 10:53:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8EF12D881 for ; Mon, 6 Jun 2016 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIa_MW1L5LmD for ; Mon, 6 Jun 2016 10:53:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7D212D0A8 for ; Mon, 6 Jun 2016 10:53:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rNj3J51f0z3nv; Mon, 6 Jun 2016 19:53:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VZPWBjECuZTY; Mon, 6 Jun 2016 19:52:59 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 6 Jun 2016 19:52:59 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B8C3F378B46; Mon, 6 Jun 2016 13:52:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B8C3F378B46 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 922AB406B809; Mon, 6 Jun 2016 13:52:57 -0400 (EDT) Date: Mon, 6 Jun 2016 13:52:57 -0400 (EDT) From: Paul Wouters To: Andrew Ayer In-Reply-To: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> Message-ID: References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: Trans Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:53:06 -0000 On Mon, 6 Jun 2016, Andrew Ayer wrote: > This enables the following attack: > > 1. A CA issues a legitimate certificate for www1.example.com and logs a > pre-certificate for ?.example.com. A monitor for example.com knows the > pre-certificate is legitimate because it matches a known certificate > for www1.example.com. > > 2. The CA misbehaves and issues an unauthorized certificate for > www2.example.com which, except for the DNS name, has exactly the same > details (including serial number and public key) as the certificate for > www1.example.com. The CA does not log a certificate or pre-certificate. > > 3. An attacker serves the rogue certificate for www2.example.com along > with the SCT for the ?.example.com pre-certificate. TLS clients accept > it because the TBSCertificate that is reconstructed from the certificate > matches the TBSCertificate of the pre-certificate. Monitors have no > idea that there is a rogue certificate for www2.example.com. That means the attacker has the private key? I guess when the second certificate would be logged, this would show up as mis-issued, and possibly both certificates would get revoked? Wouldn't that be the system working as intended? Paul From nobody Mon Jun 6 11:17:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00612D516 for ; Mon, 6 Jun 2016 11:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VstHpMNUZhNd for ; Mon, 6 Jun 2016 11:17:46 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5E012D1A3 for ; Mon, 6 Jun 2016 11:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465237065; bh=BrNzjTHdBPRko8JvWYTijrJp1/bpwX1K/wY9NgGTSMw=; h=Date:From:To:Subject:In-Reply-To:References; b=OrIVZahbS17c5BkgBHkS3h9SPlpd0cWcIenFbxyiTKcqpzgFLp+urmV+ym2c/kge4 NO++SQv6dtM7E4F/SRPaTTJkQ0nXrWccYmN+rdu1FW4k2eo7GNJRoUmWxNRun9JIeQ 6c9NWUyHU3EnQf63XFG3ajKe5n6TZl989DzQNkgDGFaMsj99c9GjtsZ1+x+gqA7yDb U4uRr4fRXG2JiJ8ReZI2LYFDaXaW/Xo16BxzGRy8HJAnzOjYCIdAnCo02cicYbZYl6 eZcc1Mu5p/2LWMHt79IKSFml9v0xWtZ40P4hxt/gJ3dDbWMTv3xccUdK4MwR6+huRe a4USkz4rc8VAw== Date: Mon, 6 Jun 2016 11:17:44 -0700 From: Andrew Ayer To: Trans Message-Id: <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> In-Reply-To: References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:17:48 -0000 On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) Paul Wouters wrote: > On Mon, 6 Jun 2016, Andrew Ayer wrote: > > > This enables the following attack: > > > > 1. A CA issues a legitimate certificate for www1.example.com and > > logs a pre-certificate for ?.example.com. A monitor for > > example.com knows the pre-certificate is legitimate because it > > matches a known certificate for www1.example.com. > > > > 2. The CA misbehaves and issues an unauthorized certificate for > > www2.example.com which, except for the DNS name, has exactly the > > same details (including serial number and public key) as the > > certificate for www1.example.com. The CA does not log a > > certificate or pre-certificate. > > > > 3. An attacker serves the rogue certificate for www2.example.com > > along with the SCT for the ?.example.com pre-certificate. TLS > > clients accept it because the TBSCertificate that is reconstructed > > from the certificate matches the TBSCertificate of the > > pre-certificate. Monitors have no idea that there is a rogue > > certificate for www2.example.com. > > That means the attacker has the private key? Yes, but that only limits the attack, not eliminate it. It means that if the attacker gets the private key for one host, they can (with CA collusion) pivot to attacking other hosts whose names match the same redaction pattern. > I guess when the second certificate would be logged, this would show > up as mis-issued, and possibly both certificates would get revoked? The second certificate would never be logged. The way that logging is enforced is that clients reject certificates that aren't accompanied by a valid SCT. But since an SCT for the first certificate's pre-certificate can be used to prove that the second certificate was logged, clients can be tricked into accepting the second certificate even if it was never logged. That's basically the crux of the problem - with name redaction, SCTs do not prove that a certificate was logged, they only prove that some pre-certificate matching the name redacted pattern was logged. I argue that for monitoring to be useful, SCTs need to prove that a pre-certificate matching the exact name was logged. Regards, Andrew From nobody Tue Jun 7 12:59:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96D312D0A8 for ; Tue, 7 Jun 2016 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rji7ZXLcep53 for ; Tue, 7 Jun 2016 12:59:41 -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 193B612D195 for ; Tue, 7 Jun 2016 12:59:36 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:39006 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bAN9u-000Hc4-O4 for trans@ietf.org; Tue, 07 Jun 2016 15:59:30 -0400 To: trans@ietf.org References: From: Stephen Kent Message-ID: <575727A2.90502@bbn.com> Date: Tue, 7 Jun 2016 15:59:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 19:59:43 -0000 Ben, I disagree with the suggestion to relegate all "spam" control mechanisms to per-log, locally-determined controls. This is another example of 6269-bis not being written as a standard, but as just a set of guidelines. Allowing another way for logs to behave in a fashion that is not predictable by log clients, except, perhaps, by trial and error, is not, IMHO, a good idea. Steve From nobody Wed Jun 8 04:46:00 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFD212D6A7 for ; Wed, 8 Jun 2016 04:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 744YRJtEfV8A for ; Wed, 8 Jun 2016 04:45:56 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D912B024 for ; Wed, 8 Jun 2016 04:45:54 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h190so6228805ith.1 for ; Wed, 08 Jun 2016 04:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W8dzjInGgIAlvtyjvKPW6tqvB7oR7IrOGACkhYUiorQ=; b=HOncdTUaa4ND1mCqc2YmoZOLj0koXXEkcXmhvzLAAmcCfhDRxmmuDXhjj/vWBREnQU 4KeZ6UlKWgwLuhOL/BZ2AmdEnuBrz+X+vsE6D8e8FMYkNP2sUG7ji+RsHHyyhZs2W/eJ DWaFZWs0ZNwIK8/TXPJcmQUjlqLVqxORK0xRypyNk4VgVswEeEVGdPXIXJJnAszEsrQu rm44Bs16xtwwboq2GAdlfRLbrpzcg99kTR65Sa7SwkmbPIPj+kpqPa4AsO2w2MmKJkwX b2kVZuAlBCRYigm6P/gUVyY8zcUlyhoynzaGki1mACXDnbLai+zNjCcbzkDJ6Q7tUsFq Ehbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W8dzjInGgIAlvtyjvKPW6tqvB7oR7IrOGACkhYUiorQ=; b=VacdaWsfAKq1aouPgMFWbNCV5e39MAli3j+5DVDIoiOir1j3sp35EwtSTJxmp70fZ/ EMDzE/A3AYj/PGTR+/ds9OTFNDAOl9QIrvTpsxpinricM6jaR42/Dv4/l4ap4lKQwdVs IY4lrrVH4swVjhRQkTZLIrZrx4Ny3S2gY1j4bBKr8f+sYjISs4iW65My6RYcbITz1o7z 7GL6Nb61/qTkr09XwpXbJ/Wp4OZ7fBOfxKSpLU3vrE5ge36ix2KaC2U8IazdYWHwtfu3 0W5DskK196He0ozRXfSBUv3arPtnqrkKsa7cppPDVrtouoRUwGtVAPMgYGSzyRs+OWh/ wC2A== X-Gm-Message-State: ALyK8tKHzpgWp0oyg58tw63LhdVBh1hELkhLDuYPf3wtIDvOjbW3F/bcrBY3EaBCYHhWRs49DOBHw5Z8/Vs7mFmd X-Received: by 10.36.66.68 with SMTP id i65mr12108591itb.91.1465386353405; Wed, 08 Jun 2016 04:45:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.72 with HTTP; Wed, 8 Jun 2016 04:45:52 -0700 (PDT) In-Reply-To: <575727A2.90502@bbn.com> References: <575727A2.90502@bbn.com> From: Ben Laurie Date: Wed, 8 Jun 2016 12:45:52 +0100 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11449d140f2efe0534c2d94d Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:46:00 -0000 --001a11449d140f2efe0534c2d94d Content-Type: text/plain; charset=UTF-8 On 7 June 2016 at 20:59, Stephen Kent wrote: > Ben, > > I disagree with the suggestion to relegate all "spam" control mechanisms to > per-log, locally-determined controls. This is another example of 6269-bis > not being written as a standard, but as just a set of guidelines. Allowing > another way for logs to behave in a fashion that is not predictable by log > clients, > except, perhaps, by trial and error, is not, IMHO, a good idea. > The point here is to allow logs to be more liberal in what they accept, which is surely a benefit? Logs should still be required to accept well-formed chains to known roots, that I definitely agree with. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11449d140f2efe0534c2d94d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 June 2016 at 20:59, Stephen Kent <kent@bbn.com> wrote:
Ben,

I disagree with the suggestion to relegate all "spam" control mec= hanisms to
per-log, locally-determined controls. This is another example of 6269-bis not being written as a standard, but as just a set of guidelines. Allowing<= br> another way for logs to behave in a fashion that is not predictable by log = clients,
except, perhaps, by trial and error, is not, IMHO, a good idea.

The point here is to allow logs to be more liberal= in what they accept, which is surely a benefit? Logs should still be requi= red to accept well-formed chains to known roots, that I definitely agree wi= th.

=C2=A0

Steve


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

--001a11449d140f2efe0534c2d94d-- From nobody Wed Jun 8 11:41:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1393412D0EB for ; Wed, 8 Jun 2016 11:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StExVovjB_XO for ; Wed, 8 Jun 2016 11:41:44 -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 96C4112D0FB for ; Wed, 8 Jun 2016 11:41:44 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33525 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bAiQ6-000Bk7-Bx for trans@ietf.org; Wed, 08 Jun 2016 14:41:38 -0400 To: trans@ietf.org References: <575727A2.90502@bbn.com> From: Stephen Kent Message-ID: <575866E2.4010408@bbn.com> Date: Wed, 8 Jun 2016 14:41:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Section 5.1 (Accepting Submissions) revision X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:41:46 -0000 Ben, Jon Postel's adage is generally a good idea for interoperability, in general. I thought the suggestion here was to suggest that logs may impose other criteria on submissions, e.g., chain length to a set of known (hopefully advertised) trust anchors, and that these criteria would not be easily known by submitters. perhaps I misunderstood the suggestion. Steve > > ... > > The point here is to allow logs to be more liberal in what they > accept, which is surely a benefit? Logs should still be required to > accept well-formed chains to known roots, that I definitely agree with. From nobody Wed Jun 8 11:47:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75F012B01D for ; Wed, 8 Jun 2016 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrPTluqcgs3a for ; Wed, 8 Jun 2016 11:47:25 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AE81200A0 for ; Wed, 8 Jun 2016 11:47:24 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id y124so5119729pfy.0 for ; Wed, 08 Jun 2016 11:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=vj3P39YVaHyP8oInqxm/Ywwr4aPtftG1Dd8J/t3wYpM=; b=d8j9ALQN5Gn/XEHuNDaOokql2GCmq3uN03/NQt9CGxe/4JRm/eRlu282uk80SGB0l0 OEweXuD0kbqQS5VWfkkSSxnxzQz/Hb70207OsG1tiOZddtS5r746gmdIhOIoi9priaNQ WgpXdPybERHaZtvb1+I9VqxjkFFK0pfTaLktMey1QVjIwxihkftaoCTKW4ILd9SDcfCh t7c3X7hDz/pa0GxUCcxPEwVk3ALNANGKCGG2IhKElLdmAOR4caFl3P8ostYmISzw85MQ ERQe+5HpoHu0zxoTQbZxZG5oajelNNngK3lltjNmz8bKcUa63ZOaYpBd3Hlqujg6B38m C0oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=vj3P39YVaHyP8oInqxm/Ywwr4aPtftG1Dd8J/t3wYpM=; b=Ik5os2sYKgmyJuWACzXi4AxPVX+LHD9K3I0AZ5AaM5f1aJsHogDwgnLCiHrnby5Pm3 WGZb9P59nSo1mAYX7r9pQBZi0KcjoEQyRRnCCEr/lDs5GUSL4ep83SqluFatEpc963iw R0jeKXdg0gNicMD8hILtaZE8C57yMRnRddgfpW3UQMU+fLWiIXl26ODarYjGAiZGC6lr kt6AFXkWGyQC45vKED64aGjR/HaXK7v/iIjZYUkZDARiXKTmyEjIkQ75BeIagQ015F3P 1sKZS12o7+Kg549iC/WGR+6k8Xjw7qHWf/e/tqybv7pPTO1utoGkQSu6RQM3n4TrKJCx ve/Q== X-Gm-Message-State: ALyK8tJ824Yxz8AEVnhzQg4Hd9ASlRj201DGMzgnbJhLl/W1McZoqB1uTYd7ln33th37Ug== X-Received: by 10.98.102.25 with SMTP id a25mr7304225pfc.30.1465411644338; Wed, 08 Jun 2016 11:47:24 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-21-246-radius.dynamic.acsalaska.net. [216.67.21.246]) by smtp.googlemail.com with ESMTPSA id k69sm4107102pfc.41.2016.06.08.11.47.23 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Jun 2016 11:47:23 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> Date: Wed, 8 Jun 2016 10:47:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:47:27 -0000 Hi, all: We'd like to restart working group last call on the threat analysis draft (https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/) but I wanted to make sure that any serious concerns have been addressed. In particular, it seems as if there may be some unresolved questions about the conspiring CA attack identified by DKG. Do you all feel that the document is ready for working group last call, and that any issues blocking it from being sent on to the IESG have been resolved? Thanks, Melinda From nobody Wed Jun 8 11:50:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB212D0BD for ; Wed, 8 Jun 2016 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRlFb9Dgw0fJ for ; Wed, 8 Jun 2016 11:50:16 -0700 (PDT) Received: from iruno.ripn.net (iruno.ripn.net [IPv6:2001:6d0:ffd9:306:194:226:71:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238DD12B05C for ; Wed, 8 Jun 2016 11:50:16 -0700 (PDT) Received: from beldmit by iruno.ripn.net with esmtp (RIPN) id 1bAiYP-0007SJ-Sx for trans@ietf.org; Wed, 08 Jun 2016 21:50:13 +0300 To: trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> From: Dmitry Belyavsky Message-ID: <575868E5.7010908@tcinet.ru> MIME-Version: 1.0 In-Reply-To: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> Content-Type: multipart/alternative; boundary="------------000309010701050706060405" X-Virus-Scanned: ClamAV Date: Wed, 08 Jun 2016 21:50:13 +0300 Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:50:22 -0000 This is a multi-part message in MIME format. --------------000309010701050706060405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear Melinda, There was a discussion about one more possible attack related with name redaction. (Letter by Andrew Ayer on June 6 ). Is not it a subject to include in the document? Thank you! On 08.06.2016 21:47, Melinda Shore wrote: > Hi, all: > > We'd like to restart working group last call on the threat > analysis draft > (https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/) > but I wanted to make sure that any serious concerns have been > addressed. In particular, it seems as if there may be some > unresolved questions about the conspiring CA attack identified > by DKG. > > Do you all feel that the document is ready for working group > last call, and that any issues blocking it from being sent on > to the IESG have been resolved? > > Thanks, > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- SY, Dmitry Belyavsky --------------000309010701050706060405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear Melinda,

There was a discussion about one more possible attack related with name redaction. (Letter by
Andrew Ayer on June 6 ).

Is not it a subject to include in the document?

Thank you!

On 08.06.2016 21:47, Melinda Shore wrote:
Hi, all:

We'd like to restart working group last call on the threat
analysis draft (https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/)
but I wanted to make sure that any serious concerns have been
addressed.  In particular, it seems as if there may be some
unresolved questions about the conspiring CA attack identified
by DKG.

Do you all feel that the document is ready for working group
last call, and that any issues blocking it from being sent on
to the IESG have been resolved?

Thanks,

Melinda

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


-- 
SY, Dmitry Belyavsky
--------------000309010701050706060405-- From nobody Wed Jun 8 13:03:27 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459912D5A5 for ; Wed, 8 Jun 2016 13:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_LxEVo6qY1a for ; Wed, 8 Jun 2016 13:03:23 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCBF12D7BF for ; Wed, 8 Jun 2016 13:03:23 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 8 Jun 2016 16:03:15 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.444.0; Wed, 8 Jun 2016 16:03:21 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id u58K3Elt019589; Wed, 8 Jun 2016 16:03:14 -0400 To: Melinda Shore References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> From: "David A. Cooper" Message-ID: <57587A02.9040606@nist.gov> Date: Wed, 8 Jun 2016 16:03:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:03:25 -0000 Unfortunately, the concerns have not been addresses. I pointed out in a message on April 26 that the text still incorrectly referring to the malicious CA issuing the bogus EE certificate as two CAs, and my message was ignored. Byran Ford sent a message on May 19 agreeing that the current text is "rather strange." Steve Kent just responded by adding more text to the document rationalizing his decision to refer to the malicious CA as "two CAs." So, the text is still unnecessarily confusing and it still contains information that is technically incorrect. On 06/08/2016 02:47 PM, Melinda Shore wrote: > Hi, all: > > We'd like to restart working group last call on the threat > analysis draft > (https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/) > but I wanted to make sure that any serious concerns have been > addressed. In particular, it seems as if there may be some > unresolved questions about the conspiring CA attack identified > by DKG. > > Do you all feel that the document is ready for working group > last call, and that any issues blocking it from being sent on > to the IESG have been resolved? > > Thanks, > > Melinda From nobody Thu Jun 9 08:29:41 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C649512D635 for ; Thu, 9 Jun 2016 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAKsNy3d6Gwk for ; Thu, 9 Jun 2016 08:29: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 33ACE12D5BD for ; Thu, 9 Jun 2016 08:29:33 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:44754 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bB1tf-0009qh-1y for trans@ietf.org; Thu, 09 Jun 2016 11:29:27 -0400 From: Stephen Kent To: trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> Message-ID: <57598B56.3000604@bbn.com> Date: Thu, 9 Jun 2016 11:29:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <575868E5.7010908@tcinet.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 15:29:38 -0000 Dmitry, I've been waiting for Rob Stradling to comment on the attack described by Andrew. I consider Rob to be the definitive expert on redacted certs (since he invented the concept) and I want to make sure that Ron concurs with the attack description and the impact characterization before adding it to the threat document. If Rob concurs, then I'll draft text to describe the attack and submit it to the WG list for review, rather than re-issuing the whole doc with this added material for review. Andrew's message noted a potential problem for Monitors dealing with redacted certs. The Monitor spec that I co-authored (draft-kent-trans-monitor-auditor-01.txt) already describes a model in which Monitors are expected to have access to the cert data associated with the Subjects they serve. So, in the case of redacted certs, I think a Monitor serving the Subject(s) of such certs will be able to function as expected. Eran suggested that a Monitor need not have such info and might be on the lookout for suspect certs in general, but I have trouble understanding how that will work, in general. I have not reviewed version 16 of 6962-bis, but I found prior descriptions of the Monitor function to be too vague. So, I'll mention the Monitor problem, as well as the CT-aware browser problem (re SCT matching), in the text I prepare. Steve From nobody Thu Jun 9 08:43:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B701012D127 for ; Thu, 9 Jun 2016 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WskRtnqIFJrE for ; Thu, 9 Jun 2016 08:43:51 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56B012D0DC for ; Thu, 9 Jun 2016 08:43:50 -0700 (PDT) Received: (qmail 10687 invoked by uid 1004); 9 Jun 2016 15:43:48 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 09 Jun 2016 16:43:48 +0100 Received: (qmail 7185 invoked by uid 1000); 9 Jun 2016 15:43:48 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 09 Jun 2016 16:43:48 +0100 To: Andrew Ayer , Trans References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> From: Rob Stradling Message-ID: <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> Date: Thu, 9 Jun 2016 16:43:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 15:43:57 -0000 On 06/06/16 19:17, Andrew Ayer wrote: > On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) > Paul Wouters wrote: > >> On Mon, 6 Jun 2016, Andrew Ayer wrote: >> >>> This enables the following attack: >>> >>> 1. A CA issues a legitimate certificate for www1.example.com and >>> logs a pre-certificate for ?.example.com. A monitor for >>> example.com knows the pre-certificate is legitimate because it >>> matches a known certificate for www1.example.com. >>> >>> 2. The CA misbehaves and issues an unauthorized certificate for >>> www2.example.com which, except for the DNS name, has exactly the >>> same details (including serial number and public key) as the >>> certificate for www1.example.com. The CA does not log a >>> certificate or pre-certificate. >>> >>> 3. An attacker serves the rogue certificate for www2.example.com >>> along with the SCT for the ?.example.com pre-certificate. TLS >>> clients accept it because the TBSCertificate that is reconstructed >>> from the certificate matches the TBSCertificate of the >>> pre-certificate. Monitors have no idea that there is a rogue >>> certificate for www2.example.com. >> >> That means the attacker has the private key? > > Yes, but that only limits the attack, not eliminate it. It means that > if the attacker gets the private key for one host, they can > (with CA collusion) pivot to attacking other hosts whose names match > the same redaction pattern. > >> I guess when the second certificate would be logged, this would show >> up as mis-issued, and possibly both certificates would get revoked? > > The second certificate would never be logged. The way that logging is > enforced is that clients reject certificates that aren't accompanied by > a valid SCT. But since an SCT for the first certificate's > pre-certificate can be used to prove that the second certificate was > logged, clients can be tricked into accepting the second certificate > even if it was never logged. > > That's basically the crux of the problem - with name redaction, SCTs do > not prove that a certificate was logged, they only prove that some > pre-certificate matching the name redacted pattern was logged. I argue > that for monitoring to be useful, SCTs need to prove that a > pre-certificate matching the exact name was logged. > > Regards, > Andrew If a wildcard cert for *.example.com is logged, it can be used for https://www1.example.com, https://www2.example.com and https://anythingyoulike.example.com. How does name redaction make the situation any worse than that? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 9 11:44:18 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D312D587 for ; Thu, 9 Jun 2016 11:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enSv2cep5yBq for ; Thu, 9 Jun 2016 11:44:15 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB6B12B078 for ; Thu, 9 Jun 2016 11:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465497854; bh=l29YqZ/g4hfQQr07mM9pdToEjLe7phxgHiBnzZZGLxw=; h=Date:From:To:Subject:In-Reply-To:References; b=NEA63ZsBKzEsWt4Z1uMhkIjHWRHdjxAb2YASFZe6lqfR9QOocBjlIOxIB3j7rt1zo gUWw72WmIowq+INEXGXmJUKr/A1OB9I7R75kFa991PbjpT5KmflbXCUhafzU1XQRwg cenQ1qXXJVigIUl7MsGNIIKDzoKoFkjWi1KweS8rGxZOUzunJHSlrfuQLxnN5nfRXE 8m9KEuDh+2ogr0+zH9GkNboEFbDPYB4Nk+ngHuhubybhiONwjUOmP0V5vvcCBSql3V bZrMOmzTdtoWc3Wb+ZEOCbvsGi8U3TiZUGdTrNpP1AFfcFsfwX1aYMXSyu9xmBULMR D39y2BoJpd3pQ== Date: Thu, 9 Jun 2016 11:44:14 -0700 From: Andrew Ayer To: Trans Message-Id: <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> In-Reply-To: <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 18:44:17 -0000 On Thu, 9 Jun 2016 16:43:48 +0100 Rob Stradling wrote: > On 06/06/16 19:17, Andrew Ayer wrote: > > On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) > > Paul Wouters wrote: > > > >> On Mon, 6 Jun 2016, Andrew Ayer wrote: > >> > >>> This enables the following attack: > >>> > >>> 1. A CA issues a legitimate certificate for www1.example.com and > >>> logs a pre-certificate for ?.example.com. A monitor for > >>> example.com knows the pre-certificate is legitimate because it > >>> matches a known certificate for www1.example.com. > >>> > >>> 2. The CA misbehaves and issues an unauthorized certificate for > >>> www2.example.com which, except for the DNS name, has exactly the > >>> same details (including serial number and public key) as the > >>> certificate for www1.example.com. The CA does not log a > >>> certificate or pre-certificate. > >>> > >>> 3. An attacker serves the rogue certificate for www2.example.com > >>> along with the SCT for the ?.example.com pre-certificate. TLS > >>> clients accept it because the TBSCertificate that is reconstructed > >>> from the certificate matches the TBSCertificate of the > >>> pre-certificate. Monitors have no idea that there is a rogue > >>> certificate for www2.example.com. > >> > >> That means the attacker has the private key? > > > > Yes, but that only limits the attack, not eliminate it. It means > > that if the attacker gets the private key for one host, they can > > (with CA collusion) pivot to attacking other hosts whose names match > > the same redaction pattern. > > > >> I guess when the second certificate would be logged, this would > >> show up as mis-issued, and possibly both certificates would get > >> revoked? > > > > The second certificate would never be logged. The way that logging > > is enforced is that clients reject certificates that aren't > > accompanied by a valid SCT. But since an SCT for the first > > certificate's pre-certificate can be used to prove that the second > > certificate was logged, clients can be tricked into accepting the > > second certificate even if it was never logged. > > > > That's basically the crux of the problem - with name redaction, > > SCTs do not prove that a certificate was logged, they only prove > > that some pre-certificate matching the name redacted pattern was > > logged. I argue that for monitoring to be useful, SCTs need to > > prove that a pre-certificate matching the exact name was logged. > > > > Regards, > > Andrew > > If a wildcard cert for *.example.com is logged, it can be used for > https://www1.example.com, https://www2.example.com and > https://anythingyoulike.example.com. > > How does name redaction make the situation any worse than that? If a domain owner requests a wildcard certificate for *.example.com, they are accepting the possibility that the certificate can be used with any sub-domain. It's expected. If a domain owner requests a certificate for www1.example.com, the expectation is that the certificate only works with www1.example.com. But if the domain owner requests redaction, they are now making it possible for the CA is misbehave and issue certificates for hosts besides www1.example.com that will be accepted by clients and not detected by the domain owner's monitor. That seems like a violation of user expectation. It also seems like a violation of a core principle of CT: that clients will only accept a cert if the cert is logged. However, when redaction is used, clients will accept a cert even if it was actually a different cert which was logged[1], as long as the two certs redact down to the same pre-cert TBSCertificate. Regards, Andrew [1] Technically, a pre-cert was logged, but a pre-cert is just a proxy for a cert. From nobody Thu Jun 9 11:44:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE712D587 for ; Thu, 9 Jun 2016 11:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htjEyIsDH-lL for ; Thu, 9 Jun 2016 11:44:51 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE36212B078 for ; Thu, 9 Jun 2016 11:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465497891; bh=x3q9xcENmRn6Oz6CDCdLb0fVSyPomEoRrFFjY2VH/8s=; h=Date:From:To:Subject:In-Reply-To:References; b=LS8alU/6T5XwzaLVmw4NC5lQ6b8SB48PpgwP5aZS/G5NZl+la2v+vmIPxJLLuSiEJ gCZCGaEoF5eB+NOHrS4GNHwPab0PqwYuA7iKdp4SXmjsFCx84teuAzlZKB79/yQKzJ VOHzVUfxeD1kLjXhpRopMktjxMV4d9kxcE0NRkEnrPYuCa+uvsj5vymdOjLR1cv7Uq TDNag1d8buA8/v0hfgwEQl5tUhwC3ZAmWR7cPfuB+bw+WlCjCGT9+Z3u12oRgbLRnB iDxfggNXqxZSCbIDu86xgDhq9QWOmPdEn86Nae1GoPx988FSUlzST0aYqUEePHrmGO Toj5bZdeNqjGA== Date: Thu, 9 Jun 2016 11:44:50 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20160609114450.e94b18a56e9539edccbb0cf2@andrewayer.name> In-Reply-To: <57598B56.3000604@bbn.com> References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 18:44:53 -0000 On Thu, 9 Jun 2016 11:29:26 -0400 Stephen Kent wrote: > Dmitry, > > I've been waiting for Rob Stradling to comment on the attack > described by Andrew. > I consider Rob to be the definitive expert on redacted certs (since > he invented > the concept) and I want to make sure that Ron concurs with the attack > description > and the impact characterization before adding it to the threat > document. > > If Rob concurs, then I'll draft text to describe the attack and > submit it to the > WG list for review, rather than re-issuing the whole doc with this > added material > for review. I would much rather the attack be fixed (I described one possible fix) than merely describing it in the threat document. Is this not an option? > Andrew's message noted a potential problem for Monitors dealing with > redacted certs. > The Monitor spec that I co-authored > (draft-kent-trans-monitor-auditor-01.txt) already > describes a model in which Monitors are expected to have access to > the cert data > associated with the Subjects they serve. So, in the case of redacted > certs, I think a > Monitor serving the Subject(s) of such certs will be able to function > as expected. No, even if a monitor has access to full cert data, they aren't maximally useful when redaction is used (I consider this unexpected). If a monitor is configured with: www1.example.com should have key A www2.example.com should have key B and it sees a pre-cert for ?.example.com using key A, it can't say for certainty whether this is OK, because the pre-cert might be for www1.example.com, or it might be for www2.example.com. draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert in this case, which makes it possible to launch the attack I described. > Eran suggested that a Monitor need not have such info and might be on > the lookout for suspect certs in general, Name redaction does pose a challenge to monitors without access to cert data, but this is a separate issue, and I don't think it can ever be resolved. However, we can and should make it possible for monitors with access to cert data to function usefully when name redaction is used. Regards, Andrew From nobody Thu Jun 9 13:19:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FE812D9B7 for ; Thu, 9 Jun 2016 13:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBNv15Fx9KZb for ; Thu, 9 Jun 2016 13:19:13 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9381F12D734 for ; Thu, 9 Jun 2016 13:19:13 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id b5so16233049pas.3 for ; Thu, 09 Jun 2016 13:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=7ytLutBpC7ksB/yd1DdEPFzaepHECwLp8/7sPFxhk2Y=; b=MeneCfAFH48MJp8Jn3qJrxNX5LPFzYNdzSQKqWtkgsg+HLZoiQG5lfUmBqkhSsKLHd myBXUqmfUQcUnbYkGZTxCLErs7YamwjdfliyK39sPIh4skgv93sYLEK3Nf8W9bc3/MVv 3S0IDksw8oxW9aq3DpiXCJk2DRarUE2jbWVZD5ofmlegjsETWYEULhhc9cC/5JJs+rMj mSRzoVMlag/3V5DVtFEyy7kILhmN31necN/STL0g/R5SEakWGfcJplGZ/VCUFaYpmFvo qZY0UnQNfvqyiDvbJnmp3cbauqVdzw8AMTa819zb3+u25A1Mr4Y0exdhG5ceydqdJEC7 gTuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7ytLutBpC7ksB/yd1DdEPFzaepHECwLp8/7sPFxhk2Y=; b=M54iCeEbKtqVqPohA2LJZRoPxEf45L9+hQVsvWq2wx0GWjdwwH+YQ6ejlo4a0qKLPY FpBZolFe4WlWB7i5ZpHCWKLx6ux1a4LqQGcuNWdLIk3O4O27ZJliuIzE23bO2g5oPqJ8 iX+xdJPMVE+Vq/2evn679/mrKe9akOXIrokyMMwCDTCJtf9zhmLXyo9kt6hxNva/+Tr4 G6AruZ8VXoLcnZA/lH3l/lcWpIx+9KY58P5I5cQzLEcusH7d6yTC/zCAQ5Za991Pq4c7 Nk0tLmgCnRb861OzrY7h2M7gLEqy9oIxak65FcbW2MRnv+y0vaDD1qGPjWBeIWnpLTro WnPw== X-Gm-Message-State: ALyK8tITHImA1CwlH9VqKs3nnuMQVGqGqeZhkqwq7cjeMjKlKIy7ftsFAyADbk/mjHs+oA== X-Received: by 10.66.51.42 with SMTP id h10mr2807699pao.31.1465503553074; Thu, 09 Jun 2016 13:19:13 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (66-230-108-1-radius.dynamic.acsalaska.net. [66.230.108.1]) by smtp.googlemail.com with ESMTPSA id l129sm12142373pfc.5.2016.06.09.13.19.11 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 13:19:12 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: Date: Thu, 9 Jun 2016 12:19:10 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 20:19:15 -0000 Hi, all: Because we're in a less-active period in the working group's work cycle and because of problems with an overscheduled agenda in Berlin, we've decided not to have a formal session at IETF 96. We will find some time for informal discussion, for those who are interested. Gossip would be the main topic under discussion, and possibly DNSSEC logging. Melinda From nobody Fri Jun 10 07:16:54 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDF212D603 for ; Fri, 10 Jun 2016 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mliQdEu7z9d0 for ; Fri, 10 Jun 2016 07:16:48 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD1D12D60B for ; Fri, 10 Jun 2016 07:16:46 -0700 (PDT) Received: (qmail 31712 invoked by uid 1004); 10 Jun 2016 14:16:44 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 10 Jun 2016 15:16:44 +0100 Received: (qmail 5520 invoked by uid 1000); 10 Jun 2016 14:16:44 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 10 Jun 2016 15:16:44 +0100 To: Andrew Ayer , Trans References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> From: Rob Stradling Message-ID: Date: Fri, 10 Jun 2016 15:16:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:16:53 -0000 On 09/06/16 19:44, Andrew Ayer wrote: > On Thu, 9 Jun 2016 16:43:48 +0100 > Rob Stradling wrote: > >> On 06/06/16 19:17, Andrew Ayer wrote: >>> On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) >>> Paul Wouters wrote: >>> >>>> On Mon, 6 Jun 2016, Andrew Ayer wrote: >>>> >>>>> This enables the following attack: >>>>> >>>>> 1. A CA issues a legitimate certificate for www1.example.com and >>>>> logs a pre-certificate for ?.example.com. A monitor for >>>>> example.com knows the pre-certificate is legitimate because it >>>>> matches a known certificate for www1.example.com. >>>>> >>>>> 2. The CA misbehaves and issues an unauthorized certificate for >>>>> www2.example.com which, except for the DNS name, has exactly the >>>>> same details (including serial number and public key) as the >>>>> certificate for www1.example.com. The CA does not log a >>>>> certificate or pre-certificate. >>>>> >>>>> 3. An attacker serves the rogue certificate for www2.example.com >>>>> along with the SCT for the ?.example.com pre-certificate. TLS >>>>> clients accept it because the TBSCertificate that is reconstructed >>>>> from the certificate matches the TBSCertificate of the >>>>> pre-certificate. Monitors have no idea that there is a rogue >>>>> certificate for www2.example.com. >>>> >>>> That means the attacker has the private key? >>> >>> Yes, but that only limits the attack, not eliminate it. It means >>> that if the attacker gets the private key for one host, they can >>> (with CA collusion) pivot to attacking other hosts whose names match >>> the same redaction pattern. >>> >>>> I guess when the second certificate would be logged, this would >>>> show up as mis-issued, and possibly both certificates would get >>>> revoked? >>> >>> The second certificate would never be logged. The way that logging >>> is enforced is that clients reject certificates that aren't >>> accompanied by a valid SCT. But since an SCT for the first >>> certificate's pre-certificate can be used to prove that the second >>> certificate was logged, clients can be tricked into accepting the >>> second certificate even if it was never logged. >>> >>> That's basically the crux of the problem - with name redaction, >>> SCTs do not prove that a certificate was logged, they only prove >>> that some pre-certificate matching the name redacted pattern was >>> logged. I argue that for monitoring to be useful, SCTs need to >>> prove that a pre-certificate matching the exact name was logged. >>> >>> Regards, >>> Andrew >> >> If a wildcard cert for *.example.com is logged, it can be used for >> https://www1.example.com, https://www2.example.com and >> https://anythingyoulike.example.com. >> >> How does name redaction make the situation any worse than that? > > If a domain owner requests a wildcard certificate for *.example.com, > they are accepting the possibility that the certificate can be used > with any sub-domain. It's expected. > > If a domain owner requests a certificate for www1.example.com, the > expectation is that the certificate only works with www1.example.com. > But if the domain owner requests redaction, they are now making it > possible for the CA is misbehave and issue certificates for hosts > besides www1.example.com that will be accepted by clients and not > detected by the domain owner's monitor. That seems like a violation of > user expectation. I think it's fair enough to say that if you withhold information from CT, CT won't help you as much as it otherwise would have done. I see the attraction of replacing "redacted labels not with '?' but with a salted cryptographic hash of the label, with the salt specified in the Redacted Labels Certificate Extension", but I'd prefer to avoid increasing complexity. > It also seems like a violation of a core principle of CT: that > clients will only accept a cert if the cert is logged. However, when > redaction is used, clients will accept a cert even if it was actually a > different cert which was logged[1], as long as the two certs redact down > to the same pre-cert TBSCertificate. > > Regards, > Andrew > > [1] Technically, a pre-cert was logged, but a pre-cert is just a proxy > for a cert. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jun 10 07:31:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7112B01F for ; Fri, 10 Jun 2016 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCY4I3ILg_fa for ; Fri, 10 Jun 2016 07:31:09 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6732C12D0A9 for ; Fri, 10 Jun 2016 07:31:09 -0700 (PDT) Received: (qmail 32382 invoked by uid 1004); 10 Jun 2016 14:31:07 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 10 Jun 2016 15:31:07 +0100 Received: (qmail 21580 invoked by uid 1000); 10 Jun 2016 14:31:07 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 10 Jun 2016 15:31:07 +0100 To: Stephen Kent , trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> From: Rob Stradling Message-ID: <80e8b3dc-1f89-05a4-ae12-1bde421f41c6@comodo.com> Date: Fri, 10 Jun 2016 15:31:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57598B56.3000604@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:31:11 -0000 Steve, I consider the consensus of this WG to be "the definitive expert". :-) FWIW though, I concur with Andrew's attack description and impact characterization. Regarding fixing it: I'd rather nuke the redaction option than add further complexity. On 09/06/16 16:29, Stephen Kent wrote: > Dmitry, > > I've been waiting for Rob Stradling to comment on the attack described > by Andrew. > I consider Rob to be the definitive expert on redacted certs (since he > invented > the concept) and I want to make sure that Ron concurs with the attack > description > and the impact characterization before adding it to the threat document. > > If Rob concurs, then I'll draft text to describe the attack and submit > it to the > WG list for review, rather than re-issuing the whole doc with this added > material > for review. > > Andrew's message noted a potential problem for Monitors dealing with > redacted certs. > The Monitor spec that I co-authored > (draft-kent-trans-monitor-auditor-01.txt) already > describes a model in which Monitors are expected to have access to the > cert data > associated with the Subjects they serve. So, in the case of redacted > certs, I think a > Monitor serving the Subject(s) of such certs will be able to function as > expected. > Eran suggested that a Monitor need not have such info and might be on > the lookout > for suspect certs in general, but I have trouble understanding how that > will work, > in general. I have not reviewed version 16 of 6962-bis, but I found > prior descriptions > of the Monitor function to be too vague. So, I'll mention the Monitor > problem, as well > as the CT-aware browser problem (re SCT matching), in the text I prepare. > > > Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jun 10 11:13:31 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0612D78F for ; Fri, 10 Jun 2016 11:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF5uAJ20BW6m for ; Fri, 10 Jun 2016 11:13:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 843BB12D0DA for ; Fri, 10 Jun 2016 11:13:27 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 053FCF98B for ; Fri, 10 Jun 2016 14:13:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BA75C2022D; Fri, 10 Jun 2016 14:13:25 -0400 (EDT) From: Daniel Kahn Gillmor To: "trans\@ietf.org" User-Agent: Notmuch/0.22+47~g4441900 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 10 Jun 2016 14:13:21 -0400 Message-ID: <87poroap4u.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [Trans] threat analysis v06 review X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:13:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all-- This is a review of https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-06, with a specific focus on the colluding CAs section, which has been a subject of some contention, and which i think was intended to capture the attack which i described on-list a few months ago. Many thanks to Steve for his work on this draft. One brief comment on the Introduction: =2D---- In the Introduction: > Also note that one proposal for distributing Audit information (to > detect misbehaving logs) calls for a browser to send SCTs [...] This should probably link directly to the gossip draft. =2D----- > 3.3. Malicious, Colluding CAs The text in this section does not clearly describe the attack i had outlined, although it comes close. I think that some ascii-art diagrams might be useful, and there is some terminology that can be cleaned up. I'll try to intersperse some comments below for improved clarity. One initial overall observation is that the "collusion" need not be contemporaneous. Consider CA A, whose intermediate CA with cert A_N (using key N) is compromised and used to issue a bogus EE cert X: A =E2=86=92 A_N =E2=86=92 X This compromise is identified, and X is revoked (by whatever means: OCSP, CRLs, CRLsets, etc). A considers the failure severe enough to conclude that N was compromised, and revokes A_N. However, the attacker has already used N to issue another bogus EE cert Y, which is not yet deployed in any scenario, so it is unknown: A =E2=86=92 A_N =E2=86=92 Y Some time later, the attacker gains control of CA B. They use this control to issue intermediate CA cert B_N whose public key is also N. This means there are two possible chains for Y: 0) A + A_N =E2=86=92 Y 1) B =E2=86=92 B_N =E2=86=92 Y The attacker logs chain 0, and receives SCT SCT_Y. The log operators can't block this inclusion in their logs without themselves becoming meta-CA. If the log decides to try to do this, i believe that other attacks on the ecosystem appear (based on non-synchronization between the intermediate CAs blocked by the log and those blocked by the relying parties). Though it was logged with chain 0, the cert is deployed with chain 1, and still shipped with SCT_Y. Anyone just looking at chain 1 and SCT_Y can tell that it the cert chain is correct, and that the EE cert has been logged. However, none of the certificates in its chain have been revoked, and so no alarm bells will be raised. Anyone monitoring the logs on behalf of the service identified in Y will note that a cert was issued to it, but under a bogus, revoked, known-compromised intermediate cert. None of the existing revocation mechanisms are likely to revoke Y, since the chain is already thoroughly debunked. If the attacker is afraid of a risk of all their certs being revoked, they can simply issue hundreds or thousands of certs while they have access to A_N, which encourages narrow-bandwidth blocklisting mechanisms like CRLsets to just revoke the intermediate CA, and not the EEs, permitting the alternate chain to be used without detection. Note that the attacker doesn't even need to maintain access to N if they are thoughtful about their plans during the period in which N is compromised. OK, on to specific comments: > Section 3.2 examined attacks in which a single CA might issue a > bogus certificate. There is also the potential that two or more CAs > might collude to issue a bogus certificate in a fashion designed to > foil the remediation (but not detection) safeguards envisioned by > CT. Their goal would be trick a CT-aware browser into accepting a > bogus certificate because it was accompanied by a valid SCT, while > evading certificate revocation status indications. This section > explores such scenarios. Aside from the implication of contemporaneousness, i think this is a fair characterisation. > In this attack two CAs that do not share a common path to a trust > anchor,=20 I don't think that "do not share a common path to a trust anchor" is relevant. in a complex issuance hierarchy like this (where the "trust anchor" is A, and all named nodes are intermediate CAs): A / \ B C /| |\ D E F G a compromise of any two nodes would suffice, despite the fact that they all share a trust anchor. > collude to create a "doppelganger" (bogus) EE certificate. I'm not sure that "doppelganger" is a useful turn of phrase here. The closest thing we have to a "doppelganger" in the particular attack i described above is B_N, which technically *isn't* any more bogus than A_N. these intermediate CA certs are "doppelgangers" because they share SPKI and Subject. But the EE cert in this attack scenario is singular, not doubled. > The attack need not be initiated by trust anchors; any subordinate > pair of (not name-constrained) CAs can effect this attack without > the knowledge of superior CAs (which are presumed to be benign). This isn't precisely true, because of path length (not name) constraints. In the attack i've outlined, at least one of the compromised CAs must either have pathLenConstraint absent, or greater than zero. If the public certs for all of the compromised CAs have pathLenConstraint =3D=3D 0, the attack is not possible. > (The following text refers to these as two CAs, because they might > be represented by entities that are organizationally distinct, > perhaps realized by different physical presences. However, because > they share the same name and key pair, one also might view them as > the same CA that appears in two cert paths terminating at different > TAs.) The two CAs must have the same Subject name and the same > public key for the attack. (RFC 5280 does not explicitly preclude > the creation of two CAs with the same name, so long as the parent > CAs are distinct. Requirements for Subject name uniqueness apply > individually to each CA but not across CA boundaries, as per Section > 4.2.1.6. However, the Security Considerations section of RFC 5280 > warns that name collisions could cause security problems.) This paragraph seems wrong to me. The compromised CAs in question are *not* the same CA, though they do need to create at least one "doubled" intermediate CA that shares at least the same key (and likely, the same Subject). Perhaps it would be better to think about "compromised CA keys" instead of "compromised CAs", and leave the mechanism of compromise out of the technical discussion? > Because the two CAs have the same name and make use of the same key, > each can issue the (bogus) doppelganger certificates. This should say "either can issue the bogus end-entity certificate". (s/each/either/ and dropping doppelganger) > Because the bogus certificate is logged, it is subject to detection > as such by a Monitor. Once the bogus certificate is detected it is > anticipated that action will be taken to render it invalid. The > bogus certificate itself might be revoked by the CA that issued and > logged it, an action that masks the malicious intent of that CA. A > browser vendor might add the bogus certificate to a blacklist > maintained by the vendor, e.g., because the CA failed to revoke the > bogus certificate. >=20 >=20 > Kent Expires November 31, 2016 [Page 17] >=20 >=20=20 > Internet-Draft Attack Model for Certificate Mis-issuance May 2016 >=20 >=20 > If the CA that logged the bogus certificate is suspected of being > malicious, e.g., because it has a history of using bogus > certificates, the certificate of that CA might itself be revoked. > This revocation might be effected by the parent of that CA (which is > not complicit), or by a browser vendor using a blacklist. Whether > the proposed attack can achieve its goal depends on which revocation > mechanism is employed, and which certificate or certificates are > revoked. It also depends on what bogus EE certificates are issued, and (arguably) whether or not any of the logs reject certificate chains with known-revoked CAs in them. Of course, if the logs start doing that kind of rejection, then log operators become required to act as meta-CAs, which i believe is a rather radical departure from the story we've told about logs in the past. > 3.3.1. Revocation of the Bogus Certificate >=20 > If the bogus (EE) certificate is revoked by the CA that issued and > logged it, browsers should treat that certificate as invalid. > However, a browser checking a CRL or OCSP response might not match > this revocation status data against the doppelganger issued by the > second CA. Again, the EE cert is actually the same cert; the "second CA" is the doppelganger. > This is because revocation status checking is performed > in the context of a certification path (during path validation). The > doppelgangers have different certification paths and thus the > revocation status data for each might be acquired and managed > independently. (RFC 5280 does not provide implementation guidance > for management of revocation data. It is known that some relying > party implementations maintain such information on a per-certificate > path basis, but others might not.) >=20 > Even if the bogus certificates contain an AIA extension pointing to > an OCSP server the attack might still succeed. This would be better as: Even if the bogus EE certificate contains an AIA extension pointing to an OCSP server the attack might still succeed. > (As noted in the Section 1, RFC 5280 does not mandate inclusion > this extension, but its presence is required by CABF requirements.) Does this mean that monitors should raise flags for EE certs missing AIA extensions which identify an OCSP server? If so, is anyone doing this check? What action should be taken if this is found missing? > As noted in Section 3.2.1.1.1, a malicious CA could send a "good" > OCSP response to a targeted browser instance, even if other parties > are provided with a "revoked" response. Also note that a TLS server > can supply an OCSP response to a browser as part of the TLS > handshake [RFC6961], if requested by the browser. A TLS server > posing as the entity named in the bogus certificate could acquire a > "good" OCSP response from the colluding CAs to effect the > attack. Only if the browser relies upon a trusted, third-party OCSP > responder, one not part of the collusion, would the attack fail. This represents a separate and distinct CA key compromise from the original described attack, since the OSCP responder is often a separate key. I think this muddies the waters when trying to describe the "dual-CA compromise". More broadly, this seems like a discussion about failings in the revocation infrastructure, which might itself be out-of-scope for CT. A separate document that collates all the failings of revocation would be interesting and useful, but shoehorning it into this section might be a mistake. > The analysis above also applies to the use of CRLs to disseminate > certificate revocation status data. The doppelganger certificate > could contain a CRL distribution point extension instead of an AIA > extension. Again, i don't think "doppelganger" should be used here. I think this refers to the "bogus EE certificate", so please use that term. > In that case a site supplying CRLs for the colluding CAs could > supply different CRLs to different requestors, in an attempt to > hide the revocation status of the doppelganger from targeted > browsers instances. This is analogous to a split-view attack > effected by a CT log. However, as noted in Section 3.2.1.1 and > 3.2.1.1.1, no element of CT is responsible for detecting > inconsistent reporting of certificate revocation status data. Again, this is a separate compromise, and i think it muddies the waters. > (Monitoring in the CT context tracks log entries made by CAs or > Subjects. Auditing is designed to detect misbehavior by logs, not by > CAs per se.) I think this is correct, but i'm not sure it belongs in this section. > If the CA that logged the certificate does not revoke it, a browser > vendor might enter the bogus certificate into a "blacklist". > Unfortunately, there are no IETF standards for such blacklists. Thus > it is conceivable that the revocation status data also might be > managed in a path-specific fashion. I think this is the most-relevant bit of this section. Some revocation mechanisms depend on the *path*, not just on the EE cert and signing subkey. Perhaps it would make more sense to enumerate those revocation mechanisms that are path-reliant (and therefore vulnerable to this colluding-CA hiding attack): a) any blocklist mechanism (like CRLsets) that sometimes blocks intermediate CA certificates without also including a full explicit blocklist of all known child certs of the blocked intermediate CA. b) relying parties which depend on identifying OCSP or CRL or other revocation mechanisms in the issuing certificate, rather than in the end-entity certificate. > If that were true, then the attack could succeed. However, if a > vendor maintains revocation status data in a path-independent > fashion, then the attack will fail. For example, if revoked > certificates are identified by CA name and serial number, or a hash > of the certificate, this attack would fail. The attack that fails for path-independent revocation mechanisms is use the bogus, known-revoked EE certificates. But the other attack (the hidden, secondary CA compromise) is still not discovered by CT in this case. > 3.3.2. Revocation of the Colluding CA Certificate >=20 > If the CA that logged the bogus certificate is viewed as acting > maliciously, its parent might revoke that CA's certificate. Even > though the two colluding CAs have the same name and use the same > public key, their certificates are distinct, e.g., they were issued > by different parents and almost certainly have different certificate > serial numbers. Thus revocation of the certificate of the CA that > logged the bogus certificate does not affect the certificate of its > colluding partner. In this case, the bogus EE certificate would be > treated as valid when it appears in a certification path involving > the second colluding CA. Thus revocation the certificate for the CA > that was detected as malicious does not prevent this attack from > succeeding. This last sentence is missing an "of". > A vendor also might choose to add the certificate of the CA that > issued the bogus certificate to its blacklist, e.g., if that CA > refuses to revoke the bogus certificate. This also may not prevent > the bogus certificate from being accepted by a browser. For example, > if the CA certificate blacklist entry is analogous to a CRL entry > (Subject name of the parent of the malicious CA and the serial > number of the malicious CA's certificate), the colluding CA's > certificate would still be valid in this case. Should we instead recommend "relying parties capable of blocking known-malicious intermediate CAs should enumerate these entities by public key" ? This doesn't entirely solve the problem (two conspiring CAs can create an unlimited number of doppelganger CA pairs), but it's certainly better than blocking intermediate CAs by full certificate or by issuer+serialnumber. Sorry that describing this attack has proved so complex. I think the complexity is due to the complexity of the overall ecosystem (including PKIX, X.509, CAs, logs, browsers, revocation mechanisms, etc). the simpler we can make things the better. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXWwNCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKglEQAL3T8RpKwRqC9Y0F9dDLZg1E 5GJ7BdtoZFNU2BE5tHxK7feH+cZdFzlwZ72fx9Wb8GhmeAcl1TPOqa80IBiK3O9X WSmI0WNmMxueGxwQPMO55qs/p/hQDj9OdaRhtObd0EPGlu1pkpTSFd1ZY9PHbkr2 i7SsH4+p1UV0jzFjgpyPlhGfMTKVbcKO3UIqytsiMJ30HNFgv+m8kkq9vtFQb0y5 2ExtlPpyRp1GGCrq0dc5N68EtiLHbMlPEz60Pj2smo1TLK+3sFWkvjPpWXTeor6a YbR3YZXg7Dww5r+fUEQHe+2/sVPKHQvyuFH/GW5jcLwnJeFe4ROoa6Qo1Fs5kZQ4 nW7pL1BGqcW6giEkOpLAhUuTgDKp3F/zsc6f9gcqWjf+M5gV7/jRokSGJ1dZbCpD oH1zraNWmUGmhwK2RtZkFrX+wwzcoege5ZxDdrSG7nelVcLiuNip/C5KdOCQQqcH fGf52KCda+bARKUfJpARCOkWs+l6LMWZpwogq+B74KDUkAIy+7lqCiSPVs77j2hs qnTzM3CJI33oRnIR4Sk9LZJXR592mtl+dPkA4xwU2q/ovTHcUvaStLu335m17I1z krFAP/WV1AG0bgtrYYB0HC2Z6ybbZZJqT2h3L3kj6+U7LqcBj/cUlpwYrP1bswtg j+Qlarbq3RsDGARzAtZP =ezrK -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 10 11:34:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DD712D7AA for ; Fri, 10 Jun 2016 11:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFgnOYP9oqRG for ; Fri, 10 Jun 2016 11:34:03 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3ED12D5AB for ; Fri, 10 Jun 2016 11:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465583642; bh=BcxS86iW/gmObsTSOpW7Fb1Bxeprm33d7bVo0zjuY7o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=KNZcRPKLTJETVO/zvpN2RDDKTG5JTVCV4BXBmptjNAGC9msSiiAnRKhilV+WCd3DT 5TH1CJC/miZNoNoUeVnq5TOB1xaa33Dns/QyrtAd/YkNTYzGo0go25jTXvf67INUGz 60J1kUU8iBWIapfMVClFDO5eM/db7pCtszZlZquqYaLWlp6uPfkYysbXu3o7fOmS0a 1g2DKO2QnIjxVe2/je6QmqYqNmE82+MDJGaakiBOcRFhFE7mjBuJEdaxetsqKEgobn VPrWQV/n40Ez95mZPdhLRy8LkoojUTNnaFptg5/DxKRDDd51Rrn5lWuZ6rNnxK2gnd ZsywDspXOtpOw== Date: Fri, 10 Jun 2016 11:34:01 -0700 From: Andrew Ayer To: Rob Stradling Message-Id: <20160610113401.06223b29078b36e3204fbbd6@andrewayer.name> In-Reply-To: <80e8b3dc-1f89-05a4-ae12-1bde421f41c6@comodo.com> References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> <80e8b3dc-1f89-05a4-ae12-1bde421f41c6@comodo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org, Stephen Kent Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 18:34:05 -0000 On Fri, 10 Jun 2016 15:31:07 +0100 Rob Stradling wrote: > Steve, > > I consider the consensus of this WG to be "the definitive > expert". :-) > > FWIW though, I concur with Andrew's attack description and impact > characterization. Regarding fixing it: I'd rather nuke the redaction > option than add further complexity. I think the removal of redaction should be considered. For those who haven't been following Chrome's ct-policy list, Chrome has announced that they will not be supporting redaction, at least until a list of concerns is addressed: https://groups.google.com/a/chromium.org/d/msg/ct-policy/fCt4Bm03GsI/jBbqE_QWBQAJ Addressing those concerns may require additional standardization (e.g. a CAA property for domain owners to opt-in to redaction). If there's still interest in redaction, it could be done in a future document, along with the necessary work to make it acceptable to Chrome. In the meantime, someone might find a simpler way to address this attack. Regards, Andrew From nobody Mon Jun 13 07:55:15 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448B912D177 for ; Mon, 13 Jun 2016 07:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAxcyisrJpan for ; Mon, 13 Jun 2016 07:55:12 -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 DC21812D16B for ; Mon, 13 Jun 2016 07:55:11 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48605 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bCTGb-000M2Q-97 for trans@ietf.org; Mon, 13 Jun 2016 10:55:05 -0400 To: trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> <20160609114450.e94b18a56e9539edccbb0cf2@andrewayer.name> From: Stephen Kent Message-ID: <9b7fb24e-e028-dea3-ae33-1ebdcce4835d@bbn.com> Date: Mon, 13 Jun 2016 10:55:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160609114450.e94b18a56e9539edccbb0cf2@andrewayer.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:55:13 -0000 Andrew, > ... > I would much rather the attack be fixed (I described one possible fix) > than merely describing it in the threat document. Is this not an > option? Not for me to say. But I agree that the issue you cited is troubling. > ... > No, even if a monitor has access to full cert data, they aren't > maximally useful when redaction is used (I consider this unexpected). > If a monitor is configured with: > > www1.example.com should have key A > www2.example.com should have key B > > and it sees a pre-cert for ?.example.com using key A, it can't > say for certainty whether this is OK, because the pre-cert might be for > www1.example.com, or it might be for www2.example.com. > draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert in > this case, which makes it possible to launch the attack I described. Yes, a Monitor serving www1 would think the log entry was OK, even though it also would match www2. But, this requires that www2 has the same key as www1. If there was a compromise of www1, then I agree that a Monitor would not detect the compromise, but a Monitor isn't really intended to do that. If this represents collusion between www1 and www2 then this is good example of how colluding Subjects could use an SCT issued for one Subject with a cert for another Subject, because of the properties of redacted certs. Got it. Steve From nobody Mon Jun 13 07:57:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564EB12B069 for ; Mon, 13 Jun 2016 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaVxFLC8fn0q for ; Mon, 13 Jun 2016 07:57:48 -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 7887712D177 for ; Mon, 13 Jun 2016 07:57:48 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:57025 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bCTJC-0003wb-GL; Mon, 13 Jun 2016 10:57:46 -0400 To: Rob Stradling , trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> <80e8b3dc-1f89-05a4-ae12-1bde421f41c6@comodo.com> From: Stephen Kent Message-ID: Date: Mon, 13 Jun 2016 10:57:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <80e8b3dc-1f89-05a4-ae12-1bde421f41c6@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:57:49 -0000 Rob, > Steve, > > I consider the consensus of this WG to be "the definitive expert". :-) If the WG had more folks commenting on more topics I'd agree, but ... > > FWIW though, I concur with Andrew's attack description and impact > characterization. Regarding fixing it: I'd rather nuke the redaction > option than add further complexity. I'm in favor of removing the redaction option. It's one of the more complex aspects of CT and if you, as its creator are comfortable holding off for now, I think that would be a good action. Steve From nobody Tue Jun 14 20:33:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E012D60C for ; Tue, 14 Jun 2016 20:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVNHUARWfZdI for ; Tue, 14 Jun 2016 20:33:10 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DCF12D62E for ; Tue, 14 Jun 2016 20:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1465961586; bh=xQcMGjgEKwRmqFSGINmX+FiFcsWY9+WlivDVU3YpCJE=; h=Date:From:To:Subject; b=mn6RHgD0Q9Cm3CcG2b8wbusOOoRKgqZSIshcAqOA1yXYpBX7DSHetw2hvKVKP5BQ9 tDlhqP4zbc128TG2JnBHdi6iSU9dCN3fuAEtm2TVF6HCSTCn1NXInwgWayZRcfRj4r NmtyZzOpKSaVeOKJFTmCA+jZTaVxBEBKsyfpRAacO7ahPTwhly3jpx0s/ougYLWGor 2V4iEy3wsS783bC6oFMR9PB2kMl+I/7IaALE9SXijvh4AZYvJXnABVUD9KABY+CohG 2had3k6zUTu6PGxpzUQitoBBY+SFECkEaMq7i1kBUp3PDa/zxNbpFlkY/YqaCssLd9 rJm1LU1pd7Rbg== Date: Tue, 14 Jun 2016 20:31:19 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20160614203119.afe271bcb2d1489b60a56520@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Some comments on draft-ietf-trans-rfc6962-bis-16 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 03:33:11 -0000 Section 6.6 (get-all-by-hash): It's not clear whether the inclusion proof is to the requested STH or to the returned STH. I'm pretty sure it's supposed to be the returned STH, but this wording suggests it's the requested STH: tree_size: The tree_size of the tree on which to base the proofs, in decimal In this wording, it's unclear what "selected STH" refers to: inclusion: A base64 encoded "TransItem" of type "inclusion_proof_v2" whose "inclusion_path" array of Merkle Tree nodes proves the inclusion of the chosen certificate in the selected STH. Section 10.1 (metadata): Is the Final STH specified as a TransItem of type signed_tree_head_v2 or as a tree_size integer? Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary to remove the Transparency Information extension, but this step is omitted. Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the TLS Feature extension plays. 10.2.5 says that compliance means "accompanied by at least one valid SCT." 10.2.6 says that if transparency_info is present in the TLS Feature extension, then "CT compliance ... is required" and that "TLS clients MUST treat certificates which fail this requirement as non-compliant." In other words, non-compliance must be treated as non-compliant, which isn't saying anything. 10.2.7 says that if the certificate chain is non-compliant, the "TLS client MUST refuse the connection," which renders the TLS feature extension unnecessary. I assume the intent is that if transparency_info is in the TLS Feature extension, then TLS clients MUST refuse connections using non-compliant chains. Otherwise, they MAY refuse connections using non-compliant chains, depending on the client's policy. From nobody Tue Jun 14 21:04:03 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4260112D757 for ; Tue, 14 Jun 2016 21:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZAbXqC1S3Tl for ; Tue, 14 Jun 2016 21:04:00 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC20F12D0A1 for ; Tue, 14 Jun 2016 21:03:59 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 62so4317654pfd.1 for ; Tue, 14 Jun 2016 21:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=xASKSAipjLVbrOBFUwPRLlG2OgaLQtiK/snZ/NPHrnE=; b=C0gj+GpoqLD9+ONXizwOu2l+rhKvgSVVBZlwKozFFXneFkUOSXcFZi31Fu0PfyR+HG ataj/KJNPw9Byr69Dqa9Jq/ffkAVsYqSitVWO7LLPm3KJHKW1X401hzaSHEEdjlKBRhK lbHKPHqxDZetN27EAc5sOvIbgWwrvZqsqhOR1/s1itP7jdvT6omd87zP4YYXYIZAYIGy aJV2st8s5F3Y2aids9BU4prgek0+eqmHXmJevrx+P9Hvk2P0mJvd0umT+SoaVdyXyuFg tsrmC7xwU6Np20GbUO+Du3JPi2u6IwGUYjci1IhmxAq2/9uQwdzq/wD+Abc5B2oa2e88 XUjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=xASKSAipjLVbrOBFUwPRLlG2OgaLQtiK/snZ/NPHrnE=; b=IGiLqvvdSz4g/oWPjA/FZvJWrPaafoVwTX2LQd2Y212SgP7hnPxgln7qien2/yA1Nn Y1fU4BmPFK3bxNoTn2E/Nn8NWyQD7YeYeFuuk75k23i/tTUyp11mcrXWFwXNNBo9CfpR 0Q10AKuKEuZlN5izUe9IIDR53ILQHvAC7yiUs430inpkj1E3jbdlLOjeYGofcjFyRwHC muNM8J1K0r16jV2eoPLUiJYAU0mYfNRLL2w5xYBCk8Tk+306hMmYDXnZPLjFpLfuzL2J +hVDEjINQ2qhQ32BUnf0Nv3XGYqmRDuzYVqaGLBHD0/ICDNNULW/ofmZuzuxvN4S9v/B WB8Q== X-Gm-Message-State: ALyK8tJ2LeL4bJ00ILJ+49Y5z2L+zR2d79t/Zx0R0wtFkJ7lWpQ3St9DWuuAu83a9EppiQ== X-Received: by 10.98.75.146 with SMTP id d18mr1421036pfj.19.1465963439119; Tue, 14 Jun 2016 21:03:59 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-209-252-radius.dynamic.acsalaska.net. [209.112.209.252]) by smtp.googlemail.com with ESMTPSA id a188sm13040123pfa.70.2016.06.14.21.03.57 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 21:03:58 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> Date: Tue, 14 Jun 2016 20:03:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 04:04:01 -0000 Hi, all: As we approach the end of working group last call on 6962-bis, it looks like we have an unresolved question about whether name redaction should stay or go. I just went through the mailing list archive and it looks like we have squishy agreement that it should go (for example, Rob's comment: "Regarding fixing it: I'd rather nuke the redaction option than add further complexity."). So, if anybody has particularly strong feelings about this, or disagrees about removing name redaction, please weigh in. Thanks, Melinda From nobody Tue Jun 14 21:05:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168C12D0A1 for ; Tue, 14 Jun 2016 21:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oksSELE78MBb for ; Tue, 14 Jun 2016 21:05:33 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C40512D757 for ; Tue, 14 Jun 2016 21:05:33 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e5so11017472ith.0 for ; Tue, 14 Jun 2016 21:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=720IMadf1P0k8s3StZ2yN4z6GvBSX47Ii8OEqvXJRSA=; b=hhA9Ef6OGtW45llTm7t4xtDXoVGCu7QcAk+xebUfkArUR9+prIT/UtDVMdTOnfNSyI mksZIeX1L+0nWg7uaSy0yHppBfleYx3ZUZQp9ZlE5Rc2/HLtdD+mvUeLxclzdsXLc7NP ZEKcayFjycpuZAdXD9KUCWBHcz0GweJNxzxcuPUmr6KibAtpCSgpxeFXeEisnx81ZE7y dvY29ExKFM/TdCaywhDVRPpMhkT8nWUpZTWShsUFBeYPqy/oJsrvEolGdwVdM8GKKLcI xvbdLbfsaHT6STJfESTXb00zZZSPYcuIlkwmnubIagSQn53f/x1Xo9lHl2PM83QEbHIa ikEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=720IMadf1P0k8s3StZ2yN4z6GvBSX47Ii8OEqvXJRSA=; b=Yv4jMk44KSgYBvWAfQbQthW/hNW8Q6fgY1DEWHPMUUmUQXKIXzPpPqkow0iHe+5S2D Hj/2uOdtqLs9aCWMbe7rZC84N0W3eb3RyAQRIHJNt1IPbsVS5e+k29AR/nOoM+sFvKz5 7J2pCd3sF0922lGByXJqLHfJ1SqvaNw2Y8tdnuLDwsfZ1YYz+AqBHw9xWDisIpbrIw9F inog9+IrGyM5YnScNkraLkxtHyfb2Cu5eCuaBvuO+nqOoQlc5Ezmgnejxywk9yB1qevb QtIP3BanLFXndOKNZovoAD3KBn9iWcrK6nUGZE0l3Fl01lBMwikXLoIgc2yaVGkTb3B9 fVyA== X-Gm-Message-State: ALyK8tLAnqlhaku2AneFZhLlRdj0yoVOxy8dSYA04zbxNMuCV0f/wtjvXzJN+a4FobaUdKRvK4Xy+KKi7RDt3g== X-Received: by 10.36.14.76 with SMTP id 73mr6942433ite.70.1465963532676; Tue, 14 Jun 2016 21:05:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.130 with HTTP; Tue, 14 Jun 2016 21:05:32 -0700 (PDT) In-Reply-To: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Peter Bowen Date: Tue, 14 Jun 2016 21:05:32 -0700 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 04:05:34 -0000 On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore wrote: > As we approach the end of working group last call on 6962-bis, > it looks like we have an unresolved question about whether > name redaction should stay or go. I just went through the > mailing list archive and it looks like we have squishy > agreement that it should go (for example, Rob's comment: > "Regarding fixing it: I'd rather nuke the redaction > option than add further complexity."). So, if anybody has > particularly strong feelings about this, or disagrees > about removing name redaction, please weigh in. To be clear, are you asking about 4.2 and 4.3 or just 4.2? From nobody Tue Jun 14 21:18:22 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051112D0A1 for ; Tue, 14 Jun 2016 21:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHnena6LbR-R for ; Tue, 14 Jun 2016 21:18:20 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FB31200A0 for ; Tue, 14 Jun 2016 21:18:20 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c2so4443346pfa.2 for ; Tue, 14 Jun 2016 21:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Uh1lrVZYiEhKOJ+7iZEreTKFetDWF6cyDeHjmssBfgE=; b=wxGSrnbeLXWRQgPGhmKgIEDtR08849I9+Q6+t6TZCYIkpPs90iDUoVcgRR0a2Cjcv6 tSieGD4tyNgH1SS0z35kmZoDMGQ26kD8U4p6Rq9P5WTMCi4B12mfteAjQvuZQIx4MViA VE8yu/9snYN0k46M1V7yBEWwmxGKtcbnyaPfyRnqj0OhlL3ZE47igCc/o4Xme2zogjGR o2yzfuGFSbz+pfZCPqHbZqXWmM6EvHg9obRK/+/2IFBSA4MRVfbEZn+0lqjgJWpTLB6J bpYwpr+yPYsQb/2rll5dSELlJJtUz2EhiWIAK1Ghs2A7xXukGKtR01eIyuFOP6Zs47Tb wJJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Uh1lrVZYiEhKOJ+7iZEreTKFetDWF6cyDeHjmssBfgE=; b=T72RxfFxFc95t0OHVPE9bKbmoft8oWMxj/dmufhMwZjfjIq+s62ZPB84byYvbbQtgp 9LCY2sIHNRWfwUzoGWXcV72QoDJugGGEs+sNFJ0fVpql6XJjWxcp0STM61a/JH1VgFmF 4PgeCzbIqlvoLXP9zWcNit8Crt/vFZHpVoG4D5TPqPXZbSfm/riym+1B7cMgc9heDzZc +T6N43hFm0HHpInQ5G4eq0GKsnSG09sEII6uvEmWZlm3mUglJUUHcx7utLy9uBIamnKQ /ChjE6LfCK/bZiAlCK0zEBWYl5sCBIdnBy8Cz8sVKeeifZSP+fNh6oZWu32xRqBOnk9g LcUw== X-Gm-Message-State: ALyK8tK5328DjetBk0AWX3DqqwpcxfadrAlfxZmdJU83CsJHVb7oispZ6T/reNT0AvEEaA== X-Received: by 10.98.204.130 with SMTP id j2mr1472749pfk.147.1465964299640; Tue, 14 Jun 2016 21:18:19 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-209-252-radius.dynamic.acsalaska.net. [209.112.209.252]) by smtp.googlemail.com with ESMTPSA id f187sm48767411pfb.60.2016.06.14.21.18.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 21:18:18 -0700 (PDT) To: Peter Bowen References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Melinda Shore Message-ID: <5a242e7c-bf5c-1bec-0252-31578a378517@gmail.com> Date: Tue, 14 Jun 2016 20:18:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 04:18:21 -0000 On 6/14/16 8:05 PM, Peter Bowen wrote: > To be clear, are you asking about 4.2 and 4.3 or just 4.2? At the moment, just 4.2. Melinda From nobody Tue Jun 14 22:53:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D636112B040 for ; Tue, 14 Jun 2016 22:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0xP0kQM0_XU for ; Tue, 14 Jun 2016 22:53:40 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4DE12B038 for ; Tue, 14 Jun 2016 22:53:40 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id e5so12277283ith.0 for ; Tue, 14 Jun 2016 22:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OGTWdigx3Ah2PBTc05gi0zYMfBFwG9AvI+cO/1jmCYY=; b=vDaJ6OVMuZnsbJp8WMXWvZOMYiSRJ7ut9Hgdo2GiEulTbbix77/onRsW8J09nAcEQD Kr75guISRGcVPrcfQZ79j0vTZv4/rX0w+rsHBckZycugTMDqVA+0i8L0VA/v7CYkjkey Rg2lI4fLJ9vfY5Dz9UX/TkQOyykKz+L++Cf/XC3a1dwUXhib8NrXHmKBuOpLQEwFnZvj YMBaUWHfAhWLNMNcyCBjlaRmTii4aLzYKDXyqsrpZfDzHmhUi+L2VlfL70kTIr7PiREV +zrhtCWKeeYPnW3LjUrafWKDWpD+Pqh0yx9k8xqKnTYbqULBLM5zs+Gm6QUKlbDacEM0 su5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OGTWdigx3Ah2PBTc05gi0zYMfBFwG9AvI+cO/1jmCYY=; b=gIngsz50WL8nbtkC2eIJJNGOS2muKeArgHlbaQAZpK/SEEQHPgusGMOKAz27cZPk0e Qs6VvySXv3HQQaA7t8SV4uPcC5cKrDJByGTURW94Y09ckiPz1BMDLbWOjdcUgnvY9wPf mEpI1W0lv3SgkVESIuSY04LZ/d1Ueo7YPpKPJxoG4E9f+4b2KelRPw6JnTxokUR9lCBd qgiEncxEnYh0iqXnXaxu29qABgtaWmGscc4U8VXyr8AJUnhp/gX718IXRnr9jWnVfuDU S0PMhbP4huw+jfKtplSg+BEYMZluLIYHKT0Hj+cXHNl2FIg3MOh3k2VS7B3+eV5CH7nU 3/8w== X-Gm-Message-State: ALyK8tJv04FSLgiIqTLp7KkxVJKIv3NpVy/2/OJr/ifz3GomXWcptGK5TKd8h1snuQLkZ0KsKPh+zHXqXQwZsw== X-Received: by 10.36.105.77 with SMTP id e74mr23590096itc.17.1465970019938; Tue, 14 Jun 2016 22:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.130 with HTTP; Tue, 14 Jun 2016 22:53:39 -0700 (PDT) In-Reply-To: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Peter Bowen Date: Tue, 14 Jun 2016 22:53:39 -0700 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 05:53:42 -0000 On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore wrote: > As we approach the end of working group last call on 6962-bis, > it looks like we have an unresolved question about whether > name redaction should stay or go. I just went through the > mailing list archive and it looks like we have squishy > agreement that it should go (for example, Rob's comment: > "Regarding fixing it: I'd rather nuke the redaction > option than add further complexity."). So, if anybody has > particularly strong feelings about this, or disagrees > about removing name redaction, please weigh in. I disagree with removing name redaction. There is value in having redacted certificates and it isn't questionable that having some info is better than none. For example, a CA could choose to log every certificate but redact some. This would make it very clear if a "rogue" certificate should up that didn't match any certificate on record. Symantec has also shown there is customer demand for redacted certificates -- they swapped their default to "log full certificate" a couple of weeks ago and have had several hundred certificates explicitly opt for redaction. From the domains, it seems that it is a number of different customers spanning multiple countries and types of organizations (commercial, government, non-profit, etc). I think redaction should stay. Thanks, Peter From nobody Wed Jun 15 01:33:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDDC12D19F for ; Wed, 15 Jun 2016 01:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TotiaBe-fI3f for ; Wed, 15 Jun 2016 01:33:10 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D3212D0A4 for ; Wed, 15 Jun 2016 01:33:09 -0700 (PDT) Received: (qmail 30775 invoked by uid 1004); 15 Jun 2016 08:33:06 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 15 Jun 2016 09:33:06 +0100 Received: (qmail 22876 invoked by uid 1000); 15 Jun 2016 08:33:06 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 15 Jun 2016 09:33:06 +0100 To: Melinda Shore References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Rob Stradling Message-ID: <4a2efa01-9bbd-05af-b165-96a476ada38d@comodo.com> Date: Wed, 15 Jun 2016 09:33:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 08:33:12 -0000 On 15/06/16 06:53, Peter Bowen wrote: > On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore wrote: >> As we approach the end of working group last call on 6962-bis, >> it looks like we have an unresolved question about whether >> name redaction should stay or go. I just went through the >> mailing list archive and it looks like we have squishy >> agreement that it should go (for example, Rob's comment: >> "Regarding fixing it: I'd rather nuke the redaction >> option than add further complexity."). So, if anybody has >> particularly strong feelings about this, or disagrees >> about removing name redaction, please weigh in. > > I disagree with removing name redaction. There is value in having > redacted certificates and it isn't questionable that having some info > is better than none. For example, a CA could choose to log every > certificate but redact some. This would make it very clear if a > "rogue" certificate should up that didn't match any certificate on > record. > > Symantec has also shown there is customer demand for redacted > certificates -- they swapped their default to "log full certificate" a > couple of weeks ago and have had several hundred certificates > explicitly opt for redaction. From the domains, it seems that it is a > number of different customers spanning multiple countries and types of > organizations (commercial, government, non-profit, etc). > > I think redaction should stay. Melinda, I think there are three potential ways forward... 1. (Stay) Keep the redaction mechanism in 6962-bis. 2. (Defer) Move the redaction mechanism into a separate I-D, so that TRANS can continue to work on defining redaction without holding up 6962-bis from progressing to RFC. 3. (Go) Kill the redaction mechanism entirely. Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 15 01:58:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38312D0AF for ; Wed, 15 Jun 2016 01:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgYyFVwPDupd for ; Wed, 15 Jun 2016 01:58:22 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FE3128E19 for ; Wed, 15 Jun 2016 01:58:22 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 5so17108844ioy.1 for ; Wed, 15 Jun 2016 01:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qvIWrmZBKtrkvxvcf2piY8DxKQztOzisbrxYWUH6jBk=; b=eaHUIgPjspQvhBNQ8+5TobYdBJWmQ6w+NkTj4Nscr/QxlivmvRp7vTY5StJR6iaH5j Tz2sOFWdEf4zpFSLxlfYIubKYOlGdkDWLN4tm3PcQWf/HOdd1YclYlMsNYRvMc9uC3n5 o7UyMj2DvawDQd17tTCKOaeAeku2zWmC4QiMA6XAKr3ce5x9pZNx+ALV6p+7bwybsDbI BTzBde6C/KwBhMKlsDHPz5dXm5DW3pQSavuGuom7DYTXXmsgLUO2pebPZWoQH8ca4Jkd ag5e2se+7htWoJS7tUoujrVJoHEkHEzZb35SqWI0fM8Ll3ZiNyZrteW73FarfW7JLHy2 TbHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qvIWrmZBKtrkvxvcf2piY8DxKQztOzisbrxYWUH6jBk=; b=f9dXY94WFvElMjAk+TcPzIK2FlVywurhVtrbk5Ox//yzk98yjXZZa7ECLG4RNlgs40 psAEp44c7V1qLLerxBf7HhQKDO3KjqrusMdaYuw3V7UfldBPBbnVV0iCVyIGTqnLCAFS t7CpJBUGYJzi4LrdQ/Yx927HxvzX8a6h9wQ+ngPzalUbI1FiOy/7gECqG7Mj6QBlReg7 ianKUriT2STjHiwHUDlnTjipXRWQxHq3mU+ThcK7V1lUaZuCgMXZCZZPqBb3F7P7qlUL WJN4RDW1/QcYu1isRhvEfCluVLzURDVAXejUycqQ4XKDAWeg33/hA8RB+ICR5kTP75R9 CkIA== X-Gm-Message-State: ALyK8tILmiEBCPuT+LMF7Mdr3//AKbQKoHJXC/em8jzh/9lZkzEyOFHQ93ERVyWjNJpEAf03DFPTxg3hL4y9wAaO X-Received: by 10.107.15.203 with SMTP id 72mr43031532iop.119.1465981101204; Wed, 15 Jun 2016 01:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.72 with HTTP; Wed, 15 Jun 2016 01:58:20 -0700 (PDT) In-Reply-To: <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> From: Ben Laurie Date: Wed, 15 Jun 2016 09:58:20 +0100 Message-ID: To: Andrew Ayer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Trans Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 08:58:24 -0000 On 9 June 2016 at 19:44, Andrew Ayer wrote: > On Thu, 9 Jun 2016 16:43:48 +0100 > Rob Stradling wrote: > >> On 06/06/16 19:17, Andrew Ayer wrote: >> > On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) >> > Paul Wouters wrote: >> > >> >> On Mon, 6 Jun 2016, Andrew Ayer wrote: >> >> >> >>> This enables the following attack: >> >>> >> >>> 1. A CA issues a legitimate certificate for www1.example.com and >> >>> logs a pre-certificate for ?.example.com. A monitor for >> >>> example.com knows the pre-certificate is legitimate because it >> >>> matches a known certificate for www1.example.com. >> >>> >> >>> 2. The CA misbehaves and issues an unauthorized certificate for >> >>> www2.example.com which, except for the DNS name, has exactly the >> >>> same details (including serial number and public key) as the >> >>> certificate for www1.example.com. The CA does not log a >> >>> certificate or pre-certificate. >> >>> >> >>> 3. An attacker serves the rogue certificate for www2.example.com >> >>> along with the SCT for the ?.example.com pre-certificate. TLS >> >>> clients accept it because the TBSCertificate that is reconstructed >> >>> from the certificate matches the TBSCertificate of the >> >>> pre-certificate. Monitors have no idea that there is a rogue >> >>> certificate for www2.example.com. >> >> >> >> That means the attacker has the private key? >> > >> > Yes, but that only limits the attack, not eliminate it. It means >> > that if the attacker gets the private key for one host, they can >> > (with CA collusion) pivot to attacking other hosts whose names match >> > the same redaction pattern. >> > >> >> I guess when the second certificate would be logged, this would >> >> show up as mis-issued, and possibly both certificates would get >> >> revoked? >> > >> > The second certificate would never be logged. The way that logging >> > is enforced is that clients reject certificates that aren't >> > accompanied by a valid SCT. But since an SCT for the first >> > certificate's pre-certificate can be used to prove that the second >> > certificate was logged, clients can be tricked into accepting the >> > second certificate even if it was never logged. >> > >> > That's basically the crux of the problem - with name redaction, >> > SCTs do not prove that a certificate was logged, they only prove >> > that some pre-certificate matching the name redacted pattern was >> > logged. I argue that for monitoring to be useful, SCTs need to >> > prove that a pre-certificate matching the exact name was logged. >> > >> > Regards, >> > Andrew >> >> If a wildcard cert for *.example.com is logged, it can be used for >> https://www1.example.com, https://www2.example.com and >> https://anythingyoulike.example.com. >> >> How does name redaction make the situation any worse than that? > > If a domain owner requests a wildcard certificate for *.example.com, > they are accepting the possibility that the certificate can be used > with any sub-domain. It's expected. > > If a domain owner requests a certificate for www1.example.com, the > expectation is that the certificate only works with www1.example.com. > But if the domain owner requests redaction, they are now making it > possible for the CA is misbehave and issue certificates for hosts > besides www1.example.com that will be accepted by clients and not > detected by the domain owner's monitor. That seems like a violation of > user expectation. That is still no different from the wildcard example, though - the CA can also issues a "second" cert for *.example.com (it is the same cert, of course) and mount the same attack. > It also seems like a violation of a core principle of CT: that > clients will only accept a cert if the cert is logged. However, when > redaction is used, clients will accept a cert even if it was actually a > different cert which was logged[1], as long as the two certs redact down > to the same pre-cert TBSCertificate. > > Regards, > Andrew > > [1] Technically, a pre-cert was logged, but a pre-cert is just a proxy > for a cert. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Wed Jun 15 02:00:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2E12B04B for ; Wed, 15 Jun 2016 02:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW4LQE4UfJU6 for ; Wed, 15 Jun 2016 02:00:29 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A140612D0AF for ; Wed, 15 Jun 2016 02:00:29 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 5so17147818ioy.1 for ; Wed, 15 Jun 2016 02:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rOkm9VnqVbc7cMv4r4SLP8SufyNUf61qpJneSHXmQcA=; b=cPKrzSVP47Qt8dKOxb3NNgAZA789e1WRJJ/4VdM8uGOc5atwcnBYMw+MWzx3aDk/c8 b/JJgY8UzcFxj4xYBY81PBmA056BM/xZimeGUwUlHUyBZI7z/DSkwoWKHLw7tHgfc0LG 5/NY+qTDRGbxVoJH5nFCSwSCbEj1cBvoMJRVGwtbtYka/09Hgvm6MPDApTjPgUdI+vDw mdaQ8bPTbC1TLM4oMhM80tJ8e6Zkj5d6sbK0oX5Yw/MY2zimc0k89Yl4VbUyI8MATAAJ 25ChmwobjDOH3vHnEA7kk6doYW3t2HbawQwSDXdOJUJ88rvOHjOpF5t5ipoXMDfoDORr DAag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rOkm9VnqVbc7cMv4r4SLP8SufyNUf61qpJneSHXmQcA=; b=cmCw0gTBgGOLViTSnZdt2qKgVaO/7/B5NiUiKOutugLYNkhxZQLdBCRr0xO6Kz3Hgl pjQJQaAeizFGFtQHQCTiOGnWWlK2GrgUU+eOWogrQu0FRuQjvxCWYCf0cihiL1VlDMWm KuipvIT4PoDSQ/TQfenWWmckcixi86VLHchrDAoMuY5OoWaxU6zCDHSOw+nXhYM/umj0 bYxCIDkBNnTq39la73jC2Nd10kQCZqPFp+tjfV9y8BIGDncgqQBn4PSZgWjcaaHkeZ8n vT6WcvHrJxeRLYKzUALWYEFHXtS3WXB8C8Nx1XYpTBoi/X3Mx6tzqJUzF061qvb3s53n 4y6g== X-Gm-Message-State: ALyK8tJFn0UrYNtEZxzUp7pcXcU8Esrvjgt2/lQIu4saz7VVrP9jemMUbno7oGJk91Y7cV+uFdoPVIl+bKUwPUZO X-Received: by 10.107.15.203 with SMTP id 72mr43042033iop.119.1465981228827; Wed, 15 Jun 2016 02:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.72 with HTTP; Wed, 15 Jun 2016 02:00:27 -0700 (PDT) In-Reply-To: References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> From: Ben Laurie Date: Wed, 15 Jun 2016 10:00:27 +0100 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Trans , Andrew Ayer Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 09:00:31 -0000 On 10 June 2016 at 15:16, Rob Stradling wrote: > I think it's fair enough to say that if you withhold information from CT, CT > won't help you as much as it otherwise would have done. > > I see the attraction of replacing "redacted labels not with '?' but with a > salted cryptographic hash of the label, with the salt specified in the > Redacted Labels Certificate Extension", but I'd prefer to avoid increasing > complexity. I also like this suggestion. It does have the obvious downside that dictionary attacks work, though they can be made expensive. From nobody Wed Jun 15 05:15:53 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595C612D1B1 for ; Wed, 15 Jun 2016 05:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpFGRMnzYURj for ; Wed, 15 Jun 2016 05:15:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BBFFB12D18E for ; Wed, 15 Jun 2016 05:15:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D17AC433413; Wed, 15 Jun 2016 12:15:48 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BAD67433406; Wed, 15 Jun 2016 12:15:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465992948; bh=5s+Cksa0Tz1WENrooZILFyKtD2D9tfDSces05LbI5Sc=; l=70; h=From:To:CC:Date:References:In-Reply-To:From; b=LCaIp3IChueOIMFW7GCtxwaE4r2Whnw/QZxnWSYDLGJc92nBGP2R8qFe2EyLUuwtZ E5MR4FQvCfz+0rk7NsxnENPMTUVvK++Vsos2SNwsODODfdGenlfupJJdO5vAclGyE7 bnf3dgtkUleYkfh1BGi/ZNmpeEMogncfCxPuV9yE= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B30AD1FC95; Wed, 15 Jun 2016 12:15:48 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 08:15:48 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 08:15:48 -0400 From: "Salz, Rich" To: Peter Bowen , Melinda Shore Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKA= Date: Wed, 15 Jun 2016 12:15:47 +0000 Message-ID: <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.61] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:15:52 -0000 > I think redaction should stay. Same here. Strongly in favor From nobody Wed Jun 15 05:47:25 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A8E12B03D for ; Wed, 15 Jun 2016 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syQ2Lxr2Z-G0 for ; Wed, 15 Jun 2016 05:47:22 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEF112D5B7 for ; Wed, 15 Jun 2016 05:47:20 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id z186so18798034ywd.2 for ; Wed, 15 Jun 2016 05:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=40fKmqXfkY5vmRzf7in84MNGCfcHjdLXPllvmFT+TVo=; b=fRNVbPwlQ9T/3Q/A6ig2UgKTEPFKJGXJ7lXIAknhkzBTML8SnociyMMNJ3tL74NepG sLeWeDF9SDpUkNJ8oIrZuY4arRs6kvTh2T5aXRWiKNQ/UgF3+2Unj0cpt3XJd7je0BSh 0NklYMWF22sUd+wF6CiTDgYen+/0xkOyMHNXnuYuf/3mPsr7FAksI4OjoenAwZGMfkO8 qTWytAfb68dOBQyGsDC+nclo7HghzuKF3T1r4Kdv23/sg4yK1YaudsVkvUJUyRvNYDBh eRKtc7/baiippx94fUpMNffx2RpGKvH7Hf4HlSYhgbPYnTCSGPF278dUh67lQ6Jc4+8l fiTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=40fKmqXfkY5vmRzf7in84MNGCfcHjdLXPllvmFT+TVo=; b=lCGs5tAwHQmeg7AGnXAPDiPfy5IJyFPdmsUuTSti1l6KA2wpt069pNmJLoUU5hOIxJ bCRJVhlRee0SypjkG4xmXEf8GNMv1FgR1G4DstNdJT4s6B5FsGZGuvkwZiHuseOERf7g jit+r7aR2XtUY5KFHoCugMdwzT6Aaf4pXS9/cVhJJCAO/W2mwag4zFZ5LiEedvUgULYo 8t+hLtXqnujibpWBQzjmJq4nO9DN0P77Ge+dhQ5MNEVc/HrLmC3NSX4AAC1XVQDQ+SrJ TmPh9gnfp6RdIxnOQ7WrNbUuS5mU/7yB+GPSO/ySz8dBnPBy9bfP07NAYkemunw+GyGL bFsw== X-Gm-Message-State: ALyK8tIl1YsHfIoJGFWKV05C1L9kJulGFx5bDyKVOhKOPGuYN+VUamaqxjmktUS8XdKoTJUpeiO6oU+bJZQX6DoN X-Received: by 10.13.223.135 with SMTP id i129mr5039100ywe.144.1465994839287; Wed, 15 Jun 2016 05:47:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Wed, 15 Jun 2016 05:47:18 -0700 (PDT) In-Reply-To: <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eran Messeri Date: Wed, 15 Jun 2016 13:47:18 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114e3724a40ed00535508591 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:47:24 -0000 --001a114e3724a40ed00535508591 Content-Type: text/plain; charset=UTF-8 Rich, why are you in favour of keeping redaction in? I'd very much like to remove redaction of labels (4.2.) as it adds significant complexity to the protocol - particularly burdening clients: * Clients would have to take apart a TBScertificate, modifying it and re-assembling it in the right manner to get the signature from the SCT to validate over the reconstructed, redacted TBSCertificate. * TLS client libraries don't usually support modification and re-encoding of certificates (as I've discovered implementing 6962 clients several times). * If the original, redacted precert had encoding violations it will be very hard for the client to re-encode it correctly (I'll point out that logs MAY accept cert chains that are "not fully valid according to RFC 5280 verification rules in order to accommodate quirks of CA certificate-issuing software"). This problem was narrowly avoided with RFC6962 and precertificates by virtue of being able to use the TBSCertificate as-is to assemble the PreCert structure signed by the SCT. I believe a name-constrained intermediate logged instead of the end-entity cert (4.3.) is a good enough solution: * It is functionally equivalent to redaction in end-entity certificates: Certificates with domain names that should be redacted would remain out of the logs. * It builds on an existing name constraining mechanism already supported in browsers. As the discussion on the ct-policy Chromium mailing list has shown, no consensus could be reached regarding a mechanism to constraint redaction any other way. * It puts the cost of redaction on the party that's interested in it in the first place - the issuer. I realize there may be operational costs making it more difficult/expensive to get redacted certs. That may serve to discourage unnecessary redaction. I'm keen to hear about cases where a name-constrained intermediate cannot be used, necessitating label redaction described in 4.2. Eran On Wed, Jun 15, 2016 at 1:15 PM, Salz, Rich wrote: > > > > I think redaction should stay. > > Same here. Strongly in favor > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114e3724a40ed00535508591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rich, why are you in favour of keeping redaction in?
<= br>
I'd very much like to remove redaction of labels (4.2.) a= s it adds significant complexity to the protocol - particularly burdening c= lients:

* Clients would have to take apart a TBSce= rtificate, modifying it and re-assembling it in the right manner to get the= signature from the SCT to validate over the reconstructed, redacted TBSCer= tificate.
* TLS client libraries don't usually support modifi= cation and re-encoding of certificates (as I've discovered implementing= 6962 clients several times).
* If the original, redacted precert= had encoding violations it will be very hard for the client to re-encode i= t correctly (I'll point out that logs MAY accept cert chains that are &= quot;not fully valid according to RFC 5280 verification rules in order to a= ccommodate quirks of CA certificate-issuing software"). This problem w= as narrowly avoided with RFC6962 and precertificates by virtue of being abl= e to use the TBSCertificate as-is to assemble the PreCert structure signed = by the SCT.

I believe a name-constrained intermedi= ate logged instead of the end-entity cert (4.3.) is a good enough solution:=
* It is functionally equivalent to redaction in end-entity certi= ficates: Certificates with domain names that should be redacted would remai= n out of the logs.
* It builds on an existing name constraining m= echanism already supported in browsers. As the disc= ussion on the ct-policy Chromium mailing list has shown, no consensus c= ould be reached regarding a mechanism to constraint redaction any other way= .
* It puts the cost of redaction on the party that's interes= ted in it in the first place - the issuer. I realize there may be operation= al costs making it more difficult/expensive to get redacted certs. That may= serve to discourage unnecessary redaction.

I'= m keen to hear about cases where a name-constrained intermediate cannot be = used, necessitating label redaction described in 4.2.

<= div>Eran




On Wed, Jun 15, 2016 at 1:1= 5 PM, Salz, Rich <rsalz@akamai.com> wrote:


> I think redaction should stay.

Same here.=C2=A0 Strongly in favor

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

--001a114e3724a40ed00535508591-- From nobody Wed Jun 15 06:25:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0925012D105 for ; Wed, 15 Jun 2016 06:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co1LZHew_dEG for ; Wed, 15 Jun 2016 06:25:22 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEF112B03E for ; Wed, 15 Jun 2016 06:25:22 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a186so17464630qkf.0 for ; Wed, 15 Jun 2016 06:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h1bYzFJ+WVUMPWHDTP4WPxapOyq/tQ1n8Rh2TVlBs1o=; b=VumUb07nmWS9InjSDheiPEVkl66vjV731Ctlz3XhLl8EnFHwKBTdrmQmw5gUMrM3Qb ke7/jPQ1AnDz0mQNt8Txhl+BniSDUeURsXr+wwg3FXcoYdOB8D6qFrdp1QwdOjSDChg6 mxoHm/QHc+HZdlxYpw8E7fKsX3dJHpZjuaqTGfoske4E2Vqe6xHddezrPIf33fJ5Gqk4 fZI2Ycq57BhzguLG98KOOvM71QRd7hJlzVtON/dkRDLM+7P5r48iSGjFX0G1uvLkErNb SpYx2fYklnNn98mjhPIFjTJBMpiihmzcy1yA3ppeIfRjG3pLcqZIAF6sS8tnV2gD+IcE O1vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h1bYzFJ+WVUMPWHDTP4WPxapOyq/tQ1n8Rh2TVlBs1o=; b=VUnLLES90foqr7YQX4O7P+OxEiXsFWgQneAQyk1UsPx0K9NxneJ0Fv/BC0c22OxbT5 Xz5n73cUV6ENmSpwmlDiDmDjJvTFcxFVE+XXR/5lw83Rkoq45Z0Q42tZisILg2FIax/5 HNFsFvwLJ0UqZaRsOuJx+aUxElGh/CkA92u4TfP6/9LngWtZ3Mecgi3XRDirU37PZcJC hrlUaExT0GYChO2nS2YdgUcZ12XemwL5plth3PrK5QvfAW+Ne2MttGVfPDRhXVDlIF+e JNJVK9bGha2khgDOiGaoj9GCkvd++TOhFLRYmwwuuFQYcUOHxDYLh5buPX6pIfWWO5B8 mITQ== X-Gm-Message-State: ALyK8tLRQ1cU38tvTEkXlvpnU1Yqtq9+311XA9yUwVdKrQOcg945yVW4FGZBertt0k44BCydBcXztAeGIPvTdh9H X-Received: by 10.200.44.136 with SMTP id 8mr26319438qtw.18.1465997121290; Wed, 15 Jun 2016 06:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.93.71 with HTTP; Wed, 15 Jun 2016 06:24:51 -0700 (PDT) In-Reply-To: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Warren Kumari Date: Wed, 15 Jun 2016 09:24:51 -0400 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 13:25:25 -0000 On Wed, Jun 15, 2016 at 12:03 AM, Melinda Shore wrote: > Hi, all: > > As we approach the end of working group last call on 6962-bis, > it looks like we have an unresolved question about whether > name redaction should stay or go. I just went through the > mailing list archive and it looks like we have squishy > agreement that it should go (for example, Rob's comment: > "Regarding fixing it: I'd rather nuke the redaction > option than add further complexity."). So, if anybody has > particularly strong feelings about this, or disagrees > about removing name redaction, please weigh in. I agree that it should go -- it adds significant complexity for (what seems to me to be) very little benefit... but than again, I'm of the view that the whole idea of redaction is silly, and that trying to hide internal domains a: is doomed to failure and b: smacks of security though obscurity. I understand that "the market" doesn't agree with me, so, well, perhaps my opinion is not valid... W > > Thanks, > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Jun 15 07:02:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EBF12D774 for ; Wed, 15 Jun 2016 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFxVMPlmHaEy for ; Wed, 15 Jun 2016 07:02:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72812D76D for ; Wed, 15 Jun 2016 07:02:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E3375433428; Wed, 15 Jun 2016 14:02:00 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CC89D43341E; Wed, 15 Jun 2016 14:02:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465999320; bh=QZ5HPIV83cONuM7jMYYLaQcsFRFlEbAI3m4gsDqUeqw=; l=354; h=From:To:CC:Date:References:In-Reply-To:From; b=K11GAs+fOAkPY6vpj8qYCO8vz6HmouZFNnbr9N/m+w8uHtpAxd0wOfVzZWN4euL3E a3j9fPMldmEWuO2QorG/+3Uremd1Vxc2CP4abNl015R01lmylxE4hT/B+VBwzh8c4x Sgp+y5URUTjSwIVlsZIwr0zcZkKWIq89+M1Y8i7E= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C88ED1FC96; Wed, 15 Jun 2016 14:02:00 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 07:02:00 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 10:02:00 -0400 From: "Salz, Rich" To: Eran Messeri Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKCAAEvuAP//0Yaw Date: Wed, 15 Jun 2016 14:01:59 +0000 Message-ID: <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:02:04 -0000 DQo+IEknbSBrZWVuIHRvIGhlYXIgYWJvdXQgY2FzZXMgd2hlcmUgYSBuYW1lLWNvbnN0cmFpbmVk IGludGVybWVkaWF0ZSBjYW5ub3QgYmUgdXNlZCwgbmVjZXNzaXRhdGluZyBsYWJlbCByZWRhY3Rp b24gZGVzY3JpYmVkIGluIDQuMi4NCg0KTm90IGV2ZXJ5Ym9keSBjYW4gYWZmb3JkIHRoZSBjb3N0 IG9mIGRvaW5nIHRoaXMgKGkuZS4sIHBheSBhIHB1YmxpYyBDQSB0byBjcmVhdGUgYW4gaW50ZXJt ZWRpYXJ5IGZvciB0aGVtKS4NCg0KCS9yJA0KDQo= From nobody Wed Jun 15 07:05:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C512D76C for ; Wed, 15 Jun 2016 07:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMzm7avWFCls for ; Wed, 15 Jun 2016 07:05:08 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E67712D149 for ; Wed, 15 Jun 2016 07:05:08 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id z186so20941140ywd.2 for ; Wed, 15 Jun 2016 07:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jKJs4NUqXjwvmw2iGgQw9SoyaOd7QQYAS5glx72OABE=; b=hLpIznlhHsiR0PflrXDz8XroPu6RaCZCaq8Hy1ox5V7mb5WInZw+MvbQtwbCl8gGRx Lo4g2+GqkvxWDzTN5OxIontL5zyBSDBXyTmYGoG1jBdaCNEVKB+9vQCJTgQGt5q3FMAu XhDvns59WQkwZ6aBbpb0nJerAVIo0kS7UB0DDE8VCu3f/xU6TRV7J+WfVIAqbQvUPiY7 32aQfoe1Zvt9halKqvzUXihRYRu5Z+FIwsbuulxvqBYWHlc7fC4cSxcSGZE16eFRtMts 5y5ue2Ke+V/3h5nu9Mi3RNKz8sJlrAKSdtRRUp+aLOFsXe19bmSJbK8ETQ3ozc1VuD6r 2psw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jKJs4NUqXjwvmw2iGgQw9SoyaOd7QQYAS5glx72OABE=; b=Wwzgb363Yqc8qheMQi4ziNcwG9g5hfp+XuxbSi8CHzhk4UDq9omiv9NmP8dpYSzAzu eSi69DWGKacGj9u0nWXDkRm0247anq8hrDlLienBGXAx9/xaDMidsBwiiHeHLm8X5Jd4 qaU2sgr11YbIoY1HViMOT0jp+YFOlDbOISDuMtc4kd8qcaKMWVnCRzjhf+mXI1Kfhv7d 3v4MmuIsEhFVPsSwrAKgJUmBnUEk59O5AIcmPxkUXC7CM7IDc0GGwveVMZnLTuMtFt6V m27DqFtatEzWUTfHZdHXsxRYGfu5vac3s3OPePfK0qa/W1OMFu/IWvjz5paW8xcK4CNm meQg== X-Gm-Message-State: ALyK8tJEf4SmHUE0egutjoIwKXFYCa0uAlCWiw36k+9ZTn18ZHUT6YVDjRonymzo4GeQQqRt7kuF6+auEx5S55Kg X-Received: by 10.13.205.69 with SMTP id p66mr5277203ywd.255.1465999507281; Wed, 15 Jun 2016 07:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Wed, 15 Jun 2016 07:05:06 -0700 (PDT) In-Reply-To: <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eran Messeri Date: Wed, 15 Jun 2016 15:05:06 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114e5824dfd46e0535519b89 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:05:12 -0000 --001a114e5824dfd46e0535519b89 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 3:01 PM, Salz, Rich wrote: > > > I'm keen to hear about cases where a name-constrained intermediate > cannot be used, necessitating label redaction described in 4.2. > > Not everybody can afford the cost of doing this (i.e., pay a public CA to > create an intermediary for them). > Can't the CA create the intermediate and keep it to itself in order to issue the end-entity certs? > > /r$ > > --001a114e5824dfd46e0535519b89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2016 at 3:01 PM, Salz, Rich <rsalz@akamai.com> wrote:

> I'm keen to hear about cases where a name-constrained intermediate= cannot be used, necessitating label redaction described in 4.2.

Not everybody can afford the cost of doing this (i.e., pay a public = CA to create an intermediary for them).
Can't the = CA create the intermediate and keep it to itself in order to issue the end-= entity certs?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /r$


--001a114e5824dfd46e0535519b89-- From nobody Wed Jun 15 07:08:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7B12D745 for ; Wed, 15 Jun 2016 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsyJIF0B8-tX for ; Wed, 15 Jun 2016 07:08:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7519112D650 for ; Wed, 15 Jun 2016 07:08:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F36B443341E; Wed, 15 Jun 2016 14:08:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DD01F433413; Wed, 15 Jun 2016 14:08:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1465999700; bh=TyboIUZ4X6yO0UGc59vv0WMHqWLTnuEsKVDwk2oO0pk=; l=1084; h=From:To:CC:Date:References:In-Reply-To:From; b=U3tQuBINWI8GlSU22PQizVpIHXFIjc5HZ6sIn6Aq+XmoX/5nGhAMopChnqT/XqVtB A/K50brCrl9EpihxYEYC1xwWSP1PWqjEVeWfUZXuAkJyUnTRmAreXKW8iPGCfmoatV uFhVhJOevESb5HvjLzhkUBhjHespNpX0WvfGklBA= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D31DA1FCA7; Wed, 15 Jun 2016 14:08:20 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 10:08:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 10:08:20 -0400 From: "Salz, Rich" To: Eran Messeri Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKCAAEvuAP//0YawgABENwD//70K4A== Date: Wed, 15 Jun 2016 14:08:20 +0000 Message-ID: <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:08:23 -0000 DQo+ID4gPiBJJ20ga2VlbiB0byBoZWFyIGFib3V0IGNhc2VzIHdoZXJlIGEgbmFtZS1jb25zdHJh aW5lZCBpbnRlcm1lZGlhdGUgY2Fubm90IGJlIHVzZWQsIG5lY2Vzc2l0YXRpbmcgbGFiZWwgcmVk YWN0aW9uIGRlc2NyaWJlZCBpbiA0LjIuDQoNCj4gPiBOb3QgZXZlcnlib2R5IGNhbiBhZmZvcmQg dGhlIGNvc3Qgb2YgZG9pbmcgdGhpcyAoaS5lLiwgcGF5IGEgcHVibGljIENBIHRvIGNyZWF0ZSBh biBpbnRlcm1lZGlhcnkgZm9yIHRoZW0pLg0KDQo+IENhbid0IHRoZSBDQSBjcmVhdGUgdGhlIGlu dGVybWVkaWF0ZSBhbmQga2VlcCBpdCB0byBpdHNlbGYgaW4gb3JkZXIgdG8gaXNzdWUgdGhlIGVu ZC1lbnRpdHkgY2VydHM/DQoNClRoYXQgZG9lc24ndCBhZGRyZXNzIHRoZSBpc3N1ZS4gIFdoZXJl IGNhbiBhIHN0YXJ0dXAsIGluIHN0ZWFsdGggbW9kZSwgZ28gdG8gZ2V0IHN1Y2ggYSBjZXJ0Pw0K DQpDVCBzaG91bGRuJ3QgcmVxdWlyZSAqZXZlcnl0aGluZyogb24gdGhlIHdlYiB0byBiZSBwdWJs aWMuICBOb3Igc2hvdWxkIGl0IHJlcXVpcmUgKmV2ZXJ5dGhpbmcqIGFjY2Vzc2libGUgdmlhIENo cm9tZSwgU2FmYXJpLCBvciBvdGhlciBDVCBicm93c2VyLCB0byBiZSBwdWJsaWMuICBBbmQgaXQg c2hvdWxkIG5vdCBsaW1pdCBwcml2YWN5IHRvIHRob3NlIHdpdGggZGVlcCBwb2NrZXRzLg0KDQpO b3cgbWF5YmUgeW91IGNhbiBhcmd1ZSB0aGF0IHRoaXMgaXMgYSBidXNpbmVzcywgbm90IGEgcHJv dG9jb2wvdGVjaG5vbG9neSBpc3N1ZS4gIEFuZCBJJ2xsIGFncmVlLiAgOikNCg0KDQo= From nobody Wed Jun 15 07:24:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9F12D7CC for ; Wed, 15 Jun 2016 07:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjaHS4snL-58 for ; Wed, 15 Jun 2016 07:24:35 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DEF12D7C5 for ; Wed, 15 Jun 2016 07:24:35 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a186so19155461qkf.0 for ; Wed, 15 Jun 2016 07:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1uJzFTwQonlLtyiTIoSUnMIYbHzbDqTwAMibfMD/+4s=; b=jSDmSvSk22JenJsVw5xvO1LKDumQHMr6Fdn47ubu8RcOcczwtRwEfovrJZ9rQyeTJS XtLtROiJUFAVFVtsscF75LLlZxnlBDAEdLsQta5EzHRQ5PMzsfdkC6icB81XNNj2eirH IuJfuDXne73hZVwkwv1tgsksIof0SQ2wdXzwYtPdXFH1Ja2W/C+N2zzIQoAJLTni9LQT L7en4iVC/h0iDT1XPnI6tt/o6Wa37WsXQwQwKZtcZYntNcGe2nWESrjmwK8D7H3lLtnx sVT8lC+2LCQeDk6akSj9XIr2ACBH9b3ThGv7qojSemGi+8vyxjlXTGRDCWj/iq/nIGki D4gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1uJzFTwQonlLtyiTIoSUnMIYbHzbDqTwAMibfMD/+4s=; b=NPSeNv1+kF9G9037XM3WEU6c60YlwoHLae8OMQ+380uZloRNYQ4VG9CaOFZDlXsLPi CRwAFu4zhtVaeLsjqJ05/2ABUTBn/GeY3KOX3nL8ZOj9qerXcoOHc3yl+xL3ff1xmXxf 2bKsXLy1qlEl0KjLgFYK2ha0hA0bJU2TZBM1B2KQ68BarMVlyoDKZyDtKJ743c1eWZhA O3an9uC4cc6uoAK7osWfas+Po9FC4iqjlqU2DtJZMVp6KUiBbPhKx1wmr4V7D/TpkGcc 5MbUT/R0guAjgw4/lvLBcBOEeenhPzn8iY5yOCExS9/1g/KUtufeNKEwpr0c4FsFuBkL HrRg== X-Gm-Message-State: ALyK8tLFleP/lZu6i2RrpLhFNKO5fK7czLQJQkznUyUlNy/XWe6nCisjNnEKV6jN13ZGjLuCdlpvL9+nLoJ5vD8K X-Received: by 10.129.43.84 with SMTP id r81mr5633220ywr.283.1466000674120; Wed, 15 Jun 2016 07:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Wed, 15 Jun 2016 07:24:33 -0700 (PDT) In-Reply-To: <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eran Messeri Date: Wed, 15 Jun 2016 15:24:33 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11413a526c5900053551e175 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:24:37 -0000 --001a11413a526c5900053551e175 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 15, 2016 at 3:08 PM, Salz, Rich wrote: > > > > > I'm keen to hear about cases where a name-constrained intermediate > cannot be used, necessitating label redaction described in 4.2. > > > > Not everybody can afford the cost of doing this (i.e., pay a public CA > to create an intermediary for them). > > > Can't the CA create the intermediate and keep it to itself in order to > issue the end-entity certs? > > That doesn't address the issue. Where can a startup, in stealth mode, go > to get such a cert? > Can you please elaborate on this scenario? Is it a startup with topsecretname.com? or topsecretproject.publicstartupname.com? I can't see redaction for the former (?.com) allowed in any scenario, and a wildcard cert (*.publicstartupname.com) would cover the other. > > CT shouldn't require *everything* on the web to be public. Nor should it > require *everything* accessible via Chrome, Safari, or other CT browser, to > be public. It doesn't. CT describes a protocol/mechanism for publicly disclosing certs, TLS client software in general (and browsers in particular) would decide on whether it's required. > And it should not limit privacy to those with deep pockets. This is where I truly lack data/insight. From a technical perspective, redaction with a name-constrained intermediate is equivalent to redaction of domain name labels but I don't know how much more work it is for a CA to set up (technical arguments on why they may not be equivalent are _very_ relevant to this discussion). Redaction can also be achieved by certificates with wildcards, so the only reason (I can see) to use 6962-bis redaction is to redact multiple levels of a domain name. > > Now maybe you can argue that this is a business, not a protocol/technology > issue. And I'll agree. :) > If only we could separate the two neatly :) --001a11413a526c5900053551e175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 15, 2016 at 3:08 PM, Salz, Rich <rsalz@akamai.com> wrote:

> > > I'm keen to hear about cases where a name-constrained in= termediate cannot be used, necessitating label redaction described in 4.2.<= br>
> > Not everybody can afford the cost of doing this (i.e., pay a publ= ic CA to create an intermediary for them).

> Can't the CA create the intermediate and keep it to itself in orde= r to issue the end-entity certs?

That doesn't address the issue.=C2=A0 Where can a startup, in st= ealth mode, go to get such a cert?
Can you please elab= orate on this scenario? Is it a startup with topsecretname.com? or topsecretproject.publicstartupname.com? I can't see= redaction for the former (?.com) =C2=A0allowed in any scenario, and a wild= card cert (*.publicstartupname.com= ) would cover the other.

CT shouldn't require *everything* on the web to be public.=C2=A0 Nor sh= ould it require *everything* accessible via Chrome, Safari, or other CT bro= wser, to be public.
It doesn't. CT describes a protoco= l/mechanism for publicly disclosing certs, TLS client software in general (= and browsers in particular) would decide on whether it's required.=C2= =A0
=C2=A0
And it should not limit privacy = to those with deep pockets.
This is where I truly lack dat= a/insight. From a technical perspective, redaction with a name-constrained = intermediate is equivalent =C2=A0to redaction of domain name labels but I d= on't know how much more work it is for a CA to set up (technical argume= nts on why they may not be equivalent are _very_ relevant to this discussio= n).
Redaction can also be achieved by certificates with wildcards= , so the only reason (I can see) to use 6962-bis redaction is to redact mul= tiple levels of a domain name.

Now maybe you can argue that this is a business, not a protocol/technology = issue.=C2=A0 And I'll agree.=C2=A0 :)
If only we c= ould separate the two neatly :)=C2=A0

--001a11413a526c5900053551e175-- From nobody Wed Jun 15 07:45:24 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F8012D7F3 for ; Wed, 15 Jun 2016 07:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNSrSzeWIl-g for ; Wed, 15 Jun 2016 07:45:21 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id A244F12D77B for ; Wed, 15 Jun 2016 07:45:20 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC11742370C; Wed, 15 Jun 2016 14:45:19 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 6E7BA423707; Wed, 15 Jun 2016 14:45:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466001919; bh=xTYZqWhuNQBDFioTsoiI4qL13AT5CzbWaR2SQD7SuLA=; l=2094; h=From:To:CC:Date:References:In-Reply-To:From; b=plhi5MqyHUo0AFdNiRvcNgerYht00fVCXsRGpw04KTZU0SpEEpxdNgnDSHM+YvXMN Wk+pqo4iAEE8Xg/HopJYR8JbPpSxsVHtT/NgTBv9tpEvzZgyQ6yZs5siq99b3kEwZw yYUOYOljoiRDUrF3s8qQvmzwqvWoVnObEpujcw9g= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 61FBF1FC86; Wed, 15 Jun 2016 14:45:19 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 10:45:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 10:45:17 -0400 From: "Salz, Rich" To: Eran Messeri Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKCAAEvuAP//0YawgABENwD//70K4IAASGWA///BtgA= Date: Wed, 15 Jun 2016 14:45:17 +0000 Message-ID: <5d46ceef7880480f8e4007b4a81a3975@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:45:24 -0000 DQo+IFRoYXQgZG9lc24ndCBhZGRyZXNzIHRoZSBpc3N1ZS7CoCBXaGVyZSBjYW4gYSBzdGFydHVw LCBpbiBzdGVhbHRoIG1vZGUsIGdvIHRvIGdldCBzdWNoIGEgY2VydD8NCj4gQ2FuIHlvdSBwbGVh c2UgZWxhYm9yYXRlIG9uIHRoaXMgc2NlbmFyaW8/IElzIGl0IGEgc3RhcnR1cCB3aXRoIHRvcHNl Y3JldG5hbWUuY29tPyBvciB0b3BzZWNyZXRwcm9qZWN0LnB1YmxpY3N0YXJ0dXBuYW1lLmNvbT8g SSBjYW4ndCBzZWUgcmVkYWN0aW9uIGZvciA+dGhlIGZvcm1lciAoPy5jb20pIMKgYWxsb3dlZCBp biBhbnkgc2NlbmFyaW8sIGFuZCBhIHdpbGRjYXJkIGNlcnQgKCoucHVibGljc3RhcnR1cG5hbWUu Y29tKSB3b3VsZCBjb3ZlciB0aGUgb3RoZXIuDQoNCkl0J3MgdGhlIGxhdHRlciwgb2YgY291cnNl LiAgQW5kIGEgd2lsZGNhcmQgY292ZXJzIG1vcmUuICBBbmQgYSBza3Vua3dvcmtzIG9yIHNlY3Jl dCBwcm9qZWN0IHdvdWxkIG5vdCB3YW50IHRoZSBnZW5lcmljIHdpbGRjYXJkLCBhbmQgdmljZS12 ZXJzYS4NCiANCg0KPkl0IGRvZXNuJ3QuIENUIGRlc2NyaWJlcyBhIHByb3RvY29sL21lY2hhbmlz bSBmb3IgcHVibGljbHkgZGlzY2xvc2luZyBjZXJ0cywgVExTIGNsaWVudCBzb2Z0d2FyZSBpbiBn ZW5lcmFsIChhbmQgYnJvd3NlcnMgaW4gcGFydGljdWxhcikgd291bGQgZGVjaWRlIG9uIHdoZXRo ZXIgaXQncyByZXF1aXJlZC7CoA0KDQpCdXQgbmFtZSByZWRhY3Rpb24gZ3JlYXRseSBsaW1pdHMg dGhlIGNob2ljZS4NCsKgDQo+IEFuZCBpdCBzaG91bGQgbm90IGxpbWl0IHByaXZhY3kgdG8gdGhv c2Ugd2l0aCBkZWVwIHBvY2tldHMuDQoNCj4gVGhpcyBpcyB3aGVyZSBJIHRydWx5IGxhY2sgZGF0 YS9pbnNpZ2h0LiBGcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlLCByZWRhY3Rpb24gd2l0aCBh IG5hbWUtY29uc3RyYWluZWQgaW50ZXJtZWRpYXRlIGlzIGVxdWl2YWxlbnQgwqB0byByZWRhY3Rp b24gb2YgZG9tYWluIG5hbWUgbGFiZWxzIGJ1dCBJIGRvbid0IGtub3cgaG93IG11Y2ggbW9yZSB3 b3JrIGl0IGlzIGZvciBhIENBIHRvIHNldCB1cCAodGVjaG5pY2FsIGFyZ3VtZW50cyBvbiB3aHkg dGhleSBtYXkgbm90IGJlIGVxdWl2YWxlbnQgYXJlIF92ZXJ5XyByZWxldmFudCB0byB0aGlzIGRp c2N1c3Npb24pLg0KDQpHbyBhc2sgdGhlIGZvbGtzIHdobyBydW4gcGtpLmdvb2dsZS5jb20gaG93 IG11Y2ggaXMgaW52b2x2ZWQuDQoNCj4gUmVkYWN0aW9uIGNhbiBhbHNvIGJlIGFjaGlldmVkIGJ5 IGNlcnRpZmljYXRlcyB3aXRoIHdpbGRjYXJkcywgc28gdGhlIG9ubHkgcmVhc29uIChJIGNhbiBz ZWUpIHRvIHVzZSA2OTYyLWJpcyByZWRhY3Rpb24gaXMgdG8gcmVkYWN0IG11bHRpcGxlIGxldmVs cyBvZiBhIGRvbWFpbiBuYW1lLg0KDQpUaGUgb3JpZ2luYWwgY2hyb21pdW0gcHJvcG9zYWwsIHJp Z2h0Pw0KDQo+SWYgb25seSB3ZSBjb3VsZCBzZXBhcmF0ZSB0aGUgdHdvLg0KDQpCdXQgeW91IGNh bid0LiAgVHJ1c3QgaXMgYSBidXNpbmVzcyBhbmQgYnJhbmRpbmcgaXNzdWUuDQo= From nobody Wed Jun 15 07:57:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9212D844 for ; Wed, 15 Jun 2016 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93kxuQ626Jqe for ; Wed, 15 Jun 2016 07:57:01 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED3012D836 for ; Wed, 15 Jun 2016 07:57:01 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id a186so21008006qkf.0 for ; Wed, 15 Jun 2016 07:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+GnOuhIWf22nUaP32gFPDMRxWO47XYlkfFrQVoTveh0=; b=l6hK7NpUwH0MLLkuMM1gDIeQ3zn4cy6drUaybudisT+4HpN1mgcaHrSvNUVJYBf3MC n6Un52+hHGVwT2SQ65atKJ8UEhataTN66fqWQcz5wh723uJ1QbbBNOc16VpqXWcAlQ2v 8pG7K2Z+/Ma4PlbbNgCJAGekEwqgbTvKe4WiJ/eXN6TiiSKvLRj3KpeQ/Lq4yWQZ4TR+ jVVIxV2Uuay9/Nzo1h3c8imKvoG2JaysBeRXpH+70WJrpbXB4OjisHx6oJ1KB2i2A78n x6Sz1zosOjGFt+LWCbVkEvUYkW5u7h06DAvBSoYz4qErP6FRo3coQkivid3SQWOf5m6x vHTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+GnOuhIWf22nUaP32gFPDMRxWO47XYlkfFrQVoTveh0=; b=DO3AqffG5unsp8DNOtTH2j1sExVfiax9Ppx4PRcsKGdsK+SffBngcB+tU8Dg3VIXBH s4UA8IY1sDwJP0XfwVQEElPm8zVvQA0q882Vg8hF0ovyQ4qnbpoVA2wRrLEYiQ0Hg5QC vVAROhfapcw7DMaTw0UnD23zpmgzXiNyrG6qyrHrOxmj50IHjaKJTb6ZlrjnLfTcGmzD tjkQUea1vzYqW7GAXg5uxa804JQz1WmP45dHAxtg+C+vev4MpqVXHy+9bgoMAoFluQNa POlqdVfDPAR49gN/SIZO4aKolrzTVBW2vS9Jf7vD2gymhNKhxn1FWDh3rSQOOp5XHgd+ H37A== X-Gm-Message-State: ALyK8tIabhUFWW+MEMB9XsA1rUJrgs8XD2JYfH8iUJtBQ7chaclC07/ZMwX7Tr8XZk6uS2/Zp9XzQOasTpolMRf8 X-Received: by 10.37.204.142 with SMTP id l136mr14450401ybf.90.1466002619912; Wed, 15 Jun 2016 07:56:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Wed, 15 Jun 2016 07:56:59 -0700 (PDT) In-Reply-To: <20160614203119.afe271bcb2d1489b60a56520@andrewayer.name> References: <20160614203119.afe271bcb2d1489b60a56520@andrewayer.name> From: Eran Messeri Date: Wed, 15 Jun 2016 15:56:59 +0100 Message-ID: To: Andrew Ayer Content-Type: multipart/alternative; boundary=94eb2c07d73a66deb9053552554a Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Some comments on draft-ietf-trans-rfc6962-bis-16 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:57:03 -0000 --94eb2c07d73a66deb9053552554a Content-Type: text/plain; charset=UTF-8 I'll send a pull request to address the comments, I've replied to some in-line. On Wed, Jun 15, 2016 at 4:31 AM, Andrew Ayer wrote: > Section 6.6 (get-all-by-hash): It's not clear whether the inclusion > proof is to the requested STH or to the returned STH. I'm pretty sure > it's supposed to be the returned STH, but this wording suggests it's > the requested STH: > > tree_size: The tree_size of the tree on which to base the > proofs, in decimal > > In this wording, it's unclear what "selected STH" refers to: > > inclusion: A base64 encoded "TransItem" of type > "inclusion_proof_v2" whose "inclusion_path" array of Merkle > Tree nodes proves the inclusion of the chosen certificate in > the selected STH. > I've changed the description to say 'returned STH' rather than 'selected STH' for more clarity. I didn't change the tree_size description as it seems obvious to me this is what the client requests, but text to clarify that this may not be what the client gets is welcome. > > > Section 10.1 (metadata): Is the Final STH specified as a TransItem of > type signed_tree_head_v2 or as a tree_size integer? > It doesn't have to be specified, but I've added a recommendation to provide it as a TransItem. > > > Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary > to remove the Transparency Information extension, but this step is > omitted. > Good point, added. > > > Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the TLS > Feature extension plays. > > 10.2.5 says that compliance means "accompanied by at least one valid > SCT." > > 10.2.6 says that if transparency_info is present in the TLS > Feature extension, then "CT compliance ... is required" and that "TLS > clients MUST treat certificates which fail this requirement as > non-compliant." In other words, non-compliance must be treated as > non-compliant, which isn't saying anything. > > 10.2.7 says that if the certificate chain is non-compliant, the "TLS > client MUST refuse the connection," which renders the TLS feature > extension unnecessary. > > I assume the intent is that if transparency_info is in the TLS Feature > extension, then TLS clients MUST refuse connections using non-compliant > chains. Otherwise, they MAY refuse connections using non-compliant > chains, depending on the client's policy. > What changes do you suggest here? That section 10.2.6 explicitly state that a TLS client must refuse the connection in case of non-compliance? > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c07d73a66deb9053552554a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll send a pull request to address the comments, I= 9;ve replied to some in-line.

On Wed, Jun 15, 2016 at 4:31 AM, Andrew Ayer <agwa@andrewayer.name&g= t; wrote:
Section 6.6 (get-all-by-hash): It'= s not clear whether the inclusion
proof is to the requested STH or to the returned STH.=C2=A0 I'm pretty = sure
it's supposed to be the returned STH, but this wording suggests it'= s
the requested STH:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 tree_size:=C2=A0 The tree_size of the tree on w= hich to base the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proofs, in decimal

In this wording, it's unclear what "selected STH" refers to:<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inclusion:=C2=A0 A base64 encoded "TransIt= em" of type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "inclusion_proof_v2" whose "incl= usion_path" array of Merkle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tree nodes proves the inclusion of the chosen c= ertificate in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the selected STH.
I've= changed the description to say 'returned STH' rather than 'sel= ected STH' for more clarity. I didn't change the tree_size descript= ion as it seems obvious to me this is what the client requests, but text to= clarify that this may not be what the client gets is welcome.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">

Section 10.1 (metadata): Is the Final STH specified as a TransItem of
type signed_tree_head_v2 or as a tree_size integer?
It= doesn't have to be specified, but I've added a recommendation to p= rovide it as a TransItem.=C2=A0


Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary=
to remove the Transparency Information extension, but this step is
omitted.
Good point, added.=C2=A0


Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the TLS Feature extension plays.

10.2.5 says that compliance means "accompanied by at least one valid SCT."

10.2.6 says that if transparency_info is present in the TLS
Feature extension, then "CT compliance ... is required" and that = "TLS
clients MUST treat certificates which fail this requirement as
non-compliant."=C2=A0 In other words, non-compliance must be treated a= s
non-compliant, which isn't saying anything.

10.2.7 says that if the certificate chain is non-compliant, the "TLS client MUST refuse the connection," which renders the TLS feature
extension unnecessary.

I assume the intent is that if transparency_info is in the TLS Feature
extension, then TLS clients MUST refuse connections using non-compliant
chains.=C2=A0 Otherwise, they MAY refuse connections using non-compliant chains, depending on the client's policy.
What cha= nges do you suggest here? That section 10.2.6 explicitly state that a TLS c= lient must refuse the connection in case of non-compliance?=C2=A0

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

--94eb2c07d73a66deb9053552554a-- From nobody Wed Jun 15 10:33:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8032A12D841 for ; Wed, 15 Jun 2016 10:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4njbzufHdRq for ; Wed, 15 Jun 2016 10:33:05 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7544212D5AF for ; Wed, 15 Jun 2016 10:33:05 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id t190so10803149pfb.3 for ; Wed, 15 Jun 2016 10:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DFZb0oOA7wYdAyMyA92whAGmV4rgJ1AVn/k+x+r+cCI=; b=byAvp+tK9VuuedaPp9cg7XC8IE9XXk85LgmVaZDqLP8GariHJesXmTYCFIezPNSLKb QSQAa7gQRhNvVVzVmf++YetmnIgll4sipGPwiFcw1F4dPDqVQls35pp/y6mWDy7SPwxb 92GQmay0KAjdOAQzAkeP++G8nUGKDDFZ87jSCeNOeM4q5jIjJZJ3CkEOjzs5kLXUCLxT 7qZuQYMZ55bPjV7ocNKnrWHQoEWVWZannRTfD13O1OPZ8gi/VYvxVN1kPXGEPZP0X7gH O2u7+vXh6RO0IJUEftH2UmWwu9M+TkAZC38DsjHt/CUg7kGNPnEl9Eu4Z4Dxn/gjoA6t 8tNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DFZb0oOA7wYdAyMyA92whAGmV4rgJ1AVn/k+x+r+cCI=; b=AcUKMshiMSU+pdUKOxD8dKbxkTDkzfiDOp5+eM17EdrHgjFambfWlqcwTWk4WQAZoF oQRq+keaxhjhl5Tr69bQ7IxSQUZRh9fEiKR70jBk2Slj35TepRUO5FrHgutlnuRYoR4c iJBbW3j0cMjMCV3Snwtfbll5I/O28/Hzqucv9b8pNye1/ENFMtYNXeiVhBC5dbS0QE8l bYxfJTyOgVXt5rIXuvVWnZJflu7YV0TPqxwHwUfrAw0dfCrPULygX+4YB0ZmyNffAgSs M/KoA977QSjWQ7mOlAwK/9i1WB22Gx7iAb6RmjfT8wl3Xla6CMtY+5irDVBptRkBAWdF 98/w== X-Gm-Message-State: ALyK8tJl9exqKRW3ubMNdSGf7sea0NyI5jLyMbLQblO9Bc4vmRy8EZZLrrdd/ex1SGD4ww== X-Received: by 10.98.79.194 with SMTP id f63mr4983466pfj.95.1466011985008; Wed, 15 Jun 2016 10:33:05 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-24-237-radius.dynamic.acsalaska.net. [216.67.24.237]) by smtp.googlemail.com with ESMTPSA id 189sm54500662pfd.18.2016.06.15.10.33.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 10:33:04 -0700 (PDT) To: Rob Stradling References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <4a2efa01-9bbd-05af-b165-96a476ada38d@comodo.com> From: Melinda Shore Message-ID: Date: Wed, 15 Jun 2016 09:33:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4a2efa01-9bbd-05af-b165-96a476ada38d@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:33:06 -0000 On 6/15/16 12:33 AM, Rob Stradling wrote: > Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"? I am asking "Stay or Go." Note that in the IETF someone can introduce a new topic/draft/whatever, and that in some sense no question is ever completely closed. But what I'm asking is what should be in 6962-bis. Melinda From nobody Wed Jun 15 10:48:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E60012D801 for ; Wed, 15 Jun 2016 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTNyDsKHg15C for ; Wed, 15 Jun 2016 10:48:38 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B92B12D5D5 for ; Wed, 15 Jun 2016 10:48:38 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 5so27873130ioy.1 for ; Wed, 15 Jun 2016 10:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=86LHsA1FDzaYEcHpl4oHz605n8/NSLcd7X8bWGE/aXw=; b=blKYB7RFCp4ZQawTmKa84IELqOVcBliXLFio2gIx4Wk4EuyxE//4fmapmZCzNgksJq 7aW9tQSDNZNocT5qF6RTA++QSuiPF22Jke4i6QgNNd5Uq4Atpm5nMKPEbzVcy7IzSIvG 0GMipSXKNQao16Fk+FaP8E4yKi+7kSKawffgq7oZc7bd+JBc612L13krL/oiwJOCIekB kz4l4cZcgwrTHay/SqnC1xN105Z5if7OfCONgdCZDM5O4PpzBTKkg3H74r5R5yZglRxK Vx/dOEBzP7o75QFgzc3S8XdO0XuQWdRtyRgimgfQFyH/UVk/ROVGq/00M2SvKxjGSQea GiQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=86LHsA1FDzaYEcHpl4oHz605n8/NSLcd7X8bWGE/aXw=; b=J0QYI7KP+zxOPYofmsd1Pq0rYgbmWwV0ohj/pOXOmUVlDWvY7gXyucVgFxZzTM7Y3R LXSUvHsn5YsaSP03d4Ll9dyiuXz5ffsWZTmmx8EQQtBTvmnhOUBl/MhhFXDsE74k6qbV HZbt3ZniQx0Vu6OENz2Bs3ix5BscRqIHVS6dt0rasrgC2xNnJdrZA/tWAXzA33jCiAuI Wg5LR+e5aNAkwiqGyJhjG4ht99Es0+etZ6DryBVNXQOypEKHr9Xum2rNVk1m+TaED43t pQfYubOdJijk8+Mtmiz6z9TkrdGctuRzg+gaSJE1lNCcv14kNJj39XW3G9v5yh+NF1HI ae0w== X-Gm-Message-State: ALyK8tJZvYZaZMJGyZN5xSALAYnydn6SMK8v8I5L0IvSWJlaRprdusiEAwGHtbD40f3kjJMMm7MyJY7ApISn3Br2 X-Received: by 10.107.15.203 with SMTP id 72mr1164815iop.119.1466012917422; Wed, 15 Jun 2016 10:48:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.136.72 with HTTP; Wed, 15 Jun 2016 10:48:36 -0700 (PDT) In-Reply-To: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <4a2efa01-9bbd-05af-b165-96a476ada38d@comodo.com> From: Ben Laurie Date: Wed, 15 Jun 2016 18:48:36 +0100 Message-ID: To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rob Stradling , "trans@ietf.org" , Peter Bowen Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:48:40 -0000 I think on balance it should stay. My reasoning is that it is unclear whether it will be used or not. Implementations that decide not to use it are not burdened by the specification. Adding it back later is substantial pain. If it really turns out to be useless, it can be removed in a later iteration. On 15 June 2016 at 18:33, Melinda Shore wrote: > On 6/15/16 12:33 AM, Rob Stradling wrote: >> >> Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"? > > > I am asking "Stay or Go." Note that in the IETF someone can > introduce a new topic/draft/whatever, and that in some sense > no question is ever completely closed. But what I'm asking is > what should be in 6962-bis. > > Melinda > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Wed Jun 15 10:57:01 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2656312DACB for ; Wed, 15 Jun 2016 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyRabVUCnAFB for ; Wed, 15 Jun 2016 10:56:59 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2368E12DAC8 for ; Wed, 15 Jun 2016 10:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466013418; bh=1/dzzaRs1WlbIM+NzB6dMuhdYbiMFdAMVTg8ezOTOts=; h=Date:From:To:Subject:In-Reply-To:References; b=HALPyCWIVwN10sh8onSOlXHn8n8NxDHfHyr5VxkrB4AgvV3j+inCv35w1iCglT6Gz qfB7zq1IlDbAAgrwb3JjyZt3sfwXyJnlZwkchBJ8xIr+TE37e56oqup/zaHPn1LoNS HF4v8ycct1Pr5vuNdBH5qCY+l4nyY7whMii8u1w/lwotVRklHwUuBER6c3ZgBkuIxf LVpFlQUDsXmNGTRUk6i+PkUcyTYIHSAK9kWww0tEj5RVpSGfbcy8xr6hcRN1/vzltP pYAdAqxnY/eN/PPeExRSWMM1j685lO4tDAyUAFSPIaaqybmGgOLbdMlDDhCmKHkuUU VpRAc1rwFDUBw== Date: Wed, 15 Jun 2016 10:56:58 -0700 From: Andrew Ayer To: Trans Message-Id: <20160615105658.c3226171a02089f4106cc88d@andrewayer.name> In-Reply-To: References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:57:00 -0000 On Wed, 15 Jun 2016 10:00:27 +0100 Ben Laurie wrote: > On 10 June 2016 at 15:16, Rob Stradling > wrote: > > I think it's fair enough to say that if you withhold information > > from CT, CT won't help you as much as it otherwise would have done. > > > > I see the attraction of replacing "redacted labels not with '?' but > > with a salted cryptographic hash of the label, with the salt > > specified in the Redacted Labels Certificate Extension", but I'd > > prefer to avoid increasing complexity. > > I also like this suggestion. It does have the obvious downside that > dictionary attacks work, though they can be made expensive. A sufficiently-long random salt makes dictionary attacks infeasible. Since the salt is only specified in the certificate, anyone who knows the salt knows the unredacted labels already. Regards, Andrew From nobody Wed Jun 15 11:04:36 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070ED12DAC0 for ; Wed, 15 Jun 2016 11:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VH8h4Qsh_-E for ; Wed, 15 Jun 2016 11:04:32 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C003D12D86A for ; Wed, 15 Jun 2016 11:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466013871; bh=iC3DosEFkTdZHmgpyV5CsrZgUiJoRiIo8rQYZiV9SkU=; h=Date:From:To:Subject:In-Reply-To:References; b=BS4aHkMhBLeO14ZrMgiKT/QFFmPOJNIaMxN3HN+dRgzMt1DpX32oZUU7cvKcWGpR6 2bNHE7wYPRsYaACjz8wVZzhgiB5s7IYttE3+bFiZy9n0Kvm15CBiJZq0LIFTYKwoI2 OVHUZgUJCRMfc6x5+W2c/0cJ2uYbUFtWZyizQJfUYmPs7MLmIEDRMMBFFjiVHglSye 4ZNnh1Boqf0oMrEB4A6/McVndAhF3203J7Do8RAQ2PIfUA4keLRloc57mrFGhLaD+n 6YuRk1ETEY4lDIVdXEUTOf/op4GSR6lDVflCHdpgrzicAbvjWOfE5DRRGSIr1Bw6mb 7C06ImDKduzFQ== Date: Wed, 15 Jun 2016 11:04:31 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20160615110431.87b47d675c97f87c91df4ced@andrewayer.name> In-Reply-To: <9b7fb24e-e028-dea3-ae33-1ebdcce4835d@bbn.com> References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> <20160609114450.e94b18a56e9539edccbb0cf2@andrewayer.name> <9b7fb24e-e028-dea3-ae33-1ebdcce4835d@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:04:35 -0000 On Mon, 13 Jun 2016 10:55:07 -0400 Stephen Kent wrote: > Andrew, > > > > > ... > > I would much rather the attack be fixed (I described one possible > > fix) than merely describing it in the threat document. Is this not > > an option? > Not for me to say. But I agree that the issue you cited is troubling. > > ... > > No, even if a monitor has access to full cert data, they aren't > > maximally useful when redaction is used (I consider this > > unexpected). If a monitor is configured with: > > > > www1.example.com should have key A > > www2.example.com should have key B > > > > and it sees a pre-cert for ?.example.com using key A, it can't > > say for certainty whether this is OK, because the pre-cert might be > > for www1.example.com, or it might be for www2.example.com. > > draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert > > in this case, which makes it possible to launch the attack I > > described. > > Yes, a Monitor serving www1 would think the log entry was OK, > even though it also would match www2. But, this requires that www2 > has the same key as www1. If there was a compromise of www1, then > I agree that a Monitor would not detect the compromise, but a > Monitor isn't really intended to do that. Alternatively, www1 could be operated by a third party who holds the private key (not an uncommon scenario). I think a Monitor should be expected to detect an attempt by that third-party to misuse their key to impersonate www2. > If this represents collusion > between www1 and www2 then this is good example of how colluding > Subjects could use an SCT issued for one Subject with a cert for > another Subject, because of the properties of redacted certs. Got it. It doesn't require collusion between the subjects. Rather, one subject colludes with the CA to attack the other subject. Regards, Andrew From nobody Wed Jun 15 11:43:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E6012D0F5 for ; Wed, 15 Jun 2016 11:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdyl5KMiS_ub for ; Wed, 15 Jun 2016 11:43:15 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6CF12D63B for ; Wed, 15 Jun 2016 11:43:15 -0700 (PDT) Received: from email.digicert.com (ex1-sgu [10.12.1.5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPS id B5E838FA2BD; Wed, 15 Jun 2016 18:43:14 +0000 (GMT) From: Jeremy Rowley To: Andrew Ayer , Trans Thread-Topic: [Trans] Name redacted pre-cert can correspond to multiple certs Thread-Index: AQHRwBkJ+d1uUWPxp0in/11IkI9qK5/dHOeAgAAG7ACABIv9AIAAMmkAgAFHl4CAB4NLgIAAleYA//+nCiA= Date: Wed, 15 Jun 2016 18:43:13 +0000 Message-ID: <2d4abb5697294607ac7652e195aba204@EX2.corp.digicert.com> References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> <20160615105658.c3226171a02089f4106cc88d@andrewayer.name> In-Reply-To: <20160615105658.c3226171a02089f4106cc88d@andrewayer.name> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.137.52.7] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0802_01D1C703.7A636A60" MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 18:43:17 -0000 ------=_NextPart_000_0802_01D1C703.7A636A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm in favor of keeping redaction in, even with the added complexity. Considering the number of enterprises that currently use domain names as a directory, I think redaction is the difference between wide spread adoption v. a single implementation for EV certificates. Since the intended beneficiaries of CT are primarily the website owners, giving them insight on certs issued to domains, it's up to the domain owner to have a policy for or against redaction of their domain names. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Andrew Ayer Sent: Wednesday, June 15, 2016 11:57 AM To: Trans Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs On Wed, 15 Jun 2016 10:00:27 +0100 Ben Laurie wrote: > On 10 June 2016 at 15:16, Rob Stradling > wrote: > > I think it's fair enough to say that if you withhold information > > from CT, CT won't help you as much as it otherwise would have done. > > > > I see the attraction of replacing "redacted labels not with '?' but > > with a salted cryptographic hash of the label, with the salt > > specified in the Redacted Labels Certificate Extension", but I'd > > prefer to avoid increasing complexity. > > I also like this suggestion. It does have the obvious downside that > dictionary attacks work, though they can be made expensive. A sufficiently-long random salt makes dictionary attacks infeasible. Since the salt is only specified in the certificate, anyone who knows the salt knows the unredacted labels already. Regards, Andrew _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_0802_01D1C703.7A636A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjE1MTg0MzEyWjAj BgkqhkiG9w0BCQQxFgQUA6kjSOxB3qDValzXqGDAdagN9oowgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEeOWYyYGYM5VolXwvNL7LvAqp+pLsrGRf2SHmSn SZERSSJqsZive5Cltc3B+bkn7bnf/9AihHDyA98u6WXA2XnygKDltVvTzJTe8qsgF4fXjyADVoGF aX1L7DCNAg10d6EP1RK19W5RS3H0/CY5SUBSs2qUsG9e9PECFaoa9Bz2r5UkFGCaBAiYG82pZJnF DwUJKgqMCVlFbxxe0If+BZaX7unJ22KqVPAvYK/t07i0R/ZIUL7vURHUMoAzqjif2otboQnM6bx6 U+S70d1OKR16WF/6APbNvkgYOHieisrNVY69oRgVnBGLEVHl7NHfytvy2HERkWsA9F21rz7CFh8A AAAAAAA= ------=_NextPart_000_0802_01D1C703.7A636A60-- From nobody Wed Jun 15 12:08:14 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1687012B04D for ; Wed, 15 Jun 2016 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uas9Zw7C5xsD for ; Wed, 15 Jun 2016 12:08:11 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F5912D63B for ; Wed, 15 Jun 2016 12:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466017690; bh=E9/QXfkMRU92F4oplXntZLDg9Od6Ig7Bmp/pOg0B6D0=; h=Date:From:To:Subject:In-Reply-To:References; b=sYz8Beh5nRAeJxOjVFAVwnFd5ZyFVEgULfcwJpRTkOcfz1PsUHGbS1uNcNQgao6do C44bfYUKPZfSqmCHII0ECjypvhWCfMHr28+c+LYJJYao5oOY7Ia4qBK+gYHa3dZEQG zNo//YA6JUboLfh1rap/jCupvWJc+XSl0/jka978qNf7ctFuS+2GSib82XPgOx/7Es Xq0FLdugesGdNuzrhI9XDIgh8JPdeMQ+vgPDMjoBpZf8fSimTqmZS5SEdj/P4c99CR px78JPzIaAXULzqLjzMutof996lX9HBOVDZW4WPm2YsVWmJ7XLknP2WoTO52t5he9+ afpVPpQbF4lAQ== Date: Wed, 15 Jun 2016 12:08:10 -0700 From: Andrew Ayer To: Trans Message-Id: <20160615120810.95d96faa74684411224e0f67@andrewayer.name> In-Reply-To: References: <20160606102935.c0c293fb4d7014aa44a180bb@andrewayer.name> <20160606111744.8dafc30af2562fd5dec55f20@andrewayer.name> <1591a26c-c3e7-719e-9a6d-3910779f33a7@comodo.com> <20160609114414.c033b7a6562f5afe27936506@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redacted pre-cert can correspond to multiple certs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:08:13 -0000 On Wed, 15 Jun 2016 09:58:20 +0100 Ben Laurie wrote: > On 9 June 2016 at 19:44, Andrew Ayer wrote: > > On Thu, 9 Jun 2016 16:43:48 +0100 > > Rob Stradling wrote: > > > >> On 06/06/16 19:17, Andrew Ayer wrote: > >> > On Mon, 6 Jun 2016 13:52:57 -0400 (EDT) > >> > Paul Wouters wrote: > >> > > >> >> On Mon, 6 Jun 2016, Andrew Ayer wrote: > >> >> > >> >>> This enables the following attack: > >> >>> > >> >>> 1. A CA issues a legitimate certificate for www1.example.com > >> >>> and logs a pre-certificate for ?.example.com. A monitor for > >> >>> example.com knows the pre-certificate is legitimate because it > >> >>> matches a known certificate for www1.example.com. > >> >>> > >> >>> 2. The CA misbehaves and issues an unauthorized certificate for > >> >>> www2.example.com which, except for the DNS name, has exactly > >> >>> the same details (including serial number and public key) as > >> >>> the certificate for www1.example.com. The CA does not log a > >> >>> certificate or pre-certificate. > >> >>> > >> >>> 3. An attacker serves the rogue certificate for > >> >>> www2.example.com along with the SCT for the ?.example.com > >> >>> pre-certificate. TLS clients accept it because the > >> >>> TBSCertificate that is reconstructed from the certificate > >> >>> matches the TBSCertificate of the pre-certificate. Monitors > >> >>> have no idea that there is a rogue certificate for > >> >>> www2.example.com. > >> >> > >> >> That means the attacker has the private key? > >> > > >> > Yes, but that only limits the attack, not eliminate it. It means > >> > that if the attacker gets the private key for one host, they can > >> > (with CA collusion) pivot to attacking other hosts whose names > >> > match the same redaction pattern. > >> > > >> >> I guess when the second certificate would be logged, this would > >> >> show up as mis-issued, and possibly both certificates would get > >> >> revoked? > >> > > >> > The second certificate would never be logged. The way that > >> > logging is enforced is that clients reject certificates that > >> > aren't accompanied by a valid SCT. But since an SCT for the > >> > first certificate's pre-certificate can be used to prove that > >> > the second certificate was logged, clients can be tricked into > >> > accepting the second certificate even if it was never logged. > >> > > >> > That's basically the crux of the problem - with name redaction, > >> > SCTs do not prove that a certificate was logged, they only prove > >> > that some pre-certificate matching the name redacted pattern was > >> > logged. I argue that for monitoring to be useful, SCTs need to > >> > prove that a pre-certificate matching the exact name was logged. > >> > > >> > Regards, > >> > Andrew > >> > >> If a wildcard cert for *.example.com is logged, it can be used for > >> https://www1.example.com, https://www2.example.com and > >> https://anythingyoulike.example.com. > >> > >> How does name redaction make the situation any worse than that? > > > > If a domain owner requests a wildcard certificate for *.example.com, > > they are accepting the possibility that the certificate can be used > > with any sub-domain. It's expected. > > > > If a domain owner requests a certificate for www1.example.com, the > > expectation is that the certificate only works with > > www1.example.com. But if the domain owner requests redaction, they > > are now making it possible for the CA is misbehave and issue > > certificates for hosts besides www1.example.com that will be > > accepted by clients and not detected by the domain owner's > > monitor. That seems like a violation of user expectation. > > That is still no different from the wildcard example, though - the CA > can also issues a "second" cert for *.example.com (it is the same > cert, of course) and mount the same attack. I suppose that one's perspective on this matter depends on what information they think a logged redacted pre-certificate should be able to convey to the domain owner. If an unredacted, non-wildcard pre-cert is logged, everybody knows what DNS name the cert is used with. If a wildcard pre-cert is logged, nobody knows what DNS name the cert is used with. I think that redacted pre-certs should occupy a middle ground: the domain owner (given the right information) knows what DNS name the cert is used with, but no one else does. This is why I think my attack is a problem. But if one thinks a redacted pre-cert shouldn't convey any more information to a domain owner than a wildcard pre-cert, then the attack is not a big deal. Regards, Andrew From nobody Wed Jun 15 12:26:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7612DB22 for ; Wed, 15 Jun 2016 12:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJHCunykxwL1 for ; Wed, 15 Jun 2016 12:26:16 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F32F12DB21 for ; Wed, 15 Jun 2016 12:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466018775; bh=/v1CFWxwx36WH/wKwilZPfhsxEm7Ef3DCX5RZROcu5Q=; h=Date:From:To:Subject:In-Reply-To:References; b=KYyKzdkpr1W5Fb40Mau9FlY2WwoITQ9/gr87oe6LYfVI35bxmSD14qQ0XEj0PY0QY 5AdYZJ0kPJ+ikRFN29NUrQZixGYKNqVjognQoAukNwLB+SJsxRhIa/on90zftVEb52 AfvPbxk6iiKfm/buGhzFKshr8wp8LWOvIoE0dhx3qn/Vr4UvoFGXgk/Tk/qtyC4LIS IXJ3dPV2lII4UCi781a2dPKOIxi+qdmF3DI6v++0xNZEwkocRPn+xigPHawZIXO6kw 5tE226m6zC9BmGLevSYj/PO7P+qLqaVOQgqUEbIbIj1yY0f53BdXKiR9n899woIUiD 5J1kSmRof3zNA== Date: Wed, 15 Jun 2016 12:26:15 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20160615122615.c3c68d82c07cdf1077426477@andrewayer.name> In-Reply-To: References: <20160614203119.afe271bcb2d1489b60a56520@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Some comments on draft-ietf-trans-rfc6962-bis-16 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:26:18 -0000 On Wed, 15 Jun 2016 15:56:59 +0100 Eran Messeri wrote: > On Wed, Jun 15, 2016 at 4:31 AM, Andrew Ayer > wrote: > > > Section 6.6 (get-all-by-hash): It's not clear whether the inclusion > > proof is to the requested STH or to the returned STH. I'm pretty > > sure it's supposed to be the returned STH, but this wording > > suggests it's the requested STH: > > > > tree_size: The tree_size of the tree on which to base the > > proofs, in decimal > > > > In this wording, it's unclear what "selected STH" refers to: > > > > inclusion: A base64 encoded "TransItem" of type > > "inclusion_proof_v2" whose "inclusion_path" array of Merkle > > Tree nodes proves the inclusion of the chosen certificate in > > the selected STH. > > > I've changed the description to say 'returned STH' rather than > 'selected STH' for more clarity. I didn't change the tree_size > description as it seems obvious to me this is what the client > requests, but text to clarify that this may not be what the client > gets is welcome. I'll think about it. Changing "Selected STH" to "Returned STH" is probably good enough. > > Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the > > TLS Feature extension plays. > > > > > 10.2.5 says that compliance means "accompanied by at least one valid > > SCT." > > > > 10.2.6 says that if transparency_info is present in the TLS > > Feature extension, then "CT compliance ... is required" and that > > "TLS clients MUST treat certificates which fail this requirement as > > non-compliant." In other words, non-compliance must be treated as > > non-compliant, which isn't saying anything. > > > > 10.2.7 says that if the certificate chain is non-compliant, the "TLS > > client MUST refuse the connection," which renders the TLS feature > > extension unnecessary. > > > > I assume the intent is that if transparency_info is in the TLS > > Feature extension, then TLS clients MUST refuse connections using > > non-compliant chains. Otherwise, they MAY refuse connections using > > non-compliant chains, depending on the client's policy. > > > What changes do you suggest here? That section 10.2.6 explicitly > state that a TLS client must refuse the connection in case of > non-compliance? I've opened a pull request on GitHub for my suggested changes: https://github.com/google/certificate-transparency-rfcs/pull/173 Regards, Andrew From nobody Wed Jun 15 13:04:28 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFA12DB42 for ; Wed, 15 Jun 2016 13:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9t0V2ZGUzgI for ; Wed, 15 Jun 2016 13:04:25 -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 CE00312D922 for ; Wed, 15 Jun 2016 13:04:25 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:42394 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDH30-000NES-3f for trans@ietf.org; Wed, 15 Jun 2016 16:04:22 -0400 To: trans@ietf.org References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <4a2efa01-9bbd-05af-b165-96a476ada38d@comodo.com> From: Stephen Kent Message-ID: <1d0b0e0b-3039-eab5-1cda-0aac9a7c196a@bbn.com> Date: Wed, 15 Jun 2016 16:04:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:04:27 -0000 Ben, > I think on balance it should stay. My reasoning is that it is unclear > whether it will be used or not. Implementations that decide not to use > it are not burdened by the specification. Adding it back later is > substantial pain. If it really turns out to be useless, it can be > removed in a later iteration. Support for redacted certs seems to be optional for CAs (as per 4.2.1). However, 10.2.2 seems to mandate support for redaction in TLS Clients. Thus it would seem that TLS Clients are burdened by redaction. Steve From nobody Wed Jun 15 14:52:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FF12D575 for ; Wed, 15 Jun 2016 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL-vLjEvnteX for ; Wed, 15 Jun 2016 14:52:28 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 2876B12D0A9 for ; Wed, 15 Jun 2016 14:52:28 -0700 (PDT) Received: from mistress.home.hezmatt.org (cl-134.syd-01.au.sixxs.net [IPv6:2001:4830:1200:85::2]) by mail.hezmatt.org (Postfix) with ESMTPSA id 4AC6094482 for ; Wed, 15 Jun 2016 21:52:24 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 6219F9FD1E; Thu, 16 Jun 2016 07:53:02 +1000 (AEST) Date: Thu, 16 Jun 2016 07:53:02 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20160615215302.GS18232@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:52:31 -0000 On Wed, Jun 15, 2016 at 02:08:20PM +0000, Salz, Rich wrote: > CT shouldn't require *everything* on the web to be public. Nor should it > require *everything* accessible via Chrome, Safari, or other CT browser, > to be public. And it should not limit privacy to those with deep pockets. CT doesn't require everything on the web to be public. It only requires everything authenticated by the web PKI to be public. - Matt -- There is no finite resource poor policy making can't make scarce. -- David Conrad, in NANOG From nobody Wed Jun 15 15:06:55 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3594D12DA28 for ; Wed, 15 Jun 2016 15:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN0iNHzTellM for ; Wed, 15 Jun 2016 15:06:53 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F6A12D0A9 for ; Wed, 15 Jun 2016 15:06:52 -0700 (PDT) X-AuditID: d80ac3f3-f79126d0000018fe-ea-5761d17bf6e8 Received: from ecl1mtahubpin01.ges.symantec.com (ussm-zone.relay.symantec.com [10.48.69.201]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id DA.11.06398.B71D1675; Wed, 15 Jun 2016 23:06:51 +0100 (BST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1bDIws-0003uh-Av; Wed, 15 Jun 2016 22:06:10 +0000 Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.73]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Wed, 15 Jun 2016 15:04:50 -0700 From: Sanjay Modi To: Melinda Shore , "trans@ietf.org" Date: Wed, 15 Jun 2016 15:04:48 -0700 Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AdHHUe9qrH6SUR6iTfuk3db3Z1Jzaw== Message-ID: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> In-Reply-To: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsXCZeB6Urf6YmK4wbV5whZtbbNYLNY+vsji wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWsu3+HseA3f8XeEydYGxj7ebsYOTkkBEwk ui5tYoKwxSQu3FvPBmILCbxilNiwW6yLkQvIfskoMfvUZmYIZyWjxOXja8A62AR0JDZNeskI YosI+El0X37EDGKzCKhKrFjcBlYjLGAo0fKgjQ2ixkhi5d8JQPUcQLaexOxtMSBhXgFTiVkz 10IttpG4v2U/2EhOAVuJFT8/sIDYjEDHfT8FsZZZQFzi1pP5UEcLSCzZc54ZwhaVePn4HyuI LQo0/t6juVC9ohJ32tczQvTqSdyYOoUNwtaWWLbwNTPEDYISJ2c+YZnAKD4LyYpZSFpmIWmZ haRlASPLKkaZktJiw+LckvzSkoLUCgNjveLK3ERghCXrJefnbmIERtkNrsOfdzD+3uN4iFGA g1GJh/f34cRwIdbEMqDKQ4wSHMxKIrx5p4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeYPKgsOE BNITS1KzU1MLUotgskwcnFINjMvbL4vcey+oftbqfu7Vxi3mle7bl8em7tizZJ8h0+bSPZMs hVuetd78LP9sddJDYZ4U351yMU57Dk5w4V/W8D9Z8X7yhEUTr+gbPRWSmZzl4sv/z4TrxIIv t0Ke9SWHe58zLDg/49VsT/c/HBq8941012bYHvyxYvF8zWPfjGM8N3/5mFRS46/EUpyRaKjF XFScCADd8BkTrgIAAA== Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:06:54 -0000 Redaction (4.2) should stay. It provides a necessary mechanism for domain owners to protect the privacy and security of their domains when participating in certificate transparency. With redaction, domain owners are able to get the full benefits of monitoring certificates issued to their domains and also get the privacy protection they need. We have talked extensively with customers who have validated the requirement for privacy. Since we rolled out redaction support several days ago, we have already had hundreds of customers select this option for over 1500 certificates. Other solution paths, while fail to support all of the key use cases like name redaction can: Wildcards =AD this could work for some organizations, however it is common for large enterprises to have explicit IT policies prohibiting the use of wildcard certificates. Name Constrained Intermediate =AD this has proven to be unmanageable as it is doesn=B9t enable additional domains to be added later, a key use case for most customers. Private CA =AD this too can work but is relevant only for non-browser use cases. Customers consistently choose publicly trusted certificates for internal sites for root ubiquity and manageability. Thanks, Sanjay On 6/14/16, 9:03 PM, "Melinda Shore" wrote: >Hi, all: > >As we approach the end of working group last call on 6962-bis, >it looks like we have an unresolved question about whether >name redaction should stay or go. I just went through the >mailing list archive and it looks like we have squishy >agreement that it should go (for example, Rob's comment: >"Regarding fixing it: I'd rather nuke the redaction >option than add further complexity."). So, if anybody has >particularly strong feelings about this, or disagrees >about removing name redaction, please weigh in. > >Thanks, > >Melinda > >_______________________________________________ >Trans mailing list >Trans@ietf.org >https://www.ietf.org/mailman/listinfo/trans From nobody Wed Jun 15 15:29:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08F12D586 for ; Wed, 15 Jun 2016 15:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zoN8-F9xb2A for ; Wed, 15 Jun 2016 15:29:16 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id D0EE812D186 for ; Wed, 15 Jun 2016 15:29:16 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4533342370E; Wed, 15 Jun 2016 22:29:16 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2EF32423704; Wed, 15 Jun 2016 22:29:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466029756; bh=H6Fnsy8QgPXfEcI0KMufGlY/7p5N38ZRSIwCEb+sbyg=; l=291; h=From:To:Date:References:In-Reply-To:From; b=B+Upe/EHfWEJtdtbA48j6/6AERO0wIuvwE1vFDnvbKLaN5mj3yiRDjWNxkDxLpqDF ePKolFPi9uPvu8jDm/0BF8L8JZlvsEk5dbgR+9Qa9DM1sKY3bCNyAwKYZNsXLynbij WvGN43B9xtA6n3E6I5S1oVjqdxuzYGtdDDTDoB2Q= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 253B61FC8B; Wed, 15 Jun 2016 22:29:16 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 18:29:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 18:29:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 18:29:15 -0400 From: "Salz, Rich" To: Matt Palmer , "trans@ietf.org" Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKCAAEvuAP//0YawgABENwD//70K4IAAxbMA///GzqA= Date: Wed, 15 Jun 2016 22:29:15 +0000 Message-ID: <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615215302.GS18232@hezmatt.org> In-Reply-To: <20160615215302.GS18232@hezmatt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.138] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:29:18 -0000 =20 > CT doesn't require everything on the web to be public. It only requires > everything authenticated by the web PKI to be public. Pretending that anyone can got an interoperable private PKI that's usable c= ommon browsers (Chrome Safari at least) is, well, just that: pretending. From nobody Wed Jun 15 15:58:57 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B29312D7F2 for ; Wed, 15 Jun 2016 15:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBkvhQPd5WSW for ; Wed, 15 Jun 2016 15:58:53 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B0212D7D5 for ; Wed, 15 Jun 2016 15:58:53 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id z189so121441110itg.0 for ; Wed, 15 Jun 2016 15:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vXDlxWtvb/PnP7VUjBtjiMQp+EF+hIYNygOceeEyozc=; b=RhvQZYud0olQ85sVTjZJ7uFq0DG5UcDhXUG5WEZSVHGlHzi2GYyrwXAfTZcIuV5Axx QzpblPG1i5x1fO1kmVyuyYEeJ6soI8oJU4AxNe0tf6lsiT/xFffFa75BI8Vtqchso/Lq DW1Tlm3SBmr9aAtUBmbcgPpNGg++i88yHtqjib271pbjlClt0BEDIYPw/ePyb835oCL3 4g+FBwulpl2lmMCSOSrJlILrwCwZEWzfc2y3z4dDHCbeP3WDMQql9gUYtoeJAWz/NCki EV9MSn6vuzMGk/uBxNSxZsIZ3E8np0hBwcc0WppspyU8iGALil3waPUXuUiAc0ByrJVD uVeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vXDlxWtvb/PnP7VUjBtjiMQp+EF+hIYNygOceeEyozc=; b=PiBkcao3+hRNste9XF47d/witLKwVyVpo9PerOKMXQKooUTS+aZ1dXw41wdnt4ay9r qH7vAXCPtpA7GlmzXgIHucfBIoDrpKOgBStzWsC17KmdK72xStQakiYy4socHH2PZc5M 9RyJeh6AK4GarVmPWN0o8Ao3w05F2DUGEnMIq3d4J2fpX3o5Qn4Nz8Ndh+wVZIbngw50 nACGCeqVwYVswcRHwNLI1O0Vbejn6kdTsLHtoZLzxYj+3cNrsT/yGDcLg8Rs1SeVEd0z N6xuNwBVoXTp+FVMpa/MCaWsFWpWCFjDq0p3FzZOailHD1wJYb9RVbnGN4ukRF2t4wwt daag== X-Gm-Message-State: ALyK8tLtrnJpCaRYjQXQm19oax4H2NiQrTgpB7wrJ0IMFEnb8StiL3+tnA5xUMQ7mvSjiz1LYAGztk+SP1m15A== X-Received: by 10.36.19.16 with SMTP id 16mr3203456itz.76.1466031532612; Wed, 15 Jun 2016 15:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.130 with HTTP; Wed, 15 Jun 2016 15:58:51 -0700 (PDT) In-Reply-To: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> From: Peter Bowen Date: Wed, 15 Jun 2016 15:58:51 -0700 Message-ID: To: Eran Messeri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Salz, Rich" , Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:58:55 -0000 On Wed, Jun 15, 2016 at 7:24 AM, Eran Messeri wrote: > On Wed, Jun 15, 2016 at 3:08 PM, Salz, Rich wrote: >> And it should not limit privacy to those with deep pockets. > > This is where I truly lack data/insight. From a technical perspective, > redaction with a name-constrained intermediate is equivalent to redaction > of domain name labels but I don't know how much more work it is for a CA to > set up (technical arguments on why they may not be equivalent are _very_ > relevant to this discussion). > Redaction can also be achieved by certificates with wildcards, so the only > reason (I can see) to use 6962-bis redaction is to redact multiple levels of > a domain name. The WebTrust for CA criteria require a full ceremony to generate CA keys (see section 4.1 in http://www.webtrust.org/homepage-documents/item54279.pdf). This is not cheap to execute. Each subordinate also needs to be configured in the CA's systems. Additionally many HSMs do have finite space -- so massively increasing the number of subordinates may require purchasing more HSMs. So a new intermediate is by no means free. Thanks, Peter From nobody Wed Jun 15 16:10:32 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9C12D930 for ; Wed, 15 Jun 2016 16:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lISECC1lral for ; Wed, 15 Jun 2016 16:10:29 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id DC02512D7D5 for ; Wed, 15 Jun 2016 16:10:28 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [1.43.248.33]) by mail.hezmatt.org (Postfix) with ESMTPSA id 8688B944BD for ; Wed, 15 Jun 2016 23:10:26 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 0E19C9FD1E; Thu, 16 Jun 2016 09:11:07 +1000 (AEST) Date: Thu, 16 Jun 2016 09:11:06 +1000 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20160615231106.GB18232@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615215302.GS18232@hezmatt.org> <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 23:10:31 -0000 On Wed, Jun 15, 2016 at 10:29:15PM +0000, Salz, Rich wrote: > > CT doesn't require everything on the web to be public. It only requires > > everything authenticated by the web PKI to be public. > > Pretending that anyone can got an interoperable private PKI that's usable > common browsers (Chrome Safari at least) is, well, just that: pretending. Now you're moving the goal posts. You said nothing about widely interoperable, and in fact, it's completely contrary to the idea of something that is "private". You can't have "private" and "accessible to lots of people", the world just doesn't work that way. Anything that's private enough that accidental or malicious disclosure isn't a significant risk is also going to be accessed by a sufficiently small group, or in a suitably constrained environment, that managing a private PKI is a smaller cost (and one which is paid by the beneficiary) than the external cost imposed upon the web PKI by redaction and other forms of attempted secrecy. For my money, I think redaction should go from 6962-bis. To my knowledge, the implementations of redaction are far less mature than the implementations of the rest of the spec, the one major client-side implementation of CT has made a policy decision not to support it, and there's still a number of different proposals to make it less prone to attack (hashed labels, et al). I believe that it would be straightforward to retrofit it into the system with a separate RFC at a later time, when all the kinks have been worked out, so there's no reason not to remove it now and have those people who believe redaction is worth pursuing work on it separately. - Matt From nobody Wed Jun 15 18:03:51 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521ED12DA34 for ; Wed, 15 Jun 2016 18:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPW1Ip6jHG9y for ; Wed, 15 Jun 2016 18:03:48 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id BF60C12D504 for ; Wed, 15 Jun 2016 18:03:48 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1800E423705; Thu, 16 Jun 2016 01:03:48 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id F097A4F0AD; Thu, 16 Jun 2016 01:03:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466039027; bh=rptIfhCL2iWBqm+goznNG8OuKPXrzmVGmsfE2X/PSSw=; l=75; h=From:To:Date:References:In-Reply-To:From; b=Y4rlaJSVgiD0LCT0UX6G4ZQSzq6g3ChoXxB6FBbTBDNVwZDb2uoYw43lIkXPJvMMb CQjFr18ObeTRXjYwa0qYiMK0LOENhXdHIPpgbun0QfM2UlTLvy3fC7oUzxaEvs8ljB EAXTDzTVajnSSYXUbZ1BMHRUEQNzQjomUFQNQS2c= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EDBFB1FC88; Thu, 16 Jun 2016 01:03:47 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Jun 2016 21:03:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 15 Jun 2016 21:03:47 -0400 From: "Salz, Rich" To: Matt Palmer , "trans@ietf.org" Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/qSh+AgAAnpKCAAEvuAP//0YawgABENwD//70K4IAAxbMA///GzqAACeBJAAAEdeFA Date: Thu, 16 Jun 2016 01:03:46 +0000 Message-ID: <16a4dd9ac52f47258a25f5607861f5f8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615215302.GS18232@hezmatt.org> <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615231106.GB18232@hezmatt.org> In-Reply-To: <20160615231106.GB18232@hezmatt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.138] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 01:03:50 -0000 > Now you're moving the goal posts. No. CT would move the goalposts. From nobody Wed Jun 15 21:30:33 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38B812D16D for ; Wed, 15 Jun 2016 21:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBoC_KiSqHI8 for ; Wed, 15 Jun 2016 21:30:30 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890B812D131 for ; Wed, 15 Jun 2016 21:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466051429; bh=k2w7nTkscIHjJW806CKJ7afNjIXNzjWVLVjlXAzjp+M=; h=Date:From:To:Subject:In-Reply-To:References; b=ZmIlrZZ/UR02nqyFTFHSaI310IGHaepcL9IX+N3binkESd3959eGSNiJ+S7LjmUaE 8Y/vBPa2lAVS0n5eIPdEIJ32VLVL0iGHUIe1v8+qEDV+skahRvhwDXYaxG/im3SlYz 87ImJSL0Cu/NX68X4lSlgRBukqgouEMCBh3o0vJR44wNIOWrB04PJRwUPFSlI99Wp6 wpUYnsCxPSiwiqTOoBSWUDI5YvTCi24icBL4AHjcDVqjEXBdNJVYW6OvKiCkcvQ7Id WjN68v33mMowxuM4ezBhY5R7GftwSjrKCKxTehezqDLDAvUFwrnWPL7BuFc2eGIjvR 8qsOpk9fb8NQQ== Date: Wed, 15 Jun 2016 21:30:29 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20160615213029.7c8eebffb857898d60951f94@andrewayer.name> In-Reply-To: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 04:30:32 -0000 Having recently started work on code to reconstruct a precert TBSCertificate given a name-redacted certificate, I agree that the following is a concern: On Wed, 15 Jun 2016 13:47:18 +0100 Eran Messeri wrote: > * If the original, redacted precert had encoding violations it will > be very hard for the client to re-encode it correctly (I'll point out > that logs MAY accept cert chains that are "not fully valid according > to RFC 5280 verification rules in order to accommodate quirks of CA > certificate-issuing software"). A concrete example is a cert with trailing garbage at the end of the subjectAltName, such as this one: https://crt.sh/?q=cf144cad0599775dc273d02205f1fccfd042a43dbf382695950e82fa0b601ec7 When reconstructing a redacted pre-cert TBSCertificate, it is necessary to parse the subjectAltName and then re-encode it. Should implementations be expected to remember the trailing garbage and include it in the reconstructed TBSCertificate? I think that would be an unreasonable requirement due to the complexity. However, if a popular implementation decides to do that, and then the ecosystem gets flooded with certs exhibiting this encoding error, it will become a de facto requirement for other implementations, driving up the complexity cost of supporting redaction. Another challenge is non-ASCII characters in DNS SANs or IA5String common names. A client might normally ignore improperly-encoded identifiers so the certificate can still work with the other identifiers. However, with redaction, for the certificate to work for any identifier, the client needs to be able to decode all of them and then re-encode the incorrectly-encoded ones with the same encoding violation as the original certificate. Regards, Andrew From nobody Wed Jun 15 21:31:05 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EFC12D684 for ; Wed, 15 Jun 2016 21:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4VWhu8Hu1pJ for ; Wed, 15 Jun 2016 21:31:01 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F88E12D662 for ; Wed, 15 Jun 2016 21:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466051460; bh=Q6fdduU3UVVJIMWHCoLvwN3AlxENTd4Nkhd76os6SMo=; h=Date:From:To:Subject; b=H34lbpDVnOgfyMk0UDGcDdtMqVBHmNHAovw+d/kbTQtwM3+P7OBrnMi3GIJDHuPln HXYu6iK8m+S4Q1HIbb5z5lLaugvc6Jff6RRG79tMPKpY2Il8cf3/r9tz2+Bq4Brfg3 HuqbDZKvLM0bSgvKh+bV4aBBSafh9i8VmypYDgdhCyVWGSH/F6z72V2i17kxrzoTOy mlryFeTL315Ucw2hK13KpySAE1XeiKBPTew7mchtQIdq6yeiFPGW9eGFZpQSsymzYO Il6gF7HfZ4vbHkaSCJxVeWKYqNLbZ9uJLPHj3f1Hj3glod8yFNb2wHRRpTEulaCTtB yIuwC3y2M0wkg== Date: Wed, 15 Jun 2016 21:31:00 -0700 From: Andrew Ayer To: trans@ietf.org Message-Id: <20160615213100.2f6c3eed7546c70061aabeed@andrewayer.name> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Redacted Labels extension with zero elements X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 04:31:02 -0000 There is an annoying edge case where a certificate with no DNS- or CN-IDs can have a Redacted Labels extension with zero elements and not be invalid according to 6962-bis. This means you can't immediately reject a certificate if the Redacted Labels extension has fewer than one element. Combined with the requirement that the last integer implicitly repeats, this made my TBSCertificate reconstruction implementation more complicated than it would be otherwise. Considering that this code involves indexing an array, which carries a risk of invalid memory access in memory unsafe languages, I think it's important to make it possible to detect and reject bad input as easily and as early as possible. If redaction is not removed, could we specify that the Redacted Labels extension MUST NOT be present if no labels are redacted? Regards, Andrew From nobody Wed Jun 15 21:42:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0684412D641 for ; Wed, 15 Jun 2016 21:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nsg14CMYwKi for ; Wed, 15 Jun 2016 21:42:10 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E212D5D0 for ; Wed, 15 Jun 2016 21:42:09 -0700 (PDT) Received: from mistress.home.hezmatt.org (cl-134.syd-01.au.sixxs.net [IPv6:2001:4830:1200:85::2]) by mail.hezmatt.org (Postfix) with ESMTPSA id 0A87D9453F for ; Thu, 16 Jun 2016 04:42:08 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id B6A059FDA1; Thu, 16 Jun 2016 14:42:00 +1000 (AEST) Date: Thu, 16 Jun 2016 14:42:00 +1000 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20160616044200.GC6196@hezmatt.org> References: <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615215302.GS18232@hezmatt.org> <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615231106.GB18232@hezmatt.org> <16a4dd9ac52f47258a25f5607861f5f8@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16a4dd9ac52f47258a25f5607861f5f8@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 04:42:11 -0000 On Thu, Jun 16, 2016 at 01:03:46AM +0000, Salz, Rich wrote: > > Now you're moving the goal posts. > > No. CT would move the goalposts. CT moves the goalposts to a good place. - Matt -- A polar bear is a rectangular bear after a coordinate transform. From nobody Thu Jun 16 02:45:07 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7312B058 for ; Thu, 16 Jun 2016 02:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR2uuHCBeneZ for ; Thu, 16 Jun 2016 02:45:04 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD8412B071 for ; Thu, 16 Jun 2016 02:45:03 -0700 (PDT) Received: (qmail 30888 invoked by uid 1004); 16 Jun 2016 09:45:00 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 16 Jun 2016 10:45:00 +0100 Received: (qmail 31448 invoked by uid 1000); 16 Jun 2016 09:45:00 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 16 Jun 2016 10:45:00 +0100 To: "trans@ietf.org" References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <65e0223ed153494aadb37c5a16e66102@usma1ex-dag1mb1.msg.corp.akamai.com> <20e16d61944f429f841e508542de396b@usma1ex-dag1mb1.msg.corp.akamai.com> <12089452c67045baa9ed5e666abf6881@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615215302.GS18232@hezmatt.org> <93719e5a191b40beb1a35a58167503cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20160615231106.GB18232@hezmatt.org> From: Rob Stradling Message-ID: <4bf918b2-909c-5065-e901-de166985a529@comodo.com> Date: Thu, 16 Jun 2016 10:45:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160615231106.GB18232@hezmatt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Matt Palmer Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:45:06 -0000 On 16/06/16 00:11, Matt Palmer wrote: > For my money, I think redaction should go from 6962-bis. To my knowledge, > the implementations of redaction are far less mature than the > implementations of the rest of the spec, the one major client-side > implementation of CT has made a policy decision not to support it, and > there's still a number of different proposals to make it less prone to > attack (hashed labels, et al). I believe that it would be straightforward > to retrofit it into the system with a separate RFC at a later time, when all > the kinks have been worked out, so there's no reason not to remove it now > and have those people who believe redaction is worth pursuing work on it > separately. +1 For all of these reasons, I've been growing increasingly uncomfortable with the thought of the redaction mechanism (as currently defined in 6962-bis section 4.2) going into the Standards Track RFC that 6962-bis is destined to become. I think we should remove it from 6962-bis, and then work on a draft-trans-redaction I-D (with the aim of publishing it as an Experimental RFC). If we take this approach, I'll volunteer to be a document (co)author. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 16 06:40:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E4712D5F0 for ; Thu, 16 Jun 2016 06:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oE1U1kL0OmI for ; Thu, 16 Jun 2016 06:40:48 -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 C97D212D0FC for ; Thu, 16 Jun 2016 06:40:48 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:46509 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDXXL-00051h-Hq for trans@ietf.org; Thu, 16 Jun 2016 09:40:47 -0400 From: Stephen Kent To: trans@ietf.org References: <0cc70c0c-b9ba-c63c-ba9c-a830ed5e8684@gmail.com> <575868E5.7010908@tcinet.ru> <57598B56.3000604@bbn.com> <20160609114450.e94b18a56e9539edccbb0cf2@andrewayer.name> <9b7fb24e-e028-dea3-ae33-1ebdcce4835d@bbn.com> <20160615110431.87b47d675c97f87c91df4ced@andrewayer.name> Message-ID: Date: Thu, 16 Jun 2016 09:40:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160615110431.87b47d675c97f87c91df4ced@andrewayer.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat document - status and question X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:40:50 -0000 Andrew, >> ... >> Yes, a Monitor serving www1 would think the log entry was OK, >> even though it also would match www2. But, this requires that www2 >> has the same key as www1. If there was a compromise of www1, then >> I agree that a Monitor would not detect the compromise, but a >> Monitor isn't really intended to do that. > Alternatively, www1 could be operated by a third party who holds the > private key (not an uncommon scenario). I think a Monitor should be > expected to detect an attempt by that third-party to misuse their key to > impersonate www2. I agree that the purpose of a Monitor is to detect cert mis-issuance and having www2 be able to use the same SCT as www1 is an example of such. If the private key for www1 is held by another party because that party is running the web site on behalf of the entity responsible for www1, then www1 already has a serious vulnerability. Is there some other case where you envision www1 will grant a 3rd party access to its private key? >> If this represents collusion >> between www1 and www2 then this is good example of how colluding >> Subjects could use an SCT issued for one Subject with a cert for >> another Subject, because of the properties of redacted certs. Got it. > It doesn't require collusion between the subjects. Rather, one subject > colludes with the CA to attack the other subject. Yes, because name-redaction requires a pre-cert, and only a CA can submit a pre-cert, the CA issuing the pre-cert has to be complicit. Thanks for the clarification. Steve From nobody Thu Jun 16 07:05:10 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01B712D669 for ; Thu, 16 Jun 2016 07:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWJC4RC-5_zd for ; Thu, 16 Jun 2016 07:05:06 -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 B45BC12D0CE for ; Thu, 16 Jun 2016 07:05:06 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54968 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDXur-000MY6-Uj for trans@ietf.org; Thu, 16 Jun 2016 10:05:06 -0400 To: trans@ietf.org References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Stephen Kent Message-ID: Date: Thu, 16 Jun 2016 10:05:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:05:08 -0000 Peter, > On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore wrote: >> As we approach the end of working group last call on 6962-bis, >> it looks like we have an unresolved question about whether >> name redaction should stay or go. I just went through the >> mailing list archive and it looks like we have squishy >> agreement that it should go (for example, Rob's comment: >> "Regarding fixing it: I'd rather nuke the redaction >> option than add further complexity."). So, if anybody has >> particularly strong feelings about this, or disagrees >> about removing name redaction, please weigh in. > To be clear, are you asking about 4.2 and 4.3 or just 4.2? As I noted in my message to Ben yesterday, section 10.2. is also relevant, as it mandates TLS client behavior that deals with name-redacted certs. Steve From nobody Thu Jun 16 09:31:19 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAFC12D993 for ; Thu, 16 Jun 2016 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAfEFcLH2VEB for ; Thu, 16 Jun 2016 09:31:16 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA5E12D8F7 for ; Thu, 16 Jun 2016 09:31:16 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id v137so47804520ywa.3 for ; Thu, 16 Jun 2016 09:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tTFYH1k1Kc1p3PXRDAQnMNGSAXy3hvVi+b2WwxwoDsk=; b=l0KJBvaksCkA73ziLI62alnNuwA6rTKVIOJjB1NqbvTzrKLPNDzBK4TMs2HXjxs3YB gsr13YWxHj24bRUYzaTTyhyx8Cs3gigzV+K1Fgv3M0AW/z87Wx0cI1zt4mjaESNkgfoB B8/F4SnP8cQsfZL7DUnqTB23ciUWGJvscyTk/Z9D/u8YwKeuQqEt6lVkaqIB4qHq5sXg vGsBQE9bL42qN28MqG+oBI2MDWRQIlBUvWOyKHFWtfDzvDIfutNnRlKSOretiXNVwGb4 +vtltUzexyTFZMrFsHWLjJB2L1lfnyovIkto1cId1vEVdmlOBNfeRqrwwCSsmhMzz+U4 tBZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tTFYH1k1Kc1p3PXRDAQnMNGSAXy3hvVi+b2WwxwoDsk=; b=Xw1hBmQeeRUxXkV4Uopi2XfTB0NG4Baf07r7ZcAvCbpt7tblQ1lpVGYB1bu4OqsjMf JIVMqhSjhjwa6VnBdOutol+tKXwdy5Wwyq3eBWdXgJlv/STGYpP9YBUBeZ9lE574HxTZ oyShqmvBMkooyxcCBTDgALZj0GUkMHU5WCGWPGJ5ySF06fK08yxa9KaHV4fLFefpuJ/g oxhP2esj8YJHRnYVBjumdXMIRliujJOWtBbP2BvXJkxxeHmLUwlk6nY3dXR5TLAZuUYp VKpg28yXS8MovaKLuDcxnIo4jH7l179Wq5GBu2yTj5hrDQZSMCOsngeWsFHu8BoSe3r/ srQg== X-Gm-Message-State: ALyK8tJpLJqgv1TY/nWxCNtoEpjHDy9qwzh/xzH6Ub3O0U6JOq5qCEGzoo5NxG1B9uF1p5Nh8zCWb8sjHQroPCem X-Received: by 10.129.43.84 with SMTP id r81mr3335320ywr.283.1466094675424; Thu, 16 Jun 2016 09:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Thu, 16 Jun 2016 09:31:14 -0700 (PDT) In-Reply-To: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Eran Messeri Date: Thu, 16 Jun 2016 17:31:14 +0100 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11413a525661df053567c4e6 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 16:31:18 -0000 --001a11413a525661df053567c4e6 Content-Type: text/plain; charset=UTF-8 Attempting to summarize a discussion for redaction (that took place on another medium yesterday, Peter Bowen and Rich Salz will correct me if I'm wrong): - Redaction doesn't seem to be for domain names that are meant to be publicly resolvable, because there's no guarantee that the first client to connect to them will submit the certificate chain to a CT log (what expectation of confidentiality can be had for a domain name that is publicly registered, publicly resolvable to a non-internal IP and secured with a certificate from a public root?). - Redaction is needed for private namespaces: domains that utilize split-horizon DNS with hostnames that resolve only if looked up from an organization's internal network. Such domains are secured using public roots because in the era of Bring-Your-Own-Device the claim is it's infeasible to install private CA certificates on all devices that access the network (some are user devices, some don't support that). - In this scenario it is more reasonable to expect clients not to log the unredacted chain (I don't expect clients to log certs without SCTs by default due to privacy implications, though one can imagine a Firefox extension doing so). - My conclusion is that redaction is a defence-in-depth mechanism for keeping internal domain names, which are considered confidential information by some organizations, from leaking. Redaction does not provide full defence against such leaks as clients may still submit unredacted certs and logs may still log them. Another downside to redaction is that it makes it more difficult to track down what a redacted certificate is used for within an organization (i.e. the security team observes, in a log, a certificate for ?.example.com not issued by the CA that issues everything else for example.com. They would then have to contact the issuer to get the identity of the requester, whereas a similar certificate for something.example.com would only require internal investigation to find out the system the certificate is used by). On Thu, Jun 16, 2016 at 3:05 PM, Stephen Kent wrote: > Peter, > > On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore >> wrote: >> >>> As we approach the end of working group last call on 6962-bis, >>> it looks like we have an unresolved question about whether >>> name redaction should stay or go. I just went through the >>> mailing list archive and it looks like we have squishy >>> agreement that it should go (for example, Rob's comment: >>> "Regarding fixing it: I'd rather nuke the redaction >>> option than add further complexity."). So, if anybody has >>> particularly strong feelings about this, or disagrees >>> about removing name redaction, please weigh in. >>> >> To be clear, are you asking about 4.2 and 4.3 or just 4.2? >> > As I noted in my message to Ben yesterday, section 10.2. is also relevant, > as it mandates TLS client behavior that deals with name-redacted certs. > That's also my understanding of section 10.2. > > Steve > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a11413a525661df053567c4e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Attempting to summarize a discussion for redaction (that t= ook place on another medium yesterday, Peter Bowen and Rich Salz will corre= ct me if I'm wrong):
- Redaction doesn't seem to be for domain = names that are meant to be publicly resolvable, because there's no guar= antee that the first client to connect to them will submit the certificate = chain to a CT log (what expectation of confidentiality can be had for a dom= ain name that is publicly registered, publicly resolvable to a non-internal= IP and secured with a certificate from a public root?).
- Redact= ion is needed for private namespaces: domains that utilize split-horizon DN= S with hostnames that resolve only if looked up from an organization's = internal network. Such domains are secured using public roots because in th= e era of Bring-Your-Own-Device the claim is it's infeasible to install = private CA certificates on all devices that access the network (some are us= er devices, some don't support that).
- In this scenario it i= s more reasonable to expect clients not to log the unredacted chain (I don&= #39;t expect clients to log certs without SCTs by default due to privacy im= plications, though one can imagine a Firefox extension doing so).
- My conclusion is that redaction is a defence-in-depth mechanism for keep= ing internal domain names, which are considered confidential information by= some organizations, from leaking. Redaction does not provide full defence = against such leaks as clients may still submit unredacted certs and logs ma= y still log them.=C2=A0

Another downside to redact= ion is that it makes it more difficult to track down what a redacted certif= icate is used for within an organization (i.e. the security team observes, = in a log, a certificate for ?.example.com not issued by the CA that issues everything else for example.com. They would then have to contact the issuer to g= et the identity of the requester, whereas a similar certificate for something.example.com would only requ= ire internal investigation to find out the system the certificate is used b= y).


On Thu, Jun 16, 2016 at 3:05 PM, Stephen Kent <kent@bbn.com> wrote:
=
Peter,

On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore <melinda.shore@gmail.com> wrote:
As we approach the end of working group last call on 6962-bis,
it looks like we have an unresolved question about whether
name redaction should stay or go.=C2=A0 I just went through the
mailing list archive and it looks like we have squishy
agreement that it should go (for example, Rob's comment:
"Regarding fixing it: I'd rather nuke the redaction
option than add further complexity.").=C2=A0 So, if anybody has
particularly strong feelings about this, or disagrees
about removing name redaction, please weigh in.
To be clear, are you asking about 4.2 and 4.3 or just 4.2?
 As I noted in my message to Ben yesterday, section 10.2. is also relevant, = as it mandates TLS client behavior that deals with name-redacted certs.
=
That's also my understanding of section 10.2.=C2=A0

Steve


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

--001a11413a525661df053567c4e6-- From nobody Thu Jun 16 10:48:09 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A1812D781 for ; Thu, 16 Jun 2016 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.999, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAIrJ7hPFH6Q for ; Thu, 16 Jun 2016 10:48: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 DD3F912D80A for ; Thu, 16 Jun 2016 10:48:01 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49165 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDbOV-0008Tb-6F for trans@ietf.org; Thu, 16 Jun 2016 13:47:55 -0400 To: trans@ietf.org References: From: Stephen Kent Message-ID: <92dee26a-f6e2-e58b-db37-220f50f029cb@bbn.com> Date: Thu, 16 Jun 2016 13:47:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C9162173A58AB81B33F7DE67" Archived-At: Subject: Re: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 17:48:05 -0000 This is a multi-part message in MIME format. --------------C9162173A58AB81B33F7DE67 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Here are my comments on 6962-bis: Section 1. Still no definition of mis-issuance here. Why not use the text I supplied months ago, and cite the threat analysis document? There ought to be a mentionof the residual vulnerabilities that arise when usingname-redacted pre-certificates or wildcard certificates, in light of the recent discussions. Specifically, the problems Monitors face in trying to protect a Subject when the Subject’s name is encompassed by SCTs associated with these certificates. I thought the WG agreed, long ago, to not mandate behavior for TLS clients with regard to the presence or absence of SCTs. Yet this section says “TLS clients can thus require that all certificates they accept asvalid are accompanied by signed timestamps.” which seems to be pretty close to that. Section 3 The term “preannounce” seems odd. “Pre-register” might make more sense, given that the action of submission to a log is a form of registration. Online dictionaries that I queried gave definitions for preannounce that didn’t seem to be a great match to this activity. Saying that the submission of a pre-certificatesignifies a binding intent to issue the certificate is slightly misleading. A CA might not wind up issuing the associated certificate, for a variety of reasons. I think it would be better to just drop the word “binding” here. Section 4 Suggested re-wording: We define a mechanism to allow these private labels to not appear in public logs, *while still retaining the security benefits that accrue from using certificate transparency mechanisms.* In Section 4.1 wording is used to motivate the need for name-redacted pre-certificates. It does not say, explicitly, that wildcard certificates can be logged and used in the CT context. It also should note the possible problems they represent for Monitors. Given the recent debate about name-redaction, I’m not convinced that the description in 4.2.2 provides sufficient detail for Monitors and TLS clients to know precisely how to compare an SCT for a name-redacted pre-certificate to a certificate. RFC 5280 states that name constraints is a critical extension, so the text in 4.3 conflicts with that RFC. Section 5 The text still says Log operators MUST NOT impose any conditions on retrieving or sharing data from the log. I asked if Rich’s on-list statement about how Akamai planned to operate a log was consistent with this mandate, but never received a response. Section 5.1 should include a statement that the list of trust anchors accepted by a log is part of the log’s metadata. Section 5.3 allows a log to create it’s own OID, instead of using one of the log ID registries. This seems to allow for collisions, and is not consistent with the general IETF rationale for creating registries. The description for log shutdown is much improved from prior version that I read. However, there are a couple of requirements here that don’t have an associated explanation of how they can be achieved. Make it known to clients and monitors that the log will be frozen Keep the log running until the certificates in all of its entries have expired or exist in other logs (this can be determined by scanning other logs or connecting to domains mentioned in the certificates and inspecting the SCTs served). Section 8 The opening sentence is 5 lines long, which makes it a bit hard to read. But, overall, this section is much improved over previous versions. The description the benefits and disadvantages of the certificate extensionto carry an SCT mentions inclusion proofs. This may be confusing to readers, since the extension does not contain an inclusionproof. It would be better to say that use of this method to deliver an SCT requires that a TLS client use a different mechanism to acquire an inclusion proof (and STH). In Section 8.1 the discussion of collusion between a CA and a log ought to cite the relevant section(s) of the threat analysis. Section 9 The transparency information extension MUST be non-critical, for backward compatibility with TLS clients that are nopt CT-aware. Note that an OCSP responder may be separate from a CA; the wording in 9.1.1 needs to be revised to reflect that. What does 9.2 means when it says When a certificate chain includes such a certificate, this indicates that CT compliance is required. Required by what? Section 10 The opening sentence is not very useful for a standards track document. It suggests CT lacks a well-defined architecture. The metadata list in 10.1 seems to omit the set of trust anchors accepted by the log. In 10.2.4 the text says “…The client then has to verify …” Did you mean to say “MUST” here? The language in 10.2.5 about compliance isn’t very useful, when separated from the text in 10.2.7. Why have these as two separate subsections? The wording in 10.2.7 seems intended to skirt the prior agreement to not mandate client behavior in the event of amissing SCT. Also, the wording is sloppy. For example, the text says In the case that use of TLS with a _valid_ certificate is mandated ... Certificate _validity_ is defined by 5280 and profiles thereof. Do you mean to say a _CT-compliant certificate_ here? The same comment applies to the next bullet which describes what to do if use of a “valid certificate” is optional. Also, what does it mean for a TLS client to “not treat the certificate as valid?” The definition of a Monitor still seems to be wrong, and the recent debate about name-redacted certificates gives further evidence of that. I think most folks believe the primary function of a Monitor is to observe logs to detect when a certificate is logged that is not consistent with the Monitor’s information about the Subject of the logged certificate. The definitionof a Monitor provided here makes this function optional. It attributes to a Monitor a function that is, I believe, a function of Auditing. The text here is not very precise in describing Monitor behavior re looking for log entries that conflict with certificates the Monitor is trying to protect. I suggest using text from draft-kent-trans-monitor-auditor-01.txt. For example: A Monitor observes a set of logs to detect certificate mis-issuance. A Monitor notifies a Subject [CA-Subject] when a bogus (orerroneous) certificate [draft-ietf-trans-threat-analysis] has been issued on behalf of that Subject. Every CT-aware Subject is expected to either perform self-Monitoring or to arrange with a third-party Monitor to detect mis-issued certificates on behalf of the Subject. Similarly, the description of how a Monitor does its job seems to omit what I believe is its critical function. Again, the cited I-D above provide a concise description in its introduction: A Monitor performs its function by examining all entries from a set of logs and comparing these entries to reference data for a set of one or more Subjects. The reference data consists, at a minimum, of a list of Subject and Subject Alternative Names and the pubic key information associated with each, supplied by the Subject. If a Monitor detects a log entry for a certificate that is inconsistent with the reference data for a Subject, the Monitor notifies the Subject. A Subject may perform self-monitoring. Overall, this section seems inadequate as a description of Monitor functionality. Section 10.4 describes audit functions reasonably well, but presents a view that there is no separate Auditor function in CT. That conflicts with the design in draft-ietf-trans-gossip-02, and with draft-kent-trans-monitor-auditor-01. I suggest that the first paragraph of this subsection be reworded to characterize the Audit function as one that may be performed by a client, Monitor, or by a separate entity. This subsection also ends with a statement not appropriate for a standard track document, as I have noted before: The following algorithm outlines may be useful for clients that wish to perform various audit operations. The statement above should be revised to _require_ that an element performing the Audit function MUST perform all of these checks in a fashion that produces results identical to those that the algorithms would yield. If the document doesn’t establish these algorithms as authoritative it is not defining what the Audit function is, and the text is not a very useful part of a standards track document. Section 11 The last sentence here probably ought to be: Certificates in the frozen log that have not yet expired and require new SCTs _SHOULD_ be submitted to the new log and the SCTs from that log used instead. Section 13 The introduction text here is good, but it should be augmented with a discussion of the problems for Monitors posed by wildcard and name-redacted certificates (if the latter feature is retained). A reference to the threat document also would be appropriate here, rather than as a separate, trivial subsection (13.7). I suggest deleting that subsection. 13.1 says that a TLS client _may_ (lowercase) decide to reject a certificate w/o an SCT. This language is rather squishy compared to the strict language in 9.2. 13.2 should refer to Monitors (10.3) as the entities that detect mis-issuance. Monitors might be domain owners, as suggested, or CAs, or third parties, but the text here mentions only the 1^st example. 13.3 notes an important consideration, and its advice to CAs is good. Saying that clients may make a decision to reject such certificates underlines the potential for interoperability problems. I guess that’s OK for a statement in an SC section, but it seems a bit vague. I note that 13.4 refers to a trusted Auditor, which conflicts with the characterization of Auditing in Section 10. Making the chnges I suggest to section would address this issue. --------------C9162173A58AB81B33F7DE67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Here are my comments on 6962-bis:

Section 1.

 

Still no definition of mis-issuance here. Why not use the text I supplied months ago, and cite the threat analysis document?

 

There ought to be a mention  of the residual vulnerabilities that arise when using  name-redacted pre-certificates or wildcard certificates, in light of the recent discussions. Specifically, the problems Monitors face in trying to protect a Subject when the Subject’s name is encompassed by SCTs associated with these certificates.

 

I thought the WG agreed, long ago, to not mandate behavior for TLS clients with regard to the presence or absence of SCTs. Yet this section says

   “TLS clients can thus require that all certificates they accept as valid are accompanied by signed timestamps.”

 

which seems to be pretty close to that.

 

 

Section 3

 

The term “preannounce” seems odd. “Pre-register” might make more sense, given that the action of submission to a log is a form of registration. Online dictionaries that I queried gave definitions for preannounce that didn’t seem to be a great match to this activity.

 

Saying that the submission of a pre-certificate  signifies a binding intent to issue the certificate is slightly misleading. A CA might not wind up issuing the associated certificate, for a variety of reasons. I think it would be better to just drop the word “binding” here.

 

Section 4

 

Suggested re-wording:

 

We define a mechanism to allow these private labels to not appear in public logs, while still retaining the security benefits that accrue from using certificate transparency mechanisms.

 

In Section 4.1 wording is used to motivate the need for name-redacted pre-certificates. It does not say, explicitly, that wildcard certificates can be logged and used in the CT context. It also should note the possible problems they represent for Monitors.

 

Given the recent debate about name-redaction, I’m not convinced that the description in 4.2.2 provides sufficient detail for Monitors and TLS clients to know precisely how to compare an SCT for a name-redacted pre-certificate to a certificate.

 

RFC 5280 states that name constraints is a critical extension, so the text in 4.3 conflicts with that RFC.

 

Section 5

 

The text still says

 

Log operators MUST NOT impose any conditions on retrieving or sharing data from the log.

 

I asked if Rich’s on-list statement about how Akamai planned to operate a log was consistent with this mandate, but never received a response.

 

Section 5.1 should include a statement that the list of trust anchors accepted by a log is part of the log’s metadata.

 

Section 5.3 allows a log to create it’s own OID, instead of using one of the log ID registries. This seems to allow for collisions, and is not consistent with the general IETF rationale for creating registries.

 

The description for log shutdown is much improved from prior version that I read. However, there are a couple of requirements here that don’t have an associated explanation of how they can be achieved.

 

Make it known to clients and monitors that the log will be frozen

 

Keep the log running until the certificates in all of its entries have expired or exist in other logs (this can be determined by scanning other logs or connecting to domains mentioned in the certificates and inspecting the SCTs served).

 

 

Section 8

 

The opening sentence is 5 lines long, which makes it a bit hard to read. But, overall, this section is much improved over previous versions.

 

The description the benefits and disadvantages of the certificate extension  to carry an SCT mentions inclusion proofs. This may be confusing to readers, since the extension does not contain an inclusion  proof. It would be better to say that use of this method to deliver an SCT requires that a TLS client use a different mechanism to acquire an inclusion proof (and STH).

 

In Section 8.1 the discussion of collusion between a CA and a log ought to cite the relevant section(s) of the threat analysis.

 

 

Section 9

 

The transparency information extension MUST be non-critical, for backward compatibility with TLS clients that are nopt CT-aware.

 

Note that an OCSP responder may be separate from a CA; the wording in 9.1.1 needs to be revised to reflect that.

 

What does 9.2 means when it says

 

When a certificate chain includes such a certificate, this indicates that CT compliance is required.

 

Required by what?

 

 

Section 10

 

The opening sentence is not very useful for a standards track document. It suggests CT lacks a well-defined architecture.

 

The metadata list in 10.1 seems to omit the set of trust anchors accepted by the log.

 

In 10.2.4 the text says “…The client then has to verify …” Did you mean to say “MUST” here?

 

The language in 10.2.5 about compliance isn’t very useful, when separated from the text in 10.2.7. Why have these as two separate subsections?

 

The wording in 10.2.7 seems intended to skirt the prior agreement to not mandate client behavior in the event of a  missing SCT. Also, the wording is sloppy. For example, the text says

 

In the case that use of TLS with a valid certificate is mandated ...

 

Certificate validity is defined by 5280 and profiles thereof. Do you mean to say a CT-compliant certificate here? The same comment applies to the next bullet which describes what to do if use of a “valid certificate” is optional. Also, what does it mean for a TLS client to “not treat the certificate as valid?”

 

The definition of a Monitor still seems to be wrong, and the recent debate about name-redacted certificates gives further evidence of that. I think most folks believe the primary function of a Monitor is to observe logs to detect when a certificate is logged that is not consistent with the Monitor’s information about the Subject of the logged certificate. The definition  of a Monitor provided here makes this function optional. It attributes to a Monitor a function that is, I believe, a function of Auditing.

 

The text here is not very precise in describing Monitor behavior re looking for log entries that conflict with certificates the Monitor is trying to protect. I suggest using text from draft-kent-trans-monitor-auditor-01.txt. For example:

 

A Monitor observes a set of logs to detect certificate mis-issuance. A Monitor notifies a Subject [CA-Subject] when a bogus (or  erroneous) certificate [draft-ietf-trans-threat-analysis] has been issued on behalf of that Subject. Every CT-aware Subject is expected to either perform self-Monitoring or to arrange with a third-party Monitor to detect mis-issued certificates on behalf of the Subject.

 

Similarly, the description of how a Monitor does its job seems to omit what I believe is its critical function. Again, the cited I-D above provide a concise description in its introduction:

 

A Monitor performs its function by examining all entries from a set of logs and comparing these entries to reference data for a set of one or more Subjects. The reference data consists, at a minimum, of a list of Subject and Subject Alternative Names and the pubic key information associated with each, supplied by the Subject. If a Monitor detects a log entry for a certificate that is inconsistent with the reference data for a Subject, the Monitor notifies the Subject. A Subject may perform self-monitoring.

 

Overall, this section seems inadequate as a description of Monitor functionality.

 

Section 10.4 describes audit functions reasonably well, but presents a view that there is no separate Auditor function in CT. That conflicts with the design in draft-ietf-trans-gossip-02, and with draft-kent-trans-monitor-auditor-01. I suggest that the first paragraph of this subsection be reworded to characterize the Audit function as one that may be performed by a client, Monitor, or by a separate entity. This subsection also ends with a statement not appropriate for a standard track document, as I have noted before:

 

The following algorithm outlines may be useful for clients that wish to perform various audit operations.

 

The statement above should be revised to require that an element performing the Audit function MUST perform all of these checks in a fashion that produces results identical to those that the algorithms would yield. If the document doesn’t establish these algorithms as authoritative it is not defining what the Audit function is, and the text is not a very useful part of a standards track document.

 

Section 11

 

The last sentence here probably ought to be:

 

Certificates in the frozen log that have not yet expired and require new SCTs SHOULD be submitted to the new log and the SCTs from that log used instead.

 

 

Section 13

 

The introduction text here is good, but it should be augmented with a discussion of the problems for Monitors posed by wildcard and name-redacted certificates (if the latter feature is retained). A reference to the threat document also would be appropriate here, rather than as a separate, trivial subsection (13.7). I suggest deleting that subsection.

 

13.1 says that a TLS client may (lowercase) decide to reject a certificate w/o an SCT. This language is rather squishy compared to the strict language in 9.2.

 

13.2 should refer to Monitors (10.3) as the entities that detect mis-issuance. Monitors might be domain owners, as suggested, or CAs, or third parties, but the text here mentions only the 1st example.

 

13.3 notes an important consideration, and its advice to CAs is good. Saying that clients may make a decision to reject such certificates underlines the potential for interoperability problems. I guess that’s OK for a statement in an SC section, but it seems a bit vague.

 

I note that 13.4 refers to a trusted Auditor, which conflicts with the characterization of Auditing in Section 10. Making the chnges I suggest to section would address this issue.

 

 

--------------C9162173A58AB81B33F7DE67-- From nobody Thu Jun 16 11:21:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A868D12DA87 for ; Thu, 16 Jun 2016 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbYdMl16nkPB for ; Thu, 16 Jun 2016 11:21:41 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A9C12B043 for ; Thu, 16 Jun 2016 11:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=0995IsHeiykE7B7vkU5NlUT5Gb/n8WOR1HPAGso0JKc=; b=CqYHfbVAJRGa0+oQyir4TuAUNQyLTqH8CsB/FLpBTIpx5PjqofXwjBK0PA75YUimMkdL2jDo7MoIjHnXAu81IAzVd6hAADaAlAANg6s4Pv3fvX+uY72KZ/I20Mz9ZP8ubkmxORIj6Wj5DChI9gMKugUjTdLKPIWDFCLnDZPi+m4=; Received: ; Thu, 16 Jun 2016 11:21:40 -0700 To: Melinda Shore , "trans@ietf.org" References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> From: Jacob Hoffman-Andrews Message-ID: <5762EE34.7020906@eff.org> Date: Thu, 16 Jun 2016 11:21:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Received-SPF: skipped for local relay Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:21:44 -0000 To echo what others have already said: redaction should go, for now. One of my main objections to redaction, voiced on the ct-policy list, is the complexity it introduces into the ecosystem. Removing redaction from 6962-bis means that clients don't have to take that complexity hit.' A very good principle here is: "No" is temporary; "Yes" is forever. If you're not sure about a new feature, say no. You can change your mind later. (https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libcont= ainer-principles) From nobody Thu Jun 16 11:24:38 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17D12DA8A for ; Thu, 16 Jun 2016 11:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJOa0W2DoYKj for ; Thu, 16 Jun 2016 11:24:35 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81B12D8B8 for ; Thu, 16 Jun 2016 11:24:35 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 045A2423702; Thu, 16 Jun 2016 18:24:34 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C323A4F0F6; Thu, 16 Jun 2016 18:24:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466101473; bh=1cgtuxxRUDSgOGhKRgheyQW1JlxwTgjrpTCER1BG5Yg=; l=351; h=From:To:Date:References:In-Reply-To:From; b=Q9/4Umab3FL0hpQ83KKpjyDFfuXT0HTTKE6NZicR5n96KNvcHN/szX1YowES1JK7i SoZNtB3Loa/lqifOfmizH8zvsQYJnlNg6jZAOy+AYzmrEQOY7PiVqXvFNgbq6aspHh Z2pYqc9CFfv0BAibGgv5zI96UG5I42/8rniADMKo= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BF0F81FC8C; Thu, 16 Jun 2016 18:24:33 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 16 Jun 2016 14:24:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 16 Jun 2016 14:24:33 -0400 From: "Salz, Rich" To: Jacob Hoffman-Andrews , Melinda Shore , "trans@ietf.org" Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/srXIA//+9mhA= Date: Thu, 16 Jun 2016 18:24:32 +0000 Message-ID: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> In-Reply-To: <5762EE34.7020906@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.240] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:24:37 -0000 > A very good principle here is: >=20 > "No" is temporary; "Yes" is forever. If you're not sure about a new featu= re, > say no. You can change your mind later. > (https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libco > ntainer-principles) That's a nice principle, but doesn't seem to hold in the IETF scale of thin= gs. From nobody Thu Jun 16 11:36:48 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE312DAB5 for ; Thu, 16 Jun 2016 11:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx5yuYjBejbv for ; Thu, 16 Jun 2016 11:36:41 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9166812D63A for ; Thu, 16 Jun 2016 11:36:41 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id hl6so20416673pac.2 for ; Thu, 16 Jun 2016 11:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=jLFgpttMRSYMInYP7H03H2C60L1Vb4hDgLGVV1Hk/l4=; b=vHhCkD64QougC99/i7ZmSFNKnt4J/Nwr4VpIVGI1douqd+vTjX/ZEfEEqFkawdjUwP 3pY6cM/69rhLztvcEoa9J5rYoUm/05eCXtqmmygJfhoCfE2OuZDJcNjH7FjVUAqY5+EU y9MK0gtSgd++VIOn0QmMgNuVIFyuFHn63/Ra6m3xlsA3LryTFW8LVbM4XkvE+D4oRvw3 WrFNLMHHEk9ny/iMfyhgA54KdUwb3D9oJ5mTyqw6I5T10c2NQYUUmDqBz4WFMtExydB6 wpaSkVFkmaMz6XNhLb7vqqVKWwKrCkt+JgedvKGCH+HVpziRhJ6UWL0hbB5BCQ0ZSoQm fRDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jLFgpttMRSYMInYP7H03H2C60L1Vb4hDgLGVV1Hk/l4=; b=R/rzd4wCb5Y0901CK1GIRtDnoD9pe1Gx/NlJFdHF8maQVGqdWHKx0Z7Q0UmqWHqfdX 5mAMS15R/+57ViW2gmswKunENJzB0AhRD9aCUKC34bhqFFvvsym6nQo1fBfVWhtRcLh7 PLZndU8UUoumE++vH7/DnJUqKmYt11e3nEx8Mo1H6kq//LVVKiuA/pdvKQ/ECyYjnuBF z/McOVZWd/aIEGGlLBhts1AiE26qM4cjS67uLgrrKDMROPzFl6whGPQhYH1RqiIitK0j dGCu3MIdUucZhZkTymr2nrhmqXrEORJOnbR1tEAJLrWPagQfbUDNVlaHomDRqQDDuywY RiYQ== X-Gm-Message-State: ALyK8tJ2ulYv0fWxGn2m74/G64qUvl1Gcbo6JW+9Zd15JD+pzt5DV9dYXxVnWGGawgfXtQ== X-Received: by 10.66.89.66 with SMTP id bm2mr6709091pab.154.1466102201121; Thu, 16 Jun 2016 11:36:41 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-71-241-radius.dynamic.acsalaska.net. [216.67.71.241]) by smtp.googlemail.com with ESMTPSA id x187sm62320464pfx.87.2016.06.16.11.36.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 11:36:40 -0700 (PDT) To: "Salz, Rich" , Jacob Hoffman-Andrews , "trans@ietf.org" References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> From: Melinda Shore Message-ID: <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> Date: Thu, 16 Jun 2016 10:36:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:36:43 -0000 On 6/16/16 10:24 AM, Salz, Rich wrote: >> A very good principle here is: >> "No" is temporary; "Yes" is forever. If you're not sure about a new feature, >> say no. You can change your mind later. >> (https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libco >> ntainer-principles) > That's a nice principle, but doesn't seem to hold in the IETF scale of things. If you're talking about overall process I don't think that's true. If you're talking about the time and effort it takes to standardize something, alas, yes, and it seems likely to me that any name redaction work in the future is likely to be as heavily contested as it is now. That does not mean, however, that it's not appropriate to defer a name redaction specification into another, later document for any number of reasons (including trying to get 6962-bis out sooner rather than later and trying to avoid being an example of process sludge). I think the core question here is whether publishing 6962-bis without it will make it difficult to specify name redaction in the future. Melinda From nobody Thu Jun 16 11:38:11 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B512DAB1 for ; Thu, 16 Jun 2016 11:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9TjbkNAD_HI for ; Thu, 16 Jun 2016 11:38:08 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5811612D63A for ; Thu, 16 Jun 2016 11:38:08 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A9C4142371C; Thu, 16 Jun 2016 18:38:07 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8EBDA423710; Thu, 16 Jun 2016 18:38:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466102287; bh=bXRRcL3A+fmdtz5q34aS5SHDksojejx6Q2rv4H7Iphs=; l=247; h=From:To:Date:References:In-Reply-To:From; b=waThWFzJBjDmrKqdSse8CggsDVHaZ5kiaAy/MX8llKPAn1v8vtFJLxQyaaTq2J3KD na9nnuIMX9OyM1suHSUe/pWJRr8xgxgEgFuqFpGyTpfrUav2iRms56/w7YIt6Aw0LB TL9/Zv+IAOreR6mEYOxz5cwbpgJWcxF0FKOtTpFo= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 85AE01FC8E; Thu, 16 Jun 2016 18:38:07 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 16 Jun 2016 14:38:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 16 Jun 2016 14:38:07 -0400 From: "Salz, Rich" To: Melinda Shore , Jacob Hoffman-Andrews , "trans@ietf.org" Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/srXIA//+9mhCAAEaTgP//vSOA Date: Thu, 16 Jun 2016 18:38:06 +0000 Message-ID: <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> In-Reply-To: <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.240] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:38:10 -0000 > I think the core question here is whether > publishing 6962-bis without it will make it difficult to specify name red= action > in the future. If it's not in the initial core spec, it will not get picked up later by br= owsers. My view. From nobody Thu Jun 16 11:38:40 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A65912D63A for ; Thu, 16 Jun 2016 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WdEEw_N8Xkb for ; Thu, 16 Jun 2016 11:38:36 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FDD12DAC5 for ; Thu, 16 Jun 2016 11:38:34 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id z186so51152750ywd.2 for ; Thu, 16 Jun 2016 11:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nYx9YJj6/ErPy8XI1ENqmVBuctoriPX5c64GovuOZHw=; b=VtsVUwFGVQ5+7g1uoEHXmejN6I0fDIeCm/JNELBVxAVQ9HepoG4EEXNWsaz9fJi2vC EYQLK15LKefekyWH/x2tj7Y1YvRhM/4ukNpF/E+qbARIoyjy1cnxDFVfGpKF9E4oewVD 92AxdXZDQ/OjzwYgssC4iCa+V5SirNJrANkGaDMEKl/ogBiCoUaQ6slqTed7/eeTPy6w LYQr5fRNCAKbhCB9AnvV3azZPb52+lb+2M2y1B2CsI/VaHShEm78vY4AoyfEy6kKeFIL es61IHQVYFnuF4UhEMmmSoza5wtIjVxrZcOWsVyoTiwUtWvcGLaStJC/W3YzmQqk9IlL rkVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nYx9YJj6/ErPy8XI1ENqmVBuctoriPX5c64GovuOZHw=; b=bcodtrha3a1srE9vA/xCNBLPxZlQjrxWcdXtf7ZI5djG3yeuAzKUPwH2MflV4GAoqH PG9LUHKKf/BMszCmwAHV2KHXlaVnAKO2hx2cV1okOEXavEYvz00UF8xuCIMJRT37tU49 glfDVD5NTpjPV6dIDYnrMhBzfM5dLPXT/8/3OHpsgp4GK/cOiNH6r6A1d8ZoPSzz/oZd VIqBQxXp2KYydyMfeK5xZ9YILW4UFWtGmC8ceDy+oKtT3huHHxO3YSbhDkmcNiHRBUVc 9PNKqryenVwMiL0nxrcrUiQ4o3LKuRZFjAIPTjWMhwZqXHNaXYUl03YNiDH6RGRJs0vO SLkA== X-Gm-Message-State: ALyK8tKvZRHko2lsU4zEbFj1rRGaFPwLWwuZ/M64fGSasQG5Gs810GpvwhMxpM+BJPUO/Lykj7kF1Hrtba9IBlZm X-Received: by 10.13.247.193 with SMTP id h184mr3450160ywf.225.1466102313748; Thu, 16 Jun 2016 11:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.19 with HTTP; Thu, 16 Jun 2016 11:38:32 -0700 (PDT) In-Reply-To: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> From: Eran Messeri Date: Thu, 16 Jun 2016 19:38:32 +0100 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c05435c9dcb3d0535698b6c Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Jacob Hoffman-Andrews Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:38:38 -0000 --94eb2c05435c9dcb3d0535698b6c Content-Type: text/plain; charset=UTF-8 Would it alleviate concerns if we commit to making an experimental RFC describing redaction separately of 6962-bis available relatively at the same time as 6962-bis? I think Rob's proposal of separating it to a different document (and taking it out of the core 6962-bis specification) is the most sensible: - The redaction mechanism is pretty much independent from the operation of precertificates. - (AFAICT) the discomfort with the redaction is its experimental / unknown nature, so it seems fitting to have it as an experimental RFC. Given the text is already written, it should be straightforward to separate it out. Eran On Thu, Jun 16, 2016 at 7:24 PM, Salz, Rich wrote: > > > A very good principle here is: > > > > "No" is temporary; "Yes" is forever. If you're not sure about a new > feature, > > say no. You can change your mind later. > > (https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libco > > ntainer-principles) > > That's a nice principle, but doesn't seem to hold in the IETF scale of > things. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c05435c9dcb3d0535698b6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it alleviate concerns if we commit to making an expe= rimental RFC describing redaction separately of 6962-bis available relative= ly at the same time as 6962-bis?

I think Rob's propo= sal of separating it to a different document (and taking it out of the core= 6962-bis specification) is the most sensible:
- The redaction me= chanism is pretty much independent from the operation of precertificates.
- (AFAICT) the discomfort with the redaction is its experimental /= unknown nature, so it seems fitting to have it as an experimental RFC.

Given the text is already written, it should be strai= ghtforward to separate it out.=C2=A0

Eran

On Thu, Jun 16, 2016 a= t 7:24 PM, Salz, Rich <rsalz@akamai.com> wrote:

> A very good principle here is:
>
> "No" is temporary; "Yes" is forever. If you're= not sure about a new feature,
> say no. You can change your mind later.
> (https://github.com/docke= r/libcontainer/blob/master/PRINCIPLES.md#libco
> ntainer-principles)

That's a nice principle, but doesn't seem to hold in the IETF scale= of things.

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

--94eb2c05435c9dcb3d0535698b6c-- From nobody Thu Jun 16 11:42:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8C12D862 for ; Thu, 16 Jun 2016 11:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkkKZth2ZCXX for ; Thu, 16 Jun 2016 11:42:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 054F212D12D for ; Thu, 16 Jun 2016 11:42:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 13B6F20008F; Thu, 16 Jun 2016 18:42:13 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id F192F20008D; Thu, 16 Jun 2016 18:42:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1466102532; bh=aGSiOqxLb9PnLT2xGVWegSAl09QpA96otnlrSZ8Uqy0=; l=350; h=From:To:CC:Date:References:In-Reply-To:From; b=e2KDkM76ZNut9UjKyhwkBRhlcp84ioafYV4KQoLTqBmi3pdC0cHfSRP+SPGo2+JUh HSJLg0VZDRev/dhKtLOZQhvsly5zSwZK/BBY+BwbncNSjEwcXf4c+CjTAAUT95GakA j6L8mIaqSr2tpqwfeg6KlB3S69Hp5+UOuJVCLaok= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id D5CDC9808A; Thu, 16 Jun 2016 18:42:12 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 16 Jun 2016 14:42:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 16 Jun 2016 14:42:12 -0400 From: "Salz, Rich" To: Eran Messeri Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrscZIbHrjfZ3EWQuH23+09IT5/srXIA//+9mhCAAEccAP//vc6w Date: Thu, 16 Jun 2016 18:42:12 +0000 Message-ID: <87471790a80e429aa6f8dac9562e3f39@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.240] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , Jacob Hoffman-Andrews Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:42:15 -0000 PiBXb3VsZCBpdCBhbGxldmlhdGUgY29uY2VybnMgaWYgd2UgY29tbWl0IHRvIG1ha2luZyBhbiBl eHBlcmltZW50YWwgUkZDIGRlc2NyaWJpbmcgcmVkYWN0aW9uIHNlcGFyYXRlbHkgb2YgNjk2Mi1i aXMgYXZhaWxhYmxlIHJlbGF0aXZlbHkgYXQgdGhlIHNhbWUgdGltZSBhcyA2OTYyLWJpcz8NCg0K TXkgcmVwbHkgd291bGQgYmUgdGhlIGludmVyc2Ugb2YgeW91ciBhbnN3ZXIgdG8gdGhpcyBvbmU6 ICB3aWxsIENocm9tZSBkbyBpdD8NCg0KDQo= From nobody Thu Jun 16 12:14:58 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3CD12B055 for ; Thu, 16 Jun 2016 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXiT4fUqBZMj for ; Thu, 16 Jun 2016 12:14:55 -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 A535912B02D for ; Thu, 16 Jun 2016 12:14:55 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:58138 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bDckb-0005Xx-I0 for trans@ietf.org; Thu, 16 Jun 2016 15:14:49 -0400 To: trans@ietf.org References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> From: Stephen Kent Message-ID: Date: Thu, 16 Jun 2016 15:14:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 19:14:57 -0000 If we look at the mess that syntactically bad CA certs cause, it does suggest that Yes is forever ;-), and not just based on IETF standards. Steve >> A very good principle here is: >> >> "No" is temporary; "Yes" is forever. If you're not sure about a new feature, >> say no. You can change your mind later. >> (https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libco >> ntainer-principles) > That's a nice principle, but doesn't seem to hold in the IETF scale of things. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Thu Jun 16 17:51:29 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1512DE46 for ; Thu, 16 Jun 2016 17:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqTWwWEJNugh for ; Thu, 16 Jun 2016 17:51:26 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A38812DE4D for ; Thu, 16 Jun 2016 17:51:26 -0700 (PDT) From: Jeremy Rowley Authentication-Results: mail.digicert.com; dkim=permerror (bad message/signature format) To: "Salz, Rich" , Melinda Shore , Jacob Hoffman-Andrews , "trans@ietf.org" Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AQHRxrr2YTt+AcsrCkqePT2oUmh8X5/szvkAgAAAzQCAAANggIAAAGsAgAADm/A= Date: Fri, 17 Jun 2016 00:51:23 +0000 Message-ID: <781d333076ae472b8bf7ae0b2d15cc5a@EX1.corp.digicert.com> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [107.191.0.241] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_03AF_01D1C800.126CCB10" MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 00:51:27 -0000 ------=_NextPart_000_03AF_01D1C800.126CCB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My view as well. If it's not part of this bis, you're basically saying goodbye to name redaction -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Thursday, June 16, 2016 12:38 PM To: Melinda Shore ; Jacob Hoffman-Andrews ; trans@ietf.org Subject: Re: [Trans] Name redaction - stay or go? > I think the core question here is whether publishing 6962-bis without > it will make it difficult to specify name redaction in the future. If it's not in the initial core spec, it will not get picked up later by browsers. My view. _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ------=_NextPart_000_03AF_01D1C800.126CCB10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPdzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggVmMIIETqADAgECAhALgHcH Lzs1YGO/amtK2gTIMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNTEwMTMwMDAwMDBaFw0xOTAxMTAxMjAwMDBaMIGBMQswCQYD VQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNlcnQx FjAUBgNVBAMTDUplcmVteSBSb3dsZXkxKTAnBgkqhkiG9w0BCQEWGmplcmVteS5yb3dsZXlAZGln aWNlcnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8kPdqjF+ljW5h8W7mQpM jaGlZ9YDLYTtUzcQjl71vRI4M6WSiZiUfbueAgupsQnxvl8By0BdwVmXnOIAUvqpFqzZhNIc8DGH M+uvXgT4+aoQvn9qPlt04CN5hzE/GFVvqs3neWgGfkzp1Z5H6RiqNoTOzdDWyr09Q8Gzm1jW9lTq sX0cxqooYtk29ooq12BvbVz0Jjgtt4Erdp27bTth11CaulJUDRT39YLLAwiR0bw3eMu8DCyuXAwV D68Ux33UbgYU9uvyFxBhJ83ST+1aw0r4E6iYTlQnKtYjEoNwlifhkwm4xS+lQHuTirpJGRFV42hd l9AtWQKRGuCUBL5EdwIDAQABo4IB8zCCAe8wHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8 inkwHQYDVR0OBBYEFPEtLfkj2twAoaYEb8gixWV8QW8HMAwGA1UdEwEB/wQCMAAwJQYDVR0RBB4w HIEaamVyZW15LnJvd2xleUBkaWdpY2VydC5jb20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG/WwEAQIwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmwwPaA7oDmG N2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVkSURDQS1nMS5jcmww eQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYI KwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAKy4O+nfR40jBgIFlaomX723rsDsnP/MT7xA9waf /K/JSqkfi97389rH0IXxwcEG/ne664wDmq4tZ9EfFkT2cGv0+itbcCDETeeu9bqOj6/LbXiYj9EB zyRFTcZih4NBIVEpTEcEIZfFfNWn3yDocY6K9wZFaM4UKLAqsnN0xYEKCNkSFsWv1Ol/8J3p363A f+PrswxqzejMiYvsi0nFYPFUMby901Crme/n4xpIJ57mLWy28YshNFip8sIOmCdVJcJ9KU65YljF 5D0cWyFk4xslKhHz6x3LKwqQmpedxWG3zYJVcaqLuTyZSqaewzJ5q8qH+usnmkmb+tcF/SDFD7Aw ggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xMzExMDUxMjAwMDBaFw0yODEx MDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXvwCd5Gy0Fh6IQQzHfDtQVG093 pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6fsk1O1bxH3xCfiWwIxnGRTjX PUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF6PGJr83/Xv9Q8/AXEf+9xYn1 vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47GIa04PBPmHn9mnNVN2Uba9s9S p307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvzsnM8wbCSnhh9vat9xX0IoSzC n3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMIGBBgNVHR8E ejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCCAbMGA1UdIASCAaowggGm MIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv bS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBz ACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMA ZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQ AFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABh AG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIA eQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AAT9jXvJQL2T90OUkyPIp5MB8G A1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBCwUAA4IBAQBO1Iknuf0d h3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZmaYHmnwTJ9vlAqKEEtkV9gpE V8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYMSBDOM2h7zZOr8GrLT1gPuXtd GwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaWgVVAjmbtgti7KF/tTGHtBlgo GVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7xkLb7L6rm2FMBpLjjt8hKlBX BMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDrzCCA6sCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UE ChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdp Q2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwCQYFKw4DAhoFAKCCAgsw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjE3MDA1MTIwWjAj BgkqhkiG9w0BCQQxFgQUhQq0ciK/jnqjwU0+wwqgb2ioySQwgYgGCSsGAQQBgjcQBDF7MHkwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0 LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK 2gTIMIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0 IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJ YIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGt9nRNaF+igWPcvNRN8xrWmNiUKAsXyZvU5s119 vJ22SPtUpj8Rkjmr1V8U9MeU0AUw1NcNlni7Mo8+CIbvR1YO42SBmSWZBmYzj3XybS9zSR2nwVoM KEtsdV7TtuC15nojwh+Bn4ueys0h2ujZB96X7LsYFkILoSalPpB1jfaNNfI+N8ogbwzph21fHToC qOxH+KHhwLdipNdN3ZvJ3RYijiKf1dqBJLOmWzZBuDS3PdZellos90tSO1dACtdjRSENTBM+mPUp mXCnACOJ4yARZfpNP+cmdnx7mIryd48c2QACjF/A2KzfAyHzwZWBnnIm+wQU/jmsquuGZdiBgGIA AAAAAAA= ------=_NextPart_000_03AF_01D1C800.126CCB10-- From nobody Thu Jun 16 17:54:49 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8982912D914 for ; Thu, 16 Jun 2016 17:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oac9ZXyErqnu for ; Thu, 16 Jun 2016 17:54:46 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 1105F12D7D8 for ; Thu, 16 Jun 2016 17:54:46 -0700 (PDT) Received: from mistress.home.hezmatt.org (pa49-181-145-145.pa.nsw.optusnet.com.au [49.181.145.145]) by mail.hezmatt.org (Postfix) with ESMTPSA id 55D049471F for ; Fri, 17 Jun 2016 00:54:44 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id BBE5CA0152; Fri, 17 Jun 2016 10:54:40 +1000 (AEST) Date: Fri, 17 Jun 2016 10:54:40 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20160617005440.GA7752@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 00:54:47 -0000 On Thu, Jun 16, 2016 at 06:38:06PM +0000, Salz, Rich wrote: > > I think the core question here is whether > > publishing 6962-bis without it will make it difficult to specify name redaction > > in the future. > > If it's not in the initial core spec, it will not get picked up later by browsers. My view. Even if it's in the initial core spec, browsers still won't necessarily pick it up. Especially if it's a scheme that's got some pretty serious concerns against it. Instead, if it gets split out into a separate spec, the current 6962-bis (sans redaction) can go forward, and the additional time needed to get a broadly workable redaction mechanism standardised can be taken by those who wish redaction to be existent. - Matt -- Yes, Java is so bulletproofed that to a C programmer it feels like being in a straightjacket, but it's a really comfy and warm straightjacket, and the world would be a safer place if everyone was straightjacketed most of the time. -- Mark 'Kamikaze' Hughes From nobody Thu Jun 16 18:48:45 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38012DE72 for ; Thu, 16 Jun 2016 18:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwon1AaVOJJ4 for ; Thu, 16 Jun 2016 18:48:42 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id B272112DE6E for ; Thu, 16 Jun 2016 18:48:42 -0700 (PDT) Received: from mistress.home.hezmatt.org (cl-134.syd-01.au.sixxs.net [IPv6:2001:4830:1200:85::2]) by mail.hezmatt.org (Postfix) with ESMTPSA id 0DB759474F for ; Fri, 17 Jun 2016 01:48:41 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 001D7A0152; Fri, 17 Jun 2016 11:48:31 +1000 (AEST) Date: Fri, 17 Jun 2016 11:48:31 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20160617014831.GO7752@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <781d333076ae472b8bf7ae0b2d15cc5a@EX1.corp.digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <781d333076ae472b8bf7ae0b2d15cc5a@EX1.corp.digicert.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 01:48:44 -0000 On Fri, Jun 17, 2016 at 12:51:23AM +0000, Jeremy Rowley wrote: > My view as well. If it's not part of this bis, you're basically saying > goodbye to name redaction How so? Has the IETF said they won't accept any further RFC submissions on redaction (or CT in general) after the publishing of 6962-bis? - Matt From nobody Thu Jun 16 19:55:50 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B612B01A for ; Thu, 16 Jun 2016 19:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KZjj01_tKsV for ; Thu, 16 Jun 2016 19:55:48 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BF12DA17 for ; Thu, 16 Jun 2016 19:55:47 -0700 (PDT) Received: from fifthhorseman.net (unknown [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id DC3E1F997; Thu, 16 Jun 2016 22:55:43 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 510AB20056; Thu, 16 Jun 2016 22:55:43 -0400 (EDT) From: Daniel Kahn Gillmor To: Matt Palmer , trans@ietf.org In-Reply-To: <20160617014831.GO7752@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <781d333076ae472b8bf7ae0b2d15cc5a@EX1.corp.digicert.com> <20160617014831.GO7752@hezmatt.org> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 16 Jun 2016 22:55:39 -0400 Message-ID: <877fdov80k.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 02:55:49 -0000 --=-=-= Content-Type: text/plain On Thu 2016-06-16 21:48:31 -0400, Matt Palmer wrote: > On Fri, Jun 17, 2016 at 12:51:23AM +0000, Jeremy Rowley wrote: >> My view as well. If it's not part of this bis, you're basically saying >> goodbye to name redaction > > How so? Has the IETF said they won't accept any further RFC submissions on > redaction (or CT in general) after the publishing of 6962-bis? Specifying it is the easy part. Figuring out a deployment story would be the hard part, especially if there are browsers (or other CT clients) in the deployed base who don't know how to deal with it. * Deploying only a new, redacted SCT means that the deployed base will think that your cert has not been logged. * Deploying a redacted SCT side-by-side with a non-redacted SCT (for the older deployed base) gives you no privacy benefit, because the non-redacted SCT is still public. As a result, servers have no strong incentive to deploy redacted SCTs, so they probably won't deploy them. And because no servers deploy redacted SCTs, no clients will have an incentive to support them. :( --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXY2asXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKiG0QAKVzOs57awU+e8Q1BZLR4/US 5UQKxXToax809vMZsjFotBb2Po5ybDgTTrAU6VfWJC/pkqLwNZmKtnlt7iioXlfQ m7tLQ7Tdt3nX5R7laNcIl+bAMOCJL6YxxHUKWbuSUiR78W//tc8awtH+9SfS7WaL AhJmHh2YvFE70hxBT6yowPmO72nEEnJoE1GBwtuunFjMyBcrB9TF1eDNwjPiM5LN n2aS4ASe2IdKGVXt+oGPZpxRL/qF3ECGn/umOze1vIx5/L/TQlSfTVG6y1kCBFsW dLEi6xOgKIMraE6z5dEr6y1K6q4LWY2SkRXuFekmo1W2HipExjKafGWHIqgoaE4a MSZLcrVvVUSIQReqmavhIMHJsfVH4z3uy20UtO3aoo38vssA8H1yDDvpXhVg0UeE WQyn+fNB70dGGTHKa7Bre5p/BXe+GkO7AcC5YjWHoMPExqw4aH1gLzXkjiN0ncXK ydMdo8XPtW6Tj90JbChrd0UYyfUc3ENBEwhpnEYBtFMaMP62iBiz9cwr/9MM6tUf OJsUVj01N72TqBXhUwebqu1F6CNq1rJEAjwZl1JonfGTRdeqbO1tJnIZflyBogq+ okGx13oFiCGaCVxIJMhB6dPwwo4qcEpEv4ddS1uplia3u6ELN18z/FPqGUQ3XlYJ 4Vnoq9xxBTJAJko8utjw =ve5+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 16 20:19:13 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35112DA90 for ; Thu, 16 Jun 2016 20:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpq0gJf4kPN1 for ; Thu, 16 Jun 2016 20:19:11 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id 050AF12D8AB for ; Thu, 16 Jun 2016 20:19:11 -0700 (PDT) Received: from mistress.home.hezmatt.org (cl-134.syd-01.au.sixxs.net [IPv6:2001:4830:1200:85::2]) by mail.hezmatt.org (Postfix) with ESMTPSA id B8C9594777 for ; Fri, 17 Jun 2016 03:19:08 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 3C8C6A0152; Fri, 17 Jun 2016 13:19:05 +1000 (AEST) Date: Fri, 17 Jun 2016 13:19:05 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20160617031905.GS7752@hezmatt.org> References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <781d333076ae472b8bf7ae0b2d15cc5a@EX1.corp.digicert.com> <20160617014831.GO7752@hezmatt.org> <877fdov80k.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877fdov80k.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 03:19:12 -0000 On Thu, Jun 16, 2016 at 10:55:39PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 21:48:31 -0400, Matt Palmer wrote: > > On Fri, Jun 17, 2016 at 12:51:23AM +0000, Jeremy Rowley wrote: > >> My view as well. If it's not part of this bis, you're basically saying > >> goodbye to name redaction > > > > How so? Has the IETF said they won't accept any further RFC submissions on > > redaction (or CT in general) after the publishing of 6962-bis? > > Specifying it is the easy part. Figuring out a deployment story would > be the hard part, especially if there are browsers (or other CT clients) > in the deployed base who don't know how to deal with it. That's the position we're in today, though, with 6962 not supporting redaction, and the single widely-deployed CT client stating they won't be recognising 6962-redacted SCTs as valid. So, whether redaction is in 6962 or not, you're still going to have all the same deployment issues (which are hardly unique to redaction; IPv6 anyone?) when redaction's kinks are worked out. - Matt From nobody Thu Jun 16 22:29:42 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466012D177 for ; Thu, 16 Jun 2016 22:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sutqsGEZ2uR6 for ; Thu, 16 Jun 2016 22:29:38 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA1C12B00C for ; Thu, 16 Jun 2016 22:29:38 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id bz2so25078838pad.1 for ; Thu, 16 Jun 2016 22:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=3rZdx928FsiqOpPCJ06xadVoGadFskknTlKIs9NZ6vk=; b=hgzW7Rjj4v4iK8u594isKDovRcA4hhGgEYHP1H4CUKWzEzNGDQ5wIuRlzp+9VBzjMp vbHVuLYA+i59jVff7ifYRUAoJ075LSU2qGAg87eLdZO2+a0Fvrtwst+V8fTtUU6z3oPh TfTvXGrpJsbM9D1PU3txIuAD509E6C0WJeOsrhN6w6TrU6jNsd8K82VbZ5aYiDWzpDox AgdfUddEgpx0SEEqjWfJ3IwG+7rU559wapfBFqNTFy+e55sNedArfwucWRXhlysdURRb IH6Jixqzso7aq+ASoV3HruDB9x7O1x0WGOw9T0SaQgMjdcg3GTR/siwhKk9IA5+j2Xe0 NWhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3rZdx928FsiqOpPCJ06xadVoGadFskknTlKIs9NZ6vk=; b=EKjHi6iTcUwuKf45YYeaxdTqqEVkPKh3P3k5QluPTqgphuDcP5r4rZKd548xs0OcbW beMnRiA+h9AGxTBCHELG+kPVep65JUMujQjOcdgVbIQQNOKDR5RDXsoqoCSdQEiH6QPG nfJePoZ5ndH8WcMjFPUWnmSBWozJ63BRlSjQBjt+1JCiuXWTTr86t04ynAF6YzP+3GlC KYObJComwC8apwG4pqskO3dygY4bWQtlLnt/MOXG4P90gMV1lUAsry9Ke/HroAJ338/A b6l/hQ4KG39kPcC3RAfjP9+X2nqIJ9KXz5ykKuFUciPONhlYYCt/dC7tYYXoo+natk5S u5TA== X-Gm-Message-State: ALyK8tIhyeu4AqmOaVs++EJB0qSsJ6p9eX75cbnLEfkapszgLwkqvmQpCb4xZOUevqlh0A== X-Received: by 10.66.25.231 with SMTP id f7mr348099pag.65.1466141377664; Thu, 16 Jun 2016 22:29:37 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-71-241-radius.dynamic.acsalaska.net. [216.67.71.241]) by smtp.googlemail.com with ESMTPSA id u4sm44820825pfi.53.2016.06.16.22.29.36 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2016 22:29:36 -0700 (PDT) To: trans@ietf.org References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20160617005440.GA7752@hezmatt.org> From: Melinda Shore Message-ID: <7f217811-1188-aa98-bcef-9e42b40c1caf@gmail.com> Date: Thu, 16 Jun 2016 21:29:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160617005440.GA7752@hezmatt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 05:29:40 -0000 On 6/16/16 4:54 PM, Matt Palmer wrote: > Even if it's in the initial core spec, browsers still won't necessarily pick > it up. Especially if it's a scheme that's got some pretty serious concerns > against it. Instead, if it gets split out into a separate spec, the current > 6962-bis (sans redaction) can go forward, and the additional time needed to > get a broadly workable redaction mechanism standardised can be taken by > those who wish redaction to be existent. Well, that's the concern (one of them). Leaving aside, for the moment, the discussion of whether or not it's a good idea, is there anybody who can say with authority that this is a feature they want for their own implementation (either in a server or browser)? Thanks, Melinda From nobody Fri Jun 17 04:02:17 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8BC12D16C for ; Fri, 17 Jun 2016 04:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGeqY32OGkIW for ; Fri, 17 Jun 2016 04:02:14 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91BE12D10F for ; Fri, 17 Jun 2016 04:02:13 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id b75so9642566ywe.1 for ; Fri, 17 Jun 2016 04:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=OssTwsj1Nmc9ooV2YtUqdRo06EYdypUtvLTxDbDZ3CA=; b=BsslVzwS6iD1MDFFIwnXC/tefwZi77tsmPt266vUptG3AaTLr6ZS3yWKIaHclW/WkG tOH+CbDDHXA420vyExkk4x+2K7ofvVX/7DSIkfEB2WP33Vmw4dqbW1RVXhEyW6BLYWvk jtXypTtBTyzeywUiRCGz3vC6o0rRarLOWx80wRs+iOnoRib1WZuHaVZzD/KOUfBHKQMt tYTyLVKyXKr1GGbHep83PHcVzVlKreJCtMVNDdIBLNTJv7sz65UFdtaMvzL6ScvFOgZH mfyGyRr4Q0otgvwINKC56hAhrMHkUSmoydJKGFIQWpNnXc/fnea6RCgMZTCo9UOy8XW9 dITA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OssTwsj1Nmc9ooV2YtUqdRo06EYdypUtvLTxDbDZ3CA=; b=hjM8VMUJ/2TBn8BMZCnjFGgOFruxSKAlQo22S/Zpr/hE5Mmw1egcBqvRvuLLBHGY7t nmv7W8096/b8KmtJ8jd491fBOuXU3xQtDSJabbi2ZiNGgJmG1jCl7m5f2ldHL7M5SvIA lAxmVF/xZxn+GodmBbNcQSB1TZRdPQMh5mMHMqnD7W61CfKn/TwHEhslfdOWpe0LryAd 5ZfFa+r5neOLrrZvsiTa/deqbJ+Mq29CxuWNU2covDwx/2IUq8doN28Jrn16YpyFDaY7 /HzbxGHWePIU4s7QZhKawr9Tydxtj8gl7wUnHbQPxmwo6XctUB3eRJ/sRCyLV7ddaTC5 TvFA== X-Gm-Message-State: ALyK8tLiVQEWZ22AEHVeH2mY7ZksQrOfL/YuFj+ba/lMDM5rJEBoo3fdkxesW1ZxcJGuiiMiH5q+pSXAY+Oga6Xg X-Received: by 10.129.45.196 with SMTP id t187mr637086ywt.153.1466161332972; Fri, 17 Jun 2016 04:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.139 with HTTP; Fri, 17 Jun 2016 04:02:12 -0700 (PDT) From: Eran Messeri Date: Fri, 17 Jun 2016 12:02:12 +0100 Message-ID: To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a1141df546ffa61053577491a Archived-At: Cc: Rob Stradling Subject: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 11:02:15 -0000 --001a1141df546ffa61053577491a Content-Type: text/plain; charset=UTF-8 This is a proposal for an alternative mechanism to redact domain names such that would shift most of the implementation complexity from the client to the issuer, while being functionally equivalent to the redaction mechanism in the current draft. In short: Rather than describe how the client should modify the labels in SAN extension to get to the redacted form that was logged, the issuer will generate the redacted SAN extension and log it, as a part of the TBSCertificate submitted to the log. Details: - The issuer, when generating a TBSCertificate for submission to the log, will add a "redacted SAN" X.509v3 extension with what the current draft specifies should be in the SAN extension (i.e. dNSNames with redacted labels, ?.example.com). - The TBSCertificate to be submitted will *not* have a SAN extension (thanks Rob for this suggestion). - The log will issue an SCT that covers the submitted TBSCertificate (+ issuer key hash as currently described). - The issuer then can issue the unredacted certificate by adding a SAN extension with the unredacted names (and potentially embedding the obtained SCTs). - The client, when receiving the unredacted certificate, simply removes the SAN extension (and the embedded SCTs extension, if present), then validates the signature from the SCT over it. - Then client can then extract the redacted domain names from the "redacted SAN" extension, compare them to the unredacted domain names from the SAN extension and apply a policy to determine if the redaction was appropriate. Benefits: - The only manipulation clients have to do to validate an SCT is to remove another X.509 extension, which it already has to do for embedded SCTs (eliminating both the error-prone process of reconstructing the redacted labels and the need to re-assemble a TBSCertificate). - Clients have both the redacted and unredacted domain names and can still choose to apply any desired policy. Disadvantages: - The commonName in the subject field cannot be redacted this way. - monitors will have to go through another hoop to make sense of the logged entry (likely by assigning the value of the "redacted SAN" extension to the SAN extension before using a standard parser to parse the TBSCertificate). Assuming this mechanism is technically sound, I would not object to keeping redaction in 6962-bis if implemented this way. Eran --001a1141df546ffa61053577491a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a proposal for an alternative mechanism to redact = domain names such that would shift most of the implementation complexity fr= om the client to the issuer, while being functionally equivalent to the red= action mechanism in the current draft.

In short: Rather = than describe how the client should modify the labels in SAN extension to g= et to the redacted form that was logged, the issuer will generate the redac= ted SAN extension and log it, as a part of the TBSCertificate submitted to = the log.

Details:
- The issuer, when gen= erating a TBSCertificate for submission to the log, will add a "redact= ed SAN" X.509v3 extension with what the current draft specifies should= be in the SAN extension (i.e. dNSNames with redacted labels, ?.example.com).
- The TBSCertificate to be = submitted will *not* have a SAN extension (thanks Rob for this suggestion).=
- The log will issue an SCT that covers the submitted TBSCertifi= cate (+ issuer key hash as currently described).
- The issuer the= n can issue the unredacted certificate by adding a SAN extension with the u= nredacted names (and potentially embedding the obtained SCTs).
- = The client, when receiving the unredacted certificate, simply removes the S= AN extension (and the embedded SCTs extension, if present), then validates = the signature from the SCT over it.
- Then client can then extrac= t the redacted domain names from the "redacted SAN" extension, co= mpare them to the unredacted domain names from the SAN extension and apply = a policy to determine if the redaction was appropriate.=C2=A0

<= /div>
Benefits:
- The only manipulation clients have to do to= validate an SCT is to remove another X.509 extension, which it already has= to do for embedded SCTs (eliminating both the error-prone process of recon= structing the redacted labels and the need to re-assemble a TBSCertificate)= .
- Clients have both the redacted and unredacted domain names an= d can still choose to apply any desired policy.

Di= sadvantages:
- The commonName in the subject field cannot be reda= cted this way.
- monitors will have to go through another hoop to= make sense of the logged entry (likely by assigning the value of the "= ;redacted SAN" extension to the SAN extension before using a standard = parser to parse the TBSCertificate).

Assuming this= mechanism is technically sound, I would not object to keeping redaction in= 6962-bis if implemented this way.

Eran
--001a1141df546ffa61053577491a-- From nobody Fri Jun 17 11:02:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087F612D954 for ; Fri, 17 Jun 2016 11:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9ZQYcjUpSmg for ; Fri, 17 Jun 2016 11:02:29 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2876D12D946 for ; Fri, 17 Jun 2016 11:02:28 -0700 (PDT) X-AuditID: d80ac3f2-f797b6d0000045c9-45-57643b336518 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 97.3A.17865.33B34675; Fri, 17 Jun 2016 19:02:27 +0100 (BST) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1bDy5R-0000jD-PG; Fri, 17 Jun 2016 14:01:46 -0400 Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.73]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Fri, 17 Jun 2016 11:01:17 -0700 From: Sanjay Modi To: Melinda Shore , "trans@ietf.org" Date: Fri, 17 Jun 2016 11:01:15 -0700 Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AdHIwj24sUy2rX4USJOIjfb91Abt0A== Message-ID: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20160617005440.GA7752@hezmatt.org> <7f217811-1188-aa98-bcef-9e42b40c1caf@gmail.com> In-Reply-To: <7f217811-1188-aa98-bcef-9e42b40c1caf@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsXCZeB6StfYOiXcYPtSWYu2tlksFmsfX2Rx YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI6Og4zFqziqvg+ZydbA+Nmji5GTg4JAROJ Sa1fmSFsMYkL99azgdhCAu8YJbY+jOli5AKyXzJKTLlwlhnCWckoMedXJwtIFZuAjsSmSS8Z QWwRAT+J7suPgIo4OJiB4ou/qIOEWQRUJfYdPssEYgsLGEq0PGhjgyg3klj5dwJUq57En7ON YEfwCphKNHz5wAix6zuTxMoNE8GaOQVsJXa8fA9mMwJd+v3UGjCbWUBc4taT+UwQHwhILNlz HuobUYmXj/+xgtiiQAvuPZrLAtErKnGnfT0jRK+OxILdn9ggbG2JZQtfQx0hKHFy5hOWCYwS s5CsmIWkZRaSlllIWhYwsqxilCkpLTYszi3JLy0pSK0wMNIrrsxNBMZesl5yfu4mRmD83eA6 /GkH48y9jocYBTgYlXh47xinhAuxJpYBVR5ilOBgVhLhZTUHCvGmJFZWpRblxxeV5qQWH2KU 5mBREuc1OZ4ULiSQnliSmp2aWpBaBJNl4uCUamDsiQ4+L2lmKcf9444+X4CImcnjHcc2iete /RFtuEpALHGXy+cQjx/P23YvnDblXOzhqHlacVLyIua71v765cB/+EbGqi/aknd3zbfnm39F oeaK2l5HdYcHeQ5fGyUn1r6RZf45vS9+9ya/2vmpPwRWnmXhsc85tbJ34vV956SnWBxeX32i 4tY6JZbijERDLeai4kQAPtEVfbsCAAA= Archived-At: Cc: Rick Andrews Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:02:42 -0000 Melinda, We want to keep reaction feature. We have talked extensively with customers who have validated the requirement for privacy. Since we rolled out redaction support several days ago, we have already had hundreds of customers select this option for over 1500 certificates. Thanks, -Sanjay On 6/16/16, 10:29 PM, "Melinda Shore" wrote: >On 6/16/16 4:54 PM, Matt Palmer wrote: >> Even if it's in the initial core spec, browsers still won't necessarily >>pick >> it up. Especially if it's a scheme that's got some pretty serious >>concerns >> against it. Instead, if it gets split out into a separate spec, the >>current >> 6962-bis (sans redaction) can go forward, and the additional time >>needed to >> get a broadly workable redaction mechanism standardised can be taken by >> those who wish redaction to be existent. > >Well, that's the concern (one of them). Leaving aside, for the >moment, the discussion of whether or not it's a good idea, is >there anybody who can say with authority that this is a feature >they want for their own implementation (either in a server or >browser)? > >Thanks, > >Melinda > >_______________________________________________ >Trans mailing list >Trans@ietf.org >https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jun 17 12:41:20 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD212DA42 for ; Fri, 17 Jun 2016 12:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aII-SFuYs-42 for ; Fri, 17 Jun 2016 12:41:12 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83E012DA3E for ; Fri, 17 Jun 2016 12:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466192470; bh=s3IiSi1qI2RB5M+wmbH7a5WNM+lZA/juueWBmuAsias=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=owN84bSWixGM0ZhGc+1k/+U+M14LQA9rojLp2CfEXSLEu4BpCCMUsv0hvhTkiT7CG r7+hKEm9z5MCR4NhIhrpsBB69xlk1/POs5HJMQ9HO6zSViDITKk54wVVaLOcS1N8if Vrg1TAkRjvLYqaE8kwwaAVA7VxrIGDqPOt0PQpLK7z2VNigkrv4bFbKlDUjcbt282/ /iS6YYccqzY3cZdhwyHS2Off/RT56lJrdygqCpegubirHQX4z+j6HQEI9Q7Re0Pbxv ILsdrbSXwc5TeSZOHU6bJPJtbaVUPkJW8ABTgt7Sk/W5Q29yTjkqVgiiiYcO4ow7gN EeFTF59CCx+qQ== Date: Fri, 17 Jun 2016 12:41:10 -0700 From: Andrew Ayer To: Eran Messeri Message-Id: <20160617124110.1372ed3abf1b33a64b4dc117@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: Rob Stradling , "trans@ietf.org" Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:41:19 -0000 Hi Eran, I really like your proposal. I like it so much that I've implemented the client-side functionality to reconstruct the TBSCertificate and do basic policy checks on the redacted labels. It took me about 45 minutes and I found it very straightforward. (Note I didn't implement the over-redaction check, but this requires the same code no matter how redaction is defined.) I didn't get bogged down like I did with my other implementation. I think this is a huge win for reducing client-side complexity. I would still like to see the SCT reuse attack fixed. Fortunately, combined with your proposal I think the complexity of fixing the attack is manageable. Here's what I propose (I've implemented the client-side parts of this too): 1. When issuing a redacted certificate, the issuer generates a random 128-bit SALT. The issuer places this SALT in a "Redacted Labels Salt" X.509v3 extension in the unredacted certificate, but not in the logged TBSCertificate. 2. When redacting a LABEL in the "redacted SAN" extension, the issuer replaces LABEL with "?"||HEX(HASH(SALT||LABEL)) instead of just "?" (|| is string concatenation). 3. When reconstructing the TBSCertificate to verify the SCT, the client removes the "Redacted Labels Salt" extension, just as it currently removes the SAN extension and the Transparency Info extension. 4. If the client desires stronger SCT matching, it checks that each redacted label in the redacted SAN extension matches the corresponding label in the SAN extension, by computing HASH(SALT||LABEL), where SALT is taken from the "Redacted Labels Salt" extension. Complexity analysis: 1. There is additional complexity imposed on issuers, but only on issuers who choose to offer redacted certificates, so I believe this is justifiable. 2. Clients need to remove an additional extension when reconstructing the TBSCertificate, but this is trivial and they already have to remove two other extensions anyways. 3. Clients which desire stronger SCT matching have to examine the "Redacted Labels Salt" extension and compute some hashes, which adds modest complexity. However, if a client doesn't desire the stronger SCT matching or can't handle the added complexity for some reason, they can skip this step (they'd ignore everything after the ? in a redacted label) and have exactly the same complexity and security properties as without my proposal. If I'm not mistaken, your proposal plus my proposal address all the technical/implementation concerns that have been raised with redaction. There will still be policy concerns, such as whether redaction is even a good idea, but those can be fleshed out by clients. I think 6962-bis would be delivering a solid technical solution for redaction with these changes. Regards, Andrew P.S. My implementation is here: https://github.com/AGWA-labs/ctredactionexperiment The diff to implement Eran's proposal on top of the RFC6962-compliant code I already had: https://github.com/AGWA-labs/ctredactionexperiment/commit/fbeaa9f3d91ebfd1eb614a657009222b25f37724 The diff to implement my proposal for hash-based label redaction on top of Eran's proposal: https://github.com/AGWA-labs/ctredactionexperiment/commit/d46cfee8eb4374e87c601317f6faa98c4f2e189e From nobody Fri Jun 17 14:33:35 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5516412DBB8 for ; Fri, 17 Jun 2016 14:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87skWqniiZxA for ; Fri, 17 Jun 2016 14:33:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id E31D612DB39 for ; Fri, 17 Jun 2016 14:33:31 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CE0F3F98B; Fri, 17 Jun 2016 17:33:30 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 74CA52003C; Fri, 17 Jun 2016 17:33:30 -0400 (EDT) From: Daniel Kahn Gillmor To: Eran Messeri , "trans\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 17 Jun 2016 17:33:30 -0400 Message-ID: <87k2hnts9h.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Rob Stradling Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 21:33:33 -0000 On Fri 2016-06-17 07:02:12 -0400, Eran Messeri wrote: > In short: Rather than describe how the client should modify the labels in > SAN extension to get to the redacted form that was logged, the issuer will > generate the redacted SAN extension and log it, as a part of the > TBSCertificate submitted to the log. I like this proposal. A clarification: It took me a second to realize that the "redacted SAN extension" is *also* present in the issued certificate, alongside the normal SAN extension. the SCT is only over the TBSCertificate without the normal SAN extension. > Disadvantages: > - The commonName in the subject field cannot be redacted this way. This is not a problem. the CA/Browser Forum Baseline requirements say that the commonName in the Subject field is "Deprecated (Discouraged, but not prohibited)" A user who really cares about redaction can simply leave out the commonName in the Subject field. I also think Andrew Ayer's extension of this proposal (the "Redacted Labels Salt" extension) is an elegant fix to the remaining technical concern about redacted SCT abuse. I would support their inclusion in 6962-bis. --dkg From nobody Fri Jun 17 15:28:43 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9EE12DBF0 for ; Fri, 17 Jun 2016 15:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AOGDD8yrr6T for ; Fri, 17 Jun 2016 15:28:41 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA67012DBDC for ; Fri, 17 Jun 2016 15:28:40 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id b13so32158019pat.0 for ; Fri, 17 Jun 2016 15:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=of1OcxIfGglLPJMU2ieezLOUW1hbpMv/UkdhMyAIwkE=; b=CHWxJzz8WKovsOYI1WoKIIG+ZKmQRLiMfk92XZA2kYbZVVS+1U/0sptAu7Q4hAGUKJ Fj1CMMIKw6yxYZOuhiehs29Yev08L1+3kf7vdN7PJZylcXf/OrJdqDNf/P19RUjxMGPl gw7KRxQlXESkX14BONljmLOo07BdanODftWjEV33RKzwIsIpek/2VNRVH9d5w949iH+H O2MSUeOPIcr3ebE1TcYTgGaLR3GSJFmQPPng5QFoSX2/S69Y2z2zwuI/0MWb+qnY9G/M w2Jps2YTWIPh7xrNeFHufHTUw+3hQV/z7r4/yJeX9FD38aORkkcgY9nF8768NyIUO6rb mSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=of1OcxIfGglLPJMU2ieezLOUW1hbpMv/UkdhMyAIwkE=; b=T3S7YKYc3ad1lpchktUZl+9ujmrqNedMDqmpzMsVWcFFm0VcPosXEertPzGTmjWZHG sn1RuIh/i9R0nLy24xnWVF2CVXld4NjvmGqmWeU6SF9M2KlEAK0MRjvQRrHwun4U7f9v G7JjM8i0gV+axR0pL+6/DqlTKpFssQdfg49bFpn+pEh9qC0xhpFnb1cXAz3eUbR9prWK 7C+noDnoLe67+T0kmAlkLMzc8tHnP1f4TtCxUGAAL7gT2/O8bnUlK8Y0LDfCFsD1Z4gH Lj/wL+RDGK8LXcIrvXPBQaVaVDm7Go8Qx752UiHgtMHo+9GlYsTzcAotIS/nwv9bGVxp jiZg== X-Gm-Message-State: ALyK8tLC8VK/BA+NLm5rrXvwpOrmio/zRNcSLKyqWpDvXmX/TbNXRhOm9UJ0IJ3X52w+kQ== X-Received: by 10.66.139.133 with SMTP id qy5mr4935996pab.4.1466202520522; Fri, 17 Jun 2016 15:28:40 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (66-230-102-208-radius.dynamic.acsalaska.net. [66.230.102.208]) by smtp.googlemail.com with ESMTPSA id c189sm41143981pfg.19.2016.06.17.15.28.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2016 15:28:39 -0700 (PDT) To: Sanjay Modi , "trans@ietf.org" References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20160617005440.GA7752@hezmatt.org> <7f217811-1188-aa98-bcef-9e42b40c1caf@gmail.com> From: Melinda Shore Message-ID: Date: Fri, 17 Jun 2016 14:28:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Rick Andrews Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 22:28:42 -0000 On 6/17/16 10:01 AM, Sanjay Modi wrote: > Melinda, We want to keep reaction feature. We have talked extensively > with customers who have validated the requirement for privacy. Since > we rolled out redaction support several days ago, we have already had > hundreds of customers select this option for over 1500 certificates. Okay, that's really good information to have. By way of follow-up, have you read Eran's proposal for an alternative mechanism, and is that something that Symantec would be interested in (acknowledging that you would not be speaking for the entire company)? Melinda From nobody Mon Jun 20 06:39:08 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBFD12D0BF for ; Mon, 20 Jun 2016 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgzIAnbuH-zp for ; Mon, 20 Jun 2016 06:39:04 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2911B12D0F4 for ; Mon, 20 Jun 2016 06:39:04 -0700 (PDT) Received: (qmail 9525 invoked by uid 1004); 20 Jun 2016 13:39:01 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 20 Jun 2016 14:39:01 +0100 Received: (qmail 29827 invoked by uid 1000); 20 Jun 2016 13:39:00 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 20 Jun 2016 14:39:00 +0100 To: "trans@ietf.org" References: <87k2hnts9h.fsf@alice.fifthhorseman.net> From: Rob Stradling Message-ID: <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> Date: Mon, 20 Jun 2016 14:39:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <87k2hnts9h.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:39:07 -0000 I think Eran's proposal is a definite improvement (compared to the current 6962-bis redaction mechanism), because it makes client implementation simpler and more robust. I agree that Andrew's extension of Eran's proposal is an elegant fix to the SCT re-use attack. However, I'd like to propose an alternative... 1. When redacting a LABEL in the "redacted SAN" extension, the issuer replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of just "?". 2. If the client desires stronger SCT matching, it checks that each redacted label in the redacted SAN extension matches the corresponding label in the SAN extension, by computing HASH(SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of the certificate. Advantages: - Slightly simpler than Andrew's proposal. (i.e. no SALT needs to be generated, put into a certificate extension, then removed to reconstruct the TBSCertificate). - Provides a (partial) technical solution to 'un'redaction (which is something that needs to be addressed before Chrome will ever support redaction [1]): If a domain owner's certificate team observes an unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||LABEL) for all of the LABELs they manage. Disadvantages: - A dictionary attack might reveal the LABEL. It wouldn't be possible to compute a rainbow table to generalize this attack, because the SERIAL_NUMBER is different for each certificate. If there's an effective way to solve the 'un'redaction problem purely via policy, then I'd say Andrew's proposal is superior. However, if there isn't, then perhaps my proposal is a necessary compromise. [1] https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ On 17/06/16 22:33, Daniel Kahn Gillmor wrote: > On Fri 2016-06-17 07:02:12 -0400, Eran Messeri wrote: >> In short: Rather than describe how the client should modify the labels in >> SAN extension to get to the redacted form that was logged, the issuer will >> generate the redacted SAN extension and log it, as a part of the >> TBSCertificate submitted to the log. > > I like this proposal. > > A clarification: > > It took me a second to realize that the "redacted SAN extension" is > *also* present in the issued certificate, alongside the normal SAN > extension. the SCT is only over the TBSCertificate without the normal > SAN extension. > >> Disadvantages: >> - The commonName in the subject field cannot be redacted this way. > > This is not a problem. the CA/Browser Forum Baseline requirements say > that the commonName in the Subject field is "Deprecated (Discouraged, > but not prohibited)" > > A user who really cares about redaction can simply leave out the > commonName in the Subject field. > > I also think Andrew Ayer's extension of this proposal (the "Redacted > Labels Salt" extension) is an elegant fix to the remaining technical > concern about redacted SCT abuse. > > I would support their inclusion in 6962-bis. > > --dkg > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Mon Jun 20 17:08:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5F12D7C3 for ; Mon, 20 Jun 2016 17:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArOkrmB_qJTN for ; Mon, 20 Jun 2016 17:08:04 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3746212D772 for ; Mon, 20 Jun 2016 17:08:04 -0700 (PDT) X-AuditID: d80ac3f3-f79126d0000018fe-54-57688563cb9f Received: from tus1smtintpin01.ges.symantec.com (smtp.engba.symantec.com [192.168.215.101]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id E0.2B.06398.36588675; Tue, 21 Jun 2016 01:08:03 +0100 (BST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1bF9EZ-000FSD-Ce; Tue, 21 Jun 2016 00:08:03 +0000 Received: from TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM ([155.64.221.73]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 20 Jun 2016 17:08:03 -0700 From: Sanjay Modi To: Melinda Shore , "trans@ietf.org" Date: Mon, 20 Jun 2016 17:08:02 -0700 Thread-Topic: [Trans] Name redaction - stay or go? Thread-Index: AdHLUPoNgoXIO2vdQuSV6qnHIpga/A== Message-ID: References: <5acc5097-4d72-59f7-76d0-8291055b1f28@gmail.com> <5762EE34.7020906@eff.org> <4c0498b8-46ee-8d32-c10a-463f79be0df4@gmail.com> <81c255ba263e4f7f80315b8a6f92ef0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20160617005440.GA7752@hezmatt.org> <7f217811-1188-aa98-bcef-9e42b40c1caf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsVyYMX1VN3k1oxwg1tb5Sza2maxWKx9fJHF gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MqYsUu04DlbxfQt09gbGA+zdjFyckgImEjs WD6HBcIWk7hwbz1bFyMXh5DAC0aJxT/2QjkvGSV2HGtlB6kSEljJKLF3FhuIzSagI7Fp0ktG EFtEwE+i+/Ij5i5GDg5moPjiL+ogYRYBVYld524xg9jCAoYSLQ/a2CDKjSRW/p3ACFIuIqAn MX9pEEiYV8BU4tbsxawQa68xSzS8OAp2HKeArcTFKYfBVjECHfr91BomEJtZQFzi1pP5TBAP CEgs2XOeGcIWlXj5+B/Yk6JA8+89mssC0Ssqcad9PSNEr47Egt2f2CBsbYllC18zQxwhKHFy 5hOWCYwSs5CsmIWkZRaSlllIWhYwsqxilCkpLTYszi3JLy0pSK0wMNYrrsxNBMZdsl5yfu4m RmDs3eA6/HkH4+89jocYBTgYlXh4v+ZlhAuxJpYBVR5ilOBgVhLhbWkGCvGmJFZWpRblxxeV 5qQWH2KU5mBREufVPpEULiSQnliSmp2aWpBaBJNl4uCUamC8zGrzr7j5o/4U80nVl5psmNbd zHIW3/c/tPnXpdX6sbPsP30tjZASllQoSsucctX239RVeTcy16QaCEcuuHVw1oOC39M2LLk7 Y5L95+TdeleWBf16YVxZJ6DpvTNG+i5z6VHeUx/c01hqgw4sZs0WOGu/18eq5oqwUsmPzBu2 mpr7fAV/7i1SYinOSDTUYi4qTgQALvQDS7kCAAA= Archived-At: Cc: Rick Andrews Subject: Re: [Trans] Name redaction - stay or go? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 00:08:05 -0000 Melinda, We are reviewing Eran's proposal and and followup posts on that. We are also looking into how to address redacted CN. I will post follow up shortly. - Sanjay On 6/17/16, 3:28 PM, "Melinda Shore" wrote: >On 6/17/16 10:01 AM, Sanjay Modi wrote: >> Melinda, We want to keep reaction feature. We have talked extensively >> with customers who have validated the requirement for privacy. Since >> we rolled out redaction support several days ago, we have already had >> hundreds of customers select this option for over 1500 certificates. > >Okay, that's really good information to have. By way of >follow-up, have you read Eran's proposal for an alternative >mechanism, and is that something that Symantec would be >interested in (acknowledging that you would not be speaking >for the entire company)? > >Melinda From nobody Mon Jun 20 21:35:34 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EC512D931 for ; Mon, 20 Jun 2016 21:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r509708tWW4M for ; Mon, 20 Jun 2016 21:35:32 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB20D12D92D for ; Mon, 20 Jun 2016 21:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1466483731; bh=oN6pajpTz/qzNaSlvX0SEBOXRXjVm2b5sZvHxKGwTLI=; h=Date:From:To:Subject:In-Reply-To:References; b=nAQWdfNcGj33SzxoNZ2Yk2mLjVVqX9STkdyesO5FF8QmaoVvdIt5rJDx9XKHzibfO cw5IRh9XW9vOqczCu/8Ar77ZsXYyvKnbg4zZvOFrji80mBYf+C/we2RCFd5Ml49mn6 jERKpetLU7iGDvjxArjwZlxz84SYqHTGuGVEVfaUPitfuwWheyGjzl03JGIuACSQoV 2RjvURAivL8eZ3K8zQ04dEY1FBAiIl+Wr7MxnGrDHVxT+w/RuGPpOM1KGllYk+BD9z mTyMiEQbBi6fzg9kK25vIACEjy9gRACN8jh2xZgpQkDDq7v4iT+skrup/tl22I5Hgj 8/VMvR78CqVAw== Date: Mon, 20 Jun 2016 21:35:31 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> In-Reply-To: <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> References: <87k2hnts9h.fsf@alice.fifthhorseman.net> <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 04:35:34 -0000 Hi Rob, On Mon, 20 Jun 2016 14:39:00 +0100 Rob Stradling wrote: > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of > just "?". > > 2. If the client desires stronger SCT matching, it checks that each > redacted label in the redacted SAN extension matches the > corresponding label in the SAN extension, by computing HASH > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > the certificate. I'm a little uneasy about using the serial number, because of the ways that serial numbers can be, and are, incorrectly encoded (e.g. not minimally encoded, or a "positive" integer with the MSB set). I think it's simpler and more robust for the client to take the salt out of an extension, so it can be treated as an opaque blob and therefore be unaffected by the vagaries of parsers. > - Provides a (partial) technical solution to 'un'redaction (which is > something that needs to be addressed before Chrome will ever support > redaction [1]): If a domain owner's certificate team observes an > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| > LABEL) for all of the LABELs they manage. Another way to support "un-redaction" is to just leave the salt extension in the pre-certificate instead of removing it. I'd prefer that approach if this style of un-redaction is desired. Regards, Andrew From nobody Tue Jun 21 02:51:26 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98D312B04F for ; Tue, 21 Jun 2016 02:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJdzOj64ygAU for ; Tue, 21 Jun 2016 02:51:21 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F6E1200A0 for ; Tue, 21 Jun 2016 02:51:21 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id b72so9026742ywa.3 for ; Tue, 21 Jun 2016 02:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Bt0sfm/5QDoywzeWrQXskKFjxiKVn+3d7O+C4qI3sc=; b=RSZEkRq83hslLyl4ofvfqvHt+MhVwagZxU470Reu0zVAEgD40eLNUahAmIF9kFsRvS lBf06U6w0U4Sj1s9+pefl1wV7M+Usvmt8XCZXhP7MR/tTlFbI21EpB1VN/xxF3NxFN5G 1UuICI64NQ+UTRAPKzBVwtYLF22ortfCoywO26/KlDauRgtpZaZiVT5QjSvaUheszID4 eMHPBvf9MEj0YbzkiQb/oE71qf5oAlHCUoecqXb8khp/qu7Y6PmTRsW6zHdghj27vkqA YGTUgghKA1vpHUtI9DuFy572VHjgypc/JB1Xz5jYTlrCcd/YzMe/ItR6ozRcpuDfaifj KS8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7Bt0sfm/5QDoywzeWrQXskKFjxiKVn+3d7O+C4qI3sc=; b=Fkcm71iJZnU61GOEZ+MgJK/orETGk/Uxd4vUfl0+FqrtaVJb2T8DC0bPpZUwg6Z86h 2xfx/acb6Fo7FVyi3ZnOQb7qM3jPpQXEfk5f0D0dgqt3vuKLRC+0b6quAzUcVlIGuWrE gMZs0YEC/bLYcIXov66CLCKf8ZKhj0U1qndAXqNkG9pWHaYcQtpSauZ/cWp1SJc/txJm tDXGSC3TdqSG10/+I2DDP6NJBJ1vPA6sW08E6Vs8frx4ZdaNgVh6Ar1x4TI7me3CC4mj sk2MRSBxfDMhu6tkDCUcV7ES2O/eS0i+RJl9D1qHZv6k4/jwnES+shaKjrGMJLeyE+G4 mskg== X-Gm-Message-State: ALyK8tKkvVNSkjuH077D9PyO2Gf8v8LuuawPoFPJhAEMZtSiwEgQox+TYvu49Ff/AZMV1oQSCfl++srmmVNNJlvO X-Received: by 10.13.223.133 with SMTP id i127mr8377555ywe.144.1466502680344; Tue, 21 Jun 2016 02:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.139 with HTTP; Tue, 21 Jun 2016 02:51:19 -0700 (PDT) In-Reply-To: <92dee26a-f6e2-e58b-db37-220f50f029cb@bbn.com> References: <92dee26a-f6e2-e58b-db37-220f50f029cb@bbn.com> From: Eran Messeri Date: Tue, 21 Jun 2016 10:51:19 +0100 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=001a114e4738538fef0535c6c398 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:51:25 -0000 --001a114e4738538fef0535c6c398 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Addressed some comments, I've left some un-addressed as I'd like to hear more feedback about them from the WG. The changes are here: https://github.com/google/certificate-transparency-rfcs/pull/174 On Thu, Jun 16, 2016 at 6:47 PM, Stephen Kent wrote: > Here are my comments on 6962-bis: > > Section 1. > > > > Still no definition of mis-issuance here. Why not use the text I supplied > months ago, and cite the threat analysis document? > > > > There ought to be a mention of the residual vulnerabilities that arise > when using name-redacted pre-certificates or wildcard certificates, in > light of the recent discussions. Specifically, the problems Monitors face > in trying to protect a Subject when the Subject=E2=80=99s name is encompa= ssed by > SCTs associated with these certificates. > > > > I thought the WG agreed, long ago, to not mandate behavior for TLS client= s > with regard to the presence or absence of SCTs. Yet this section says > > =E2=80=9CTLS clients can thus require that all certificates they accep= t as > valid are accompanied by signed timestamps.=E2=80=9D > > > > which seems to be pretty close to that. > > > > > > Section 3 > > > > The term =E2=80=9Cpreannounce=E2=80=9D seems odd. =E2=80=9CPre-register= =E2=80=9D might make more sense, > given that the action of submission to a log is a form of registration. > Online dictionaries that I queried gave definitions for preannounce that > didn=E2=80=99t seem to be a great match to this activity. > Changed. > > > Saying that the submission of a pre-certificate signifies a binding > intent to issue the certificate is slightly misleading. A CA might not wi= nd > up issuing the associated certificate, for a variety of reasons. I think = it > would be better to just drop the word =E2=80=9Cbinding=E2=80=9D here. > Would it help to say that for all intents and purposes an observer of a CT log can assume a CA has intended to issue a certificate denoted by a precertificate observed in the log? > > > Section 4 > > > > Suggested re-wording: > > > > We define a mechanism to allow these private labels to not appear in > public logs, *while still retaining the security benefits that accrue > from using certificate transparency mechanisms.* > > > > In Section 4.1 wording is used to motivate the need for name-redacted > pre-certificates. It does not say, explicitly, that wildcard certificates > can be logged and used in the CT context. It also should note the possibl= e > problems they represent for Monitors. > I believe the first sentence does. At least, I can't see any dis-ambiguity here. > > > Given the recent debate about name-redaction, I=E2=80=99m not convinced t= hat the > description in 4.2.2 provides sufficient detail for Monitors and TLS > clients to know precisely how to compare an SCT for a name-redacted > pre-certificate to a certificate. > That's likely to change with the simplified redaction suggestion. > > > RFC 5280 states that name constraints is a critical extension, so the tex= t > in 4.3 conflicts with that RFC. > Seeking feedback here - one possible option is to remove the 'critical or non-critical' part of the sentence. > > > Section 5 > > > > The text still says > > > > Log operators MUST NOT impose any conditions on retrieving or sharing dat= a > from the log. > > > > I asked if Rich=E2=80=99s on-list statement about how Akamai planned to o= perate a > log was consistent with this mandate, but never received a response. > IIRC the plan was to restrict submission, that text is about getting data from logs. > > > Section 5.1 should include a statement that the list of trust anchors > accepted by a log is part of the log=E2=80=99s metadata. > What is the goal behind such a statement? I'm failing to see what it would add to the reader (it's already mentioned that the list can be obtained by calling get-anchors). > > > Section 5.3 allows a log to create it=E2=80=99s own OID, instead of using= one of > the log ID registries. This seems to allow for collisions, and is not > consistent with the general IETF rationale for creating registries. > How about the following text as the first sentence: Each log is identified by an OID which MUST be unique. > > > The description for log shutdown is much improved from prior version that > I read. However, there are a couple of requirements here that don=E2=80= =99t have an > associated explanation of how they can be achieved. > > > > Make it known to clients and monitors that the log will be frozen > > > > Keep the log running until the certificates in all of its entries have > expired or exist in other logs (this can be determined by scanning other > logs or connecting to domains mentioned in the certificates and inspectin= g > the SCTs served). > You're right - they depend on the metadata dissemination mechanism, which isn't currently specified. > > > > > Section 8 > > > > The opening sentence is 5 lines long, which makes it a bit hard to read. > But, overall, this section is much improved over previous versions. > > > > The description the benefits and disadvantages of the certificate extensi= on > to carry an SCT mentions inclusion proofs. This may be confusing to > readers, since the extension does not contain an inclusion proof. > Inclusion proofs can be included in the extension since an inclusion proof is a particular type of TransItem and the extension carries a list of TransItems. It is not immediately obvious, though, so if you point to a particular area of the text where this can be clarified I'll try to add some text. > It would be better to say that use of this method to deliver an SCT > requires that a TLS client use a different mechanism to acquire an > inclusion proof (and STH). > > > > In Section 8.1 the discussion of collusion between a CA and a log ought t= o > cite the relevant section(s) of the threat analysis. > > > > > > Section 9 > > > > The transparency information extension MUST be non-critical, for backward > compatibility with TLS clients that are nopt CT-aware. > Done. > > > Note that an OCSP responder may be separate from a CA; the wording in > 9.1.1 needs to be revised to reflect that. > Can you suggest text? It'll help understanding in which way the separation between CA and OCSP responder is important in the CT context. > > > What does 9.2 means when it says > > > > When a certificate chain includes such a certificate, this indicates that > CT compliance is required. > > > > Required by what? > By the TLS feature extension. Andrew Ayer has suggested text to clarify it which is under review ( https://github.com/google/certificate-transparency-rfcs/pull/173). > > > > > Section 10 > > > > The opening sentence is not very useful for a standards track document. I= t > suggests CT lacks a well-defined architecture. > > > > The metadata list in 10.1 seems to omit the set of trust anchors accepted > by the log. > > > > In 10.2.4 the text says =E2=80=9C=E2=80=A6The client then has to verify = =E2=80=A6=E2=80=9D Did you mean to > say =E2=80=9CMUST=E2=80=9D here? > Seems to me it follows from the protocol - if the client doesn't do it, then it has no guarantee of inclusion (same as if it didn't check the inclusion proof at all). > > > The language in 10.2.5 about compliance isn=E2=80=99t very useful, when s= eparated > from the text in 10.2.7. Why have these as two separate subsections? > How do you suggest merging the two? > > > The wording in 10.2.7 seems intended to skirt the prior agreement to not > mandate client behavior in the event of a missing SCT. Also, the wording > is sloppy. For example, the text says > > > > In the case that use of TLS with a *valid* certificate is mandated ... > > > > Certificate *validity* is defined by 5280 and profiles thereof. Do you > mean to say a *CT-compliant certificate* here? The same comment applies > to the next bullet which describes what to do if use of a =E2=80=9Cvalid > certificate=E2=80=9D is optional. Also, what does it mean for a TLS clien= t to =E2=80=9Cnot > treat the certificate as valid?=E2=80=9D > I agree - wording was somewhat vague here, so I re-wrote this section. see the pull request for the change. > > > The definition of a Monitor still seems to be wrong, and the recent debat= e > about name-redacted certificates gives further evidence of that. I think > most folks believe the primary function of a Monitor is to observe logs t= o > detect when a certificate is logged that is not consistent with the > Monitor=E2=80=99s information about the Subject of the logged certificate= . The > definition of a Monitor provided here makes this function optional. It > attributes to a Monitor a function that is, I believe, a function of > Auditing. > > > > The text here is not very precise in describing Monitor behavior re > looking for log entries that conflict with certificates the Monitor is > trying to protect. I suggest using text from > draft-kent-trans-monitor-auditor-01.txt. For example: > > > > A Monitor observes a set of logs to detect certificate mis-issuance. A > Monitor notifies a Subject [CA-Subject] when a bogus (or erroneous) > certificate [draft-ietf-trans-threat-analysis] has been issued on behalf = of > that Subject. Every CT-aware Subject is expected to either perform > self-Monitoring or to arrange with a third-party Monitor to detect > mis-issued certificates on behalf of the Subject. > > > > Similarly, the description of how a Monitor does its job seems to omit > what I believe is its critical function. Again, the cited I-D above provi= de > a concise description in its introduction: > > > > A Monitor performs its function by examining all entries from a set of > logs and comparing these entries to reference data for a set of one or mo= re > Subjects. The reference data consists, at a minimum, of a list of Subject > and Subject Alternative Names and the pubic key information associated wi= th > each, supplied by the Subject. If a Monitor detects a log entry for a > certificate that is inconsistent with the reference data for a Subject, t= he > Monitor notifies the Subject. A Subject may perform self-monitoring. > > > > Overall, this section seems inadequate as a description of Monitor > functionality. > The detailed description of monitors' operation in the threat analysis document is very suitable and for this reason would like to keep the section about monitors very brief. > > > Section 10.4 describes audit functions reasonably well, but presents a > view that there is no separate Auditor function in CT. That conflicts wit= h > the design in draft-ietf-trans-gossip-02, and with draft-kent-trans-monit= or-auditor-01. > I suggest that the first paragraph of this subsection be reworded to > characterize the Audit function as one that may be performed by a client, > Monitor, or by a separate entity. This subsection also ends with a > statement not appropriate for a standard track document, as I have noted > before: > > > > The following algorithm outlines may be useful for clients that wish to > perform various audit operations. > > > > The statement above should be revised to *require* that an element > performing the Audit function MUST perform all of these checks in a fashi= on > that produces results identical to those that the algorithms would yield. > If the document doesn=E2=80=99t establish these algorithms as authoritati= ve it is > not defining what the Audit function is, and the text is not a very usefu= l > part of a standards track document. > I agree that an element performing auditing must perform these checks in a fashion that produces results identical to those that the algorithms would yield. I'm not sure how effective it would be to require it in the document though - if the algorithm is wrong it would produce incorrect results, no meaningful audit has been performed. > > > Section 11 > > > > The last sentence here probably ought to be: > > > > Certificates in the frozen log that have not yet expired and require new > SCTs *SHOULD* be submitted to the new log and the SCTs from that log used > instead. > Changed. > > > > > Section 13 > > > > The introduction text here is good, but it should be augmented with a > discussion of the problems for Monitors posed by wildcard and name-redact= ed > certificates (if the latter feature is retained). A reference to the thre= at > document also would be appropriate here, rather than as a separate, trivi= al > subsection (13.7). I suggest deleting that subsection. > IIUC you suggest moving the reference to the threat analysis document from 13.7 to the introduction in 13. I've made that change. Re wildcard and name redaction, wouldn't a discussion on the threats posed by those be more appropriate in the threat analysis document? The introduction text is very general and it does not seem appropriate to me to discuss wildcards/redacted names here. > > > 13.1 says that a TLS client *may* (lowercase) decide to reject a > certificate w/o an SCT. This language is rather squishy compared to the > strict language in 9.2. > Removed that sentence. > > > 13.2 should refer to Monitors (10.3) as the entities that detect > mis-issuance. Monitors might be domain owners, as suggested, or CAs, or > third parties, but the text here mentions only the 1st example. > I've tried fitting that in and it felt like fitting a square peg in a round hole. There's already a section about monitors and it should be straightforward to figure out how to watch a log for certificates of interest. > > > 13.3 notes an important consideration, and its advice to CAs is good. > Saying that clients may make a decision to reject such certificates > underlines the potential for interoperability problems. I guess that=E2= =80=99s OK > for a statement in an SC section, but it seems a bit vague. > Acknowledged. > > > I note that 13.4 refers to a trusted Auditor, which conflicts with the > characterization of Auditing in Section 10. Making the chnges I suggest t= o > section would address this issue. > How does it conflict? I agree it's a bit terse to say a client can hand over observed SCTs to a trusted auditor, but I don't see the conflict. > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a114e4738538fef0535c6c398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Addressed some comments, I've left some un-addressed a= s I'd like to hear more feedback about them from the WG.
The change= s are here:=C2=A0https://github.com/google/certificate-transparency-rfcs/= pull/174

O= n Thu, Jun 16, 2016 at 6:47 PM, Stephen Kent <kent@bbn.com> wrote:
=20 =20 =20

Here are my comments on 6962-bis:

=20

Sectio= n 1.

=C2=A0

Still = no definition of mis-issuance here. Why not use the text I supplied months ago, and cite the threat analysis document?

=C2=A0

There = ought to be a mention=C2=A0 of the residual vulnerabilities that arise when using=C2=A0 name-redacted pre-certificates or wildcard certificates, in light of the recent discussions. Specifically, the problems Monitors face in trying to protect a Subject when the Subject=E2=80=99s name is encompassed by SCTs associated with these certificates.

=C2=A0

I thou= ght the WG agreed, long ago, to not mandate behavior for TLS clients with regard to the presence or absence of SCTs. Yet this section says

= =C2=A0=C2=A0 =E2=80=9CTLS clients can thus require that all certificates they accept as valid are accompanied by signed timestamps.=E2=80=9D

=C2=A0

which = seems to be pretty close to that.

=C2=A0

=C2=A0

Sectio= n 3

=C2=A0

The te= rm =E2=80=9Cpreannounce=E2=80=9D seems odd. =E2=80=9CPre-register=E2=80=9D might make more sense, gi= ven that the action of submission to a log is a form of registration. Online dictionaries that I queried gave definitions for preannounce that didn=E2=80=99t seem t= o be a great match to this activity.

Changed.=C2=A0<= /div>

=C2=A0

Saying= that the submission of a pre-certificate=C2=A0 signifies a binding intent to issue the certificate is slightly misleading. A CA might not wind up issuing the associated certificate, for a variety of reasons. I think it would be better to just drop the word =E2=80=9Cbinding=E2=80=9D here.

Would it help to say that for all intents an= d purposes an observer of a CT log can assume a CA has intended to issue a = certificate denoted by a precertificate observed in the log?

=C2=A0

Sectio= n 4

=C2=A0

Sugges= ted re-wording:

=C2=A0

We define a mechanism to allow these private labels to not appear in public logs, while still retaining the security benefits that accrue from using certificate transparency mechanisms.

=C2=A0

In Sec= tion 4.1 wording is used to motivate the need for name-redacted pre-certificates. It does not say, explicitly, that wildcard certificates can be logged and used in the CT context. It also should note the possible problems they represent for Monitors.

I believe= the first sentence does. At least, I can't see any dis-ambiguity here.= =C2=A0

=C2=A0

Given = the recent debate about name-redaction, I=E2=80=99m not convinced that the descriptio= n in 4.2.2 provides sufficient detail for Monitors and TLS clients to know precisely how to compare an SCT for a name-redacted pre-certificate to a certificate.=

That's likely to change with the simplified= redaction suggestion.=C2=A0

=

=C2=A0

RFC 52= 80 states that name constraints is a critical extension, so the text in 4.3 conflicts with that RFC.

Seeking feedback here - one = possible option is to remove the 'critical or non-critical' part of= the sentence.

=C2=A0

Sectio= n 5

=C2=A0

The te= xt still says

=C2=A0

Log operators MUST NOT impose any conditions on retrieving or sharing data from the log.

=C2=A0

I aske= d if Rich=E2=80=99s on-list statement about how Akamai planned to operate a log was consistent with this mandate, but never received a response.

IIRC the plan was to restrict submission, that text is about getting= data from logs.=C2=A0

<= /span>

=C2=A0

Sectio= n 5.1 should include a statement that the list of trust anchors accepted by a log is part of the log=E2=80=99s metadata.

What is t= he goal behind such a statement? I'm failing to see what it would add t= o the reader (it's already mentioned that the list can be obtained by c= alling get-anchors).=C2=A0
<= p class=3D"gmail-MsoNormal"><= /u>

=C2=A0

Sectio= n 5.3 allows a log to create it=E2=80=99s own OID, instead of using one of the log ID registries. This seems to allow for collisions, and is not consistent with the general IETF rationale for creating registries.

How about the following text as the first sentence:
Each log is= identified by an OID which MUST be unique.=C2=A0

=C2=A0

The description for log shutdown is much improved from prior version that I read. However, there are a couple of requirements here that don=E2=80=99t have an associated explanation of how they can be achieved.

=C2=A0

Make it known to clients and monitors that the log will be frozen=

=C2=A0

Keep the log running until the certificates in all of its entries have expired or exist in other logs (this can be determined by scanning other logs or connecting to domains mentioned in the certificates and inspecting the SCTs served).

You're right - they = depend on the metadata dissemination mechanism, which isn't currently s= pecified.=C2=A0

=C2=A0

=C2=A0

Sectio= n 8

=C2=A0

The op= ening sentence is 5 lines long, which makes it a bit hard to read. But, overall, this section is much improved over previous versions.

=C2=A0

The description the benefits and disadvantages of the certificate extension=C2=A0= to carry an SCT mentions inclusion proofs. This may be confusing to readers, since the extension does not contain an inclusion=C2=A0 proof.

Inclusion proofs can be included in the extension since an inclusion pro= of is a particular type of TransItem and the extension carries a list of Tr= ansItems.
It is not immediately obvious, though, so if you point = to a particular area of the text where this can be clarified I'll try t= o add some text.=C2=A0

It would be better to say that use of this method to deliver an SCT requires that a TLS client use a different mechanism to acquire an inclusion proof (and STH).=

=C2=A0

In Sec= tion 8.1 the discussion of collusion between a CA and a log ought to cite the relevant section(s) of the threat analysis.

=C2=A0

=C2=A0

Sectio= n 9

=C2=A0

The transparency information extension MUST be non-critical, for backward compatibility with TLS clients that are nopt CT-aware.

D= one.=C2=A0

=C2=A0

Note t= hat an OCSP responder may be separate from a CA; the wording in 9.1.1 needs to be revised to reflect that.

Can you suggest = text? It'll help understanding in which way the separation between CA a= nd OCSP responder is important in the CT context.=C2=A0

=C2=A0

What d= oes 9.2 means when it says

=C2=A0

When a certificate chain includes such a certificate, this indicates that CT compliance is required.

=C2=A0

Requir= ed by what?

By the TLS feature extensio= n. Andrew Ayer has suggested text to clarify it which is under review (ht= tps://github.com/google/certificate-transparency-rfcs/pull/173).=C2=A0<= /div>

=C2=A0

=C2=A0

Sectio= n 10

=C2=A0

The op= ening sentence is not very useful for a standards track document. It suggests CT lacks a well-defined architecture.

=C2=A0

The me= tadata list in 10.1 seems to omit the set of trust anchors accepted by the log.<= u>

=C2=A0

In 10.= 2.4 the text says =E2=80=9C=E2=80=A6The client then has to verify =E2=80=A6=E2=80=9D Did you mean to say = =E2=80=9CMUST=E2=80=9D here?

Seems to me = it follows from the protocol - if the client doesn't do it, then it has= no guarantee of inclusion (same as if it didn't check the inclusion pr= oof at all).=C2=A0

=C2=A0

The la= nguage in 10.2.5 about compliance isn=E2=80=99t very useful, when separated from the= text in 10.2.7. Why have these as two separate subsections?

How do you suggest merging the two?=C2=A0

=C2=A0

The wo= rding in 10.2.7 seems intended to skirt the prior agreement to not mandate client behavior in the event of a=C2=A0 missing SCT. Also, the wording is sloppy. For example, the text says<= /p>

= =C2=A0

In the case that use of TLS with a valid certificate is mandated ...

=C2=A0

Certif= icate validity is defined by 5280 and profiles thereof. Do you mean to say a CT= -compliant certificate here? The same comment applies to the next bullet which describes what to do if use of a =E2=80=9Cvalid certificate=E2=80= =9D is optional. Also, what does it mean for a TLS client to =E2=80=9Cnot treat the certificate= as valid?=E2=80=9D

I agree - wording= was somewhat vague here, so I re-wrote this section. see the pull request = for the change.

=

=C2=A0

The definition of a Monitor still seems to be wrong, and the recent debate about name-redacted certificates gives further evidence of that. I think most folks believe the primary function of a Monitor is to observe logs to detect when a certificate is logged that is not consistent with the Monitor=E2=80=99s informa= tion about the Subject of the logged certificate. The definition=C2=A0 of a Monitor provided here makes this function optional. It attributes to a Monitor a function that is, I believe, a function of Auditing.

=C2=A0

The te= xt here is not very precise in describing Monitor behavior re looking for log entries that conflict with certificates the Monitor is trying to protect. I suggest using text from draft-kent-trans-monitor-auditor-01.txt. For example:

=C2=A0

A Monitor observes a set of logs to detect certificate mis-issuance. A Monitor notifies a Subject [CA-Subject] when a bogus (or=C2=A0 erroneous) certificate [draft-ietf-trans-threat-analysis] has been issued on behalf of that Subject. Every CT-aware Subject is expected to either perform self-Monitoring or to arrange with a third-party Monitor to detect mis-issued certificates on behalf of the Subject.

=C2=A0

Simila= rly, the description of how a Monitor does its job seems to omit what I believe is its critical function. Again, the cited I-D above provide a concise description in its introduction:

=C2=A0

A Monitor performs its function by examining all entries from a set of logs and comparing these entries to reference data for a set of one or more Subjects. The reference data consists, at a minimum, of a list of Subject and Subject Alternative Names and the pubic key information associated with each, supplied by the Subject. If a Monitor detects a log entry for a certificate that is inconsistent with the reference data for a Subject, the Monitor notifies the Subject. A Subject may perform self-monitoring.

=C2=A0

Overal= l, this section seems inadequate as a description of Monitor functionality.

=
The detailed description of monitors' operation in the threat anal= ysis document is very suitable and for this reason would like to keep the s= ection about monitors very brief.

<= /u>

=C2=A0

Sectio= n 10.4 describes audit functions reasonably well, but presents a view that there is no separate Auditor function in CT. That conflicts with the design in draft-ietf-trans-gossip-02, and with draft-kent-tran= s-monitor-auditor-01. I suggest that the first paragraph of this subsection be reworded to characterize the Audit function as one that may be performed by a client, Monitor, or by a separate entity. This subsection also ends with a statement not appropriate for a standard track document, as I have noted before:

=C2=A0

The following algorithm outlines may be useful for clients that wish to perform various audit operations.

=C2=A0

The statement above should be revised to require that an element performing the Audit function MUST perform all of these checks in a fashion that produces results identical to those that the algorithms would yield. If the document doesn=E2=80= =99t establish these algorithms as authoritative it is not defining what the Audit function is, and the text is not a very useful part of a standards track document.

I agree that an element= performing auditing must perform these checks in a fashion that produces r= esults identical to those that the algorithms would yield.=C2=A0
= I'm not sure how effective it would be to require it in the document th= ough - if the algorithm is wrong it would produce incorrect results, no mea= ningful audit has been performed.

<= /u>

=C2=A0

Sectio= n 11

=C2=A0

The la= st sentence here probably ought to be:

=C2=A0

Certificates in the frozen log that have not yet expired and require new SCTs SHOULD= be submitted to the new log and the SCTs from that log used instead.

Changed.=C2=A0

=C2=A0

=C2=A0

Sectio= n 13

=C2=A0

The introduction text here is good, but it should be augmented with a discussion of the problems for Monitors posed by wildcard and name-redacted certificates (if the latter feature is retained). A reference to the threat document also would be appropriate here, rather than as a separate, trivial subsection (13.7). I suggest deleting that subsection.

IIUC you suggest movi= ng the reference to the threat analysis document from 13.7 to the introduct= ion in 13. I've made that change.
Re wildcard and name redact= ion, wouldn't a discussion on the threats posed by those be more approp= riate in the threat analysis document? The introduction text is very genera= l and it does not seem appropriate to me to discuss wildcards/redacted name= s here.
=C2=A0

=C2=A0

13.1 s= ays that a TLS client may (lowercase) decide to reject a certificate w/o an SCT. This language is rather squishy compared to the strict language in 9.2.

Removed that sentence.=C2=A0

=C2=A0

13.2 s= hould refer to Monitors (10.3) as the entities that detect mis-issuance. Monitors might be domain owners, as suggested, or CAs, or third parties, but the text here mentions only the 1st example.

I've tried fitting that in and it felt like fitting a square p= eg in a round hole. There's already a section about monitors and it sho= uld be straightforward to figure out how to watch a log for certificates of= interest.

=C2=A0

13.3 n= otes an important consideration, and its advice to CAs is good. Saying that clients may make a decision to reject such certificates underlines the potential for interoperability problems. I guess that=E2=80=99s OK for a statemen= t in an SC section, but it seems a bit vague.

Acknowledged.=C2=A0
=

=

=C2=A0

I note= that 13.4 refers to a trusted Auditor, which conflicts with the characterization of Auditing in Section 10. Making the chnges I suggest to section would address this issue.

How does it conflict?= I agree it's a bit terse to say a client can hand over observed SCTs t= o a trusted auditor, but I don't see the conflict. =C2=A0

=C2=A0

=C2=A0

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20

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


--001a114e4738538fef0535c6c398-- From nobody Tue Jun 21 08:57:12 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6712D9AD for ; Tue, 21 Jun 2016 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps30svp9RrV6 for ; Tue, 21 Jun 2016 08:57:09 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E95E12D9B3 for ; Tue, 21 Jun 2016 08:57:09 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l125so17613278ywb.2 for ; Tue, 21 Jun 2016 08:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0qGrwarq8mHMsOK5ta8h2O8tpZrPAG5EgFpaNC8wNtA=; b=pMFxgspoQbvWi8HOinF4SkD+MOYBMqeONJsP/MeQePHh1xkpZf6Jcgmoc8630drndV T+3aQ4sBXW9vjuoQ7mm+RDoJtCum+A/XtYFDs8sAb2dJvtGkoGJAT7gM0leNEzbEe6zc JFbIcVMiCDh3Dme/ZSxc8xYgScOdTx5lBREKB+jaWdSLrYpo9M/B10P+uqBC9r8glKZ4 Ga3PoLxvgYqF40bef/yaSIhJ9bSQrV++ejt6U6L54IXrxhzdZrCo0sJ+8jX4J1g76l0F wmbTnvKkIfoNWCkzJnL/IaoGv3kkRZzrFEZEQkt7luZT1yZ0Kuoc5NgMWkU1W3sdl/Ci pNYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0qGrwarq8mHMsOK5ta8h2O8tpZrPAG5EgFpaNC8wNtA=; b=UowyiCYHQSYH9xQ4RN9ysMboAIfxbf3ZEhfZd1gfnPpvEHyP0CnRF8F9/SaLci6Fve 7ltnicpEylR9lI+4oCT5GGCyVHqFmBimXf40mRRKTAslurJgoWFd0qFR8hmVf54lLkqD 3sbB0tg95mJeev6fRu/+9xxFyynYaiL1vJbryQehI5X0WW5FRHr76oyC0sPTuvtGhx9c JDWzuRHA1Y7cMfVY3w/izFsAvW0haZadGkVbpVyO/VSm16Y32bFS98/mDDhC9sHdLZ07 q0uaU7Pt+o+5RZi2I8nQjLBhJkvkde6MHlBE2kAq+/z75hs6/yrbShFZCYTaAXYySfsN fwNA== X-Gm-Message-State: ALyK8tLJDuljd7ssKw1TX4sccsrxLz67JwL/+XeBgbcNGfzBhMoHxguU9Uj9sWdWxRDgEmaVrw2dZhymtR3BMw== X-Received: by 10.129.137.4 with SMTP id z4mr11898040ywf.213.1466524628533; Tue, 21 Jun 2016 08:57:08 -0700 (PDT) MIME-Version: 1.0 References: <87k2hnts9h.fsf@alice.fifthhorseman.net> <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> In-Reply-To: <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> From: Steve Date: Tue, 21 Jun 2016 15:56:59 +0000 Message-ID: To: Andrew Ayer , "trans@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c06c10089c52c0535cbdfea Archived-At: Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:57:11 -0000 --94eb2c06c10089c52c0535cbdfea Content-Type: text/plain; charset=UTF-8 If a client can un-redact, what's the point of redaction? Kind regards, Steve On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer wrote: > Hi Rob, > > On Mon, 20 Jun 2016 14:39:00 +0100 > Rob Stradling wrote: > > > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer > > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of > > just "?". > > > > 2. If the client desires stronger SCT matching, it checks that each > > redacted label in the redacted SAN extension matches the > > corresponding label in the SAN extension, by computing HASH > > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > > the certificate. > > I'm a little uneasy about using the serial number, because of > the ways that serial numbers can be, and are, incorrectly encoded (e.g. > not minimally encoded, or a "positive" integer with the MSB set). I > think it's simpler and more robust for the client to take the salt out > of an extension, so it can be treated as an opaque blob and therefore > be unaffected by the vagaries of parsers. > > > - Provides a (partial) technical solution to 'un'redaction (which is > > something that needs to be addressed before Chrome will ever support > > redaction [1]): If a domain owner's certificate team observes an > > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| > > LABEL) for all of the LABELs they manage. > > Another way to support "un-redaction" is to just leave the salt > extension in the pre-certificate instead of removing it. I'd prefer > that approach if this style of un-redaction is desired. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --94eb2c06c10089c52c0535cbdfea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If a client can un-redact, what's the point of redaction= ?

Kind regards,
Steve


On Tue, Jun 21, 2016, 12:35= AM Andrew Ayer <agwa@andrewayer= .name> wrote:
Hi Rob,

On Mon, 20 Jun 2016 14:39:00 +0100
Rob Stradling <rob.stradling@comodo.com> wrote:

> 1. When redacting a LABEL in the "redacted SAN" extension, t= he issuer
> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) ins= tead of
> just "?".
>
> 2. If the client desires stronger SCT matching, it checks that each > redacted label in the redacted SAN extension matches the
> corresponding label in the SAN extension, by computing HASH
> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > the certificate.

I'm a little uneasy about using the serial number, because of
the ways that serial numbers can be, and are, incorrectly encoded (e.g.
not minimally encoded, or a "positive" integer with the MSB set).= =C2=A0 I
think it's simpler and more robust for the client to take the salt out<= br> of an extension, so it can be treated as an opaque blob and therefore
be unaffected by the vagaries of parsers.

> - Provides a (partial) technical solution to 'un'redaction (wh= ich is
> something that needs to be addressed before Chrome will ever support > redaction [1]): If a domain owner's certificate team observes an > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||
> LABEL) for all of the LABELs they manage.

Another way to support "un-redaction" is to just leave the salt extension in the pre-certificate instead of removing it.=C2=A0 I'd pref= er
that approach if this style of un-redaction is desired.

Regards,
Andrew

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--94eb2c06c10089c52c0535cbdfea-- From nobody Tue Jun 21 09:16:14 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F4E12DA45 for ; Tue, 21 Jun 2016 09:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df_IGpUL6Eu6 for ; Tue, 21 Jun 2016 09:16:10 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A7412DA57 for ; Tue, 21 Jun 2016 09:16:10 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i12so17959330ywa.1 for ; Tue, 21 Jun 2016 09:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cPw9OUqBJ4tpsh5h4e9htXUUi03iAcs71jQFdfohNvs=; b=pmuaJJhM8PHx2d50okRd0bEJnxu3L1xQSzjTkA1Um/oYjDGVIJvD0gBFk5cVfgRx6k wpDkaQf3vJ8+LS9+5cGO73QWTBNsM491cRbEfynC1+kq/cmv/p30sPuA3YYDHkmkcUzY FgEj0PnWYlZ56quXLu7BtjI0cWAxm3mRffmvhV+/8Mp4o2xTUPXMsTspbt2CYONgD1ds YnPBHyFCXIhh9SrlqsfPqeI6VjeIvohDDRiZZLpthR+kae12gXebKOby50V3W0flq6C/ 1+Vq1hYq/FYZx61inuBWOoUHne+7d059C12xyCPCtH0P/7p3t5hNIuK/tS2snvOKMQ1s 4MyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cPw9OUqBJ4tpsh5h4e9htXUUi03iAcs71jQFdfohNvs=; b=a+W6vjxZn5B4DOTg4bVUMJLdanoSZrzetCFU90st62uz85E6bn0mim8rh6jD972D3x Yp5kIe1fckVjgssGkW/wIoeDJjPWDUewdT5qOPxzsrbx3uzUhmmP8t2M0TmAYJxuANlS 4epGZmKsEONILv39tCjY6cqkSFYxsPvqo9nTRt0CdhLOCkI2ZC9dAiV4MRo45kSpK7YM mQk4/OCdkHyTtF8ul0gUhByEHRj0+xBcgvt/w/ZXFg9n1t142+z1SDeCL5TQwTu0MleH TdOzTz3qZ06d3Kg7Kr5CkEY5VFMNfjzIyB9WzlTQktuh3xms3l5RX/sLbGRNVEsTTim1 bZmA== X-Gm-Message-State: ALyK8tLc0p/8Bq18u2FLBfovPk4y2ywmO2Qc+52kpt8pkE1Zxef9i4W1cbXKU2rZ4XHUIehOqN2IeXWsg9dazrih X-Received: by 10.37.113.87 with SMTP id m84mr3427221ybc.117.1466525769395; Tue, 21 Jun 2016 09:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.199.139 with HTTP; Tue, 21 Jun 2016 09:16:08 -0700 (PDT) In-Reply-To: References: <87k2hnts9h.fsf@alice.fifthhorseman.net> <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> From: Eran Messeri Date: Tue, 21 Jun 2016 17:16:08 +0100 Message-ID: To: Steve Content-Type: multipart/alternative; boundary=001a11489eca8a834c0535cc239f Archived-At: Cc: "trans@ietf.org" , Andrew Ayer Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 16:16:13 -0000 --001a11489eca8a834c0535cc239f Content-Type: text/plain; charset=UTF-8 FYI proposed text for this change (unreviewed) is in https://github.com/google/certificate-transparency-rfcs/pull/175 On Tue, Jun 21, 2016 at 4:56 PM, Steve wrote: > If a client can un-redact, what's the point of redaction? > A monitor of the log which observes a certificate with redacted dNSName fields and has a list of subdomains for that domain (for example, because it is operated by the legitimate domain owner who knows about all the subdomains registered under this domain) can distinguish between a redacted cert for one of the known subdomains and a redacted cert for an unknown subdomain. TLS clients have to receive the un-redacted certificate, but having the redacted dNSNames alongside the unredacted ones allows clients to apply a policy for determining whether the redaction is acceptable or not. > Kind regards, > Steve > > On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer wrote: > >> Hi Rob, >> >> On Mon, 20 Jun 2016 14:39:00 +0100 >> Rob Stradling wrote: >> >> > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer >> > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of >> > just "?". >> > >> > 2. If the client desires stronger SCT matching, it checks that each >> > redacted label in the redacted SAN extension matches the >> > corresponding label in the SAN extension, by computing HASH >> > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of >> > the certificate. >> >> I'm a little uneasy about using the serial number, because of >> the ways that serial numbers can be, and are, incorrectly encoded (e.g. >> not minimally encoded, or a "positive" integer with the MSB set). I >> think it's simpler and more robust for the client to take the salt out >> of an extension, so it can be treated as an opaque blob and therefore >> be unaffected by the vagaries of parsers. >> > Per this feedback, the proposed text requires the use of all bytes used to encode the serial number, including the tag and length bytes. > >> > - Provides a (partial) technical solution to 'un'redaction (which is >> > something that needs to be addressed before Chrome will ever support >> > redaction [1]): If a domain owner's certificate team observes an >> > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| >> > LABEL) for all of the LABELs they manage. >> >> Another way to support "un-redaction" is to just leave the salt >> extension in the pre-certificate instead of removing it. I'd prefer >> that approach if this style of un-redaction is desired. >> > The reason I'm uneasy with the salt as a separate extension is it adds some complications (another extension to remove, another thing to get right when matching the redacted labels with unredacted ones). As far as I can tell, the serial number could serve the same purpose. > >> Regards, >> Andrew >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --001a11489eca8a834c0535cc239f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI proposed text for this change (unreviewed) is in=C2=A0= https://github.com/google/certificate-transparency-rfcs/pull/175
<= div class=3D"gmail_extra">
On Tue, Jun 21, 20= 16 at 4:56 PM, Steve <steve.medin@gmail.com> wrote:
=

If a client can un-redact, what's the point of redaction= ?

A =C2=A0monitor of the log=C2=A0which observes a cer= tificate with redacted dNSName fields and has a list of subdomains for that= domain (for example, because it is operated by the legitimate domain owner= who knows about all the subdomains registered under this domain) can disti= nguish between a redacted cert for one of the known subdomains and a redact= ed cert for an unknown subdomain.
TLS clients have to receive the= un-redacted certificate, but having the redacted dNSNames alongside the un= redacted ones allows clients to apply a policy for determining whether the = redaction is acceptable or not.

Kind regards,
Steve


On Tue, Jun 21, 2016, 12:35= AM Andrew Ayer <agwa@andrewayer= .name> wrote:
Hi Rob,

On Mon, 20 Jun 2016 14:39:00 +0100
Rob Stradling <rob.stradling= @comodo.com> wrote:

> 1. When redacting a LABEL in the "redacted SAN" extension, t= he issuer
> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) ins= tead of
> just "?".
>
> 2. If the client desires stronger SCT matching, it checks that each > redacted label in the redacted SAN extension matches the
> corresponding label in the SAN extension, by computing HASH
> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > the certificate.

I'm a little uneasy about using the serial number, because of
the ways that serial numbers can be, and are, incorrectly encoded (e.g.
not minimally encoded, or a "positive" integer with the MSB set).= =C2=A0 I
think it's simpler and more robust for the client to take the salt out<= br> of an extension, so it can be treated as an opaque blob and therefore
be unaffected by the vagaries of parsers.
Per this feedback, the proposed text requires the use of= all bytes used to encode the serial number, including the tag and length b= ytes.

> - Provides a (partial) technical solution to 'un'redaction (wh= ich is
> something that needs to be addressed before Chrome will ever support > redaction [1]): If a domain owner's certificate team observes an > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||
> LABEL) for all of the LABELs they manage.

Another way to support "un-redaction" is to just leave the salt extension in the pre-certificate instead of removing it.=C2=A0 I'd pref= er
that approach if this style of un-redaction is desired.
The reason I'm uneasy with the salt as= a separate extension is it adds some complications (another extension to r= emove, another thing to get right when matching the redacted labels with un= redacted ones). As far as I can tell, the serial number could serve the sam= e purpose.=C2=A0

Regards,
Andrew

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

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


--001a11489eca8a834c0535cc239f-- From nobody Tue Jun 21 09:27:06 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3073712DA5F for ; Tue, 21 Jun 2016 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMpW-s5sIZOY for ; Tue, 21 Jun 2016 09:27:02 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D36712DA69 for ; Tue, 21 Jun 2016 09:26:54 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id b72so18636057ywa.3 for ; Tue, 21 Jun 2016 09:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A+KaXo162KSx7TVB8sXh4964oH1L8hSDukC7GpQ/T2M=; b=TyT9hH+upc0QuQ5dh2ew3k5jOU7BGErltZ0iOkfd4M62wYOGvY8wYrFuEUPxhNxB3P j788/M6e1UbZS9mZT3KxYjjBdLiFKS5Z/5xfIzFDFSdVcqNhSpR0fXCM/ZEUFKYfant6 MnJhELpb2OlFCSu3Lf6iyylS3oRLkdTkMX4iuTfrpZNeZilD2ztMHYhScqi/iRW+cCwm K+2IvYFWvMYhePT9BLzUyXsS5LwNmd8pVn9ccgblmWOv92ZxQzImLeTUH5cG6x+GTzKD J7wBkiElFMH9S6CzOF+I1+qBxnMajr9VxfB7GzaT5vUaJbAG1TYl+/LXvSpI9FP40hs+ WgMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A+KaXo162KSx7TVB8sXh4964oH1L8hSDukC7GpQ/T2M=; b=iVM/UvXZ5ShrH2khX2OsnffjCejgc39D/lr1thhcghnGIErwilHuf+KlSwK5VGKMME 5lWTsOuBKppTwwxvWW1tl2xDVWHGyfCNf4RJu2gmcREXNm/wwwQYVNJBNvNUlF54qMRN Dr9B9mLepPl+x+e/iUewzDTQVTXHgjP8c+1sasu4+Ichl5zNg9mQobr4p5eG4q7ixlKS OHQNWsAxpBrF377YXQNNXwr/esw6dTU9XIJ9V0HfLeGEuqCeepy89q4OjBT1EftHYc8T blVOHROU1WiCH4mhS92Na4/SZi16nz1zAKxaPG7Dp1ZA31vrmFbdNavSUup8Y7oLXmJJ p71A== X-Gm-Message-State: ALyK8tLzV79ENSS3xfFWTobdkoanueIOhpImM1VnYGrHtWXikzgX8Coz4X4QA+Csh6qIfOIBZsY9nNTowA0bMA== X-Received: by 10.129.122.66 with SMTP id v63mr12287659ywc.219.1466526413729; Tue, 21 Jun 2016 09:26:53 -0700 (PDT) MIME-Version: 1.0 References: <87k2hnts9h.fsf@alice.fifthhorseman.net> <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> In-Reply-To: From: Steve Date: Tue, 21 Jun 2016 16:26:44 +0000 Message-ID: To: Eran Messeri Content-Type: multipart/alternative; boundary=94eb2c0b1a26f1b5fc0535cc49eb Archived-At: Cc: "trans@ietf.org" , Andrew Ayer Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 16:27:05 -0000 --94eb2c0b1a26f1b5fc0535cc49eb Content-Type: text/plain; charset=UTF-8 So a real world situation has been brought forward that requires CT to care about visibility of subdomains when ownership of name property is granted from ICANN at the level of the visible content in a redacted name? On Tue, Jun 21, 2016, 9:16 AM Eran Messeri wrote: > FYI proposed text for this change (unreviewed) is in > https://github.com/google/certificate-transparency-rfcs/pull/175 > > On Tue, Jun 21, 2016 at 4:56 PM, Steve wrote: > >> If a client can un-redact, what's the point of redaction? >> > A monitor of the log which observes a certificate with redacted dNSName > fields and has a list of subdomains for that domain (for example, because > it is operated by the legitimate domain owner who knows about all the > subdomains registered under this domain) can distinguish between a redacted > cert for one of the known subdomains and a redacted cert for an unknown > subdomain. > TLS clients have to receive the un-redacted certificate, but having the > redacted dNSNames alongside the unredacted ones allows clients to apply a > policy for determining whether the redaction is acceptable or not. > >> Kind regards, >> Steve >> >> On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer wrote: >> >>> Hi Rob, >>> >>> On Mon, 20 Jun 2016 14:39:00 +0100 >>> Rob Stradling wrote: >>> >>> > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer >>> > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of >>> > just "?". >>> > >>> > 2. If the client desires stronger SCT matching, it checks that each >>> > redacted label in the redacted SAN extension matches the >>> > corresponding label in the SAN extension, by computing HASH >>> > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of >>> > the certificate. >>> >>> I'm a little uneasy about using the serial number, because of >>> the ways that serial numbers can be, and are, incorrectly encoded (e.g. >>> not minimally encoded, or a "positive" integer with the MSB set). I >>> think it's simpler and more robust for the client to take the salt out >>> of an extension, so it can be treated as an opaque blob and therefore >>> be unaffected by the vagaries of parsers. >>> >> Per this feedback, the proposed text requires the use of all bytes used > to encode the serial number, including the tag and length bytes. > >> >>> > - Provides a (partial) technical solution to 'un'redaction (which is >>> > something that needs to be addressed before Chrome will ever support >>> > redaction [1]): If a domain owner's certificate team observes an >>> > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| >>> > LABEL) for all of the LABELs they manage. >>> >>> Another way to support "un-redaction" is to just leave the salt >>> extension in the pre-certificate instead of removing it. I'd prefer >>> that approach if this style of un-redaction is desired. >>> >> The reason I'm uneasy with the salt as a separate extension is it adds > some complications (another extension to remove, another thing to get right > when matching the redacted labels with unredacted ones). As far as I can > tell, the serial number could serve the same purpose. > >> >>> Regards, >>> Andrew >>> >>> _______________________________________________ >>> Trans mailing list >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >>> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> --94eb2c0b1a26f1b5fc0535cc49eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So a real world situation has been brought forward that requ= ires CT to care about visibility of subdomains when ownership of name prope= rty is granted from ICANN at the level of the visible content in a redacted= name?


On Tue, Jun 21, 2016, 9:16 = AM Eran Messeri <eranm@google.com> wrote:
On Tue, = Jun 21, 2016 at 4:56 PM, Steve <steve.medin@gmail.com> w= rote:

If a client can un-redact, what= 9;s the point of redaction?

A =C2=A0moni= tor of the log=C2=A0which observes a certificate with redacted dNSName fiel= ds and has a list of subdomains for that domain (for example, because it is= operated by the legitimate domain owner who knows about all the subdomains= registered under this domain) can distinguish between a redacted cert for = one of the known subdomains and a redacted cert for an unknown subdomain.
TLS clients have to receive the un-redacted certificate, but havin= g the redacted dNSNames alongside the unredacted ones allows clients to app= ly a policy for determining whether the redaction is acceptable or not.

Kind regards,
Steve


On Tue, Jun 21, 2016, 12:35= AM Andrew Ayer <agwa@andrewayer.name> wrote:
Hi Rob,
On Mon, 20 Jun 2016 14:39:00 +0100
Rob Stradling <rob.stradling@comodo.com> wrote:

> 1. When redacting a LABEL in the "redacted SAN" extension, t= he issuer
> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) ins= tead of
> just "?".
>
> 2. If the client desires stronger SCT matching, it checks that each > redacted label in the redacted SAN extension matches the
> corresponding label in the SAN extension, by computing HASH
> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of > the certificate.

I'm a little uneasy about using the serial number, because of
the ways that serial numbers can be, and are, incorrectly encoded (e.g.
not minimally encoded, or a "positive" integer with the MSB set).= =C2=A0 I
think it's simpler and more robust for the client to take the salt out<= br> of an extension, so it can be treated as an opaque blob and therefore
be unaffected by the vagaries of parsers.
Per this feedback, the proposed text requi= res the use of all bytes used to encode the serial number, including the ta= g and length bytes.

> - Provides a (partial) technical solution to 'un'redaction (wh= ich is
> something that needs to be addressed before Chrome will ever support > redaction [1]): If a domain owner's certificate team observes an > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||
> LABEL) for all of the LABELs they manage.

Another way to support "un-redaction" is to just leave the salt extension in the pre-certificate instead of removing it.=C2=A0 I'd pref= er
that approach if this style of un-redaction is desired.
The reason I'm uneasy = with the salt as a separate extension is it adds some complications (anothe= r extension to remove, another thing to get right when matching the redacte= d labels with unredacted ones). As far as I can tell, the serial number cou= ld serve the same purpose.=C2=A0
<= div>

Regards,
Andrew

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

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

--94eb2c0b1a26f1b5fc0535cc49eb-- From nobody Wed Jun 22 05:56:30 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259212B00E for ; Wed, 22 Jun 2016 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI-_MjGi1NQN for ; Wed, 22 Jun 2016 05:56:26 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0979312D090 for ; Wed, 22 Jun 2016 05:56:25 -0700 (PDT) Received: (qmail 9535 invoked by uid 1004); 22 Jun 2016 12:56:24 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 22 Jun 2016 13:56:24 +0100 Received: (qmail 15808 invoked by uid 1000); 22 Jun 2016 12:56:23 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 22 Jun 2016 13:56:23 +0100 To: Andrew Ayer , "trans@ietf.org" References: <87k2hnts9h.fsf@alice.fifthhorseman.net> <9b3a2daf-ce0a-8f03-6bc9-892aad9e6105@comodo.com> <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> From: Rob Stradling Message-ID: <610771fb-af63-ba85-bedb-7c32cda49577@comodo.com> Date: Wed, 22 Jun 2016 13:56:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160620213531.78e10b6f2bfbab848a23a6e2@andrewayer.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Suggesting an alternative mechanism for name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 12:56:29 -0000 On 21/06/16 05:35, Andrew Ayer wrote: > Hi Rob, > > On Mon, 20 Jun 2016 14:39:00 +0100 > Rob Stradling wrote: > >> 1. When redacting a LABEL in the "redacted SAN" extension, the issuer >> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of >> just "?". >> >> 2. If the client desires stronger SCT matching, it checks that each >> redacted label in the redacted SAN extension matches the >> corresponding label in the SAN extension, by computing HASH >> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of >> the certificate. > > I'm a little uneasy about using the serial number, because of > the ways that serial numbers can be, and are, incorrectly encoded (e.g. > not minimally encoded, or a "positive" integer with the MSB set). I > think it's simpler and more robust for the client to take the salt out > of an extension, so it can be treated as an opaque blob and therefore > be unaffected by the vagaries of parsers. Hi Andrew. I agree that incorrect encodings of the serial number are a concern. What if we say that SERIAL_NUMBER must consist of the INTEGER tag, length and contents (rather than just the potentially-encoded-differently contents)? >> - Provides a (partial) technical solution to 'un'redaction (which is >> something that needs to be addressed before Chrome will ever support >> redaction [1]): If a domain owner's certificate team observes an >> unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| >> LABEL) for all of the LABELs they manage. > > Another way to support "un-redaction" is to just leave the salt > extension in the pre-certificate instead of removing it. I'd prefer > that approach if this style of un-redaction is desired. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 22 13:06:44 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6565012DB77 for ; Wed, 22 Jun 2016 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-V3XgI3ZD6f for ; Wed, 22 Jun 2016 13:06:38 -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 3016312DB6A for ; Wed, 22 Jun 2016 13:06:38 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:46262 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bFoPz-000MOM-MS for trans@ietf.org; Wed, 22 Jun 2016 16:06:36 -0400 From: Stephen Kent To: trans@ietf.org References: <92dee26a-f6e2-e58b-db37-220f50f029cb@bbn.com> Message-ID: <84927b23-f6a0-06bd-016b-bbd6eaeb7eb5@bbn.com> Date: Wed, 22 Jun 2016 16:06:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AC110030E8094ED5049B5240" Archived-At: Subject: Re: [Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 20:06:42 -0000 This is a multi-part message in MIME format. --------------AC110030E8094ED5049B5240 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Eran, Responses to your edits, below: > > > Section 3 > > The term “preannounce” seems odd. “Pre-register” might make more > sense, given that the action of submission to a log is a form of > registration. Online dictionaries that I queried gave definitions > for preannounce that didn’t seem to be a great match to this activity. > > Changed. > > Saying that the submission of a pre-certificatesignifies a binding > intent to issue the certificate is slightly misleading. A CA might > not wind up issuing the associated certificate, for a variety of > reasons. I think it would be better to just drop the word > “binding” here. > > Would it help to say that for all intents and purposes an observer of > a CT log can assume a CA has intended to issue a certificate denoted > by a precertificate observed in the log? Yes, that's a good characterization. > > Section 4 > > Suggested re-wording: > > We define a mechanism to allow these private labels to not appear > in public logs, *while still retaining the security benefits that > accrue from using certificate transparency mechanisms.* > > In Section 4.1 wording is used to motivate the need for > name-redacted pre-certificates. It does not say, explicitly, that > wildcard certificates can be logged and used in the CT context. It > also should note the possible problems they represent for Monitors. > > I believe the first sentence does. At least, I can't see any > dis-ambiguity here. Which first sentence? 4.1 begins: A certificate containing a DNS-ID [RFC6125] of "*.example.com" could be used to secure the domain "topsecret.example.com", without revealing the string "topsecret" publicly. This says nothing about the ability to log such a cert. It just says that such a cert can be issued by a CA without revealing the domain names represented by "*". The next paragraph provides further rationale why a redacted name cert is desirable, but, again, it does not say that q wildcard cert can be logged. It cites RFC 6125, which tells TLS client (not just CT-aware TLS client) how to match a wildcard cert to a DNS name in a cert. Both of the cited texts do what I said, i.e., they are providing rationale for redacted name certs, without stating, explicitly, that wildcard certs are legitimate for submission to logs. > > Given the recent debate about name-redaction, I’m not convinced > that the description in 4.2.2 provides sufficient detail for > Monitors and TLS clients to know precisely how to compare an SCT > for a name-redacted pre-certificate to a certificate. > > That's likely to change with the simplified redaction suggestion. agreed. > > RFC 5280 states that name constraints is a critical extension, so > the text in 4.3 conflicts with that RFC. > > Seeking feedback here - one possible option is to remove the 'critical > or non-critical' part of the sentence. yes, removing that would address the issue I noted. > > Section 5 > > The text still says > > Log operators MUST NOT impose any conditions on retrieving or > sharing data from the log. > > I asked if Rich’s on-list statement about how Akamai planned to > operate a log was consistent with this mandate, but never received > a response. > > IIRC the plan was to restrict submission, that text is about getting > data from logs. 5.1 says that a log MUST accept any cert that meets 5280 and was issued by one of the trust anchors associated with the log. I'm still not certain that matches what Rich indicated, but I may be mistaken. Hopefully Rich can clarify, and address the submission vs. retrieval constraints question at the same time. > > Section 5.1 should include a statement that the list of trust > anchors accepted by a log is part of the log’s metadata. > > What is the goal behind such a statement? I'm failing to see what it > would add to the reader (it's already mentioned that the list can be > obtained by calling get-anchors). Whoops, I missed that interface when it was added in ver 12. sorry. > > Section 5.3 allows a log to create it’s own OID, instead of using > one of the log ID registries. This seems to allow for collisions, > and is not consistent with the general IETF rationale for creating > registries. > > How about the following text as the first sentence: > Each log is identified by an OID which MUST be unique. That's clearly the goal, but why not mandate use of one of the two registries? The primary reason for creating an IANA registry is to help ensure uniqueness for IDs in a fashion that promotes, dare I say, transparency :-). > > The description for log shutdown is much improved from prior > version that I read. However, there are a couple of requirements > here that don’t have an associated explanation of how they can be > achieved. > > Make it known to clients and monitors that the log will be frozen > > Keep the log running until the certificates in all of its entries > have expired or exist in other logs (this can be determined by > scanning other logs or connecting to domains mentioned in the > certificates and inspecting the SCTs served). > > You're right - they depend on the metadata dissemination mechanism, > which isn't currently specified. It think it's more of an issue than what I have complained about previously. The first requirement mandates a way to contact every TLS client. I presume that the intent is that this will be done by having browse vendors make changes in config data that is made available to users. Studies have shown that it may take a long while for users to update to new versions of browser software. Also if one argues that CT TLS Clients are not just browsers, but any users of TLS, then the mechanism for distributing log metadata includes OS vendors too. Thus it seems appropriate to declare, in this doc, what mechanisms are assumed to achieve the stated requirements. Otherwise a reader might conclude that we're sweeping this hard problem under the rug. perhaps this is a topic to be discussed in the Security Considerations section. finally, re-reading 5.11, I see these are just "suggested" actions, which means that, again, we have no standard's-level description of what it means for a log to safely shut down. > > Section 8 > > The opening sentence is 5 lines long, which makes it a bit hard to > read. But, overall, this section is much improved over previous > versions. > > The description the benefits and disadvantages of the certificate > extensionto carry an SCT mentions inclusion proofs. This may be > confusing to readers, since the extension does not contain an > inclusionproof. > > Inclusion proofs can be included in the extension since an inclusion > proof is a particular type of TransItem and the extension carries a > list of TransItems. > It is not immediately obvious, though, so if you point to a particular > area of the text where this can be clarified I'll try to add some text. Looking at section 5, 5.1, 5.2, and 5.3 mandate log support for the structures defined in these subsections. For 5.4 (TransItem) I see no MUSTs. So, it appears that log support for this structure is optional, at best (though I didn't see a MAY here either). Text in 5.8 mandates support for returning an STH, but consistency and inclusion proofs don't seem to have any MUSTs. I think Section 5 needs to be revised to ensure consistent treatment of what you guys feel are really mandatory log interfaces and data types. > > ... > > The transparency information extension MUST be non-critical, for > backward compatibility with TLS clients that are nopt CT-aware. > > Done. > > Note that an OCSP responder may be separate from a CA; the wording > in 9.1.1 needs to be revised to reflect that. > > Can you suggest text? It'll help understanding in which way the > separation between CA and OCSP responder is important in the CT context. _An OCSP responder_ MAY include a Transparency Information X.509v3 extension in the "singleExtensions" of a "SingleResponse" in an OCSP response. > > What does 9.2 means when it says > > When a certificate chain includes such a certificate, this > indicates that CT compliance is required. > > Required by what? > > By the TLS feature extension. Andrew Ayer has suggested text to > clarify it which is under review > (https://github.com/google/certificate-transparency-rfcs/pull/173). I looked at the page that the URL displayed and didn't see any text that seems relevant to my question. is 9.2 trying to say that IF a CA includes the indicated extension in its TA or an intermediate CA cert, THEN a TLS client MUST reject any subordinate EE cert if there is not a corresponding SCT, IF the client recognizes the extension? If that's the intent, please say so directly. Also, why is this extension described as SHOULD be non-critical? Under what circumstances ought as CA mark it CRITICAL? > > Section 10 > > The opening sentence is not very useful for a standards track > document. It suggests CT lacks a well-defined architecture. > > The metadata list in 10.1 seems to omit the set of trust anchors > accepted by the log. > > In 10.2.4 the text says “…The client then has to verify …” Did you > mean to say “MUST” here? > > Seems to me it follows from the protocol - if the client doesn't do > it, then it has no guarantee of inclusion (same as if it didn't check > the inclusion proof at all). The phrase "has to" is not a substitute for MUST in a standards track RFC. It's just a matter RFC style/clarity. > > The language in 10.2.5 about compliance isn’t very useful, when > separated from the text in 10.2.7. Why have these as two separate > subsections? > > How do you suggest merging the two? I suggest a simple merge, removing redundant text: A certificate not accompanied by any valid SCTs MUST NOT be considered compliant by TLS clients. If a TLS server presents a certificate chain that is non-compliant, there are two possibilities. o In the case that use of TLS with a valid certificate is mandated by explicit security policy, application protocol specification, or other means, the TLS client MUST refuse the connection. o If the use of TLS with a valid certificate is optional, the TLS client MAY accept the connection but MUST NOT treat the certificate as valid. > The wording in 10.2.7 seems intended to skirt the prior agreement > to not mandate client behavior in the event of amissing SCT. Also, > the wording is sloppy. For example, the text says > > In the case that use of TLS with a _valid_ certificate is mandated ... > > Certificate _validity_ is defined by 5280 and profiles thereof. Do > you mean to say a _CT-compliant certificate_ here? The same > comment applies to the next bullet which describes what to do if > use of a “valid certificate” is optional. Also, what does it mean > for a TLS client to “not treat the certificate as valid?” > > I agree - wording was somewhat vague here, so I re-wrote this section. > see the pull request for the change. > > ... > > The detailed description of monitors' operation in the threat analysis > document is very suitable and for this reason would like to keep the > section about monitors very brief. I fear you may be confusing the threat analysis text with the text in draft-kent-trans-monitor-auditor-01.txt. the text in the threat analysis doc does not define the Monitor function in the requisite detail. Additionally, the text describing Monitors here is not just brief, it's in conflict with the way that several of us have said what we believe a Monitor does. > > Section 10.4 describes audit functions reasonably well, but > presents a view that there is no separate Auditor function in CT. > That conflicts with the design in draft-ietf-trans-gossip-02, and > with draft-kent-trans-monitor-auditor-01. I suggest that the first > paragraph of this subsection be reworded to characterize the Audit > function as one that may be performed by a client, Monitor, or by > a separate entity. This subsection also ends with a statement not > appropriate for a standard track document, as I have noted before: > > The following algorithm outlines may be useful for clients that > wish to perform various audit operations. > > The statement above should be revised to _require_ that an element > performing the Audit function MUST perform all of these checks in > a fashion that produces results identical to those that the > algorithms would yield. If the document doesn’t establish these > algorithms as authoritative it is not defining what the Audit > function is, and the text is not a very useful part of a standards > track document. > > I agree that an element performing auditing must perform these checks > in a fashion that produces results identical to those that the > algorithms would yield. > I'm not sure how effective it would be to require it in the document > though - if the algorithm is wrong it would produce incorrect results, > no meaningful audit has been performed. if the alg in this section is wrong it has no place in a standards doc ;-). The point of this doc is to define the functionality and behavior of all elements of CT, right? If one cannot provide a definitive description of required behavior for an element of a system, then one has failed to specify it in enough detail to be part of a standard. > > Section 11 > > The last sentence here probably ought to be: > > Certificates in the frozen log that have not yet expired and > require new SCTs _SHOULD_ be submitted to the new log and the SCTs > from that log used instead. > > Changed. thanks. > > Section 13 > > The introduction text here is good, but it should be augmented > with a discussion of the problems for Monitors posed by wildcard > and name-redacted certificates (if the latter feature is > retained). A reference to the threat document also would be > appropriate here, rather than as a separate, trivial subsection > (13.7). I suggest deleting that subsection. > > IIUC you suggest moving the reference to the threat analysis document > from 13.7 to the introduction in 13. I've made that change. > Re wildcard and name redaction, wouldn't a discussion on the threats > posed by those be more appropriate in the threat analysis document? > The introduction text is very general and it does not seem appropriate > to me to discuss wildcards/redacted names here. > > 13.1 says that a TLS client _may_ (lowercase) decide to reject a > certificate w/o an SCT. This language is rather squishy compared > to the strict language in 9.2. > > Removed that sentence. thanks. > > 13.2 should refer to Monitors (10.3) as the entities that detect > mis-issuance. Monitors might be domain owners, as suggested, or > CAs, or third parties, but the text here mentions only the 1^st > example. > > I've tried fitting that in and it felt like fitting a square peg in a > round hole. There's already a section about monitors and it should be > straightforward to figure out how to watch a log for certificates of > interest. If it's trivial, it should be easy to state in a few sentences. I note that only recently did the WG become aware of the problems faced by Monitors when trying to match redacted certs to reference data. So added detail does seem to be needed, even if we have a new design for redacted certs. > > I note that 13.4 refers to a trusted Auditor, which conflicts with > the characterization of Auditing in Section 10. Making the chnges > I suggest to section would address this issue. > > How does it conflict? I agree it's a bit terse to say a client can > hand over observed SCTs to a trusted auditor, but I don't see the > conflict. The conflict is that the gossip I-D has an auditor as an essential, distinct function in the system. 6962-bis states "Audits are performed by monitors or TLS clients." which suggests that there is no separate Auditor. That is a conflict. Steve --------------AC110030E8094ED5049B5240 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Eran,

Responses to your edits, below:


 

Section 3

 

The term “preannounce” seems odd. “Pre-register” might make more sense, given that the action of submission to a log is a form of registration. Online dictionaries that I queried gave definitions for preannounce that didn’t seem to be a great match to this activity.

Changed. 

 

Saying that the submission of a pre-certificate  signifies a binding intent to issue the certificate is slightly misleading. A CA might not wind up issuing the associated certificate, for a variety of reasons. I think it would be better to just drop the word “binding” here.

Would it help to say that for all intents and purposes an observer of a CT log can assume a CA has intended to issue a certificate denoted by a precertificate observed in the log?
Yes, that's a good characterization.

 

Section 4

 

Suggested re-wording:

 

We define a mechanism to allow these private labels to not appear in public logs, while still retaining the security benefits that accrue from using certificate transparency mechanisms.

 

In Section 4.1 wording is used to motivate the need for name-redacted pre-certificates. It does not say, explicitly, that wildcard certificates can be logged and used in the CT context. It also should note the possible problems they represent for Monitors.

I believe the first sentence does. At least, I can't see any dis-ambiguity here.
Which first sentence? 4.1 begins:

   A certificate containing a DNS-ID [RFC6125] of "*.example.com" could
   be used to secure the domain "topsecret.example.com", without
   revealing the string "topsecret" publicly.

This says nothing about the ability to log such a cert. It just says that such a cert can be issued by a CA without revealing the domain names represented by "*".

The next paragraph provides further rationale why a redacted name cert is desirable, but, again, it does not say that q wildcard cert can be logged. It cites RFC 6125, which tells TLS client (not just CT-aware TLS client) how to match a wildcard cert to a DNS name in a cert.

Both of the cited texts do what I said, i.e., they are providing rationale for redacted name certs, without stating, explicitly, that wildcard certs are legitimate for submission to logs.

 

Given the recent debate about name-redaction, I’m not convinced that the description in 4.2.2 provides sufficient detail for Monitors and TLS clients to know precisely how to compare an SCT for a name-redacted pre-certificate to a certificate.

That's likely to change with the simplified redaction suggestion.
agreed.
 

 

RFC 5280 states that name constraints is a critical extension, so the text in 4.3 conflicts with that RFC.

Seeking feedback here - one possible option is to remove the 'critical or non-critical' part of the sentence.
yes, removing that would address the issue I noted.

 

Section 5

 

The text still says

 

Log operators MUST NOT impose any conditions on retrieving or sharing data from the log.

 

I asked if Rich’s on-list statement about how Akamai planned to operate a log was consistent with this mandate, but never received a response.

IIRC the plan was to restrict submission, that text is about getting data from logs.
 
5.1 says that a log MUST accept any cert that meets 5280 and was issued by one of the trust anchors associated with the log. I'm still not certain that matches what Rich indicated, but I may be mistaken. Hopefully Rich can clarify, and address the submission vs. retrieval constraints question at the same time.

 

Section 5.1 should include a statement that the list of trust anchors accepted by a log is part of the log’s metadata.

What is the goal behind such a statement? I'm failing to see what it would add to the reader (it's already mentioned that the list can be obtained by calling get-anchors).
Whoops, I missed that interface when it was added in ver 12. sorry.

 

Section 5.3 allows a log to create it’s own OID, instead of using one of the log ID registries. This seems to allow for collisions, and is not consistent with the general IETF rationale for creating registries.

How about the following text as the first sentence:
Each log is identified by an OID which MUST be unique.
That's clearly the goal, but why not mandate use of one of the two registries? The primary reason for creating an IANA registry is to help ensure uniqueness for IDs in a fashion that promotes, dare I say, transparency :-).

 

The description for log shutdown is much improved from prior version that I read. However, there are a couple of requirements here that don’t have an associated explanation of how they can be achieved.

 

Make it known to clients and monitors that the log will be frozen

 

Keep the log running until the certificates in all of its entries have expired or exist in other logs (this can be determined by scanning other logs or connecting to domains mentioned in the certificates and inspecting the SCTs served).

You're right - they depend on the metadata dissemination mechanism, which isn't currently specified.
It think it's more of an issue than what I have complained about previously. The first requirement mandates a way to contact every TLS client. I presume that the intent is that this will be done by having browse vendors make changes in config data that is made available to users. Studies have shown that it may take a long while for users to update to new versions of browser software. Also if one argues that CT TLS Clients are not just browsers, but any users of TLS, then the mechanism for distributing log metadata includes OS vendors too. Thus it seems appropriate to declare, in this doc, what mechanisms are assumed to achieve the stated requirements. Otherwise a reader might conclude that we're sweeping this hard problem under the rug. perhaps this is a topic to be discussed in the Security Considerations section. finally, re-reading 5.11, I see these are just "suggested" actions, which means that, again, we have no standard's-level description of what it means for a log to safely shut down.

 

 

Section 8

 

The opening sentence is 5 lines long, which makes it a bit hard to read. But, overall, this section is much improved over previous versions.

 

The description the benefits and disadvantages of the certificate extension  to carry an SCT mentions inclusion proofs. This may be confusing to readers, since the extension does not contain an inclusion  proof.

Inclusion proofs can be included in the extension since an inclusion proof is a particular type of TransItem and the extension carries a list of TransItems.
It is not immediately obvious, though, so if you point to a particular area of the text where this can be clarified I'll try to add some text.
Looking at section 5, 5.1, 5.2, and 5.3 mandate log support for the structures defined in these subsections. For 5.4 (TransItem) I see no MUSTs. So, it appears that log support for this structure is optional, at best (though I didn't see a MAY here either). Text in 5.8 mandates support for returning an STH,  but consistency and inclusion proofs don't seem to have any MUSTs. I think Section 5 needs to be revised to ensure consistent treatment of what you guys feel are really mandatory log interfaces and data types.
...

 

The transparency information extension MUST be non-critical, for backward compatibility with TLS clients that are nopt CT-aware.

Done. 

 

Note that an OCSP responder may be separate from a CA; the wording in 9.1.1 needs to be revised to reflect that.

Can you suggest text? It'll help understanding in which way the separation between CA and OCSP responder is important in the CT context.
   An OCSP responder MAY include a Transparency Information
   X.509v3 extension in the "singleExtensions" of a "SingleResponse" in
   an OCSP response.

 

What does 9.2 means when it says

 

When a certificate chain includes such a certificate, this indicates that CT compliance is required.

 

Required by what?

By the TLS feature extension. Andrew Ayer has suggested text to clarify it which is under review (https://github.com/google/certificate-transparency-rfcs/pull/173).
I looked at the page that the URL displayed and didn't see any text that seems relevant to my question. is 9.2 trying to say that IF a CA includes the indicated extension in its TA or an intermediate CA cert, THEN a TLS client MUST reject any subordinate EE cert if there is not a corresponding SCT, IF the client recognizes the extension? If that's the intent, please say so directly. Also, why is this extension described as SHOULD be non-critical? Under what circumstances ought as CA mark it CRITICAL?

 

 

Section 10

 

The opening sentence is not very useful for a standards track document. It suggests CT lacks a well-defined architecture.

 

The metadata list in 10.1 seems to omit the set of trust anchors accepted by the log.

 

In 10.2.4 the text says “…The client then has to verify …” Did you mean to say “MUST” here?

Seems to me it follows from the protocol - if the client doesn't do it, then it has no guarantee of inclusion (same as if it didn't check the inclusion proof at all).
The phrase "has to" is not a substitute for MUST in a standards track RFC. It's just a matter RFC style/clarity.

 

The language in 10.2.5 about compliance isn’t very useful, when separated from the text in 10.2.7. Why have these as two separate subsections?

How do you suggest merging the two?
I suggest a simple merge, removing redundant text:

   A certificate not accompanied by any valid SCTs
   MUST NOT be considered compliant by TLS clients.

   If a TLS server presents a certificate chain that is non-compliant,
   there are two possibilities.

   o  In the case that use of TLS with a valid certificate is mandated
      by explicit security policy, application protocol specification,
      or other means, the TLS client MUST refuse the connection.

   o  If the use of TLS with a valid certificate is optional, the TLS
      client MAY accept the connection but MUST NOT treat the
      certificate as valid.

 

The wording in 10.2.7 seems intended to skirt the prior agreement to not mandate client behavior in the event of a  missing SCT. Also, the wording is sloppy. For example, the text says

 

In the case that use of TLS with a valid certificate is mandated ...

 

Certificate validity is defined by 5280 and profiles thereof. Do you mean to say a CT-compliant certificate here? The same comment applies to the next bullet which describes what to do if use of a “valid certificate” is optional. Also, what does it mean for a TLS client to “not treat the certificate as valid?”

I agree - wording was somewhat vague here, so I re-wrote this section. see the pull request for the change.

 ...

The detailed description of monitors' operation in the threat analysis document is very suitable and for this reason would like to keep the section about monitors very brief.
I fear you may be confusing the threat analysis text with the text in draft-kent-trans-monitor-auditor-01.txt. the text in the threat analysis doc does not define the Monitor function in the requisite detail. Additionally, the text describing Monitors here is not just brief, it's in conflict with the way that several of us have said  what we believe a Monitor does.

 

Section 10.4 describes audit functions reasonably well, but presents a view that there is no separate Auditor function in CT. That conflicts with the design in draft-ietf-trans-gossip-02, and with draft-kent-trans-monitor-auditor-01. I suggest that the first paragraph of this subsection be reworded to characterize the Audit function as one that may be performed by a client, Monitor, or by a separate entity. This subsection also ends with a statement not appropriate for a standard track document, as I have noted before:

 

The following algorithm outlines may be useful for clients that wish to perform various audit operations.

 

The statement above should be revised to require that an element performing the Audit function MUST perform all of these checks in a fashion that produces results identical to those that the algorithms would yield. If the document doesn’t establish these algorithms as authoritative it is not defining what the Audit function is, and the text is not a very useful part of a standards track document.

I agree that an element performing auditing must perform these checks in a fashion that produces results identical to those that the algorithms would yield. 
I'm not sure how effective it would be to require it in the document though - if the algorithm is wrong it would produce incorrect results, no meaningful audit has been performed.

if the alg in this section is wrong it has no place in a standards doc ;-). The point of this doc is to define the functionality and behavior of all elements of CT, right? If one cannot provide a definitive description of required behavior for an element of a system, then one has failed to specify it in enough detail to be part of a standard.

 

Section 11

 

The last sentence here probably ought to be:

 

Certificates in the frozen log that have not yet expired and require new SCTs SHOULD be submitted to the new log and the SCTs from that log used instead.

Changed.
thanks.

 

 

Section 13

 

The introduction text here is good, but it should be augmented with a discussion of the problems for Monitors posed by wildcard and name-redacted certificates (if the latter feature is retained). A reference to the threat document also would be appropriate here, rather than as a separate, trivial subsection (13.7). I suggest deleting that subsection.

IIUC you suggest moving the reference to the threat analysis document from 13.7 to the introduction in 13. I've made that change.
Re wildcard and name redaction, wouldn't a discussion on the threats posed by those be more appropriate in the threat analysis document? The introduction text is very general and it does not seem appropriate to me to discuss wildcards/redacted names here.
 

 

13.1 says that a TLS client may (lowercase) decide to reject a certificate w/o an SCT. This language is rather squishy compared to the strict language in 9.2.

Removed that sentence.
thanks.

 

13.2 should refer to Monitors (10.3) as the entities that detect mis-issuance. Monitors might be domain owners, as suggested, or CAs, or third parties, but the text here mentions only the 1st example.

I've tried fitting that in and it felt like fitting a square peg in a round hole. There's already a section about monitors and it should be straightforward to figure out how to watch a log for certificates of interest.
If it's trivial, it should be easy to state in a few sentences. I note that only recently did the WG become aware of the problems faced by Monitors when trying to match redacted certs to reference data. So added detail does seem to be needed, even if we have a new design for redacted certs.

 

I note that 13.4 refers to a trusted Auditor, which conflicts with the characterization of Auditing in Section 10. Making the chnges I suggest to section would address this issue.

How does it conflict? I agree it's a bit terse to say a client can hand over observed SCTs to a trusted auditor, but I don't see the conflict. 
The conflict is that the gossip I-D has an auditor as an essential, distinct function in the system. 6962-bis states "Audits are performed by monitors or TLS clients." which suggests that there is no separate Auditor. That is a conflict.

Steve

--------------AC110030E8094ED5049B5240-- From nobody Fri Jun 24 09:07:28 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A759812DD1B; Fri, 24 Jun 2016 09:00:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160056.10933.72193.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:56 -0700 Archived-At: Cc: trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Requested session has been scheduled for IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:57 -0000 Dear Melinda Shore, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:00:00) Wednesday, Morning Session I 1000-1230 Room Name: Charlottenburg I size: 80 --------------------------------------------- Special Note: 10:00-11:00 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 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: dane curdle dnsop tls Second Priority: ipsecme saag Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 10:44:52 2016 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59712DC92 for ; Fri, 24 Jun 2016 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qrd_pvl9TaW for ; Fri, 24 Jun 2016 10:44:48 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C001412DC44 for ; Fri, 24 Jun 2016 10:44:44 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id i123so41268864pfg.0 for ; Fri, 24 Jun 2016 10:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5BNVgTSh1TUJpn8Bn9NKUDr6rc1hLhTN+DHJhHVp88g=; b=cVaOy9wjNbs33ZYOcrr73qOsNXRpoHvq22Bg2gsShOvxIAAlUUz8WwFV3KdLPFGghS KAzal3BoNL3JdFWUwzFcxhhJ0Ea6MPf+hcJcLNyETCg2KwvRi6wsarm1YkWmCm0D03Mm iNicVzSehOQccyyLD/ha7vbXc2qT+0y5/lt6bZZCc72A4IW0CGhsAsCmJuGUVmX3XZy2 iG69lJ+4GwEJ4EVIjlHS0Fg3Xc7VmOFeYY5aAtMRKarGmbpK2tnTnTmKGEBEEnTiIKwT +ytWX4McmnQiQzzoOtIFgThuW8DT5kkBPnYfJvLX1i2YmNiFoFgJcKpXBNuuMTWN8y+m oouA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5BNVgTSh1TUJpn8Bn9NKUDr6rc1hLhTN+DHJhHVp88g=; b=k3/gd/GcNBTza1r4+SwxllfqXE3cZ6e2+7yxTzZ96G0JhU+E3Z7miTcjj2IOf8IsAk 2GFpCQO21b3PHiwbf21+DOUEPwLqga7UGKDcXH99ViLqrFNJfRTXy2cRLXTCI+xBfA+Y yWVx5G7xX4uWSllIs4joK3YW/jMzw43TTm83HI6ZSqcP55IF5WlTmtF2NdzIePAEig4q 7cB4ZbCIk1fLfeayJFyXP0ObqcNnPHFZGFzkX8mi//HEo1G/3TyAzdfAvVQtb/uxMZyT i2gCkOzPAg/iyi8r+GioAZ+W/GR1ugC2REEK8R3LHUkLiu6lI1uoBK+85VGO/TM+MO9O 2DyA== X-Gm-Message-State: ALyK8tL4qxd/MlYEkfq0cKODElncSQyjR0UDkAHHxXxnHQhVKyrh8QrmgROMOON1oN8fYw== X-Received: by 10.98.31.140 with SMTP id l12mr9473593pfj.51.1466790284339; Fri, 24 Jun 2016 10:44:44 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (209-112-215-89-radius.dynamic.acsalaska.net. [209.112.215.89]) by smtp.googlemail.com with ESMTPSA id e126sm1535873pfc.5.2016.06.24.10.44.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 10:44:43 -0700 (PDT) References: <20160624160056.10933.72193.idtracker@ietfa.amsl.com> To: "trans@ietf.org" From: Melinda Shore X-Forwarded-Message-Id: <20160624160056.10933.72193.idtracker@ietfa.amsl.com> Message-ID: <3306d8a1-976c-5795-c331-9312bb3a9534@gmail.com> Date: Fri, 24 Jun 2016 09:44:42 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160624160056.10933.72193.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: trans - Requested session has been scheduled for IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 17:44:51 -0000 Please note that we are not meeting in Berlin, and were scheduled in error. Thanks, Melinda From nobody Thu Jun 30 10:44:59 2016 Return-Path: X-Original-To: trans@ietf.org Delivered-To: trans@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC76E12DAEA; Thu, 30 Jun 2016 10:44:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160630174446.29606.241.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2016 10:44:46 -0700 Archived-At: Cc: trans@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Trans] trans - Requested session has been scheduled for IETF 96 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.17 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:44:47 -0000 Dear Melinda Shore, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. trans Session 1 (1:00:00) Wednesday, Morning Session I 1000-1230 Room Name: Charlottenburg I size: 80 --------------------------------------------- Special Note: CANCELED 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 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: dane curdle dnsop tls Second Priority: ipsecme saag Special Requests: ---------------------------------------------------------