From nobody Mon Feb 24 09:52:05 2020 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 5C4F53A0FD9; Mon, 24 Feb 2020 09:52:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, trans@ietf.org, Paul Wouters , paul@nohats.ca X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158256672236.5218.5900524348687725605.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2020 09:52:02 -0800 Archived-At: Subject: [Trans] Roman Danyliw's Yes on draft-ietf-trans-rfc6962-bis-34: (with COMMENT) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:52:03 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-trans-rfc6962-bis-34: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Adding a Yes ballot with comments on my own document as it was inherent during an AD change) ** Section 2.2 and 3.2. Reference the IANA registry name, not just the document section -- Section 2.2. Per “A log MUST use one of the signature algorithms defined in Section 10.3.”, recommend instead saying that the acceptable signature algorithms are defined in “the IANA ‘CT Signature Algorithms’ registry described in Section 10.3. -- Section 3.2. Per the digestAlgorithm “MUST be one of the hash algorithm OIDs listed in Section 10.2”, recommend instead saying “MUST be one of the hash algorithms OIDs listed in the IANA ‘CT Hash Algorithms’ registry described in Section 10.2”. ** Section 4.13. Per the list of guidance on shutting down a log following “[t]o avoid that, the following actions are suggested:”, should normative language be used in making this recommendation. Perhaps “To avoid that the following actions are RECOMMENDED:” or “To avoid that the following actions SHOULD be taken:”? ** Section 4.13. Per “Make it known to clients and monitors that the log will be frozen.”, I recommend clarifying that this is via some out-of-band/out-of-scope mechanism not defined in the Section 5.x API. ** Section 5.1, 5.3, 5.4, 5.6. Each of these sections helpfully lists the possible errors given the action, however, the corresponding HTTP response codes is not clear. ** Section 11.3 and 11.4. Do the following references to gossip still make sense since ietf-trans-gossip is not proceeding? -- (Section 11.3) “There are various ways this could be done, for example via gossip (see [I-D.ietf-trans-gossip]) …” -- (Section 11.4) “Clients that gossip STH …”, if the gossip reference is removed, using this verb doesn’t make sense. ** Editorial nits: -- Per “Various data structures Section 1.2 are signed”: o s/Section 1.2/in Section 1.2/ o practically, there are no data structures in Section 1.2, only a reference to a presentation language of available data structures. From nobody Mon Feb 24 12:44:40 2020 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E43A12C5 for ; Mon, 24 Feb 2020 12:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTrfpNOpPthb for ; Mon, 24 Feb 2020 12:44:37 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 AC7423A12C7 for ; Mon, 24 Feb 2020 12:44:37 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01OKiajm037546 for ; Mon, 24 Feb 2020 15:44:36 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 01OKiajm037546 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1582577076; bh=QzcyGeDkekvvqavViadq6gqgBxpLZG+sZsS7dsIHY1w=; h=From:To:Subject:Date:From; b=AMW1+mK5tzDjUCeCpA6SJ69suIrTzwqzXDfAEAfS/XRVgivhR7Nzf8UolHq/LKHre /PGuhWptbTMimrrl/K/b0Y/ssY5iXqSGPv942InNMhxGnIwFUDxhIdD8GlVJeNPU84 D2JrK0VYXrupjcJuWbjoB1Nhd3GK3H9Hi4L2H0Mg= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 01OKiYmp038470 for ; Mon, 24 Feb 2020 15:44:34 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 15:44:34 -0500 From: Roman Danyliw To: "trans@ietf.org" Thread-Topic: Summary of DISCUSS items for draft-ietf-trans-rfc6962-bis Thread-Index: AdXrTUfm8XWVAz9CSdW38cgkiAaelg== Date: Mon, 24 Feb 2020 20:44:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F4C1D7@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Trans] Summary of DISCUSS items for draft-ietf-trans-rfc6962-bis X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 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, 24 Feb 2020 20:44:39 -0000 Hi! I just balloted YES with a few comments on draft-ietf-trans-rfc6962-bis. T= o follow-up on Paul's earlier summary [1], I saw that some discussion has o= ccurred in response to the IESG ballot but wanted to check-in with the auth= ors on the disposition of addressing the remaining DISCUSS items. [1] https://mailarchive.ietf.org/arch/msg/trans/9zGMHr_Fu1EefWbvthvqSANl3nA= / =3D=3D[ Ben Kaduk From: https://mailarchive.ietf.org/arch/msg/trans/2Sc26GMFwQnTRl5DEEk_-51AB= FU/ Item #1 Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and inclusion proofs, respectively, with minimum array size of 1. However, Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the possibility of zero-length proofs in degenerate cases, which the aforementioned protocol description language forbids the conveyance of. (Section 5.3 explicitly requires the use of an empty consistency proof.) Do those minimum array sizes need to be (implicit) zero? (If they do not, it seems that a minimum size of 32 would have the same effect as that of one, since a NodeHash has minimum size 32.) Item #2 In Section 6: o An Online Certificate Status Protocol (OCSP) [RFC6960] response extension (see Section 7.1.1), where the OCSP response is provided in the "CertificateStatus" message, provided that the TLS client included the "status_request" extension in the (extended) "ClientHello" (Section 8 of [RFC6066]). [...] This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not use the "CertificateStatus message", but rather uses the encoding of that structure in a status_request extension in the CertificateEntry. draft-ietf-trans-rfc6962-bis =3D=3D=3D =3D=3D[ Mirja K=FChlewind From: https://mailarchive.ietf.org/arch/msg/trans/0R9dKzZ4h2bLQX4pyHqwdA4uV= do/ There was a presentation at maprg IETF 103 about the question=20 if CT helps attackers to find new domains. I think this risk should at=20 least be mentioned in the security considerations section. [Roman] Pending review by Mirja. Section 11.6 was added. =3D=3D=3D =3D=3D[ Alexey Melnikov From: https://mailarchive.ietf.org/arch/msg/trans/qiURoDHiWrP1l7X3WY9RRvYrW= Fg/ 5. Log Client Messages type: A URN reference identifying the problem. To facilitate automated response to errors, this document defines a set of standard tokens for use in the "type" field, within the URN namespace of: "urn:ietf:params:trans:error:". I think you need to register this in =3D=3D=3D Regards, Roman From nobody Tue Feb 25 02:03:34 2020 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 7ADA93A07F1; Tue, 25 Feb 2020 02:03:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, trans@ietf.org, Paul Wouters , paul@nohats.ca X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158262500249.15511.17475010232903674131.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 02:03:22 -0800 Archived-At: Subject: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-trans-rfc6962-bis-34=3A_=28with_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 10:03:23 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-trans-rfc6962-bis-34: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and adding some more text in the security consideration section! I believe all comments below are still valid, expect 2 which is a nit that was fixed. I would really like to see some recommendations on point 5 before this document moves on! 1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms? Maybe that could be further clarified 2) Please expand STH on first occurrence (in sec 4.1) 3) Sec 4.4: „A log's operator MUST either allocate the OID themselves or request an OID from the Log ID Registry (see Section 10.6.1).“ Isn't there an obligation to register? 4) sec 4.8: „If an implementation sees an extension that it does not understand, it SHOULD ignore that extension.“ Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not? 5) sec 5: „MAY retry the same request without modification at a later date.“ Would it be possible to provide a recommendation how long the client should wait? 6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per "get-entries" request.“ Should this be added to sec 4.1? 7) sec 10.3: Couldn’t you use the TLS SignatureScheme Registry directly (instead of forming an own registry)? 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry? 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 recommend to always (clearly) name the registry. And finally one higher level question mainly out of curiosity: was it considered to e.g. use json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?