Responses to author comments and the changes in the new version. ---------- Forwarded message ---------- From: ekr (Eric Rescorla) <[email protected]> Date: Mon, Nov 13, 2017 at 5:34 AM Subject: [Differential] [Requested Changes] D13: draft-ietf-trans-rfc6962-bis-26.txt: 2017-08-18 16:09:04.815339 To: [email protected]
ekr requested changes to this revision. ekr added a comment. This revision now requires changes to proceed. View Revision <https://mozphab-ietf.devsvcdev.mozaws.net/D13> This looks pretty good, but I have a few notes below on things that I still think need to be addressed. *INLINE COMMENTS* View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-535> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:157 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/274 LGTM. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-536> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:336 The blank line between "history tree" and "[CrosbyWallach] proposal"? I've no idea. I only see it here on Phabricator. It's not in the source .md file. kramdown-rfc2629 doesn't add it. "xml2rfc --raw" doesn't add it. "xml2rfc --text" does have a page break at this point though. Could it be a strange artefact of importing the .txt doc into Phabricator? Yeah, probably. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-537> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:625 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/275 "see Section 5.7 might help here", but this is OK View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-539> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:763 Noting that EKR and Ben disagreed on "chose to limit it" versus "chooses to limit it", I propose "imposes any limit", which sidesteps the question of precisely when the log operator made the choice and instead simply refers to the expected current behaviour. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/277 LGTM View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-540> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:785 How else could we achieve our goal (i.e., "To avoid being overloaded by invalid submissions")? Permitting submitters to submit partial chains would require logs to do path construction. This would add complexity to log implementations and would result in the submission process becoming significantly less deterministic: not all logs would have prior knowledge of all existing intermediates; fetching missing intermediates can be unreliable (e.g., AIA->caIssuers URLs absent, or returning HTTP 404, etc). The submitter probably possesses the complete chain already; and if they don't, they might be better placed (than the log) to obtain any missing intermediates (i.e., the submitter might be the CA or a customer of the CA). Therefore, it seems reasonable to require the submitter to provide the complete chain; operational experience with RFC6962 has not found this to be a problem in practice. BTW, note that there are tools available to assist submitters with the task of constructing a chain. e.g., https://crt.sh/gen-add-chain You might avoid being overloaded by charging people to log stuff with your log. I'm not arguing that you shouldn't require submission of complete chains, I'm saying I don't understand why MUST verify is a conformance requirement. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-541> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:816 Superfluous certificates are not allowed. The "chain" input to the submit-entry API (section 5.2) is defined as follows: "An array of zero or more base64 encoded CA certificates. The first element is the certifier of the submission; the second certifies the first; etc. The last element of chain (or, if chain is an empty array, the submission) is certified by an accepted trust anchor." Given the extensive use of cross-certification in the Web PKI, there may be multiple possible chains for a given certificate that a log would accept. In this case, the submitter may submit any one of those chains. >From the TRANS list: EKR: Hmm... So your theory is that the submitter does path construction Ben: Yep - and that's borne out by practice. EKR: OK, well, then it would help if the document were clearer on this point. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/278 (which clarifies that the submitter does path construction). OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-542> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:837 >From earlier in the document... "1.2. Data Structures Data structures are defined and encoded according to the conventions laid out in Section 4 of [RFC5246]." However, I suppose we should revise this TLS 1.2 reference to refer to TLS 1.3 instead... Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/279 OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-543> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:926 That's true, but what's the most logical and sensible lower bound to put in the document? This PKIX thread concluded that the smallest well-formed certificate is 66 octets: https://mailarchive.ietf.org/arch/search/?q=World%27s+smallest+well-formed+ certificate I could change our definition from... opaque TBSCertificate<1..2^24-1>; ...to... opaque TBSCertificate<66..2^24-1>; ...but wouldn't this just cause readers to waste time scratching their heads and wondering "why 66?" ? BTW, TLS 1.3 -21 section 4.4.2 says... case X509: opaque cert_data<1..2^24-1>; So I'm minded to leave our definition as it is. OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-544> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:948 Andrew Ayer wrote: "That's not a problem, since the name of the CA is included in the Issuer field of the TBSCertificate, which is part of the Merkle leaf input along with the CA's public key hash." OK, so it seems like it's safe, but it also seems like the claim about what the hash does may not be correct. Or am I confused? View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-545> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:970 It's daft, but might a log's parameters ever declare a signature algorithm of "null" for testing purposes? BTW, "opaque signature<0..2^16-1>;" appears twice in TLS 1.3 -21. PR wanted for TLS 1.3 :) Anyway, I am OK with leaving it as is, I suppose View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-548> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1163 Ben wrote "The normative requirements are in the various messages below." OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-550> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1432 https://github.com/google/certificate-transparency-rfcs/pull/281 puts these into a table. LGTM View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-551> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1435 Ben wrote "union would probably be a better word." Also being addressed by https://github.com/google/ certificate-transparency-rfcs/pull/281 LGTM View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-552> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1522 Ben wrote "The response includes an STH, which says how big the tree is. Probably should be the latest one known to that server." Also, note that section 8.2 (Monitor) expects monitor clients to fetch and verify the latest STH using get-sth before fetching entries using get-entries. OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-555> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1599 Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 Thanks View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-556> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1627 There's another place in the document where we concatenate TransItems, and that also uses TransItemList - see section 7.1 (Transparency Information X.509v3 Extension). Why wouldn't our approach suffice in any other places you might want to concatenate TransItems? We've been trying to make SCTs and other TransItems as small as possible, so that they add as little bloat as possible to certificates, OCSP responses and TLS handshakes. The theory is: less bloat == less resistance to adoption. I wouldn't do this this way, but it's a WG decision. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-557> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1649 Section 6 of the document says (emphasis mine): "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 client during full TLS handshakes, **where each SCT corresponds to the server certificate**." So yes, there is no explicit support for CT entries for intermediate certs. Should there arise a need for this, note that the extension is extensible (i.e., further VersionedTransType values could be defined by future documents). IIRC, TLS1.3 will have per-certificate TLS extensions, so it may be simple to accommodate CT entries for intermediates for TLS1.3. Thanks. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-558> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1651 This section defines requirements for CT-using TLS Servers, so it's not the appropriate section in which to require that clients send an empty extension. Section 8.1 defines the requirements for TLS Clients; subsection 8.1.1 (Receiving SCTs and inclusion proofs) already says: 'TLS clients that support the "transparency_info" TLS extension SHOULD include it in ClientHello messages, with empty "extension_data".' Requiring "the server to validate that it is in fact empty" is being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-559> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1654 I think part of the reason we wrote this "SHOULD" is that we want to encourage the use of the "transparency_info" TLS extension, because it offers more agility than embedding TransItems in certs / OCSP responses. But yes, we want to avoid duplicating the same information, and I agree that the current text needs some improvement in that regard. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 LGTM. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-677> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1722 I'm not yet sufficiently familiar with the TLS 1.3 draft to be able to do that. I guess I can live without it. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-567> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1823 Isn't this already covered by "CT-using 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 client during full TLS handshakes..." ? i.e., If a TLS server elects to not use "transparency_info", then it follows that it "MUST use" at least one of the other two mechanisms (SCTs embedded in the cert or stapled OCSP response)! "Trying to reconstruct the reasoning here" We could be more explicit about the reasoning. Being addressed by https://github.com/google/certificate-transparency-rfcs/pull/283 LGTM. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-667> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:1912 That's covered by the paragraph below: A TLS client (Section 8.1) can audit by verifying an SCT against any STH dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle inclusion proof (Section 5.4). OK. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-670> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2009 That was the outcome of this thread: https://mailarchive.ietf.org/ arch/search/?q=The+RFC6979+requirement+in+RFC6962-bis+is+bad OK View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-671> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2150 Fair enough. I propose to switch to First Come First Served then. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/287 LGTM. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-672> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2163 I think you're referring to the "or that the log has misbehaved, which will be discovered when the SCT is audited" clause, which I'll therefore propose to drop. Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/288 LGTM View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-674> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2237 The risk is against "Clients that gossip STHs or report back SCTs can be tracked or traced if..." Not sure about incentives. Maybe we should change it to a MUST, so that violating this requirement becomes a clear case of log misbehaviour? I think "tracked or traced" by who. As far as a deterministic scheme, that seems like a wg decision, but what would be the implication for RSA-PSS? View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-675> robstradling wrote in draft-ietf-trans-rfc6962-bis.txt:2243 I'll propose to rephrase this as "By requiring...TLS clients reduce..." Being addressed by https://github.com/google/certificate-transparency-rfcs/ pull/282 LGTM. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-1011> draft-ietf-trans-rfc6962-bis.txt:2006 the "transparency_info" extension in the ServerHello with the "extension_data" set to this "TransItemList". I think this last point needs to be a MUST if you want to ensure the client gets the data. View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D13#inline-1004> draft-ietf-trans-rfc6962-bis.txt:2304 6. Repeat from step 6. This doesn't seem right, because this is step 6. *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D13 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr *Cc: *robstradling
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
