From nobody Fri Apr 13 04:42:04 2018 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 B0A301270A3; Fri, 13 Apr 2018 04:41:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: trans@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152361971767.26293.17263814622570887509@ietfa.amsl.com> Date: Fri, 13 Apr 2018 04:41:57 -0700 Archived-At: Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-13.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 11:41:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency WG of the IETF. Title : Attack and Threat Model for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-13.txt Pages : 30 Date : 2018-04-13 Abstract: This document describes an attack model and discusses threats for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates are being developed. The model provides an analysis of detection and remediation mechanisms for both syntactic and semantic mis-issuance. The model introduces an outline of attacks to organize the discussion. The model also describes the roles played by the elements of the Certificate Transparency (CT) system, to establish a context for the model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13 https://datatracker.ietf.org/doc/html/draft-ietf-trans-threat-analysis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 16 14:01:42 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0883E126CB6 for ; Mon, 16 Apr 2018 14:01:41 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yas2HGTOfXWr for ; Mon, 16 Apr 2018 14:01:39 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 9563F124B0A for ; Mon, 16 Apr 2018 14:01:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Q15Y2zzjz6S; Mon, 16 Apr 2018 23:01:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1523912497; bh=XNLm/tVgR29CJsP4rFSkbKVWRMHuRqCoe220VD652j0=; h=Date:From:To:Subject; b=ew25S9arDIhttZLsTnhI7TFRN1R1aU6NmM3qeq5TRXIp+2WnDulGakuq0KSkZJuzu daxMAALX/YQhsw8bPJM2dtZ18XPTCFzmzkc2WihYSRGTIUVeGMfXMt14y46qj+L3MD GULs68AqEk9t5FHJTsds4T88vxHx26dgFuX1iXcw= 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 iPgMScFmepAH; Mon, 16 Apr 2018 23:01:35 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 16 Apr 2018 23:01:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4EBEC62D29; Mon, 16 Apr 2018 17:01:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4EBEC62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 48ACA40D358A; Mon, 16 Apr 2018 17:01:34 -0400 (EDT) Date: Mon, 16 Apr 2018 17:01:34 -0400 (EDT) From: Paul Wouters To: Trans , Melinda Shore Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Trans] WGLC started for draft-ietf-trans-threat-analysis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2018 21:01:41 -0000 Hi, This starts a 3 week WGLC for draft-ietf-trans-threat-analysis Previously, there were some contentious issues regarding the dual CA attack that dkg came up with. The current version should address all those issues. But since it has been a (very!) long time since this document was discussed and consumed, please review the entire document. https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13 Paul & Melinda From nobody Thu Apr 19 06:30:39 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253D612D9FF for ; Thu, 19 Apr 2018 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN5OyjNgUbf9 for ; Thu, 19 Apr 2018 06:30:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 5EBF912D964 for ; Thu, 19 Apr 2018 06:30:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40Rfxh681gz38r; Thu, 19 Apr 2018 15:30:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524144632; bh=iCmFHtpiQ/hkahJdi62pLF2IjexbJ1oA3Mce3qs6Cus=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=syvQHIWdqgh/sooeJq6le0tkdxJ2xyC79iiIKQmy2cZRArbTTETQRDjmMekNK1Ue5 iz6kGPgpFaNhIPoCTpuBGGan+MHHKEBsn32fhYyhs/sRVn9JdpWcvqKxgpk8sRwcyY jjMG/YhKDZSue4L1L/Zq4YSHORq/6PYiWtdGncLA= 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 OHiKzw3fjujB; Thu, 19 Apr 2018 15:30:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 19 Apr 2018 15:30:27 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DFD6F61D7F; Thu, 19 Apr 2018 09:30:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DFD6F61D7F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8E43411AC49; Thu, 19 Apr 2018 09:30:25 -0400 (EDT) Date: Thu, 19 Apr 2018 09:30:25 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: "trans@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 13:30:38 -0000 On Thu, 7 Sep 2017, Eric Rescorla wrote: Eric, Are all your concerns raised in the AD review met by version -28 ? The diff since your last review: https://tools.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-28.txt&url1=draft-ietf-trans-rfc6962-bis-26.txt Paul > Date: Thu, 7 Sep 2017 10:41:45 > From: Eric Rescorla > Cc: "trans@ietf.org" > To: Ben Laurie > Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt > > > > On Thu, Sep 7, 2017 at 3:24 AM, Ben Laurie wrote: > > > On 5 September 2017 at 18:46, Eric Rescorla wrote: > > > On Tue, Sep 5, 2017 at 9:04 AM, Ben Laurie wrote: > > > On 4 September 2017 at 00:17, Eric Rescorla wrote: > Hi folks, > > Please find enclosed the first cut of my AD review of this draft. > > Note: the original of this review is on Phabricator at: > >   https://mozphab-ietf.devsvcdev.mozaws.net/D13 > > If you want to see comments in context -- which is a lot easier -- you > can go there. Also, you can create an account and respond inline if > you like.  If you elect to, let me know if you run into problems. > > -Ekr > > > Note: I have not yet reviewed the algorithms in S 2.1. I plan to do > that separately, but figured it would be useful to provide the rest of > my review on the assumption that the changes to that section will be > modest if any. > > > High-Level: > > 1. This document makes a variety of claims about the assurances that > clients get that only obtain if some as-yet-to-be-specified > third-party verifiability mechanism is implemented. For instance, in > the intro: > >   Certificate Transparency aims to mitigate the problem of misissued >   certificates by providing append-only logs of issued certificates. >   The logs do not need to be trusted because they are publicly >   auditable. > > > As the extensive discussion following Richard Barnes's and my previous > comments should make clear, this is only a property of CT if you also > have some mechanism for third-party verifiability of STHs, and this > document does not supply that. In the actually deployed -- we can > debate deployable separately the deployability of some of the > proposals for how to get this-- versions of CT, what clients get is > SCTs, which are effectively countersignatures and in fact do require > trusting the logs. This is implicitly acknowledged by proposals that > RPs only accept certificates with >1 SCT. > > > The purpose of multiple SCTs is to avoid the death of a single log causing the death of a large number of certificates. It is not about trust. > > > That seems like the reason for the server to offer it, but not for the client to require it. > > Line 763 >    Maximum Chain Length:  The longest chain submission the log is >       willing to accept, if the log chose to limit it. > Nit: chooses > > > Past tense seems correct? > > > I'm willing to dert this to the RFC Editor. >   >   > > > Line 785 >    accepted trust anchor, using only the chain of intermediate CA >    certificates provided by the submitter. > Why is this a 2119 MUST? It seems wise, but not necessarily a conformance requirement > > > "To avoid being overloaded by invalid submissions" > > > There seem like one way to prevent this, but not the only one. > >   > Line 816 >    anchor used to verify the chain (even if it was omitted from the >    submission).  The log MUST present this chain for auditing upon >    request (see Section 5.6).  This prevents the CA from avoiding blame > What happens in cases of multiple chains. For instance, say that the submitter provides superfluous certificates? > > > Not allowed. > > > Hmm...  So your theory is that the submitter does path construction > > > Yep - and that's borne out by practice. > > > OK, well, then it would help if the document were clearer on this point.  > >   >   > > > Line 837 >        opaque LogID<2..127>; > This seems to be the first use of the TLS specification language, but I don't see a cite. Please provide one, > > > See s1.2. > > > OK. Thanks.  > >   > > Line 926 >        opaque TBSCertificate<1..2^24-1>; > NIT: there's no actual way a TBSCertificate can be 1 byte. > > > Line 948 >    "tbs_certificate".  The length of the "issuer_key_hash" MUST match >    HASH_SIZE. > Is this true? What happens if we have two CAs that share a key? > > > Eh? > > > Say that a CA spins up two subordinates that happen to share the same key. I agree it's foolish. >  return an empty > > > > Line 1522 >    permissible.  These entries SHALL be sequential beginning with the >    entry specified by "start". > How does the client know which of the above two cases has occurred? > > > The response includes an STH, which says how big the tree is. Probably should be the latest one known to that server. >   > > > Line 1552 >    TLS servers MUST use at least one of the three mechanisms listed >    below to present one or more SCTs from one or more logs to each TLS > This needs to somehow be clear that it only applies to TLS servers that are compliant with this specification, as it's not a new requirement on all > TLS servers. > > > Surely its the other way round: i.e. new requirements on all TLS servers have to be made clear? > > > I'm not sure what you mean. This document does not get to require that all TLS servers do CT. Was that your intent? > > > What I meant is that if every time you mention a thing you have to say "but only if you are conforming to this RFC" then you a) make the whole thing a lot more > cumbersome, b) are stating the obvious (i.e. that you only have to conform to the RFC if you have decided to conform to the RFC). > > > I don't think it's merely stating the obvious in that we have *other* RFCs which actually do attempt to retrospectively impose requirements on all uses of TLS. See, for > instance: https://tools.ietf.org/html/rfc7465. And this is a different story, in that we are not (I assume) going to go around saying that TLS stacks that don't do CT are not > TLS conformant. > > I think the text I would use here would be "CT-using TLS servers MUST..." > > > Surely if you are making a new requirement for TLS compliance then you have to explicitly say so? > > > Well, my point is that the way that this document is written in fact does so, and so you have to look at "Updates" to find out that that's not the case. > > -Ekr >   >   > >   > > -EKr > > > > Line 1595 >    been struck off for misbehavior, has had a key compromise, or is not >    known to the TLS client).  For example: > Maybe replace "For example:" with "Some ways this can happen are..." > > > Line 1599 >       misissuance from clients.  Including SCTs from different logs >       makes it more difficult to mount this attack. > Assuming that the server is malicious, why would it include multiple SCTs? It seems like requiring multiple SCTs does in fact provide this defense, > but that's not an argument for servers to provide multiples. > > > Line 1627 >              SerializedTransItem trans_item_list<1..2^16-1>; >          } TransItemList; > Structurally, it's kind of a mess to have this be the place that you make TransItems self-contained (by having a defined length field). What about > other places I might want to concatenate TransItems. Why don't you instead make TransItem self-contained, like so: > > struct { >           VersionedTransType versioned_type; >           uint16 length;   // NEW >           select (versioned_type) { >               case x509_entry_v2: TimestampedCertificateEntryDataV2; >               case precert_entry_v2: TimestampedCertificateEntryDataV2; >               case x509_sct_v2: SignedCertificateTimestampDataV2; >               case precert_sct_v2: SignedCertificateTimestampDataV2; >               case signed_tree_head_v2: SignedTreeHeadDataV2; >               case consistency_proof_v2: ConsistencyProofDataV2; >               case inclusion_proof_v2: InclusionProofDataV2; >           } data; >       } TransItem; > This is pretty much the universal TLS convention. > > > Line 1649 > 6.4.  transparency_info TLS Extension > This extension appears not to have any explicit support for CT entries for intermediate certs. Am I just supposed to glue together all the TransItems? > > > Line 1651 >    Provided that a TLS client includes the "transparency_info" extension >    type in the ClientHello, the TLS server SHOULD include the > You need to provide an actual definition of what the client includes, and having the server ignore the contents is bad mojo. TLS convention is for the > client to include an empty extension and the server to validate that it is in fact empty. > > > Line 1654 >    "transparency_info" extension in the ServerHello with >    "extension_data" set to a "TransItemList".  The TLS server SHOULD >    ignore any "extension_data" sent by the TLS client.  Additionally, > IMPORTANT: The normative language here is kind of confusing. It SHOULD include the extension but if it's included, it MUST consist of TransItemList, > no? And surely only SHOU > Also, I'm not sure this is the right logic. If the server knows that it has the SCT information in the certificate or in OCSP, why SHOULD It send this > extension. I would think, rather that servers should aim to send information at most once, so that it should only send the extension if it contains > information that's not in the cert/OCSP. as it pretty much has to send those anyway. Otherwise, don't we just end up in a world where if this info is > in OCSP and certs, it's always sent twice, because the client doesn't know where the info is, and so has to always offer the extension. > > > Line 1658 >    session is resumed, since session resumption uses the original >    session information. > Does this mean the client MUST abort the handshake if the server includes it? > > > Line 1668 >    o  The TLS client includes the "transparency_info" extension type in >       the ClientHello. > This condition is non-sensical, because if the client *doesn't* include the extension, the server cannot send the transparency_info extension at all. > > > Line 1722 > 8.  Clients > Given the imminent standardization of TLS 1.3, you need to somehow provide a mapping for client-side CT for that, I think > > > Line 1739 >    view.  The exact mechanisms will be in separate documents, but it is >    expected there will be a variety. > Given the somewhat science fictional status of Gossip, this entire paragraph should be stricken > > > Line 1747 >    MUST implement all of the three mechanisms by which TLS servers may >    present SCTs (see Section 6).  TLS clients MAY also accept SCTs via >    the "status_request_v2" extension ([RFC6961]).  TLS clients that > IMPORTANT: This also needs to be rewritten so it makes clear it's not a general levy on TLS clients. > > Line 1770 >    In addition to normal validation of the server certificate and its >    chain, TLS clients SHOULD validate each received SCT for which they >    have the corresponding log's parameters.  To validate an SCT, a TLS > IMPORTANT: Why is this a SHOULD and not a MUST? If you support CT at all, why would you not do this? > > Line 1791 >    TLS clients MUST NOT consider valid any SCT whose timestamp is in the >    future. > What's the reason for this? If your clock is slightly wrong, this is going to cause new certs to fail even if they otherwise would have succeeded > (because the notBefore and notAfter are more conservative). > > > Line 1800 >    will disclose to the log which TLS server the client has been >    communicating with. > IMPORTANT: This "Note" just mentions in passing a huge privacy issue. You need to be a lot clearer about this. > > Line 1823 >    "transparency_info" and "status_request" TLS extensions in the >    ClientHello. > IMPORTANT: This is not consistent with the requirements on the server. > Trying to reconstruct the reasoning here, the client can only decide that the server is noncompliant if it has given the server a chance to send the > SCTs by every mechanism., otherwise the server might just want to send the SCT some other way. However, if servers can optionally ignore > transparency_info (it's a SHOULD above), then you can have two compliant implementations with the server having a CT-compliant cert and yet the client > declares it noncompliant. To fix this, you need to require the server to respond to "transparency_info" > > > Line 1831 >    "CachedObject" of type "ct_compliant" in the "cached_info" extension. >    The "hash_value" field MUST be 1 byte long with the value 0. > You should explain why this is one byte long (that the PDU is defined as having a minimum length of 1). Also the server should be required to check > it. > > > Line 1842 >    watches.  It may also want to keep copies of entire logs.  In order >    to do this, it should follow these steps for each log: > Why is this not a 2119 SHOULD? > > Also, what does "in order to do this" refer to? Clearly not how to keep copies.... Presumably, how to poll the log. > > > Line 1864 >    8.  Either: > IMPORTANT: You seem to be missing there part where you actually look at the entries to verify that they don't contain bogus data (e.g., certificates > for your domain). I get that it's implicit here, but given that you provide an algorithm, that should be an explicit stage. > This is a pretty odd algorithm. If I understand it correctly, 1-4 are setup steps and then 5-9 is supposed to be repeated, but I could just do this > once and stop at 4. > > > Line 1912 >    STHs it receives, ensure that each entry can be fetched and that the >    STH is indeed the result of making a tree from all fetched entries. > IMPORTANT: How do you verify MMD? > > Line 1944 >    If it should become necessary to deprecate an algorithm used by a >    live log, then the log should be frozen as specified in Section 4.13 >    and a new log should be started.  Certificates in the frozen log that > RFC 2119 SHOULD? Isn't this a MUST, though? > > > Line 1958 >    "transparency_info" TLS extension.  IANA should update this extension >    type to point at this document. > IMPORTANT: You'll need to fill in the new field specified in https://tlswg.github.io/draft-ietf-tls-iana-registry-updates/#rfc.section.6 > > Line 2009 >    |                                | ECDSA (NIST P-256) |             | >    |                                | with HMAC-SHA256   |             | >    |                                |                    |             | > Why are you defining both algorithms? > > > Line 2150 >    (with the intention of actually running a CT log that will be >    identified by the allocated Log ID). > This seems like it's not a great thing to be asking an expert to do, as it seems to require business arrangements. Is it really that valuable to save > a few bytes here? > > > Line 2163 >    that the log has misbehaved, which will be discovered when the SCT is >    audited.  A signed timestamp is not a guarantee that the certificate >    is not misissued, since appropriate monitors might not have checked > IMPORTANT: This is not correct, because the client does not know that the monitors are verifying the data that it is. See my general comments on > public verifiability above. > > Line 2182 >    operating correctly.  As a log is allowed to serve an STH that's up >    to MMD old, the maximum period of time during which a misissued >    certificate can be used without being available for audit is twice > Nit: up to the MMD old > > > Line 2211 >    compute the proofs from the log) or communicate with the log via >    proxies. > This also seems quite handwavy in light of the facts on the ground. > > > Line 2237 >       and STHs can be stored by the log and served to other clients that >       submit the same certificate or request the same STH. > This needs to be expanded. Who is this risk against? The log or someone else? If the log, what's the logs incentive? > > > Line 2243 >    reduce the effectiveness of an attack where a CA and a log collude >    (see Section 6.1). > See my comments in 6.1 about this. > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > > > > From nobody Thu Apr 19 16:47:28 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58551126D0C for ; Thu, 19 Apr 2018 16:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 sgGoHbwd0rEu for ; Thu, 19 Apr 2018 16:47:23 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 BA699126CE8 for ; Thu, 19 Apr 2018 16:47:22 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id e23-v6so6486781oiy.1 for ; Thu, 19 Apr 2018 16:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ifY91rVcZDXU4yIytHOmz1EDhD88565x0QlqzIgZl7w=; b=Wg9bI1FDiqMSvQCn/dWd5YNKLqsCkASD1Yl5grlO+mhdOGoRl0hD38cntsaguY0nxo N5g5gBYHBvOt1zihCtWnbVTo8c4vIBLGrS2FLvME8+12V0QciAdYwRLvrYoWXftsKl7R cecS7BdH/Tzedb/9IdOPVEuARhvxLPvG2gAx2KC/F0v6qAsYOIpeZU8ckTV9QoqGB0tS QNfFo/9EnNaQIHpibEJjRejOpvXDfNdwJuHkp7pvkK4mo18G2aSdKnMnvluu1iAj4Z7R 2dfnbjTOFu1hVsoaqo5gClUL/GcuBBmMF4oY62eIzJRnpVazT+kDO0Efgyb/Y+0OgEUV T/aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ifY91rVcZDXU4yIytHOmz1EDhD88565x0QlqzIgZl7w=; b=c4VqUPYWahJSurSVb8DJYsGQE10du3rx2imaRyMxXdU0NrkEfT6NnIk4gxbcjJmLJd M/7gSZuGPZQn7zQlkymbPZtPqLhbqpVYlbmVMeKKFE5v8Nyk91VHbsymVLWquPaGq17N SSC4mbZrFuddo1kPw/7JMlntFtyHACEG9ErmdZKJ5IQidCp9hSxs2g8VrRs3KBHbIYzJ 5V5upLuMPgbK1p/M76rzQH/N1qahfZTXbutVTnnOOiuq6QBFL9Ab3n7dH/fYRm2zCSOQ Djz7FcRSwZRwbq3eby5sfRQIOBTHunu1LDqfyoJIDxSgwUPzBnrBnLAOrkBwq+mEm+IL Bv3w== X-Gm-Message-State: ALQs6tAvWpFHRLPDND01g3o9RHbcWSQZxny9md6RZh2fxS423nHDdy1y xKClH4W283lWU9K8XabZoc/iFg/a1TmOEDiOXUcXVcnQ X-Google-Smtp-Source: AIpwx49bitHR4vBzOfFI97IFa/2bXC7fDC9GFQtPPGJ6WVY2Qn1oyV1oW92gqnnTDP7U9GLHZelVaEehLryyxxJrtqU= X-Received: by 2002:aca:c744:: with SMTP id x65-v6mr4684268oif.43.1524181641997; Thu, 19 Apr 2018 16:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 19 Apr 2018 16:46:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 19 Apr 2018 16:46:41 -0700 Message-ID: To: Paul Wouters Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="000000000000584344056a3c3164" Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 23:47:27 -0000 --000000000000584344056a3c3164 Content-Type: text/plain; charset="UTF-8" Hi Paul, I still have to review this. Will try to do so in the next week or so -Ekr On Thu, Apr 19, 2018 at 6:30 AM, Paul Wouters wrote: > On Thu, 7 Sep 2017, Eric Rescorla wrote: > > Eric, > > Are all your concerns raised in the AD review met by version -28 ? > > The diff since your last review: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962 > -bis-28.txt&url1=draft-ietf-trans-rfc6962-bis-26.txt > > Paul > > Date: Thu, 7 Sep 2017 10:41:45 >> From: Eric Rescorla >> Cc: "trans@ietf.org" >> To: Ben Laurie >> Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt >> >> >> >> >> On Thu, Sep 7, 2017 at 3:24 AM, Ben Laurie wrote: >> >> >> On 5 September 2017 at 18:46, Eric Rescorla wrote: >> >> >> On Tue, Sep 5, 2017 at 9:04 AM, Ben Laurie >> wrote: >> >> >> On 4 September 2017 at 00:17, Eric Rescorla < >> ekr@rtfm.com> wrote: >> Hi folks, >> >> Please find enclosed the first cut of my AD review of this draft. >> >> Note: the original of this review is on Phabricator at: >> >> https://mozphab-ietf.devsvcdev.mozaws.net/D13 >> >> If you want to see comments in context -- which is a lot easier -- you >> can go there. Also, you can create an account and respond inline if >> you like. If you elect to, let me know if you run into problems. >> >> -Ekr >> >> >> Note: I have not yet reviewed the algorithms in S 2.1. I plan to do >> that separately, but figured it would be useful to provide the rest of >> my review on the assumption that the changes to that section will be >> modest if any. >> >> >> High-Level: >> >> 1. This document makes a variety of claims about the assurances that >> clients get that only obtain if some as-yet-to-be-specified >> third-party verifiability mechanism is implemented. For instance, in >> the intro: >> >> Certificate Transparency aims to mitigate the problem of misissued >> certificates by providing append-only logs of issued certificates. >> The logs do not need to be trusted because they are publicly >> auditable. >> >> >> As the extensive discussion following Richard Barnes's and my previous >> comments should make clear, this is only a property of CT if you also >> have some mechanism for third-party verifiability of STHs, and this >> document does not supply that. In the actually deployed -- we can >> debate deployable separately the deployability of some of the >> proposals for how to get this-- versions of CT, what clients get is >> SCTs, which are effectively countersignatures and in fact do require >> trusting the logs. This is implicitly acknowledged by proposals that >> RPs only accept certificates with >1 SCT. >> >> >> The purpose of multiple SCTs is to avoid the death of a single log >> causing the death of a large number of certificates. It is not about trust. >> >> >> That seems like the reason for the server to offer it, but not for the >> client to require it. >> >> Line 763 >> Maximum Chain Length: The longest chain submission the log is >> willing to accept, if the log chose to limit it. >> Nit: chooses >> >> >> Past tense seems correct? >> >> >> I'm willing to dert this to the RFC Editor. >> >> >> >> >> Line 785 >> accepted trust anchor, using only the chain of intermediate CA >> certificates provided by the submitter. >> Why is this a 2119 MUST? It seems wise, but not necessarily a conformance >> requirement >> >> >> "To avoid being overloaded by invalid submissions" >> >> >> There seem like one way to prevent this, but not the only one. >> >> >> Line 816 >> anchor used to verify the chain (even if it was omitted from the >> submission). The log MUST present this chain for auditing upon >> request (see Section 5.6). This prevents the CA from avoiding blame >> What happens in cases of multiple chains. For instance, say that the >> submitter provides superfluous certificates? >> >> >> Not allowed. >> >> >> Hmm... So your theory is that the submitter does path construction >> >> >> Yep - and that's borne out by practice. >> >> >> OK, well, then it would help if the document were clearer on this point. >> >> >> >> >> >> Line 837 >> opaque LogID<2..127>; >> This seems to be the first use of the TLS specification language, but I >> don't see a cite. Please provide one, >> >> >> See s1.2. >> >> >> OK. Thanks. >> >> >> >> Line 926 >> opaque TBSCertificate<1..2^24-1>; >> NIT: there's no actual way a TBSCertificate can be 1 byte. >> >> >> Line 948 >> "tbs_certificate". The length of the "issuer_key_hash" MUST match >> HASH_SIZE. >> Is this true? What happens if we have two CAs that share a key? >> >> >> Eh? >> >> >> Say that a CA spins up two subordinates that happen to share the same >> key. I agree it's foolish. >> return an empty >> >> >> >> Line 1522 >> permissible. These entries SHALL be sequential beginning with the >> entry specified by "start". >> How does the client know which of the above two cases has occurred? >> >> >> The response includes an STH, which says how big the tree is. Probably >> should be the latest one known to that server. >> >> >> >> Line 1552 >> TLS servers MUST use at least one of the three mechanisms listed >> below to present one or more SCTs from one or more logs to each TLS >> This needs to somehow be clear that it only applies to TLS servers that >> are compliant with this specification, as it's not a new requirement on all >> TLS servers. >> >> >> Surely its the other way round: i.e. new requirements on all TLS servers >> have to be made clear? >> >> >> I'm not sure what you mean. This document does not get to require that >> all TLS servers do CT. Was that your intent? >> >> >> What I meant is that if every time you mention a thing you have to say >> "but only if you are conforming to this RFC" then you a) make the whole >> thing a lot more >> cumbersome, b) are stating the obvious (i.e. that you only have to >> conform to the RFC if you have decided to conform to the RFC). >> >> >> I don't think it's merely stating the obvious in that we have *other* >> RFCs which actually do attempt to retrospectively impose requirements on >> all uses of TLS. See, for >> instance: https://tools.ietf.org/html/rfc7465. And this is a different >> story, in that we are not (I assume) going to go around saying that TLS >> stacks that don't do CT are not >> TLS conformant. >> >> I think the text I would use here would be "CT-using TLS servers MUST..." >> >> >> Surely if you are making a new requirement for TLS compliance then >> you have to explicitly say so? >> >> >> Well, my point is that the way that this document is written in fact does >> so, and so you have to look at "Updates" to find out that that's not the >> case. >> >> -Ekr >> >> >> >> >> >> -EKr >> >> >> >> Line 1595 >> been struck off for misbehavior, has had a key compromise, or is not >> known to the TLS client). For example: >> Maybe replace "For example:" with "Some ways this can happen are..." >> >> >> Line 1599 >> misissuance from clients. Including SCTs from different logs >> makes it more difficult to mount this attack. >> Assuming that the server is malicious, why would it include multiple >> SCTs? It seems like requiring multiple SCTs does in fact provide this >> defense, >> but that's not an argument for servers to provide multiples. >> >> >> Line 1627 >> SerializedTransItem trans_item_list<1..2^16-1>; >> } TransItemList; >> Structurally, it's kind of a mess to have this be the place that you make >> TransItems self-contained (by having a defined length field). What about >> other places I might want to concatenate TransItems. Why don't you >> instead make TransItem self-contained, like so: >> >> struct { >> VersionedTransType versioned_type; >> uint16 length; // NEW >> select (versioned_type) { >> case x509_entry_v2: TimestampedCertificateEntryDataV2; >> case precert_entry_v2: TimestampedCertificateEntryDataV2; >> case x509_sct_v2: SignedCertificateTimestampDataV2; >> case precert_sct_v2: SignedCertificateTimestampDataV2; >> case signed_tree_head_v2: SignedTreeHeadDataV2; >> case consistency_proof_v2: ConsistencyProofDataV2; >> case inclusion_proof_v2: InclusionProofDataV2; >> } data; >> } TransItem; >> This is pretty much the universal TLS convention. >> >> >> Line 1649 >> 6.4. transparency_info TLS Extension >> This extension appears not to have any explicit support for CT entries >> for intermediate certs. Am I just supposed to glue together all the >> TransItems? >> >> >> Line 1651 >> Provided that a TLS client includes the "transparency_info" extension >> type in the ClientHello, the TLS server SHOULD include the >> You need to provide an actual definition of what the client includes, and >> having the server ignore the contents is bad mojo. TLS convention is for the >> client to include an empty extension and the server to validate that it >> is in fact empty. >> >> >> Line 1654 >> "transparency_info" extension in the ServerHello with >> "extension_data" set to a "TransItemList". The TLS server SHOULD >> ignore any "extension_data" sent by the TLS client. Additionally, >> IMPORTANT: The normative language here is kind of confusing. It SHOULD >> include the extension but if it's included, it MUST consist of >> TransItemList, >> no? And surely only SHOU >> Also, I'm not sure this is the right logic. If the server knows that it >> has the SCT information in the certificate or in OCSP, why SHOULD It send >> this >> extension. I would think, rather that servers should aim to send >> information at most once, so that it should only send the extension if it >> contains >> information that's not in the cert/OCSP. as it pretty much has to send >> those anyway. Otherwise, don't we just end up in a world where if this info >> is >> in OCSP and certs, it's always sent twice, because the client doesn't >> know where the info is, and so has to always offer the extension. >> >> >> Line 1658 >> session is resumed, since session resumption uses the original >> session information. >> Does this mean the client MUST abort the handshake if the server includes >> it? >> >> >> Line 1668 >> o The TLS client includes the "transparency_info" extension type in >> the ClientHello. >> This condition is non-sensical, because if the client *doesn't* include >> the extension, the server cannot send the transparency_info extension at >> all. >> >> >> Line 1722 >> 8. Clients >> Given the imminent standardization of TLS 1.3, you need to somehow >> provide a mapping for client-side CT for that, I think >> >> >> Line 1739 >> view. The exact mechanisms will be in separate documents, but it is >> expected there will be a variety. >> Given the somewhat science fictional status of Gossip, this entire >> paragraph should be stricken >> >> >> Line 1747 >> MUST implement all of the three mechanisms by which TLS servers may >> present SCTs (see Section 6). TLS clients MAY also accept SCTs via >> the "status_request_v2" extension ([RFC6961]). TLS clients that >> IMPORTANT: This also needs to be rewritten so it makes clear it's not a >> general levy on TLS clients. >> >> Line 1770 >> In addition to normal validation of the server certificate and its >> chain, TLS clients SHOULD validate each received SCT for which they >> have the corresponding log's parameters. To validate an SCT, a TLS >> IMPORTANT: Why is this a SHOULD and not a MUST? If you support CT at all, >> why would you not do this? >> >> Line 1791 >> TLS clients MUST NOT consider valid any SCT whose timestamp is in the >> future. >> What's the reason for this? If your clock is slightly wrong, this is >> going to cause new certs to fail even if they otherwise would have succeeded >> (because the notBefore and notAfter are more conservative). >> >> >> Line 1800 >> will disclose to the log which TLS server the client has been >> communicating with. >> IMPORTANT: This "Note" just mentions in passing a huge privacy issue. You >> need to be a lot clearer about this. >> >> Line 1823 >> "transparency_info" and "status_request" TLS extensions in the >> ClientHello. >> IMPORTANT: This is not consistent with the requirements on the server. >> Trying to reconstruct the reasoning here, the client can only decide that >> the server is noncompliant if it has given the server a chance to send the >> SCTs by every mechanism., otherwise the server might just want to send >> the SCT some other way. However, if servers can optionally ignore >> transparency_info (it's a SHOULD above), then you can have two compliant >> implementations with the server having a CT-compliant cert and yet the >> client >> declares it noncompliant. To fix this, you need to require the server to >> respond to "transparency_info" >> >> >> Line 1831 >> "CachedObject" of type "ct_compliant" in the "cached_info" extension. >> The "hash_value" field MUST be 1 byte long with the value 0. >> You should explain why this is one byte long (that the PDU is defined as >> having a minimum length of 1). Also the server should be required to check >> it. >> >> >> Line 1842 >> watches. It may also want to keep copies of entire logs. In order >> to do this, it should follow these steps for each log: >> Why is this not a 2119 SHOULD? >> >> Also, what does "in order to do this" refer to? Clearly not how to keep >> copies.... Presumably, how to poll the log. >> >> >> Line 1864 >> 8. Either: >> IMPORTANT: You seem to be missing there part where you actually look at >> the entries to verify that they don't contain bogus data (e.g., certificates >> for your domain). I get that it's implicit here, but given that you >> provide an algorithm, that should be an explicit stage. >> This is a pretty odd algorithm. If I understand it correctly, 1-4 are >> setup steps and then 5-9 is supposed to be repeated, but I could just do >> this >> once and stop at 4. >> >> >> Line 1912 >> STHs it receives, ensure that each entry can be fetched and that the >> STH is indeed the result of making a tree from all fetched entries. >> IMPORTANT: How do you verify MMD? >> >> Line 1944 >> If it should become necessary to deprecate an algorithm used by a >> live log, then the log should be frozen as specified in Section 4.13 >> and a new log should be started. Certificates in the frozen log that >> RFC 2119 SHOULD? Isn't this a MUST, though? >> >> >> Line 1958 >> "transparency_info" TLS extension. IANA should update this extension >> type to point at this document. >> IMPORTANT: You'll need to fill in the new field specified in >> https://tlswg.github.io/draft-ietf-tls-iana-registry-updates >> /#rfc.section.6 >> >> Line 2009 >> | | ECDSA (NIST P-256) | | >> | | with HMAC-SHA256 | | >> | | | | >> Why are you defining both algorithms? >> >> >> Line 2150 >> (with the intention of actually running a CT log that will be >> identified by the allocated Log ID). >> This seems like it's not a great thing to be asking an expert to do, as >> it seems to require business arrangements. Is it really that valuable to >> save >> a few bytes here? >> >> >> Line 2163 >> that the log has misbehaved, which will be discovered when the SCT is >> audited. A signed timestamp is not a guarantee that the certificate >> is not misissued, since appropriate monitors might not have checked >> IMPORTANT: This is not correct, because the client does not know that the >> monitors are verifying the data that it is. See my general comments on >> public verifiability above. >> >> Line 2182 >> operating correctly. As a log is allowed to serve an STH that's up >> to MMD old, the maximum period of time during which a misissued >> certificate can be used without being available for audit is twice >> Nit: up to the MMD old >> >> >> Line 2211 >> compute the proofs from the log) or communicate with the log via >> proxies. >> This also seems quite handwavy in light of the facts on the ground. >> >> >> Line 2237 >> and STHs can be stored by the log and served to other clients that >> submit the same certificate or request the same STH. >> This needs to be expanded. Who is this risk against? The log or someone >> else? If the log, what's the logs incentive? >> >> >> Line 2243 >> reduce the effectiveness of an attack where a CA and a log collude >> (see Section 6.1). >> See my comments in 6.1 about this. >> >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> >> >> >> >> >> >> --000000000000584344056a3c3164 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

I still have to rev= iew this. Will try to do so in the next week or so

-Ekr


On Thu, Apr 19, 2018 at 6:30 AM, Paul Wouters <paul@nohats.c= a> wrote:
On Thu, 7 Sep 201= 7, Eric Rescorla wrote:

Eric,

Are all your concerns raised in the AD review met by version -28 ?

The diff since your last review:

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-t= rans-rfc6962-bis-28.txt&url1=3Ddraft-ietf-trans-rfc6962-bis-2= 6.txt

Paul

Date: Thu, 7 Sep 2017 10:41:45
From: Eric Rescorla <e= kr@rtfm.com>
Cc: "trans@ietf.or= g" <trans@i= etf.org>
To: Ben Laurie <ben= l@google.com>
Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt




On Thu, Sep 7, 2017 at 3:24 AM, Ben Laurie <benl@google.com> wrote:


=C2=A0 =C2=A0 =C2=A0 On 5 September 2017 at 18:46, Eric Rescorla <ekr@rtfm.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Sep 5, 2017 at 9:04 AM, B= en Laurie <benl@goo= gle.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 4 Septemb= er 2017 at 00:17, Eric Rescorla <ekr@rtfm.com> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Hi folks,

Please find enclosed the first cut of my AD review of this draft.

Note: the original of this review is on Phabricator at:

=C2=A0 https://mozphab-ietf.devsvcdev.mozaws.net/D= 13

If you want to see comments in context -- which is a lot easier -- you
can go there. Also, you can create an account and respond inline if
you like.=C2=A0 If you elect to, let me know if you run into problems.

-Ekr


Note: I have not yet reviewed the algorithms in S 2.1. I plan to do
that separately, but figured it would be useful to provide the rest of
my review on the assumption that the changes to that section will be
modest if any.


High-Level:

1. This document makes a variety of claims about the assurances that
clients get that only obtain if some as-yet-to-be-specified
third-party verifiability mechanism is implemented. For instance, in
the intro:

=C2=A0 Certificate Transparency aims to mitigate the problem of misissued =C2=A0 certificates by providing append-only logs of issued certificates. =C2=A0 The logs do not need to be trusted because they are publicly
=C2=A0 auditable.


As the extensive discussion following Richard Barnes's and my previous<= br> comments should make clear, this is only a property of CT if you also
have some mechanism for third-party verifiability of STHs, and this
document does not supply that. In the actually deployed -- we can
debate deployable separately the deployability of some of the
proposals for how to get this-- versions of CT, what clients get is
SCTs, which are effectively countersignatures and in fact do require
trusting the logs. This is implicitly acknowledged by proposals that
RPs only accept certificates with >1 SCT.


The purpose of multiple SCTs is to avoid the death of a single log causing = the death of a large number of certificates. It is not about trust.


That seems like the reason for the server to offer it, but not for the clie= nt to require it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Line 763
=C2=A0 =C2=A0Maximum Chain Length: =C2=A0The longest chain submission the l= og is
=C2=A0 =C2=A0 =C2=A0 willing to accept, if the log chose to limit it.
Nit: chooses


Past tense seems correct?


I'm willing to dert this to the RFC Editor.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0


Line 785
=C2=A0 =C2=A0accepted trust anchor, using only the chain of intermediate CA=
=C2=A0 =C2=A0certificates provided by the submitter.
Why is this a 2119 MUST? It seems wise, but not necessarily a conformance r= equirement


"To avoid being overloaded by invalid submissions"


There seem like one way to prevent this, but not the only one.

=C2=A0
=C2=A0 =C2=A0 =C2=A0 Line 816
=C2=A0 =C2=A0anchor used to verify the chain (even if it was omitted from t= he
=C2=A0 =C2=A0submission).=C2=A0 The log MUST present this chain for auditin= g upon
=C2=A0 =C2=A0request (see Section 5.6).=C2=A0 This prevents the CA from avo= iding blame
What happens in cases of multiple chains. For instance, say that the submit= ter provides superfluous certificates?


Not allowed.


Hmm...=C2=A0 So your theory is that the submitter does path construction

Yep - and that's borne out by practice.


OK, well, then it would help if the document were clearer on this point.=C2= =A0

=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0


Line 837
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque LogID<2..127>;
This seems to be the first use of the TLS specification language, but I don= 't see a cite. Please provide one,


See s1.2.


OK. Thanks.=C2=A0

=C2=A0

Line 926
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaque TBSCertificate<1..2^24-1>;
NIT: there's no actual way a TBSCertificate can be 1 byte.


Line 948
=C2=A0 =C2=A0"tbs_certificate".=C2=A0 The length of the "iss= uer_key_hash" MUST match
=C2=A0 =C2=A0HASH_SIZE.
Is this true? What happens if we have two CAs that share a key?


Eh?


Say that a CA spins up two subordinates that happen to share the same key. = I agree it's foolish.
=C2=A0return an empty



Line 1522
=C2=A0 =C2=A0permissible.=C2=A0 These entries SHALL be sequential beginning= with the
=C2=A0 =C2=A0entry specified by "start".
How does the client know which of the above two cases has occurred?


The response includes an STH, which says how big the tree is. Probably shou= ld be the latest one known to that server.
=C2=A0


Line 1552
=C2=A0 =C2=A0TLS servers MUST use at least one of the three mechanisms list= ed
=C2=A0 =C2=A0below to present one or more SCTs from one or more logs to eac= h TLS
This needs to somehow be clear that it only applies to TLS servers that are= compliant with this specification, as it's not a new requirement on al= l
TLS servers.


Surely its the other way round: i.e. new requirements on all TLS servers ha= ve to be made clear?


I'm not sure what you mean. This document does not get to require that = all TLS servers do CT. Was that your intent?


What I meant is that if every time you mention a thing you have to say &quo= t;but only if you are conforming to this RFC" then you a) make the who= le thing a lot more
cumbersome, b) are stating the obvious (i.e. that you only have to conform = to the RFC if you have decided to conform to the RFC).


I don't think it's merely stating the obvious in that we have *othe= r* RFCs which actually do attempt to retrospectively impose requirements on= all uses of TLS. See, for
instance:=C2=A0https://tools.ietf.org/html/rfc7465. And = this is a different story, in that we are not (I assume) going to go around= saying that TLS stacks that don't do CT are not
TLS conformant.

I think the text I would use here would be "CT-using TLS servers MUST.= .."


=C2=A0 =C2=A0 =C2=A0 Surely if you are making a new requirement for TLS com= pliance then you have to explicitly say so?


Well, my point is that the way that this document is written in fact does s= o, and so you have to look at "Updates" to find out that that'= ;s not the case.

-Ekr
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0

-EKr



Line 1595
=C2=A0 =C2=A0been struck off for misbehavior, has had a key compromise, or = is not
=C2=A0 =C2=A0known to the TLS client).=C2=A0 For example:
Maybe replace "For example:" with "Some ways this can happen= are..."


Line 1599
=C2=A0 =C2=A0 =C2=A0 misissuance from clients.=C2=A0 Including SCTs from di= fferent logs
=C2=A0 =C2=A0 =C2=A0 makes it more difficult to mount this attack.
Assuming that the server is malicious, why would it include multiple SCTs? = It seems like requiring multiple SCTs does in fact provide this defense, but that's not an argument for servers to provide multiples.


Line 1627
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SerializedTransItem trans_i= tem_list<1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} TransItemList;
Structurally, it's kind of a mess to have this be the place that you ma= ke TransItems self-contained (by having a defined length field). What about=
other places I might want to concatenate TransItems. Why don't you inst= ead make TransItem self-contained, like so:

struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VersionedTransType versioned_type;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16 length; =C2=A0 // NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select (versioned_type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case x509_entry_v2: Timest= ampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_entry_v2: Tim= estampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case x509_sct_v2: SignedCe= rtificateTimestampDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_sct_v2: Signe= dCertificateTimestampDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case signed_tree_head_v2: = SignedTreeHeadDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case consistency_proof_v2:= ConsistencyProofDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case inclusion_proof_v2: I= nclusionProofDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } data;
=C2=A0 =C2=A0 =C2=A0 } TransItem;
This is pretty much the universal TLS convention.


Line 1649
6.4. =C2=A0transparency_info TLS Extension
This extension appears not to have any explicit support for CT entries for = intermediate certs. Am I just supposed to glue together all the TransItems?=


Line 1651
=C2=A0 =C2=A0Provided that a TLS client includes the "transparency_inf= o" extension
=C2=A0 =C2=A0type in the ClientHello, the TLS server SHOULD include the
You need to provide an actual definition of what the client includes, and h= aving the server ignore the contents is bad mojo. TLS convention is for the=
client to include an empty extension and the server to validate that it is = in fact empty.


Line 1654
=C2=A0 =C2=A0"transparency_info" extension in the ServerHello wit= h
=C2=A0 =C2=A0"extension_data" set to a "TransItemList".= =C2=A0 The TLS server SHOULD
=C2=A0 =C2=A0ignore any "extension_data" sent by the TLS client.= =C2=A0 Additionally,
IMPORTANT: The normative language here is kind of confusing. It SHOULD incl= ude the extension but if it's included, it MUST consist of TransItemLis= t,
no? And surely only SHOU
Also, I'm not sure this is the right logic. If the server knows that it= has the SCT information in the certificate or in OCSP, why SHOULD It send = this
extension. I would think, rather that servers should aim to send informatio= n at most once, so that it should only send the extension if it contains information that's not in the cert/OCSP. as it pretty much has to send = those anyway. Otherwise, don't we just end up in a world where if this = info is
in OCSP and certs, it's always sent twice, because the client doesn'= ;t know where the info is, and so has to always offer the extension.


Line 1658
=C2=A0 =C2=A0session is resumed, since session resumption uses the original=
=C2=A0 =C2=A0session information.
Does this mean the client MUST abort the handshake if the server includes i= t?


Line 1668
=C2=A0 =C2=A0o =C2=A0The TLS client includes the "transparency_info&qu= ot; extension type in
=C2=A0 =C2=A0 =C2=A0 the ClientHello.
This condition is non-sensical, because if the client *doesn't* include= the extension, the server cannot send the transparency_info extension at a= ll.


Line 1722
8.=C2=A0 Clients
Given the imminent standardization of TLS 1.3, you need to somehow provide = a mapping for client-side CT for that, I think


Line 1739
=C2=A0 =C2=A0view.=C2=A0 The exact mechanisms will be in separate documents= , but it is
=C2=A0 =C2=A0expected there will be a variety.
Given the somewhat science fictional status of Gossip, this entire paragrap= h should be stricken


Line 1747
=C2=A0 =C2=A0MUST implement all of the three mechanisms by which TLS server= s may
=C2=A0 =C2=A0present SCTs (see Section 6).=C2=A0 TLS clients MAY also accep= t SCTs via
=C2=A0 =C2=A0the "status_request_v2" extension ([RFC6961]).=C2=A0= TLS clients that
IMPORTANT: This also needs to be rewritten so it makes clear it's not a= general levy on TLS clients.

Line 1770
=C2=A0 =C2=A0In addition to normal validation of the server certificate and= its
=C2=A0 =C2=A0chain, TLS clients SHOULD validate each received SCT for which= they
=C2=A0 =C2=A0have the corresponding log's parameters.=C2=A0 To validate= an SCT, a TLS
IMPORTANT: Why is this a SHOULD and not a MUST? If you support CT at all, w= hy would you not do this?

Line 1791
=C2=A0 =C2=A0TLS clients MUST NOT consider valid any SCT whose timestamp is= in the
=C2=A0 =C2=A0future.
What's the reason for this? If your clock is slightly wrong, this is go= ing to cause new certs to fail even if they otherwise would have succeeded<= br> (because the notBefore and notAfter are more conservative).


Line 1800
=C2=A0 =C2=A0will disclose to the log which TLS server the client has been<= br> =C2=A0 =C2=A0communicating with.
IMPORTANT: This "Note" just mentions in passing a huge privacy is= sue. You need to be a lot clearer about this.

Line 1823
=C2=A0 =C2=A0"transparency_info" and "status_request" T= LS extensions in the
=C2=A0 =C2=A0ClientHello.
IMPORTANT: This is not consistent with the requirements on the server.
Trying to reconstruct the reasoning here, the client can only decide that t= he server is noncompliant if it has given the server a chance to send the SCTs by every mechanism., otherwise the server might just want to send the = SCT some other way. However, if servers can optionally ignore
transparency_info (it's a SHOULD above), then you can have two complian= t implementations with the server having a CT-compliant cert and yet the cl= ient
declares it noncompliant. To fix this, you need to require the server to re= spond to "transparency_info"


Line 1831
=C2=A0 =C2=A0"CachedObject" of type "ct_compliant" in t= he "cached_info" extension.
=C2=A0 =C2=A0The "hash_value" field MUST be 1 byte long with the = value 0.
You should explain why this is one byte long (that the PDU is defined as ha= ving a minimum length of 1). Also the server should be required to check it.


Line 1842
=C2=A0 =C2=A0watches.=C2=A0 It may also want to keep copies of entire logs.= =C2=A0 In order
=C2=A0 =C2=A0to do this, it should follow these steps for each log:
Why is this not a 2119 SHOULD?

Also, what does "in order to do this" refer to? Clearly not how t= o keep copies.... Presumably, how to poll the log.


Line 1864
=C2=A0 =C2=A08.=C2=A0 Either:
IMPORTANT: You seem to be missing there part where you actually look at the= entries to verify that they don't contain bogus data (e.g., certificat= es
for your domain). I get that it's implicit here, but given that you pro= vide an algorithm, that should be an explicit stage.
This is a pretty odd algorithm. If I understand it correctly, 1-4 are setup= steps and then 5-9 is supposed to be repeated, but I could just do this once and stop at 4.


Line 1912
=C2=A0 =C2=A0STHs it receives, ensure that each entry can be fetched and th= at the
=C2=A0 =C2=A0STH is indeed the result of making a tree from all fetched ent= ries.
IMPORTANT: How do you verify MMD?

Line 1944
=C2=A0 =C2=A0If it should become necessary to deprecate an algorithm used b= y a
=C2=A0 =C2=A0live log, then the log should be frozen as specified in Sectio= n 4.13
=C2=A0 =C2=A0and a new log should be started.=C2=A0 Certificates in the fro= zen log that
RFC 2119 SHOULD? Isn't this a MUST, though?


Line 1958
=C2=A0 =C2=A0"transparency_info" TLS extension.=C2=A0 IANA should= update this extension
=C2=A0 =C2=A0type to point at this document.
IMPORTANT: You'll need to fill in the new field specified in https://tlswg.github.io/draft-= ietf-tls-iana-registry-updates/#rfc.section.6

Line 2009
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ECDSA (NIST P-256) | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| with HMAC-SHA256 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
Why are you defining both algorithms?


Line 2150
=C2=A0 =C2=A0(with the intention of actually running a CT log that will be<= br> =C2=A0 =C2=A0identified by the allocated Log ID).
This seems like it's not a great thing to be asking an expert to do, as= it seems to require business arrangements. Is it really that valuable to s= ave
a few bytes here?


Line 2163
=C2=A0 =C2=A0that the log has misbehaved, which will be discovered when the= SCT is
=C2=A0 =C2=A0audited.=C2=A0 A signed timestamp is not a guarantee that the = certificate
=C2=A0 =C2=A0is not misissued, since appropriate monitors might not have ch= ecked
IMPORTANT: This is not correct, because the client does not know that the m= onitors are verifying the data that it is. See my general comments on
public verifiability above.

Line 2182
=C2=A0 =C2=A0operating correctly.=C2=A0 As a log is allowed to serve an STH= that's up
=C2=A0 =C2=A0to MMD old, the maximum period of time during which a misissue= d
=C2=A0 =C2=A0certificate can be used without being available for audit is t= wice
Nit: up to the MMD old


Line 2211
=C2=A0 =C2=A0compute the proofs from the log) or communicate with the log v= ia
=C2=A0 =C2=A0proxies.
This also seems quite handwavy in light of the facts on the ground.


Line 2237
=C2=A0 =C2=A0 =C2=A0 and STHs can be stored by the log and served to other = clients that
=C2=A0 =C2=A0 =C2=A0 submit the same certificate or request the same STH. This needs to be expanded. Who is this risk against? The log or someone els= e? If the log, what's the logs incentive?


Line 2243
=C2=A0 =C2=A0reduce the effectiveness of an attack where a CA and a log col= lude
=C2=A0 =C2=A0(see Section 6.1).
See my comments in 6.1 about this.


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








--000000000000584344056a3c3164-- From nobody Fri Apr 20 14:06:52 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0B12D885 for ; Fri, 20 Apr 2018 14:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td6w46lhkG5Q for ; Fri, 20 Apr 2018 14:06:47 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0055.outbound.protection.outlook.com [104.47.33.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D9F12D72F for ; Fri, 20 Apr 2018 14:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E9uzaujyAfSUhFm+XuSMxwbN8DI7Cd1PCyvdawjZseI=; b=SgP0vSmvetvZ8D2Q70zQORsSFduQDtZW8ICdraTx2S/nvnEu7Fimk/3KU/vI+eDV8MoFd0C8YcYnSn9RYLPoNTyPIfV8hydhedAPjr8kCBe2y6xkroefccssLpAawnCbkgb4ccVfynh4U5vyshWimvODKVGEPEFF/nDVbhLjVHM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rob@comodoca.com; Received: from [192.168.1.81] (51.6.119.163) by BLUPR17MB0292.namprd17.prod.outlook.com (2a01:111:e400:524f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.12; Fri, 20 Apr 2018 21:06:43 +0000 To: Eric Rescorla , Paul Wouters Cc: "trans@ietf.org" References: From: Rob Stradling Message-ID: <42df349d-fdc2-72ae-b42b-5cc2ce4d685d@ComodoCA.com> Date: Fri, 20 Apr 2018 22:06:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [51.6.119.163] X-ClientProxiedBy: DB6PR04CA0013.eurprd04.prod.outlook.com (2603:10a6:6::26) To BLUPR17MB0292.namprd17.prod.outlook.com (2a01:111:e400:524f::22) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:BLUPR17MB0292; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0292; 3:D5Y75eBvYi1nXvfMoooyJZ/X9H0ogM4DHgavYv9pXWU3o2wie1VAoufcwgjw4zvqcs+3/wWT3+xjdXPvTBMd2X8+NjQu0hPwMH9HM2wocxwQCU4A8FRLhKAJHuRUckaquqm1mwF9lDvYfBeUQSOFtmPahlq3CEqPB0t18a3rPjzAJowNqvvjzHEK6GPVGaL3m7BSjoKmX9aZ5kpn48596DIJxU/M0EruIz5dZhe20gjW8NuRX6s2TUtoAOQN+C1F; 25:Q7WHvJlnwW04M7XyR9puRSpUH7lyKUqRnMQH6GTokexiE6MHn8xjUhaGhxNlOKYmXUXAZvqGY9JAQfVoc0qwHxHihyUzmtnT15lTnNO6kP79jt89xhMZvTAYbfZ8iB3p8dlTu7raGdmLqyGVagF79pKCBZvrLyv0nxcWIGVbFhYMAGew8/5RRCCeFhAqRPhRNzsrJUmf8BkdBgG2AY+WUX08j0PxGbvb4fpuLB7Vb3xaeJpLs23HQY9XEDawCcUwJw4+fnYOiWguY/4lFm/G4rlJ1MytJWLfC3vMIbLY6OJwqZhR1riNBOaVyJbc+IntlCQZmCfprpgFzidEDkFFdw==; 31:lSKV6tLBeULLyAv5U8jwsgF9yi2UFwxOSYNoRNynAVZnoPjrpQoWC7FCHQPNu1VEqw5/T+Ifmr8bnlcjCKIrQYv9ALqMDGgHS2M9GK7nfi20/jhQzrhxX/hMALAAPcya5Y7zf8hXmBF78dlkVRzxiwQ6fAmwiYU4KLfT6oAcu4FkWgdmtqmkDrXsseDIbBZU50c4FTWa2tinu9xdi3K53JnSzvw9nkCsmzUe2pRTgjI= X-MS-TrafficTypeDiagnostic: BLUPR17MB0292: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089)(211936372134217)(153496737603132); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231232)(944501398)(52105095)(10201501046)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR17MB0292; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0292; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0292; 4:NpdXo+vcQBbU1mheSWBCxP5Zp75QO8WDgAM3BWMMot/uQp+93oeSCK0iCOKkCKtfW4AkT4nsrO0EWjqBMe7luz6TDDJh57dTQ7d1/5AsFhWtlq2QvSFUp1nLkK7JPHMtWzrMglLjoz3nN8G7hfjFMAGEjLAQMnHE9dGD/Ap+4KBE5KSLBQid64KXKAqUSBgKyeeucjtKJDn+5+yhE8egpk6EZq2/81DbBfcdd3Xm77PwLB7SBx8XFtR4Zhy40EtcCCTWCd51dq0OIh37LcCQH4sYWLJQvC8TjsrOrVoZH4hRmo8uqoXSzvrHZhupcgaMkBpfwo57QIGqXyT2z0t1xx/1H+1lrnkilAVbpnM2Ifir0OqZDUVERSWnU/1f6/eQaMFxncT19wK49UmheKTexqGDzIN4T2R0A58qBM92GFI= X-Forefront-PRVS: 0648FCFFA8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(39380400002)(39850400004)(366004)(346002)(376002)(252514010)(956004)(2906002)(11346002)(966005)(23676004)(2616005)(7736002)(50466002)(305945005)(65826007)(65806001)(446003)(52116002)(2486003)(59450400001)(76176011)(6666003)(52146003)(6306002)(6486002)(476003)(386003)(25786009)(4326008)(53546011)(229853002)(86362001)(2870700001)(110136005)(67846002)(58126008)(6116002)(117156002)(8676002)(478600001)(64126003)(3846002)(186003)(31686004)(16576012)(8936002)(31696002)(36756003)(47776003)(77096007)(316002)(81166006)(53936002)(5660300001)(16526019)(6246003)(66066001)(26005)(65956001)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR17MB0292; H:[192.168.1.81]; FPR:; SPF:None; LANG:en; MLV:nov; PTR:InfoNoRecords; Received-SPF: None (protection.outlook.com: comodoca.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjE3TUIwMjkyOzIzOlVWb200bHQxN3F5TXdPWDZFVzh3dG5JZDFk?= =?utf-8?B?QitnL3gwZkhDM04rQVF2MTRrUUtiNVU3NERwUFkvSTUrL3RiNG11cFBrcGpk?= =?utf-8?B?c2JRL04yT2V4R3FFY1p2c216Qk5ncUNGL3NJbnJtK24vaGNBS0pKUVA5bTly?= =?utf-8?B?ZkV4U21ZMlJjZFFQUjJGaUlkbDY1WFQxVklOaWhrdjVSUXI3SC82ZzNWZSt0?= =?utf-8?B?YVRIOTVYWnhKV2pHVjY2TW1TUCtkRHdkL3pXcnZQQ2lsZFlSOE5DZWxzRTFB?= =?utf-8?B?bHRmaXlLZmpwQU9iL2xwaW1PMUdSNnNPT2ppTHZhQ3BCWUQvV3FBWjM5dDAz?= =?utf-8?B?UHhYaTlLb0RaeldvbFlLVDEwZXlJTU9zZVVSWXFsU3cvNWJFb2VoRERVRkYw?= =?utf-8?B?S05GRXo3ZVpzeFlKWlZOQjR1SEZyWGYvMVJYTnBJWTQvSWNQam9GaWVQTVE0?= =?utf-8?B?TWZnQ1g4OCtlRnlEUDZXTXFuYmREeU80SFRySURJV1Y2ZVJuc0hCVnZXeEIz?= =?utf-8?B?SmkzT2tUN0IrV0ZNV2FGeDVmeDlDQjY0M2RESjMvU2tvdWR0V1ZxUmVXbFZY?= =?utf-8?B?bUFhMzJFaW1VSDVxRlM2NVZPVGxWYXVNV2t5UDllUTAweTRNZk5VQXBhZnR3?= =?utf-8?B?L1M4K1U2WDVtU1lhVDJQOS9KUmhmUklCbktuWWpxUG4vb2M1a3NOQ05tbnZo?= =?utf-8?B?UlczU0xaM1lyYXdBUTh3YkdsYzc5bHVMYWhVeW5GU1puVmhaQzJGdXJ0LzJy?= =?utf-8?B?enFWcWVYalN6b0VlcE1zZkEzb3ZVR1lWUEJ1N1NOSUpaZzB2Mi95UTdsWkYr?= =?utf-8?B?NkdTVGs1dVNybFIyRlh5OVdqZGRwSE4xaFg5WUMvcHZ2Nng3YkxrK0RJNnFk?= =?utf-8?B?cGlURW85aTVjc0pDTFBxMXdqbmpRT2djNzhOcE1FYVJ1WWsrV0RrbkEzUlJu?= =?utf-8?B?enRPRnpadFEvVUxNYXVkZkM2QkVqS2JJSHRwLzNOYjRCVWRiNXZRbWNhRWM4?= =?utf-8?B?TXVMOHRNUVBFYWZwYWd6Y1Q1WFpsdk01cVFyenkwdXhiTThTWmljc3FiYkQv?= =?utf-8?B?MHRHQTZjeXJielBqUmh2eGcrTUhLbm41VWZSem93d2FYa1BBY3NFUjBMNkJS?= =?utf-8?B?Rm0rOHgwTmtLRFU4VWpJNWgrdUY5eTAzQTl2d0Q0L3ljci9KSjlMSkdvcW9o?= =?utf-8?B?SFQxeC9ZRGpMajlLYlFWMW9HRFp2ODZUOTk4WXdZQ09yUDhHNWp2V2RJSG0x?= =?utf-8?B?UXlGbWtXdVlsUzA2N3RvYnlDckpXaXJWdmpCemZPTmgxRlRSQnRoY1lNdjBB?= =?utf-8?B?clZ1bUFUMXRkNStWWU1lWFhmMEd3bTZ6M1VudVNBZXBKSmVENVBEM05qME1i?= =?utf-8?B?cUdKaWhUSWcvNlRYaitmYWFvSmxvZlBkWU1NbjhKenBLOUR2QmdSbjBCYzdz?= =?utf-8?B?bmovMTlKYmRnQVh1N0s2VlpwMnhSN1Izb0M5L2VDWTVaRGYxVU4wTDVrYmQ1?= =?utf-8?B?cUhWaE56VkorYlcrOWhqQWcxZW9pK2VETmFoSjNqZFhyN2VuUzVGb0VIZm5W?= =?utf-8?B?TDg0QWxOQk8zenRSSzBUbzdjZHlxSTEveFNsMDVSVkFmdFN2RzBsYnZTbkJu?= =?utf-8?B?RU5OZndQdmhwSnJGajRhSStVZU83OWtUd2lYNkV4ZVFyd0tHaXFFVW1oRnBK?= =?utf-8?B?dTdrbDlHNkp3V2t3NkVUZVFBN3dmTWxmTFluZ05MM1RZNFpyWkc2blJVdHNR?= =?utf-8?B?SlRGbTVuNTZqN0RVRHhhQ1FqY25xZnFCZFRmazNraGttdFMyVjY0REoxV0lK?= =?utf-8?B?MFFjRGVub1JFZ09pdGJhME9QVDFDQTRHM0dZWkFXbjFrRlo1NytPY01SNExa?= =?utf-8?B?M3NKenNNdFRraVpxa0MrRGlYU1NqMFBQY3BXZmtiOGl5Y24xbnBjQzhVY0d3?= =?utf-8?B?T3QzbHYzN3ZBPT0=?= X-Microsoft-Antispam-Message-Info: D0I7Fuz8JuXKRWkBL/53jvsmGghEjc15q6AR6CCumXccz4fTJiKh3FlPh1cb9OgGgaTx2xJjPjH3q4biyxKcP0uoTZmWQ2ISjz79keAB8dGvfTyoYwrquPvCIYRJb6p69LCuioX7m+QAxg3MVIv1nna1l+ROh81HGqbh7YT/vJRUGLoyiASz3oHXrx5ytBl1 X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0292; 6:98L845iKPGp5bwdcIoEoMinsdfd1dhDjEh2PAGek+HpUbguZ3RjNdgTE/XsLmZ0pvOQBzqdEn2p4Pad6CqOO3A4tM9EBl033gE1DgbYlXWrPHC6MyCeU+WaVTMghD48SLSLcINt4Ndm/JswJExlkV5asYpXKgWIwOgLKYIdSqHHirQXN22eEyxO9XSlDRffmqtghOS9keZP0s3pN4fbK725hqHTAKpiZEGKrTtcWyBSYdQeY/WRnEiQAIqViWVnUO9CiTUA/ThEpGIc4Dfmm93bK1h5Uc6ZA0T1lCKqcct16EyCEaoB77lKrFOXXtY7yI31jeK84dSi+96C82epmoIWzglfrBf24pU6CHld5ag/XC7GJUb7wVIkf7ZnK20V+FPfVxblNt+A3GAqVrhM0Oyh8+RpbO7Kcrud9ujGIexvqs8s6n8te65TxGMjgpZQr1SQwnpzdb1cCLuzjUrqFPg==; 5:KH8BewrezmLjwFxajXjH+ys0lsTxMI8S0PyVahvYOPyU9DWrR0Gvw9zfogQO917ubtoFx6kAqm/OR9eN63R1BDtuexkRE+WG/cpC6YOb1y1W0zzh0EptxTMe4OaWX44SsMnQCCJYXpU5pq5fGchUWwTBsZNXw0B7uImHwiFV5n8=; 24:biuToJjRMh5PkmdC1xfGyo5JmIaqKvSaqsZnVJ50ZM5GZJoSuRaZAAjHM8xooxn627+h6LZON+eKWpMrvOYGIimiY5r2B4AtkAy6v5gYSB4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0292; 7:OYhgquwZxhy+BR25ExT5NyUDs+7NlTSMEwSjOFLQba+ZplTnSOJEy7gukde6nbT6Ji49kYeLK/8VK03vkp03HfJF9wUsRnw8RYbZ5HX9njNqTMX8u6sghZ98JLFfzPyNSh424s/r1aSEJ2nDiWLw3NzAPVb8gVTCBoAauKJDzXJizGLuvFbZbsJK7mMPYQCR8Aif0pTIbsTC3KcfwrCo6kfIZWrxA0iolLCBatXFsYjaH4AnjtPh1zrOH2VkedIg X-MS-Office365-Filtering-Correlation-Id: 5dc08496-bd0b-4ae6-9527-08d5a7029f41 X-OriginatorOrg: comodoca.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2018 21:06:43.9015 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5dc08496-bd0b-4ae6-9527-08d5a7029f41 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0292 Archived-At: Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 21:06:52 -0000 I've just opened 2 PRs, which we (the authors) will deal with and then publish version -29. I believe this will resolve all of the concerns raised in EKR's previous review. On 20/04/18 00:46, Eric Rescorla wrote: > Hi Paul, > > I still have to review this. Will try to do so in the next week or so > > -Ekr > > > On Thu, Apr 19, 2018 at 6:30 AM, Paul Wouters > wrote: > > On Thu, 7 Sep 2017, Eric Rescorla wrote: > > Eric, > > Are all your concerns raised in the AD review met by version -28 ? > > The diff since your last review: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-28.txt&url1=draft-ietf-trans-rfc6962-bis-26.txt > > > Paul > > Date: Thu, 7 Sep 2017 10:41:45 > From: Eric Rescorla > > Cc: "trans@ietf.org " > > To: Ben Laurie > > Subject: Re: [Trans] AD Review: draft-ietf-trans-rfc6962-bis-26.txt > > > > > On Thu, Sep 7, 2017 at 3:24 AM, Ben Laurie > wrote: > > >       On 5 September 2017 at 18:46, Eric Rescorla > wrote: > > >             On Tue, Sep 5, 2017 at 9:04 AM, Ben Laurie > > wrote: > > >                   On 4 September 2017 at 00:17, Eric Rescorla > > wrote: >                         Hi folks, > > Please find enclosed the first cut of my AD review of this draft. > > Note: the original of this review is on Phabricator at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D13 > > > If you want to see comments in context -- which is a lot easier > -- you > can go there. Also, you can create an account and respond inline if > you like.  If you elect to, let me know if you run into problems. > > -Ekr > > > Note: I have not yet reviewed the algorithms in S 2.1. I plan to do > that separately, but figured it would be useful to provide the > rest of > my review on the assumption that the changes to that section will be > modest if any. > > > High-Level: > > 1. This document makes a variety of claims about the assurances that > clients get that only obtain if some as-yet-to-be-specified > third-party verifiability mechanism is implemented. For instance, in > the intro: > >   Certificate Transparency aims to mitigate the problem of > misissued >   certificates by providing append-only logs of issued > certificates. >   The logs do not need to be trusted because they are publicly >   auditable. > > > As the extensive discussion following Richard Barnes's and my > previous > comments should make clear, this is only a property of CT if you > also > have some mechanism for third-party verifiability of STHs, and this > document does not supply that. In the actually deployed -- we can > debate deployable separately the deployability of some of the > proposals for how to get this-- versions of CT, what clients get is > SCTs, which are effectively countersignatures and in fact do require > trusting the logs. This is implicitly acknowledged by proposals that > RPs only accept certificates with >1 SCT. > > > The purpose of multiple SCTs is to avoid the death of a single > log causing the death of a large number of certificates. It is > not about trust. > > > That seems like the reason for the server to offer it, but not > for the client to require it. > >             Line 763 >    Maximum Chain Length:  The longest chain submission the log is >       willing to accept, if the log chose to limit it. > Nit: chooses > > > Past tense seems correct? > > > I'm willing to dert this to the RFC Editor. > > > > > Line 785 >    accepted trust anchor, using only the chain of intermediate CA >    certificates provided by the submitter. > Why is this a 2119 MUST? It seems wise, but not necessarily a > conformance requirement > > > "To avoid being overloaded by invalid submissions" > > > There seem like one way to prevent this, but not the only one. > > >       Line 816 >    anchor used to verify the chain (even if it was omitted from the >    submission).  The log MUST present this chain for auditing upon >    request (see Section 5.6).  This prevents the CA from > avoiding blame > What happens in cases of multiple chains. For instance, say that > the submitter provides superfluous certificates? > > > Not allowed. > > > Hmm...  So your theory is that the submitter does path construction > > > Yep - and that's borne out by practice. > > > OK, well, then it would help if the document were clearer on > this point. > > > > > > Line 837 >        opaque LogID<2..127>; > This seems to be the first use of the TLS specification > language, but I don't see a cite. Please provide one, > > > See s1.2. > > > OK. Thanks. > > > > Line 926 >        opaque TBSCertificate<1..2^24-1>; > NIT: there's no actual way a TBSCertificate can be 1 byte. > > > Line 948 >    "tbs_certificate".  The length of the "issuer_key_hash" MUST > match >    HASH_SIZE. > Is this true? What happens if we have two CAs that share a key? > > > Eh? > > > Say that a CA spins up two subordinates that happen to share the > same key. I agree it's foolish. >  return an empty > > > > Line 1522 >    permissible.  These entries SHALL be sequential beginning > with the >    entry specified by "start". > How does the client know which of the above two cases has occurred? > > > The response includes an STH, which says how big the tree is. > Probably should be the latest one known to that server. > > > > Line 1552 >    TLS servers MUST use at least one of the three mechanisms listed >    below to present one or more SCTs from one or more logs to > each TLS > This needs to somehow be clear that it only applies to TLS > servers that are compliant with this specification, as it's not > a new requirement on all > TLS servers. > > > Surely its the other way round: i.e. new requirements on all TLS > servers have to be made clear? > > > I'm not sure what you mean. This document does not get to > require that all TLS servers do CT. Was that your intent? > > > What I meant is that if every time you mention a thing you have > to say "but only if you are conforming to this RFC" then you a) > make the whole thing a lot more > cumbersome, b) are stating the obvious (i.e. that you only have > to conform to the RFC if you have decided to conform to the RFC). > > > I don't think it's merely stating the obvious in that we have > *other* RFCs which actually do attempt to retrospectively impose > requirements on all uses of TLS. See, for > instance: https://tools.ietf.org/html/rfc7465 > . And this is a different > story, in that we are not (I assume) going to go around saying > that TLS stacks that don't do CT are not > TLS conformant. > > I think the text I would use here would be "CT-using TLS servers > MUST...." > > >       Surely if you are making a new requirement for TLS > compliance then you have to explicitly say so? > > > Well, my point is that the way that this document is written in > fact does so, and so you have to look at "Updates" to find out > that that's not the case. > > -Ekr > > > > > > -EKr > > > > Line 1595 >    been struck off for misbehavior, has had a key compromise, > or is not >    known to the TLS client).  For example: > Maybe replace "For example:" with "Some ways this can happen are..." > > > Line 1599 >       misissuance from clients.  Including SCTs from different logs >       makes it more difficult to mount this attack. > Assuming that the server is malicious, why would it include > multiple SCTs? It seems like requiring multiple SCTs does in > fact provide this defense, > but that's not an argument for servers to provide multiples. > > > Line 1627 >              SerializedTransItem trans_item_list<1..2^16-1>; >          } TransItemList; > Structurally, it's kind of a mess to have this be the place that > you make TransItems self-contained (by having a defined length > field). What about > other places I might want to concatenate TransItems. Why don't > you instead make TransItem self-contained, like so: > > struct { >           VersionedTransType versioned_type; >           uint16 length;   // NEW >           select (versioned_type) { >               case x509_entry_v2: > TimestampedCertificateEntryDataV2; >               case precert_entry_v2: > TimestampedCertificateEntryDataV2; >               case x509_sct_v2: SignedCertificateTimestampDataV2; >               case precert_sct_v2: > SignedCertificateTimestampDataV2; >               case signed_tree_head_v2: SignedTreeHeadDataV2; >               case consistency_proof_v2: ConsistencyProofDataV2; >               case inclusion_proof_v2: InclusionProofDataV2; >           } data; >       } TransItem; > This is pretty much the universal TLS convention. > > > Line 1649 > 6.4.  transparency_info TLS Extension > This extension appears not to have any explicit support for CT > entries for intermediate certs. Am I just supposed to glue > together all the TransItems? > > > Line 1651 >    Provided that a TLS client includes the "transparency_info" > extension >    type in the ClientHello, the TLS server SHOULD include the > You need to provide an actual definition of what the client > includes, and having the server ignore the contents is bad mojo. > TLS convention is for the > client to include an empty extension and the server to validate > that it is in fact empty. > > > Line 1654 >    "transparency_info" extension in the ServerHello with >    "extension_data" set to a "TransItemList".  The TLS server > SHOULD >    ignore any "extension_data" sent by the TLS client. > Additionally, > IMPORTANT: The normative language here is kind of confusing. It > SHOULD include the extension but if it's included, it MUST > consist of TransItemList, > no? And surely only SHOU > Also, I'm not sure this is the right logic. If the server knows > that it has the SCT information in the certificate or in OCSP, > why SHOULD It send this > extension. I would think, rather that servers should aim to send > information at most once, so that it should only send the > extension if it contains > information that's not in the cert/OCSP. as it pretty much has > to send those anyway. Otherwise, don't we just end up in a world > where if this info is > in OCSP and certs, it's always sent twice, because the client > doesn't know where the info is, and so has to always offer the > extension. > > > Line 1658 >    session is resumed, since session resumption uses the original >    session information. > Does this mean the client MUST abort the handshake if the server > includes it? > > > Line 1668 >    o  The TLS client includes the "transparency_info" extension > type in >       the ClientHello. > This condition is non-sensical, because if the client *doesn't* > include the extension, the server cannot send the > transparency_info extension at all. > > > Line 1722 > 8.  Clients > Given the imminent standardization of TLS 1.3, you need to > somehow provide a mapping for client-side CT for that, I think > > > Line 1739 >    view.  The exact mechanisms will be in separate documents, > but it is >    expected there will be a variety. > Given the somewhat science fictional status of Gossip, this > entire paragraph should be stricken > > > Line 1747 >    MUST implement all of the three mechanisms by which TLS > servers may >    present SCTs (see Section 6).  TLS clients MAY also accept > SCTs via >    the "status_request_v2" extension ([RFC6961]).  TLS clients that > IMPORTANT: This also needs to be rewritten so it makes clear > it's not a general levy on TLS clients. > > Line 1770 >    In addition to normal validation of the server certificate > and its >    chain, TLS clients SHOULD validate each received SCT for > which they >    have the corresponding log's parameters.  To validate an > SCT, a TLS > IMPORTANT: Why is this a SHOULD and not a MUST? If you support > CT at all, why would you not do this? > > Line 1791 >    TLS clients MUST NOT consider valid any SCT whose timestamp > is in the >    future. > What's the reason for this? If your clock is slightly wrong, > this is going to cause new certs to fail even if they otherwise > would have succeeded > (because the notBefore and notAfter are more conservative). > > > Line 1800 >    will disclose to the log which TLS server the client has been >    communicating with. > IMPORTANT: This "Note" just mentions in passing a huge privacy > issue. You need to be a lot clearer about this. > > Line 1823 >    "transparency_info" and "status_request" TLS extensions in the >    ClientHello. > IMPORTANT: This is not consistent with the requirements on the > server. > Trying to reconstruct the reasoning here, the client can only > decide that the server is noncompliant if it has given the > server a chance to send the > SCTs by every mechanism., otherwise the server might just want > to send the SCT some other way. However, if servers can > optionally ignore > transparency_info (it's a SHOULD above), then you can have two > compliant implementations with the server having a CT-compliant > cert and yet the client > declares it noncompliant. To fix this, you need to require the > server to respond to "transparency_info" > > > Line 1831 >    "CachedObject" of type "ct_compliant" in the "cached_info" > extension. >    The "hash_value" field MUST be 1 byte long with the value 0. > You should explain why this is one byte long (that the PDU is > defined as having a minimum length of 1). Also the server should > be required to check > it. > > > Line 1842 >    watches.  It may also want to keep copies of entire logs. > In order >    to do this, it should follow these steps for each log: > Why is this not a 2119 SHOULD? > > Also, what does "in order to do this" refer to? Clearly not how > to keep copies.... Presumably, how to poll the log. > > > Line 1864 >    8.  Either: > IMPORTANT: You seem to be missing there part where you actually > look at the entries to verify that they don't contain bogus data > (e.g., certificates > for your domain). I get that it's implicit here, but given that > you provide an algorithm, that should be an explicit stage. > This is a pretty odd algorithm. If I understand it correctly, > 1-4 are setup steps and then 5-9 is supposed to be repeated, but > I could just do this > once and stop at 4. > > > Line 1912 >    STHs it receives, ensure that each entry can be fetched and > that the >    STH is indeed the result of making a tree from all fetched > entries. > IMPORTANT: How do you verify MMD? > > Line 1944 >    If it should become necessary to deprecate an algorithm used > by a >    live log, then the log should be frozen as specified in > Section 4.13 >    and a new log should be started.  Certificates in the frozen > log that > RFC 2119 SHOULD? Isn't this a MUST, though? > > > Line 1958 >    "transparency_info" TLS extension.  IANA should update this > extension >    type to point at this document. > IMPORTANT: You'll need to fill in the new field specified in > https://tlswg.github.io/draft-ietf-tls-iana-registry-updates/#rfc.section.6 > > > Line 2009 >    |                                | ECDSA (NIST P-256) | >         | >    |                                | with HMAC-SHA256   | >         | >    |                                |                    | >         | > Why are you defining both algorithms? > > > Line 2150 >    (with the intention of actually running a CT log that will be >    identified by the allocated Log ID). > This seems like it's not a great thing to be asking an expert to > do, as it seems to require business arrangements. Is it really > that valuable to save > a few bytes here? > > > Line 2163 >    that the log has misbehaved, which will be discovered when > the SCT is >    audited.  A signed timestamp is not a guarantee that the > certificate >    is not misissued, since appropriate monitors might not have > checked > IMPORTANT: This is not correct, because the client does not know > that the monitors are verifying the data that it is. See my > general comments on > public verifiability above. > > Line 2182 >    operating correctly.  As a log is allowed to serve an STH > that's up >    to MMD old, the maximum period of time during which a misissued >    certificate can be used without being available for audit is > twice > Nit: up to the MMD old > > > Line 2211 >    compute the proofs from the log) or communicate with the log via >    proxies. > This also seems quite handwavy in light of the facts on the ground. > > > Line 2237 >       and STHs can be stored by the log and served to other > clients that >       submit the same certificate or request the same STH. > This needs to be expanded. Who is this risk against? The log or > someone else? If the log, what's the logs incentive? > > > Line 2243 >    reduce the effectiveness of an attack where a CA and a log > collude >    (see Section 6.1). > See my comments in 6.1 about this. > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > > > > > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist Email: Rob@ComodoCA.com Bradford, UK Office: +441274730505 ComodoCA.com This message and any files associated with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient, you are not permitted to use, copy, or forward it, in whole or in part without the express consent of the sender. Please notify the sender by reply email, disregard the foregoing messages, and delete it immediately. From nobody Fri Apr 20 14:07:53 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDCB12D72F for ; Fri, 20 Apr 2018 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf35P4M_GDuR for ; Fri, 20 Apr 2018 14:07:49 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0072.outbound.protection.outlook.com [104.47.42.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A5712D885 for ; Fri, 20 Apr 2018 14:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7VAf9CEQCHpM9eQNFRvl4TQyGzKvSOOsd+FM9j97MjI=; b=zsyGT5bafXeNHxtSNhBjDwjxA61EwMpiM3hTHF93fW+S1c8uQq+4ynW7AeGDQ0hlqNhMBxPEjPYpNUDRAiXu6bzc2IF6X6WeV5h+zkScE1qC8O+HQMtTW5ZdR4ytlUsSqbyZEv3pmcE/FEl7hjTWDADJOl+w7WBIZeWtV1wLEqU= Received: from [192.168.1.81] (51.6.119.163) by BY2PR17MB0295.namprd17.prod.outlook.com (2a01:111:e400:58e6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Fri, 20 Apr 2018 21:07:46 +0000 From: Rob Stradling To: trans@ietf.org Cc: Andrew Ayer References: <20180320151249.ef2e85feaf05de8edac24479@andrewayer.name> Message-ID: <08ec0e15-2244-ac90-3acf-d3e4153bcf75@ComodoCA.com> Date: Fri, 20 Apr 2018 22:07:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180320151249.ef2e85feaf05de8edac24479@andrewayer.name> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [51.6.119.163] X-ClientProxiedBy: DB6PR04CA0008.eurprd04.prod.outlook.com (2603:10a6:6::21) To BY2PR17MB0295.namprd17.prod.outlook.com (2a01:111:e400:58e6::21) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR17MB0295; X-Microsoft-Exchange-Diagnostics: 1; BY2PR17MB0295; 3:hQqubChSLg6XpoVF3lsMvjbWQaGoAEqSqCUL//XPiPyvYzX9cQFAZ05lFazNkELlKk8g8VUKEH1s3qYgGsbC/hCPihDiEeHixs9KJJmwWCfcJ1/b0s56OWwvsuSlqfkkzC12+3dBBiWqa+sS5VPZXVn7GKK3ELs59NvHAgUcp9BC803F3Mq6VOl1Tgu3EdYoJS6GGzJEKl/zO66K3l+plUx0o85zhUVYz6qvivP7uM8Xr3IfVDzZxOcrai4V/44A; 25:rs/MgSjMe8Bkk8mdiOgH3nLbvAPXZbLaCmyrYrP3h5G8KrfflHjN5VLBRNcWSCH1c/szeAOgcB+ZLfDbdhZWFTGLUZoxUPTcAoXys+RFcGSZ5LDHMUdg4whCcM5O1by6U+0vZKyrWcb88BGkArxkodKOlVhtc5vodJZvG9sbH1nL074LJGtuZL7Ln/c3vonWZCCVMJcz8Oor2A3xiKbHaXqQHRRjczxeCHjytL2gM1K7yux41gkNSkREoN8FNqsypN2lQE+iyrkfdzFyPRaNAXrJP+3vJISkhbW8wmkOKUKdifJXi98E6AIopIr7ku4fRZAOfEWCoCPURV1nFZNDnw==; 31:GucfTJx5rNJUhVMS9oFd1wgHFGevPEjCO1yrnWrt5pzjlag2bHvY2Ks2r3J/FVmJOFiqxpqjnHHNEAgcBuXnYH3grv/OJT3fguBcnVInLCwfENjrpVCOkuK39yfDATK5QYNmISPgZd420iZShqpgSCyjzGgttTwuzcWwxiDk8WytjKCSMZZ3vmuMfhPzQc6foOB3OdDfe7VrDg17Hom+Rrek43uVU0P+p3hOk3oJ2l0= X-MS-TrafficTypeDiagnostic: BY2PR17MB0295: Authentication-Results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=ComodoCA.com; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231232)(944501398)(52105095)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR17MB0295; BCL:0; PCL:0; RULEID:; SRVR:BY2PR17MB0295; X-Microsoft-Exchange-Diagnostics: 1; BY2PR17MB0295; 4:RQ/JYGZQWjEHiDrwdvDO/bTwWOTXfACpd9rAe3e4qWS1TesvnkVeLQPbW7rnvvkR42Pcc7Lx4oWVvc36T+wbvgVrTF3VPDet8Aw3zi1t6GM5IqkWRsK7Ne/7tCO5ctMIQO+nG5Lc8VE+34b1Q69V6l/3bQA9kSnpngJKFPeVzZmi/lsjafQpK9A8pOJSMoyeiGEBnoMu8a3mEQ2tWy2stvtKn7nPeIsetVOKOua2dwO7R9gNNV/FZU64ySWYW+FMR5FGOeirqDXAtX8uPG/Da+HJilUd9vNKZzJJsLNOXpuuq9hlsMbBcAXxyr0hMMZ27yLLfoBqes22nZ6uPPoOspSTbXV57q9OTutKamB28iA= X-Forefront-PRVS: 0648FCFFA8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(376002)(346002)(39380400002)(252514010)(478600001)(4326008)(2361001)(25786009)(5660300001)(966005)(59450400001)(117156002)(7736002)(305945005)(67846002)(316002)(230700001)(3846002)(31696002)(2906002)(86362001)(81166006)(6306002)(6486002)(2351001)(47776003)(8936002)(66066001)(23676004)(6116002)(6246003)(2486003)(8676002)(229853002)(53936002)(52116002)(76176011)(31686004)(386003)(52146003)(476003)(53546011)(2616005)(956004)(11346002)(186003)(15650500001)(6666003)(16576012)(77096007)(16526019)(446003)(6916009)(50466002)(65826007)(26005)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR17MB0295; H:[192.168.1.81]; FPR:; SPF:None; LANG:en; MLV:sfv; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjE3TUIwMjk1OzIzOmVQNXFjeG1CNDd5NVZGMmszeHZGVEwxOGg5?= =?utf-8?B?TGpYaGhGc2lVVm96ZW9seEVTS3JYdG5IdzRIL1A4RzBwUWRCa3pxMWRuemJX?= =?utf-8?B?VTZBcGVZSS9lb3ZuUEpscEhvU2IxeGZjS040ZjF2RWNHWjh4TnVZQlV6Q1ZR?= =?utf-8?B?dmU3Mi9UMGswV3lteTFqZGJLRlhXQUU3VmlEOEgrckFLWElJOFBqdlR6dFdm?= =?utf-8?B?V0QvS3lVWEJLbUZwZ2h1N2NndnkxakJVSFZJQ0VvZ0lJd1pYbjdYZjhjQ1Uw?= =?utf-8?B?RG01UG8rbVhzZk1XaFNzV01jdzd6SnJZOHlKL085L0pFcUwvUEVnVWZucVR5?= =?utf-8?B?QkpZSjM0WVpnNk9VS3VxTmdtVnY0c2xoWU9sWkxiSXZLYURnaWgvMmU5U2hK?= =?utf-8?B?VndleWtIbGNGMUx5TWYwOEduSnQrRlJQZFovZnpPVzRSend5Mkw4Qi9FNHRK?= =?utf-8?B?UlliblhIaDBxbHNRa2FJakM2QlIvUkJrK2hzV0pXN1NyU2w1bGg1NWJuSHZS?= =?utf-8?B?MXJDN2NkY1AyWXFBM1NSaksraDZvYjg0OW5xS1Rlbmd6NUQyWGt5eThUS0Fv?= =?utf-8?B?bmIzYndxRnhNdTNkTTZtZmZHUE1EUXdDdXkvWGE2Z0NEanRDZTUyNTk5Szc2?= =?utf-8?B?WWRkQU9aUWZ5V0w1Y2tpTDBqY2xadXFvRG1UaUF6SDhCNXFQSDFvRWV2V1Y3?= =?utf-8?B?ejgvYW83V3FwdmY2NVd2OGtNakV2S3F3VVMrVGRSdTNBWjA0NEUzdnhtYm4r?= =?utf-8?B?eEh1bWdaa1JhSVcvdW5KNFZTelZjNHo1THlxdmNjSlN2S0xpY1dlNlpCREpF?= =?utf-8?B?dzQ5NTkwN2VvNmdZbHFuYy90V3o1eDdpbktjbC9LdllKdWt4MWQ2dkRDUXN6?= =?utf-8?B?UklNTm0wbjhmRk4yT1BtRXBIVXFuZ1hSRGVqS0ZTa21WNnFDQUwxTXRnVDRv?= =?utf-8?B?ZDZDb1JMQkROU2pudFVQaE56TEY3RVIxc0U1SDd1WVhoNU4zcjJwWW9ncWdy?= =?utf-8?B?ZDRDZ0pWR2FidmtscjZtYmU4T0h4dEVoSGtVWjNzeHZxb1EwRnRsUDBhcFl0?= =?utf-8?B?ZUh4Q1VSRnc5UGsxb1RpOUgrUEFYVHlkTHdkRUFkYzYwaytLcXdaMk8zT05D?= =?utf-8?B?K0tGNTNwRElsc3hST1NQZHh6R1AxVE85SmdIR2ZGbERNWGpzbnk0ZlpOYVhn?= =?utf-8?B?V25Ja3JwaithN3N3UStXaDR3cnV2Q05SNUNWVmhiMEJpV1JtdjZSNU9JVE01?= =?utf-8?B?SDI2cGRhdjFYaXYrODhxWHBvNENGR1ZvS0s0R2FGS1lDbjdySW0rWjBXTldo?= =?utf-8?B?ZWNnbzYvdll3ZGN5QlhjNUo2c012dVRNS25VZkRkTDZ2bE55OWRMbVhRVFdM?= =?utf-8?B?TGdmMk5Wb3preE1yNXE1d1IydFdSQThJUjVIelAxcjA1VVFRa3Q2c2VaWDhI?= =?utf-8?B?cEd5enU1UlRkbTdSUDZpRTZXaTdJNVJmQzZ5cDJ3WGdTR1hKeGQrdGxZQktn?= =?utf-8?B?ZnpPWTR5NlVQblZvTXZ0a3dBa2x3QThaZEMyOHlUTW5sQ24ySnBkcjhWeVpn?= =?utf-8?B?VmVUOTA3aS9adURMTmFZRjltVHovekgydkZJTFpYMkZXOW5RVUdYdXZvaDBr?= =?utf-8?B?V3NLWXpzVWpJRWdyY2J4QkxWa1dyWUJCNStQRU41Mjk4S1JEaEtQMzhDeVBy?= =?utf-8?B?RXRZQlZHUTRvYzRtdkhhSklFS1pYNy9KU3UvbjU1Wkl6RHk3QytvL2NXOFl4?= =?utf-8?B?UnJFSUY1TllOT1JncVMxM29uUnZBMGI2YjNOeHNZeEUyOGlOYVcyZXdqS2JN?= =?utf-8?Q?1FawTvJZmxxlX?= X-Microsoft-Antispam-Message-Info: sOICUpIT/iqs6mA0P6E3AsKed1Bb7doYAqG71GBn35XU+XLqvx6G6OMO8+ALUc02W79KTb2SyVukuMmnw3IBUR7NXzeyl95Gp1J1nIkt2exJuAAk/NlaGJrF56zUA/4vk7Tj9QG5HM6ZzF82/w/LUFUdQkHGEPUg7eVd2AQgbC2UxPGEkW/jqfO20lsUglBc X-Microsoft-Exchange-Diagnostics: 1; BY2PR17MB0295; 6:7EUUD3seyHP6B4gO+VAKlyEtUoopkJjNKB+zJ6q+2R2AMffIZ/4QHqjv0BBVHKyedqL631TD6btzGmUtWjCQZlUpEDibm1TJzrOyE9VLodgUkK1+Bdsrs47rQC8hWd5EZ4cPxw1dv/wQfbwJlJgqDteiLE2r5GFAsX+acigflNqRIeoNSGhj/mv+/89tCnYksJaav4NgydaOGi/DokirERldPb6LX98V7lEmphV4YEiVs8QQdGLRLAmanzw4PtvGip9PfjWX7TRL2Zm3WHsdgQ7vGh9sRNbMw5KyGIh2ax5Ry7LFPZG2VLEUIh3/BznxaN8oDzw1hPoDNeI9KPcWXJh+3iNyUb1frxsGWwUtc5VbA/g+dHqbuOwVepa5/7owNAx6atwaa6DzfOdDfjKc9qWlOCOvjx/EXVvftk7ac/zeQC6E0wUDdFu7CVD6PZ6/kxXqoWzF63QkupbbzHEDgg==; 5:FlFyyJQt+o/UItKcIH3jAGsw7OzFKiAlaFEwn/1MYNWILZbnGDVIILBpFQAAS9q7FJUVahStX2YqstY1hcALSbdyQmzgo2YMOjpWZqe/nYMvIqLhOHbb6dNI0GJVEflVVm6gMQiTUCq8ZvXGD7yrc9aqdwmzMiYQGe6U6kAPQ78=; 24:ERaHBBwWZ23UaA3c3iwgyFEy4xlc+R5nLnsau+gsnf7+jmqm0C1cCFetlZUYHx9uABuFFIbxzIApmJ37o++l0If9bHzsLaQDvdI63Hs8sRw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR17MB0295; 7:mFINuQM6FoDsM2DQIlmE9xsLcLop+NWepbpZ7Bnboarbx1oZDabgFiwB2TFO8QB3bwPtdaC7WfmX/jynXNEKh0WygP3EBaw2V3+BARcFr99qlJxdgzUOMNlAOMNL6PWhr3hsTuGHtuPHuo1wbfUlu8eldmTHnYVPCskmjUjkQcLJMTydNPt6HZZAF3uaSFpFbqMjn4+Ct4P7wsQ4m1SgnHrF/pG7qBvxa9c15E81YHx+4Ox0+9Kd+moudPXlSRZ3 X-MS-Office365-Filtering-Correlation-Id: 8c12fb7e-8382-41b6-0280-08d5a702c46e X-OriginatorOrg: comodoca.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2018 21:07:46.2609 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c12fb7e-8382-41b6-0280-08d5a702c46e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR17MB0295 Archived-At: Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-28: "no security implications" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 21:07:51 -0000 I think this is a good change. I've posted a PR here: https://github.com/google/certificate-transparency-rfcs/pull/296 Anyone have any objections? On 20/03/18 22:12, Andrew Ayer wrote: > draft-ietf-trans-rfc6962-bis-28 added the following text to > section 4.2: > > "While there are no security implications to a log accepting > a submission that does not chain to one of its accepted trust > anchors..." > > This isn't true. The certificate chain enables the logged certificate > to be attributed to a known trust anchor. This is security-sensitive, > as without the chain, monitors and trust store operators can't respond > to a misissued certificate because they don't know which trust anchor > should be sanctioned/distrusted for misissuing the certificate.[1] > > Therefore, this text should be removed. > > It might also be a good idea, to avoid any future confusion about this > requirement, to add "to ensure that logged certificates are attributable > to a known trust anchor" to the sentence at the beginning of 4.2 that > explains why the requirement exists. > > Regards, > Andrew > > > [1] In the general case, a monitor could probably construct the chain > using its own store of intermediate certificates. But this fails if > the intermediate isn't known, which might happen in the adversarial > case where an intermediate certificate is issued for the sole purpose > of evading responsibility for a misissued certificate. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist Email: Rob@ComodoCA.com From nobody Fri Apr 20 14:14:13 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAD712D887 for ; Fri, 20 Apr 2018 14:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7BrioDod8sh for ; Fri, 20 Apr 2018 14:14:08 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0057.outbound.protection.outlook.com [104.47.34.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB21312D72F for ; Fri, 20 Apr 2018 14:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QNXoXEQpmtFYc757TPbW9k0Au4DaFZ8oWFLO9IN/AXo=; b=ULow/LX8CZJSvXAjHBGMOYfUkcOktWbv86DXKq6g7A0eaSMwkWNSLFBCDz66np6aiANwfrlKQ5W86diXCkY+k6rjJPOTnNhX05epcuaQfUlkh8Y0OTAWUJMjuZcM5MvJ2NYAbxEuP6Lagpl+UnAop8kLjUfDZ751/y64j5ssrYA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rob@comodoca.com; Received: from [192.168.1.81] (51.6.119.163) by SN1PR17MB0304.namprd17.prod.outlook.com (2a01:111:e400:51a0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Fri, 20 Apr 2018 21:14:06 +0000 To: "trans@ietf.org" From: Rob Stradling Message-ID: <433531cf-87c6-f7ff-b476-f2210a681a52@ComodoCA.com> Date: Fri, 20 Apr 2018 22:13:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [51.6.119.163] X-ClientProxiedBy: AM4P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::13) To SN1PR17MB0304.namprd17.prod.outlook.com (2a01:111:e400:51a0::16) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN1PR17MB0304; X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0304; 3:Y+KadMqN1JZMJy1YdwWpCbALx9klAeIfUwdgl7gEgzt2Jo2xxVQGohyLXCJ2mFrHK8/Wp/KKnZsBxuIN+9zhraOqLaua6IAO9dlFzFc+wmIO5YT+m5YsLY42TpFtk6BoSqhOOdvr8BLt2Nt+kNId5mP0WDGdQcrFqqkmaWLoAOixSEhgQEZNWPJ+36+3mGL91xBbRt8W7QK+eRRE0PT+ZEsxSrqmqspVt8yTZb6FRUJDg4D/YTOhTBJZQZ6K8IRZ; 25:8PZ4wFdg2H/reUx30e1IoEA4i+whqiEpXYiW2BOUXtaJ9sT4cOxc3i8L6lic+HBekQb6BS8q1WqJoTCHmSY8uLaku+PYMxFzWy8ifa8q3sqfHVB1A3GZU4Q9hqmt6nQuK4JlGNZFk9a4GK0rIQM02PC+qknFBiOdJOAO1ydlCn1eJPDg401Te6km5cVV+/8ujrnvp+hNGuSYZVe7/H3eWoO/j4XYH5Pm54CpyBBkdNRL9SyPD6QFHfzAZhfOAm85JYNSTF2MNUzXooS47Jz2LB7Qdnt/eX9KKhTKG702vR7T6UkOrtLvqJPS5B7a4XdsQEe8tfDJT8Ofh7Yfrc2xCw==; 31:VBdxvYh9lhRG8Aksfu6pzBOZeCYT+iVvaOMaID9DeYwKZnbPRq+Pg7F4vhzitH3i7Ti+AllQ+ndJBgaAzKhh+WXM2hW8yOWrtqYZV2Hlmuv0cLltePKeUQcG91lVq9UyuxNJzYW6WHV3A8/dey/by+GEqjPibn/PmORTfqw+gzRfmCOYag3irgqZBrxHs1/xebD7ymKxFIMx7zxugXkaaGRw065GFasnqADnXWNXG1Y= X-MS-TrafficTypeDiagnostic: SN1PR17MB0304: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231232)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:SN1PR17MB0304; BCL:0; PCL:0; RULEID:; SRVR:SN1PR17MB0304; X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0304; 4:noHPP36bIJ1eClUC6pkRB3/bOOytUwrgGc9EJW6TW+5Ku0cr1kZF6df4Tc8kxKcdA8bMtidZ6FIGeeLtTGFQtaP0lk96M5uuUhNFIh/EAkp2x1zyrYfpSjrlCSB0UOsf97af4uR3b2oUgX8TbSMy4ZKtuoz75P20jXSAxSBEW+/mLfD5c22N6x6xHqdBI3Gd50so7ZEg0+N5wORDFei1tsf1PRQZS6eJtQRkyOp9fyZSWSYaCzF3040CJEPFOHiF1FbKjzDwBiygaKug4zW6ENsyZHdkQ4WReAH50aZLQ2ndHk8DCbg/QxCKCpPWxuJq X-Forefront-PRVS: 0648FCFFA8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(39850400004)(39380400002)(366004)(346002)(376002)(252514010)(77096007)(36756003)(2486003)(52146003)(52116002)(186003)(2501003)(386003)(64126003)(16576012)(23676004)(476003)(230700001)(316002)(58126008)(5640700003)(31696002)(53936002)(6306002)(86362001)(67846002)(31686004)(6916009)(117156002)(305945005)(66066001)(65956001)(16526019)(65806001)(2616005)(6666003)(25786009)(2351001)(2906002)(5660300001)(65826007)(6486002)(6116002)(50466002)(26005)(3846002)(47776003)(81166006)(8676002)(8936002)(478600001)(966005)(1730700003)(956004)(7736002)(12269545002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR17MB0304; H:[192.168.1.81]; FPR:; SPF:None; LANG:en; MLV:nov; PTR:InfoNoRecords; Received-SPF: None (protection.outlook.com: comodoca.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjE3TUIwMzA0OzIzOm9MWnYyRVAxdjVoekpwcDZFcjA4Z24wTDJp?= =?utf-8?B?RXdvcTR5eFFwajZseS9OUXQvTXJPRHhKcHFrRU1TL21IQnA1RWhwdTR3VjI4?= =?utf-8?B?bFBoRy9KdVdkbnlrdEpBT3g2TkFJV1NnVkRqaWVwU0hMNWE3SzRIbUdObzdJ?= =?utf-8?B?VzVncEtjNnMvY2F6cXlIOGQzbDJXTmhBRFZMOWpDMURBZ2RBWW1PMkJWSHBI?= =?utf-8?B?dXl3MkRnZzBVbWF3dVNHM2Q5dkhUcjZoelNOZXBhellRc3hMc1lVQ1pMNmRu?= =?utf-8?B?L3R5bUVZK3BoUUdMVElJU3F5RnByYnVWWEFPdngxMS96K2IvV2FLbnpaMm5q?= =?utf-8?B?YjdldHd4dGV5V0x3OXVka2Jzck9QeEZIWTMyZWZ6UUJsaDhuREIwTkYxZ3Rj?= =?utf-8?B?aUdFYXFraUJtVlNjcW9CTFFzZDZTNW1JSXpXYTIvTHFYODQ3L1RtV1FtbDBO?= =?utf-8?B?SU9Ba2doN2NxNmdWNGUvcGw5dHBXSWF1MUR2cVJmTFFzbVBzVUtxSnB4WTV6?= =?utf-8?B?TFNjREVIeHJTRXFMZSsvVDVUbGgrdjhJOEt3T0VTd1hObEZITjk5bTErU1pY?= =?utf-8?B?M1l6czFiaTN4aUMzT1BkRGFJMXpQNFBoTkNDQUlScFJ4ZVBRbFhjdmxSSmhr?= =?utf-8?B?OEgwNkg1VnFERVdPaW1hV2RuSVpZK1pqUWtnbjJkL0hxbDd0RExyY3dmU1pv?= =?utf-8?B?WDZqSXRUY2J3SituZmdwVzBWRGcyUTlPSXU4Y3A3L0hENDFUZTFJM2lEeXV4?= =?utf-8?B?amR2aUVYaVhHQlRvTm00a0hyRW5NVU9PY2lXd0M4akFnZjJWRFJhOXJ4U2NX?= =?utf-8?B?Z1A1U0VibU1UNVpvS29UZ013T1ROWTZ2bW1KaDB1bHJpd1dFZ0VlZTNyM3o5?= =?utf-8?B?dlRUU2dSenlPR2JBWDFyMkh0aW1mMW9kWXZRejgwUFR4U0pUbXlKcXpOWEpV?= =?utf-8?B?QXZ3NkRUakNkbG1QSUlFSTNtMk93bytQa3J1bVF5ZlNlVHJxRmZ3UEpFR0tj?= =?utf-8?B?bVBWNUk0LzdBdm9IN1RUN2t0c3lOOWcyeVJOb1plZzNraXNFOG1KOEUxbzBJ?= =?utf-8?B?RjkzcWdYSkJ6QUxnemRjeGtBemZkMTJvUjVVZWM2UVRnMDhJbVhKZzcxQ0dH?= =?utf-8?B?eVNlakFHeFBKMUFRa2pIcnpoNlBxNTJ3NlIwZmE4Y1RqWm1QZ1dVbmJaQ3lj?= =?utf-8?B?QUt0LzJuOFlsQllXb04yMThnRGEzdzZ6ZS9adlJSUUNDK1BSNFQ0bEw4QitS?= =?utf-8?B?WGlsWjRsMFZJcmMyNG9qaGZuMWtsNngyQ0ZOODl6aWhDRnR0ZGZhaTVrVEZO?= =?utf-8?B?bXhXRWNDalhBL3orYVE3bVJkdlorbnBwNm5tZFJIeVkxbTBwaHZVNXhVc1VT?= =?utf-8?B?a1FBZFRjOG5lTEtNWWE4bXVKcS8wMWNpTElaWEQ2WWVTWEpLTVBjaDQ4czlK?= =?utf-8?B?L1FiQXpDakp0dTgrb3QxL2tUUEdVb0V2UVViOG5zZVdKVmpPem9JNkVwZ3JR?= =?utf-8?B?SkxNRDNCMUNCVDB2NkRoK2Z5MWFmM2tpcjcwSytnVnNWOVE1dHdGb1lFdDc0?= =?utf-8?B?a3V5YnZWOUViVlZXWTV4NGlOcTZKMElVNE9TOFY1Njk2VnFGbWErY1FFQ3k5?= =?utf-8?B?RUYyTlhvM09qT0dWemMzVXdVVFdUSS9ydm1EMS9qRkI1V0MyaFh4bXpoWjB2?= =?utf-8?B?YW5nWkFYWFYrcGEvUDI0TG8vdjhyQU5STUVaV2FrTWdmWGtmOS9yUzlMYW9C?= =?utf-8?B?bFJ0b1Bma3JpNjdPMXpyaE5BRjhubEZodkIra3FUaFFUYk1IRE9Ka0h2dkMz?= =?utf-8?Q?G9nsdIEbOXrpg?= X-Microsoft-Antispam-Message-Info: RxqJj1CiEb2f0sCmY3MIB3eqGlYmiCVU+rk0O6aDD5aDoYC8c2fNCvk6DEgZFuh/dr9sLzbi38XtFqBjYF7YnCQZ47NvWEPWm1m7cIIW/sU3o2aP9mpTqHfWIwmHMG6IBULPgWmYMikEbSZZzKNCYs3+gfVY5MxUFZzB5mUlK8HqapYD9f1cBq9uPrJMhgF9 X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0304; 6:zyFdR6idBSYdX9qVcnS76HTyyzOd185umeKxRBYxmzB5EdQkxKhDRTH2sHZez1Nx3ti5Yst+vO5imniEWFMaXtO6dfAmnrpm+RTQl0jocRoimewBH7DNspajCbb8bVt9RQgGhoa74jZxiYi23PF6tHa8JhS1PFIMuiPn4OWd+Y8ZP464sbIF10LkZjYmk4ynLcLXlOWEd3EAODWQ6DuQGByokJmHLyYXTuPnaP35ykJ8bAq621ZxK6Ixn7/JdFo+vk9aGAUENxMcnIobYKO8WtMJl8XTvITJLliEJ2QEeK6cVF3Fubth3h/7B0BatmyuUX2xiia6aBFeyKlH5MGLD5/WteSmwnxwyVZzpP/UxdIqANxa0ZYYlS+4S908QX2f+clEImcgoyKltGo1ipJDrOcOeTWvaLV/zLgvKR0pgwMIR5P3BFqqkJvxvPN+rHUJRqX0sRkMm9n3e373s7RWig==; 5:6SBdmFqmPxV5sbe2Vuew9aqhZsxShat2NRNIsEevcxQmt4uJzbfMjUw5I3T9sFJf0+fwuJZpUA4lnKdS9MSabBQR6uO8c90rAccO+U6dTyWO0FvJFB2Zx8ymlqLtLyBhHNrq2jtHv5dxkAp4xEVMXZypwCiwepK1ExkjVUhJTQg=; 24:2UXwa11rKN/ETdxZri4xY1ar1aaYGlDcoAscJe0jtmb3yh7yEsQiuiGxKqMFlx7hJisUNwLVOsu0Fp5U3mkPIwOaAw5HQLaFLiRcl0wVxpY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR17MB0304; 7:kwEwe7THuUXQSWxOZ2DQmSr5qBAwIvsXo3tzg7Kf2s8QRz0FudXdWq5rCX/sN7ttuFp9mrflWx1jsS+O64kZqCXzKJi1Ajq2ZKU3Dtl7Rlc0BwwcTpvfi13sb+IOiakVOSdAcl/fQtUjPADG0z4aTArOMTCsuoRlKB0rRssKPC48JlitbHjsdaCrwhc0bcwoXE33FMDYF6WXY4yymn7BFR7NdTm7UGoOJ+S9Ga6xAYqjMnyqZg42xmInTekRS9tK X-MS-Office365-Filtering-Correlation-Id: e463c1fb-cf15-4c09-cc8b-08d5a703a722 X-OriginatorOrg: comodoca.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2018 21:14:06.7202 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e463c1fb-cf15-4c09-cc8b-08d5a703a722 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR17MB0304 Archived-At: Subject: [Trans] Removing the Preventing Tracking Clients section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 21:14:11 -0000 EKR had some concerns about this section (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-28#section-11.4). We (the authors) discussed it and concluded that this section should probably be struck from 6962-bis. PR here: https://github.com/google/certificate-transparency-rfcs/pull/295 Anyone have any objections? -- Rob Stradling Senior Research & Development Scientist Email: Rob@ComodoCA.com From nobody Tue Apr 24 09:28:36 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295BD12E8D7 for ; Tue, 24 Apr 2018 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMGDYWnYa6Go for ; Tue, 24 Apr 2018 09:28:32 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D439F12702E for ; Tue, 24 Apr 2018 09:28:32 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 3805930002B27 for ; Tue, 24 Apr 2018 09:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=9+Z77FNZ9Jwxgbs5+y3vkJYxvGE=; b= uXRaKofuH5rryD1EzHDnPrYqTMCq8leQE+HGZ4UbZF5tn/n7zIy7LXrbmuR69Q1W y2qWcs1ZDBoRbscqz6POyNgs3w3ob7QvegERExziMlUBVxir8uBiaMBuIHTJQLXq KIdnFAMyObH0xwGeOAWSWNBllS0hm5yRIwzLaug1nIY= Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 28DB730002B21 for ; Tue, 24 Apr 2018 09:28:32 -0700 (PDT) Received: by mail-it0-f50.google.com with SMTP id m134-v6so16305323itb.3 for ; Tue, 24 Apr 2018 09:28:32 -0700 (PDT) X-Gm-Message-State: ALQs6tD7kqIspM6PNf5gf5B2mWSd3pHekl4Hi5oFiJuzPVscUULe77Cq lupTfA8pd9ihgM033w5u4L8IFjYfYcIHppvIi8w= X-Google-Smtp-Source: AIpwx48ZpzxfrQhL6MRqptFMtFs5tBWFrUNp6Raykyp+GnszsAgXqDmY/5qBdIdu+hwPW/63ebWFCooadDh/lHLKin8= X-Received: by 2002:a24:d88b:: with SMTP id b133-v6mr17694966itg.119.1524587311466; Tue, 24 Apr 2018 09:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 09:28:30 -0700 (PDT) In-Reply-To: <08ec0e15-2244-ac90-3acf-d3e4153bcf75@ComodoCA.com> References: <20180320151249.ef2e85feaf05de8edac24479@andrewayer.name> <08ec0e15-2244-ac90-3acf-d3e4153bcf75@ComodoCA.com> From: Ryan Sleevi Date: Tue, 24 Apr 2018 12:28:30 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rob Stradling Cc: Trans , Andrew Ayer Content-Type: multipart/alternative; boundary="00000000000021204f056a9aa529" Archived-At: Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-28: "no security implications" X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 16:28:35 -0000 --00000000000021204f056a9aa529 Content-Type: text/plain; charset="UTF-8" None here. I support this change :) On Fri, Apr 20, 2018 at 5:07 PM, Rob Stradling wrote: > I think this is a good change. I've posted a PR here: > https://github.com/google/certificate-transparency-rfcs/pull/296 > > Anyone have any objections? > > > On 20/03/18 22:12, Andrew Ayer wrote: > >> draft-ietf-trans-rfc6962-bis-28 added the following text to >> section 4.2: >> >> "While there are no security implications to a log accepting >> a submission that does not chain to one of its accepted trust >> anchors..." >> >> This isn't true. The certificate chain enables the logged certificate >> to be attributed to a known trust anchor. This is security-sensitive, >> as without the chain, monitors and trust store operators can't respond >> to a misissued certificate because they don't know which trust anchor >> should be sanctioned/distrusted for misissuing the certificate.[1] >> >> Therefore, this text should be removed. >> >> It might also be a good idea, to avoid any future confusion about this >> requirement, to add "to ensure that logged certificates are attributable >> to a known trust anchor" to the sentence at the beginning of 4.2 that >> explains why the requirement exists. >> >> Regards, >> Andrew >> >> >> [1] In the general case, a monitor could probably construct the chain >> using its own store of intermediate certificates. But this fails if >> the intermediate isn't known, which might happen in the adversarial >> case where an intermediate certificate is issued for the sole purpose >> of evading responsibility for a misissued certificate. >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> >> > -- > Rob Stradling > Senior Research & Development Scientist > Email: Rob@ComodoCA.com > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --00000000000021204f056a9aa529 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
None here. I support this change :)

On Fri, Apr 20, 2018 at 5:07 PM, R= ob Stradling <Rob@comodoca.com> wrote:
I think this is a good change.=C2=A0 I've posted a PR her= e:
https://github.com/google/certi= ficate-transparency-rfcs/pull/296

Anyone have any objections?


On 20/03/18 22:12, Andrew Ayer wrote:
draft-ietf-trans-rfc6962-bis-28 added the following text to
section 4.2:

"While there are no security implications to a log accepting
a submission that does not chain to one of its accepted trust
anchors..."

This isn't true.=C2=A0 The certificate chain enables the logged certifi= cate
to be attributed to a known trust anchor.=C2=A0 This is security-sensitive,=
as without the chain, monitors and trust store operators can't respond<= br> to a misissued certificate because they don't know which trust anchor should be sanctioned/distrusted for misissuing the certificate.[1]

Therefore, this text should be removed.

It might also be a good idea, to avoid any future confusion about this
requirement, to add "to ensure that logged certificates are attributab= le
to a known trust anchor" to the sentence at the beginning of 4.2 that<= br> explains why the requirement exists.

Regards,
Andrew


[1] In the general case, a monitor could probably construct the chain
using its own store of intermediate certificates.=C2=A0 But this fails if the intermediate isn't known, which might happen in the adversarial
case where an intermediate certificate is issued for the sole purpose
of evading responsibility for a misissued certificate.

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


--
Rob Stradling
Senior Research & Development Scientist
Email: Rob@ComodoCA.com


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

--00000000000021204f056a9aa529-- From nobody Tue Apr 24 09:45:33 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A40F12D960 for ; Tue, 24 Apr 2018 09:45:32 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x3p51MVwWNl for ; Tue, 24 Apr 2018 09:45:30 -0700 (PDT) Received: from thompson.beanwood.com (thompson.beanwood.com [IPv6:2600:1f14:a46:c400:6107:163e:4681:134e]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658A612702E for ; Tue, 24 Apr 2018 09:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1524588329; bh=95lCtTGCm+zg7erp2T/hkSkoOWmJlOWoN6rWM5KOX1k=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LTc4H+HJiMh8K5rUTw+dPKCvbBNO82d/zEyhrESRt2TV0GNtZ/PcjcA389jF3CaI/ fElsdxjsEQ8a+1SqbMzqJoYAHoWo8JSDxRELhbq2nb9lsSH0zLssCTJsIiRQgLGslh cYv4PpDg7AIvDlmwsn2X0iCXlPRT5lM6UY8YJhsaazr+56bfJX/g5wj/QzQaIJ+4zn AXaplbAK4/FBMrIDH4cBbcqfsurJT6Wywh9gj0vX+OF212nOtmGYcBLJ9618b+uBHJ c4jE24rFf3nq+JA1O/IUPq8UqXb0LU1V5IzqlRzR5Rf0+imul42lX9JEFqNe44v4U1 qlLla7x9br+HA== Date: Tue, 24 Apr 2018 09:43:10 -0700 From: Andrew Ayer To: Rob Stradling Cc: "trans@ietf.org" Message-Id: <20180424094310.22c8c8c856a3b223becf4b00@andrewayer.name> In-Reply-To: <433531cf-87c6-f7ff-b476-f2210a681a52@ComodoCA.com> References: <433531cf-87c6-f7ff-b476-f2210a681a52@ComodoCA.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Removing the Preventing Tracking Clients section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 16:45:32 -0000 On Fri, 20 Apr 2018 22:13:54 +0100 Rob Stradling wrote: > EKR had some concerns about this section > (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-28#section-11.4). > We (the authors) discussed it and concluded that this section > should probably be struck from 6962-bis. > > PR here: > https://github.com/google/certificate-transparency-rfcs/pull/295 > > Anyone have any objections? Yes. Developing a workable gossip solution will require experimentation to get it right. If log artifacts (STHs and SCTs) can act as supercookies, it will limit the type of experimentation that can be done by TLS clients, as clients won't be able to store and transmit artifacts without potentially violating their users' privacy. Al proposes that this section be moved to a gossip doc, but that creates a circular dependency: logs won't implement an unproven, experimental gossip spec, but proving the viability of the spec will only be possible if logs comply with the spec's anti-tracking provisions. We can avoid the circular dependency by leaving this section in 6962-bis. This will allow TLS clients to experiment with different types of gossip without worrying that the log artifacts that they're gossiping might be supercookies. I'd like to better understand EKR's concern with this section, so I can propose better text. But I don't see any inline comments about this section at https://mozphab-ietf.devsvcdev.mozaws.net/D13 (perhaps I'm not using Phabricator correctly?). Regards, Andrew From nobody Tue Apr 24 12:52:59 2018 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22D12D87B for ; Tue, 24 Apr 2018 12:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOyoNm6l33Bu for ; Tue, 24 Apr 2018 12:52:54 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 C71AD12D877 for ; Tue, 24 Apr 2018 12:52:53 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w3OJqfpp078402 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 24 Apr 2018 21:52:43 +0200 Received: from datan (tor02.zencurity.dk [185.129.62.63]) (authenticated bits=0) by smtp1.sunet.se (8.15.2/8.14.9) with ESMTPSA id w3OJqY4C022678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Apr 2018 19:52:39 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1524599561; bh=y6Vpz9k3+Opsd6T6+H4s0YEW9OprhL94ZhnyRyx4Fhg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=qTUlXhje9VvZP/w/stLPCv15fPAqj9aUIz2kD+9Ry+i651qkZjbAu6B06IGSpB40g l4XGdEWQENy1ClymSMcw6A27JukOXkWEIJLTZdOn0zm7JgmFYF9LBFAdrl7tVu0QAy d0oEc4r5enm+4rHADfF8eB+WnSqu/9leDzlWYsYI= From: Linus Nordberg To: Andrew Ayer Cc: Rob Stradling , "trans\@ietf.org" Organization: Sunet References: <433531cf-87c6-f7ff-b476-f2210a681a52@ComodoCA.com> <20180424094310.22c8c8c856a3b223becf4b00@andrewayer.name> Date: Tue, 24 Apr 2018 21:52:29 +0200 In-Reply-To: <20180424094310.22c8c8c856a3b223becf4b00@andrewayer.name> (Andrew Ayer's message of "Tue, 24 Apr 2018 09:43:10 -0700") Message-ID: <87y3hcidqa.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Bayes-Prob: 0.001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=185.129.62.63; country=DK; latitude=55.7123; longitude=12.0564; http://maps.google.com/maps?q=55.7123,12.0564&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09VCjQGWB - 204b30d80226 - 20180424 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Trans] Removing the Preventing Tracking Clients section X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 19:52:58 -0000 Andrew Ayer wrote Tue, 24 Apr 2018 09:43:10 -0700: > On Fri, 20 Apr 2018 22:13:54 +0100 > Rob Stradling wrote: > >> EKR had some concerns about this section >> (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-28#section-11.4).> We (the authors) discussed it and concluded that this section >> should probably be struck from 6962-bis. >> >> PR here: >> https://github.com/google/certificate-transparency-rfcs/pull/295> >> Anyone have any objections? > > Yes. Developing a workable gossip solution will require experimentation > to get it right. If log artifacts (STHs and SCTs) can act as > supercookies, it will limit the type of experimentation that can be done > by TLS clients, as clients won't be able to store and transmit artifacts > without potentially violating their users' privacy. +1