From nobody Sun Sep 3 16:17:55 2017 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 5438B13240D for ; Sun, 3 Sep 2017 16:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 hyD6U0snczOt for ; Sun, 3 Sep 2017 16:17:51 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED5313247A for ; Sun, 3 Sep 2017 16:17:50 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t188so18773246ywb.1 for ; Sun, 03 Sep 2017 16:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=n1LosaGmyk9igZG8zKX4irrDUPCEGTA0y6rUnBgpH8k=; b=SyevwqxyOS73WI6nET9zsKHNnjeIKpeOgpYXd1lxrqKC+AYPpx1sLkXCrf5+LLucKB nYEzNctbhwGsc6saFVlYOerfrw9lg2fTZA29OetSLmUVD4OW0jWlUVZ7a9ojc2upevZ4 utkgh6hunFLEnKcjas70d/LFcOa5QgNtN3q6+Z6YN1qkgdoayaW8S6/Rdg8p5cqaEGl5 zbaneWcX6kXZcq968DfLDyGUE2E/tHNCzqyTBcDm3dECBWoiRo+Tcfz5l6MG8gOmIVqv lCcN2k09q+e5cVTJ4b6hLidQVs1ipEUWFTyNFu7GP5DE9PPtWDOhJ5VzUPthcAHWLZPi LPgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n1LosaGmyk9igZG8zKX4irrDUPCEGTA0y6rUnBgpH8k=; b=jMJkzJnLKB2h9v62XHEL4wWAueKTlNZkVIJIA6ZL4hDT4YrcPGb1Bb8fA3GgR7zoH/ +oi8neLnaFCUsthbAk8yw1e5LC+La69jol8TqOcPD7W76brVZSMv+XsNX+wOJzBV907/ +5S1t9LgfZZTi7xPXUUkwuGvjv9wIREzMXlVjqS5doz8HEkyOj4trdCPbB81aKWDvrmu redbqMPK0esRtN+DW23efMcF3g5TQ5BzNSWwH9bzK+0A6DC4c0LPwcKv34Ygh0bwLG1D pPtcRDXPZokV5flskTn1yFRGBe0vmS4gIkcMEZgGBrSxQoXfO67eaHvrnie9kq4gCd3E UeVw== X-Gm-Message-State: AHPjjUj9S6IQLYIUV6ZlKS2yWLr9PdPKR26Bh01YDnko1uu0lF6qUdO6 buLS6OgQT8vR/stdyJGQS9LqqnvSnoETW1oMvQ== X-Google-Smtp-Source: ADKCNb5LL2S0O6zXoG2nU/9HiL8i5l8KKWim97jw+/iDTYAG9B9GDVzWtu6PwzLWSxSo4IYQrnj/1D50iops6stKU3E= X-Received: by 10.129.168.131 with SMTP id f125mr7560689ywh.19.1504480669808; Sun, 03 Sep 2017 16:17:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sun, 3 Sep 2017 16:17:09 -0700 (PDT) From: Eric Rescorla Date: Sun, 3 Sep 2017 16:17:09 -0700 Message-ID: To: trans@ietf.org Content-Type: multipart/alternative; boundary="94eb2c13cbe2e550ce05585133e6" Archived-At: Subject: [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: Sun, 03 Sep 2017 23:17:54 -0000 --94eb2c13cbe2e550ce05585133e6 Content-Type: text/plain; charset="UTF-8" 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. I've noted a number of places in my review in detail, but in general, you need to scale back all the claims of third-party verifiability to make clear what you get with: (a) the current system vs. (b) a system in which the missing third-party verifiability pieces were filled in. 2. You need to work out how the various TLS extensions work for TLS 1.3. I suppose you could persuade me that this is a followon piece of work, but given that TLS 1.3 is in a similar state of maturity, that seems kind of silly. INLINE COMMENTS Line 157 The logs do not need to be trusted because they are publicly auditable. Anyone may verify the correctness of each log and monitor when new certificates are added to it. The logs do not themselves This may be the objective, but it doesn't seem to be what CT actually delivers in practice. Line 336 [CrosbyWallach] proposal, except our definition handles non-full trees differently). NIT: what happened here? Line 625 chain up to an accepted trust anchor. The trust anchor (a root or intermediate CA certificate) MAY be omitted from the submission. How does the submitter know what an accepted trust anchor is? Please provide a reference to the appropriate section here. Line 735 of the tree. * Sign the root of the tree (see Section 4.10). The log may append multiple entries before signing the root of the tree. I think you mean for these to be bullets with line breaks. Line 763 Maximum Chain Length: The longest chain submission the log is willing to accept, if the log chose to limit it. Nit: chooses 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 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? 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, 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? Line 970 Extension sct_extensions<0..2^16-1>; opaque signature<0..2^16-1>; } SignedCertificateTimestampDataV2; Why is signature 0 bytes? Certainly it must be at least 1. Line 1155 Note that JSON objects and URL parameters may contain fields not specified here. These extra fields should be ignored. Is this a 2119 SHOULD? Line 1163 errors may occur that are caused by skew between the machines. Where such errors are possible, the front-end will return additional information (as specified below) making it possible for clients to "will"? What's the normative force of this? Line 1233 (or, if "chain" is an empty array, the "submission") is certified by an accepted trust anchor. IMPORTANT: Is the implication here that the log is not supposed to do path construction because the submitter provides a complete path? Line 1432 index of requested hash < latest STH Return "inclusion". This would be clearer with colons or dashes or somesuch. " latest STH < requested STH: Return latest STH" Line 1435 Note that more than one case can be true, in which case the returned data is their concatenation. It is also possible for none to be true, in which case the front-end MUST return an empty It's not actually concatenation, right? It's all the fields. 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? 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. 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. --94eb2c13cbe2e550ce05585133e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Please find enclos= ed the first cut of my AD review of this draft.

No= te: the original of this review is on Phabricator at:

<= div>=C2=A0 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.=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
tha= t 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 th= e 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 Certi= ficate 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 e= xtensive 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<= /div>
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 req= uire
trusting the logs. This is implicitly acknowledged by propos= als that
RPs only accept certificates with >1 SCT. I've no= ted a number of
places in my review in detail, but in general, yo= u need to scale back
all the claims of third-party verifiability = to make clear what you get
with:

(a) the= current system
vs.
(b) a system in which the missing t= hird-party verifiability pieces were filled in.

2.= You need to work out how the various TLS extensions work for TLS
1.3.=C2=A0 I suppose you could persuade me that this is a followon piece o= f
work, but given that TLS 1.3 is in a similar state of maturity,= that
seems kind of silly.


INLINE COMMENTS
Line 157
=C2=A0 =C2=A0The logs do not= need to be trusted because they are publicly
=C2=A0 =C2=A0audita= ble.=C2=A0 Anyone may verify the correctness of each log and monitor
<= div>=C2=A0 =C2=A0when new certificates are added to it.=C2=A0 The logs do n= ot themselves
This may be the objective, but it doesn't seem = to be what CT actually delivers in practice.


<= /div>
Line 336
=C2=A0 =C2=A0[CrosbyWallach] proposal, except = our definition handles non-full
=C2=A0 =C2=A0trees differently).<= /div>
NIT: what happened here?


= Line 625
=C2=A0 =C2=A0chain up to an accepted trust anchor.=C2=A0= The trust anchor (a root or
=C2=A0 =C2=A0intermediate CA certifi= cate) MAY be omitted from the submission.
How does the submitter = know what an accepted trust anchor is? Please provide a reference to the ap= propriate section here.


Line 735
=C2=A0 =C2=A0of the tree. =C2=A0* Sign the root of the tree (see Se= ction 4.10).=C2=A0 The
=C2=A0 =C2=A0log may append multiple entri= es before signing the root of the tree.
I think you mean for thes= e to be bullets with line breaks.


L= ine 763
=C2=A0 =C2=A0Maximum Chain Length: =C2=A0The longest chai= n submission the log is
=C2=A0 =C2=A0 =C2=A0 willing to accept, i= f the log chose to limit it.
Nit: chooses


Line 785
=C2=A0 =C2=A0accepted trust anchor, usi= ng only the chain of intermediate CA
=C2=A0 =C2=A0certificates pr= ovided by the submitter.
Why is this a 2119 MUST? It seems wise, = but not necessarily a conformance requirement


=
Line 816
=C2=A0 =C2=A0anchor used to verify the chain = (even if it was omitted from the
=C2=A0 =C2=A0submission).=C2=A0 = The log MUST present this chain for auditing upon
=C2=A0 =C2=A0re= quest (see Section 5.6).=C2=A0 This prevents the CA from avoiding blame
What happens in cases of multiple chains. For instance, say that the= submitter provides superfluous certificates?


=
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,


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


Li= ne 948
=C2=A0 =C2=A0"tbs_certificate".=C2=A0 The length= of the "issuer_key_hash" MUST match
=C2=A0 =C2=A0HASH_= SIZE.
Is this true? What happens if we have two CAs that share a = key?


Line 970
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extension sct_extensions<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque signature<0..2^= 16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0} SignedCertificateTimestamp= DataV2;
Why is signature 0 bytes? Certainly it must be at least 1= .


Line 1155
=C2=A0 =C2=A0= Note that JSON objects and URL parameters may contain fields not
= =C2=A0 =C2=A0specified here.=C2=A0 These extra fields should be ignored.
Is this a 2119 SHOULD?


Line= 1163
=C2=A0 =C2=A0errors may occur that are caused by skew betwe= en the machines.=C2=A0 Where
=C2=A0 =C2=A0such errors are possibl= e, the front-end will return additional
=C2=A0 =C2=A0information = (as specified below) making it possible for clients to
"will= "? What's the normative force of this?

Line 1233
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or, if = "chain" is an empty array, the "submission") is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0certified by an accepted trust anchor.=
IMPORTANT: Is the implication here that the log is not supposed = to do path construction because the submitter provides a complete path?

Line 1432
=C2=A0 =C2=A0 =C2=A0 index of req= uested hash < latest STH =C2=A0Return "inclusion".
T= his would be clearer with colons or dashes or somesuch.

" latest STH < requested STH: Return latest STH"


Line 1435
=C2=A0 =C2=A0 =C2=A0 N= ote that more than one case can be true, in which case the
=C2=A0= =C2=A0 =C2=A0 returned data is their concatenation.=C2=A0 It is also possi= ble for
=C2=A0 =C2=A0 =C2=A0 none to be true, in which case the f= ront-end MUST return an empty
It's not actually concatenation= , right? It's all the fields.


L= ine 1522
=C2=A0 =C2=A0permissible.=C2=A0 These entries SHALL be s= equential beginning with the
=C2=A0 =C2=A0entry specified by &quo= t;start".
How does the client know which of the above two ca= ses has occurred?


Line 1552
=C2=A0 =C2=A0TLS servers MUST use at least one of the three mechanisms l= isted
=C2=A0 =C2=A0below 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&#= 39;s not a new requirement on all TLS servers.

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


Line 1599
=C2=A0 =C2=A0 =C2=A0 misissuance f= rom clients.=C2=A0 Including SCTs from different 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&#= 39;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_item_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 make TransItem= s self-contained (by having a defined length field). What about other place= s I might want to concatenate TransItems. Why don't you instead make Tr= ansItem 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: Time= stampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 case precert_entry_v2: TimestampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case x509_sct_v2: = SignedCertificateTimestampDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 case precert_sct_v2: SignedCertificateTimestampDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case signed_tree_h= ead_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 th= e universal TLS convention.


Line 16= 49
6.4. =C2=A0transparency_info TLS Extension
This exte= nsion appears not to have any explicit support for CT entries for intermedi= ate certs. Am I just supposed to glue together all the TransItems?


Line 1651
=C2=A0 =C2=A0Provided t= hat a TLS client includes the "transparency_info" extension
=
=C2=A0 =C2=A0type in the ClientHello, the TLS server SHOULD include th= e
You need to provide an actual definition of what the client inc= ludes, and having the server ignore the contents is bad mojo. TLS conventio= n is for the client to include an empty extension and the server to validat= e that it is in fact empty.


Line 16= 54
=C2=A0 =C2=A0"transparency_info" extension in the Se= rverHello with
=C2=A0 =C2=A0"extension_data" set to a &= quot;TransItemList".=C2=A0 The TLS server SHOULD
=C2=A0 =C2= =A0ignore any "extension_data" sent by the TLS client.=C2=A0 Addi= tionally,
IMPORTANT: The normative language here is kind of confu= sing. It SHOULD include the extension but if it's included, it MUST con= sist 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 info= rmation 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 on= ce, so that it should only send the extension if it contains information th= at'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 OCS= P and certs, it's always sent twice, because the client doesn't kno= w where the info is, and so has to always offer the extension.

Line 1658
=C2=A0 =C2=A0session is res= umed, since session resumption uses the original
=C2=A0 =C2=A0ses= sion information.
Does this mean the client MUST abort the handsh= ake if the server includes it?


Line= 1668
=C2=A0 =C2=A0o =C2=A0The TLS client includes the "tran= sparency_info" extension type in
=C2=A0 =C2=A0 =C2=A0 the Cl= ientHello.
This condition is non-sensical, because if the client = *doesn't* include the extension, the server cannot send the transparenc= y_info extension at all.


Line 1722<= /div>
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.
Gi= ven the somewhat science fictional status of Gossip, this entire paragraph = should be stricken


Line 1747
<= div>=C2=A0 =C2=A0MUST implement all of the three mechanisms by which TLS se= rvers may
=C2=A0 =C2=A0present SCTs (see Section 6).=C2=A0 TLS cl= ients MAY also accept SCTs via
=C2=A0 =C2=A0the "status_requ= est_v2" extension ([RFC6961]).=C2=A0 TLS clients that
IMPORT= ANT: This also needs to be rewritten so it makes clear it's not a gener= al 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 para= meters.=C2=A0 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
=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 sligh= tly wrong, this is going to cause new certs to fail even if they otherwise = would have succeeded (because the notBefore and notAfter are more conservat= ive).


Line 1800
=C2=A0 = =C2=A0will disclose to the log which TLS server the client has been
=C2=A0 =C2=A0communicating with.
IMPORTANT: This "Note&qu= ot; just mentions in passing a huge privacy issue. You need to be a lot cle= arer about this.

Line 1823
=C2=A0 =C2=A0= "transparency_info" and "status_request" TLS extensions= in the
=C2=A0 =C2=A0ClientHello.
IMPORTANT: This is no= t consistent with the requirements on the server.
Trying to recon= struct the reasoning here, the client can only decide that the server is no= ncompliant if it has given the server a chance to send the SCTs by every me= chanism., otherwise the server might just want to send the SCT some other w= ay. However, if servers can optionally ignore transparency_info (it's a= SHOULD above), then you can have two compliant implementations with the se= rver having a CT-compliant cert and yet the client declares it noncompliant= . To fix this, you need to require the server to respond to "transpare= ncy_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 shou= ld explain why this is one byte long (that the PDU is defined as having a m= inimum length of 1). Also the server should be required to check it.
<= div>

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 to keep copi= es.... 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 t= o verify that they don't contain bogus data (e.g., certificates for you= r 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 od= d 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=A0STH= s it receives, ensure that each entry can be fetched and that the
=C2=A0 =C2=A0STH is indeed the result of making a tree from all fetched en= tries.
IMPORTANT: How do you verify MMD?

Line 1944
=C2=A0 =C2=A0If it should become necessary to deprecat= e an algorithm used by a
=C2=A0 =C2=A0live log, then the log shou= ld be frozen as specified in Section 4.13
=C2=A0 =C2=A0and a new = log should be started.=C2=A0 Certificates in the frozen 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
=C2=A0 =C2=A0identified= by the allocated Log ID).
This seems like it's not a great t= hing to be asking an expert to do, as it seems to require business arrangem= ents. Is it really that valuable to save a few bytes here?


Line 2163
=C2=A0 =C2=A0that the log has m= isbehaved, which will be discovered when the SCT is
=C2=A0 =C2=A0= audited.=C2=A0 A signed timestamp is not a guarantee that the certificate
=C2=A0 =C2=A0is not misissued, since appropriate monitors might no= t 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.

Li= ne 2182
=C2=A0 =C2=A0operating correctly.=C2=A0 As a log is allow= ed to serve an STH that's up
=C2=A0 =C2=A0to MMD old, the max= imum period of time during which a misissued
=C2=A0 =C2=A0certifi= cate can be used without being available for audit is twice
Nit: = up to the MMD old


Line 2211
=C2=A0 =C2=A0compute the proofs from the log) or communicate with the lo= g via
=C2=A0 =C2=A0proxies.
This also seems quite handw= avy in light of the facts on the ground.


Line 2237
=C2=A0 =C2=A0 =C2=A0 and STHs can be stored by th= e log and served to other clients that
=C2=A0 =C2=A0 =C2=A0 submi= t 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, wh= at's the logs incentive?


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

--94eb2c13cbe2e550ce05585133e6-- From nobody Tue Sep 5 09:05:11 2017 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 ABFA0132D6C for ; Tue, 5 Sep 2017 09:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p7ZD4YUaSfl for ; Tue, 5 Sep 2017 09:05:01 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27E6132D6F for ; Tue, 5 Sep 2017 09:05:00 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id c82so669429vkd.4 for ; Tue, 05 Sep 2017 09:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ttP76MM2ym8VGLHJRSgVHJvOfO01GR3h2/1g+CSyxE=; b=b11SGru0RhkxQrvGCy1voyYKbfAdMw4KkQOG/AIVJMGI1ptbsbUWmQxXonMoHa2Pax 6WF5e5oP6LHFlUwNtixUlJIWyIRJ08cI1h0rJDk0LUZpfhNUnTRsxKUiPmh1hxai2Jbq txRn2rsviT9w9uKVLub5DJ6fQxECd6DPAuNnQ+dC29PVSfzZQphyRfCjHo4weRuS28OJ RdIdBtVMlWUdUkJphR51AMj1vMvNdk0kLNPYGDw+IL2X1cTUEB1Vk8+NSeOkxXSR6xMw Ub23S1w+HpHo8yUjJYFfj9kDVN8cwSK6T8p6Gt9kJMSvQBKe6svpUvR4IF4fI2wqcK0S AbWA== 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=/ttP76MM2ym8VGLHJRSgVHJvOfO01GR3h2/1g+CSyxE=; b=OH4XRwdbqtbwbCo6BqngUNHfbALYaC1Jx1BGGr5HTLDzRnbUPDVT/Q6bgEo4wr/K6U q+88xZjTapJMU2VZ0j7Dmmxfi5TJT1puLkekNCIABSHIjwZyXFuFZTP1p43gzSZa55MS sCh1XWqfL8Ji/whyO4AASG62a/lcF1YkRCZeHJnE6YHjua/ihG43sEk6mvAtvKA5YPQL +MDXRshLOfli6Mj3YPBXHuA42c0dPjZrEds5XoqeYrpXNLYO6KIr74zw0PhNmYrYSSDp WIZF+41Lzhb90OG7bIoGXS8WRWSD+gAjOdYC7K1gttAir9TKjTSwj4PJzX3ZT+p5DYok L68Q== X-Gm-Message-State: AHPjjUjvKAOYIfvF7RlTgo7C6k7cUUfkjBPMX1phGpxoYg83rsJHc+Gf xl/FhDhKKGxexZe/cjT6wNQcSAn0Kys6 X-Google-Smtp-Source: ADKCNb5fDOu1NtVdWdTaFNuu5ZSnQdWTlDw6nv6W6DWIbbXKZwtKt66jGa+FD6FvyYSj7IZ/nFh+Y7D6BekgYVxrNLQ= X-Received: by 10.31.175.134 with SMTP id y128mr2097322vke.165.1504627499382; Tue, 05 Sep 2017 09:04:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.183.200 with HTTP; Tue, 5 Sep 2017 09:04:56 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Tue, 5 Sep 2017 17:04:56 +0100 Message-ID: To: Eric Rescorla Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a1143fc569f71e805587363eb" 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: Tue, 05 Sep 2017 16:05:10 -0000 --001a1143fc569f71e805587363eb Content-Type: text/plain; charset="UTF-8" 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. > I've noted a number of > places in my review in detail, but in general, you need to scale back > all the claims of third-party verifiability to make clear what you get > with: > > (a) the current system > vs. > (b) a system in which the missing third-party verifiability pieces were > filled in. > > 2. You need to work out how the various TLS extensions work for TLS > 1.3. I suppose you could persuade me that this is a followon piece of > work, but given that TLS 1.3 is in a similar state of maturity, that > seems kind of silly. > > > INLINE COMMENTS > Line 157 > The logs do not need to be trusted because they are publicly > auditable. Anyone may verify the correctness of each log and monitor > when new certificates are added to it. The logs do not themselves > This may be the objective, but it doesn't seem to be what CT actually > delivers in practice. > > > Line 336 > [CrosbyWallach] proposal, except our definition handles non-full > trees differently). > NIT: what happened here? > > > Line 625 > chain up to an accepted trust anchor. The trust anchor (a root or > intermediate CA certificate) MAY be omitted from the submission. > How does the submitter know what an accepted trust anchor is? Please > provide a reference to the appropriate section here. > > > Line 735 > of the tree. * Sign the root of the tree (see Section 4.10). The > log may append multiple entries before signing the root of the tree. > I think you mean for these to be bullets with line breaks. > > > 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? > > > 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" > > > 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. > > > 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. > > > 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? > > > Line 970 > Extension sct_extensions<0..2^16-1>; > opaque signature<0..2^16-1>; > } SignedCertificateTimestampDataV2; > Why is signature 0 bytes? Certainly it must be at least 1. > > > Line 1155 > Note that JSON objects and URL parameters may contain fields not > specified here. These extra fields should be ignored. > Is this a 2119 SHOULD? > Probably should be. > > > Line 1163 > errors may occur that are caused by skew between the machines. Where > such errors are possible, the front-end will return additional > information (as specified below) making it possible for clients to > "will"? What's the normative force of this? > The normative requirements are in the various messages below. > > > Line 1233 > (or, if "chain" is an empty array, the "submission") is > certified by an accepted trust anchor. > IMPORTANT: Is the implication here that the log is not supposed to do path > construction because the submitter provides a complete path? > Yes. > > Line 1432 > index of requested hash < latest STH Return "inclusion". > This would be clearer with colons or dashes or somesuch. > > " latest STH < requested STH: Return latest STH" > Agree. > > > Line 1435 > Note that more than one case can be true, in which case the > returned data is their concatenation. It is also possible for > none to be true, in which case the front-end MUST return an empty > It's not actually concatenation, right? It's all the fields. > union would probably be a better word. > > > 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? > 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 > > --001a1143fc569f71e805587363eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 4 September 2017 at 00:17, Eric Rescorla <ekr@rtfm.com> wr= ote:
=
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:


= 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 probl= ems.

-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-Le= vel:

1. This document makes a variety of claims ab= out the assurances that
clients get that only obtain if some as-y= et-to-be-specified
third-party verifiability mechanism is impleme= nted. 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 publ= icly
=C2=A0 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 al= so
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 a= void the death of a single log causing the death of a large number of certi= ficates. It is not about trust.
=C2=A0
I've noted a number= of
places in my review in detail, but in general, you need to sc= ale back
all the claims of third-party verifiability to make clea= r what you get
with:

(a) the current sys= tem
vs.
(b) a system in which the missing third-party v= erifiability pieces were filled in.

2. You need to= work out how the various TLS extensions work for TLS
1.3.=C2=A0 = I suppose you could persuade me that this is a followon piece of
= work, but given that TLS 1.3 is in a similar state of maturity, that
<= div>seems kind of silly.


INLINE COM= MENTS
Line 157
=C2=A0 =C2=A0The logs do not need to be = trusted because they are publicly
=C2=A0 =C2=A0auditable.=C2=A0 A= nyone may verify the correctness of each log and monitor
=C2=A0 = =C2=A0when new certificates are added to it.=C2=A0 The logs do not themselv= es
This may be the objective, but it doesn't seem to be what = CT actually delivers in practice.


L= ine 336
=C2=A0 =C2=A0[CrosbyWallach] proposal, except our definit= ion handles non-full
=C2=A0 =C2=A0trees differently).
N= IT: what happened here?


Line 625
=C2=A0 =C2=A0chain up to an accepted trust anchor.=C2=A0 The trust = anchor (a root or
=C2=A0 =C2=A0intermediate CA certificate) MAY b= e omitted from the submission.
How does the submitter know what a= n accepted trust anchor is? Please provide a reference to the appropriate s= ection here.


Line 735
=C2= =A0 =C2=A0of the tree. =C2=A0* Sign the root of the tree (see Section 4.10)= .=C2=A0 The
=C2=A0 =C2=A0log may append multiple entries before s= igning the root of the tree.
I think you mean for these to be bul= lets with line breaks.


Line 763
=C2=A0 =C2=A0Maximum Chain Length: =C2=A0The longest chain submissio= n the log is
=C2=A0 =C2=A0 =C2=A0 willing to accept, if the log c= hose to limit it.
Nit: chooses

<= /div>
Past tense seems correct?
=C2=A0


<= /div>
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 requirement

"To avoid= being overloaded by invalid submissions"
=C2=A0

Line 816
=C2=A0 =C2=A0anchor used to = verify the chain (even if it was omitted from the
=C2=A0 =C2=A0su= bmission).=C2=A0 The log MUST present this chain for auditing upon
=C2=A0 =C2=A0request (see Section 5.6).=C2=A0 This prevents the CA from a= voiding blame
What happens in cases of multiple chains. For insta= nce, say that the submitter provides superfluous certificates?
<= /blockquote>

Not allowed.
=C2=A0

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

See s1.2.

=C2= =A0


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


<= /div>
Line 948
=C2=A0 =C2=A0"tbs_certificate".=C2= =A0 The length of the "issuer_key_hash" MUST match
=C2= =A0 =C2=A0HASH_SIZE.
Is this true? What happens if we have two CA= s that share a key?

Eh?
=C2=A0


Line 970
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extension sct_extensions<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque signature<0..2^= 16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0} SignedCertificateTimestamp= DataV2;
Why is signature 0 bytes? Certainly it must be at le= ast 1.


Line 1155
=C2=A0 = =C2=A0Note that JSON objects and URL parameters may contain fields not
=C2=A0 =C2=A0specified here.=C2=A0 These extra fields should be ignor= ed.
Is this a 2119 SHOULD?

Probably should be.
=C2=A0


= Line 1163
=C2=A0 =C2=A0errors may occur that are caused by skew b= etween the machines.=C2=A0 Where
=C2=A0 =C2=A0such errors are pos= sible, the front-end will return additional
=C2=A0 =C2=A0informat= ion (as specified below) making it possible for clients to
"= will"? What's the normative force of this?

The normative requirements are in the various messages= below.
=C2=A0


Line 1233
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or, if "chain" is an empty a= rray, the "submission") is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0certified by an accepted trust anchor.
IMPORTANT: Is the im= plication here that the log is not supposed to do path construction because= the submitter provides a complete path?

<= /div>
Yes.
=C2=A0

Line 1432
=C2=A0= =C2=A0 =C2=A0 index of requested hash < latest STH =C2=A0Return "i= nclusion".
This would be clearer with colons or dashes or so= mesuch.

" latest STH < requested STH: Retu= rn latest STH"

Agree.
=C2=A0


Line 1435
=C2=A0 =C2= =A0 =C2=A0 Note that more than one case can be true, in which case the
=C2=A0 =C2=A0 =C2=A0 returned data is their concatenation.=C2=A0 It i= s also possible for
=C2=A0 =C2=A0 =C2=A0 none to be true, in whic= h case the front-end MUST return an empty
It's not actually c= oncatenation, right? It's all the fields.
=
union would probably be a better word.
=C2=A0

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 clie= nt know which of the above two cases has occurred?
=

The response includes an STH, which says how big the tr= ee is. Probably should 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 listed
=C2= =A0 =C2=A0below to present one or more SCTs from one or more logs to each T= LS
This needs to somehow be clear that it only applies to TLS ser= vers that are compliant with this specification, as it's not a new requ= irement on all TLS servers.

Sur= ely its the other way round: i.e. new requirements on all TLS servers have = to be made clear?


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 f= rom different logs
=C2=A0 =C2=A0 =C2=A0 makes it more difficult t= o mount this attack.
Assuming that the server is malicious, why w= ould it include multiple SCTs? It seems like requiring multiple SCTs does i= n fact provide this defense, but that's not an argument for servers to = provide multiples.


Line 1627
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SerializedTransItem tra= ns_item_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 th= is be the place that you make TransItems self-contained (by having a define= d length field). What about other places I might want to concatenate TransI= tems. Why don't you instead 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: TimestampedCertificateEntryDataV= 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_= entry_v2: TimestampedCertificateEntryDataV2;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case x509_sct_v2: SignedCertificateTimes= tampDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= case precert_sct_v2: SignedCertificateTimestampDataV2;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case signed_tree_head_v2: Sig= nedTreeHeadDataV2;
=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: InclusionPr= oofDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } data;
= =C2=A0 =C2=A0 =C2=A0 } TransItem;
This is pretty much the univers= al TLS convention.


Line 1649
<= div>6.4. =C2=A0transparency_info TLS Extension
This extension app= ears 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_info" extension
=C2= =A0 =C2=A0type in the ClientHello, the TLS server SHOULD include the
<= div>You need to provide an actual definition of what the client includes, a= nd 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 i= t is in fact empty.


Line 1654
=
=C2=A0 =C2=A0"transparency_info" extension in the ServerHell= o with
=C2=A0 =C2=A0"extension_data" set to a "Tra= nsItemList".=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 include the extension but if it's included, it MUST consist of T= ransItemList, no? And surely only SHOU
Also, I'm not sure thi= s is the right logic. If the server knows that it has the SCT information i= n the certificate or in OCSP, why SHOULD It send this extension. I would th= ink, rather that servers should aim to send information at most once, so th= at 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 cer= ts, it's always sent twice, because the client doesn't know where t= he info is, and so has to always offer the extension.

<= div>
Line 1658
=C2=A0 =C2=A0session is resumed, sin= ce session resumption uses the original
=C2=A0 =C2=A0session info= rmation.
Does this mean the client MUST abort the handshake if th= e server includes it?


Line 1668
=C2=A0 =C2=A0o =C2=A0The TLS client includes the "transparency_= info" extension type in
=C2=A0 =C2=A0 =C2=A0 the ClientHello= .
This condition is non-sensical, because if the client *doesn= 9;t* include the extension, the server cannot send the transparency_info ex= tension at all.


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<= /div>


Line 1739
=C2=A0 =C2=A0vi= ew.=C2=A0 The exact mechanisms will be in separate documents, but it is
=C2=A0 =C2=A0expected there will be a variety.
Given the s= omewhat science fictional status of Gossip, this entire paragraph should be= stricken


Line 1747
=C2= =A0 =C2=A0MUST implement all of the three mechanisms by which TLS servers m= ay
=C2=A0 =C2=A0present SCTs (see Section 6).=C2=A0 TLS clients M= AY also accept SCTs via
=C2=A0 =C2=A0the "status_request_v2&= quot; extension ([RFC6961]).=C2=A0 TLS clients that
IMPORTANT: Th= is also needs to be rewritten so it makes clear it's not a general levy= on TLS clients.

Line 1770
=C2=A0 =C2=A0= In addition to normal validation of the server certificate and its
=C2=A0 =C2=A0chain, TLS clients SHOULD validate each received SCT for whi= ch 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, why would you not do this?
<= div>
Line 1791
=C2=A0 =C2=A0TLS clients MUST NOT co= nsider valid any SCT whose timestamp is in the
=C2=A0 =C2=A0futur= e.
What's the reason for this? If your clock is slightly wron= g, this is going to cause new certs to fail even if they otherwise would ha= ve succeeded (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
=C2=A0 = =C2=A0communicating with.
IMPORTANT: This "Note" just m= entions in passing a huge privacy issue. You need to be a lot clearer about= this.

Line 1823
=C2=A0 =C2=A0"tran= sparency_info" and "status_request" TLS extensions in the
=C2=A0 =C2=A0ClientHello.
IMPORTANT: This is not consiste= nt 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. Howeve= r, if servers can optionally ignore transparency_info (it's a SHOULD ab= ove), then you can have two compliant implementations with the server havin= g a CT-compliant cert and yet the client declares it noncompliant. To fix t= his, you need to require the server to respond to "transparency_info&q= uot;


Line 1831
=C2=A0 =C2= =A0"CachedObject" of type "ct_compliant" in the "c= ached_info" extension.
=C2=A0 =C2=A0The "hash_value&quo= t; 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 len= gth 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 &qu= ot;in order to do this" refer to? Clearly not how to keep copies.... P= resumably, how to poll the log.


Lin= e 1864
=C2=A0 =C2=A08.=C2=A0 Either:
IMPORTANT: You see= m 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 algorit= hm, that should be an explicit stage.
This is a pretty odd algori= thm. If I understand it correctly, 1-4 are setup steps and then 5-9 is supp= osed to be repeated, but I could just do this once and stop at 4.


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

Line 19= 44
=C2=A0 =C2=A0If it should become necessary to deprecate an alg= orithm used by a
=C2=A0 =C2=A0live log, then the log should be fr= ozen as specified in Section 4.13
=C2=A0 =C2=A0and a new log shou= ld be started.=C2=A0 Certificates in the frozen log that
RFC 2119= SHOULD? Isn't this a MUST, though?


=
Line 1958
=C2=A0 =C2=A0"transparency_info" TLS ext= ension.=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.gi= thub.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 |<= /div>
=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 algorithm= s?


Line 2150
=C2=A0 =C2= =A0(with the intention of actually running a CT log that will be
= =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 re= quire business arrangements. Is it really that valuable to save 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 guarante= e that the certificate
=C2=A0 =C2=A0is not misissued, since appro= priate monitors might not have checked
IMPORTANT: This is not cor= rect, 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
=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 misissued
=
=C2=A0 =C2=A0certificate can be used without being available for audit= is twice
Nit: up to the MMD old


Line 2211
=C2=A0 =C2=A0compute the proofs from the log) o= r communicate with the log via
=C2=A0 =C2=A0proxies.
Th= is 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 so= meone else? If the log, what's the logs incentive?

=

Line 2243
=C2=A0 =C2=A0reduce the effectivene= ss of an attack where a CA and a log collude
=C2=A0 =C2=A0(see Se= ction 6.1).
See my comments in 6.1 about this.


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


--001a1143fc569f71e805587363eb-- From nobody Tue Sep 5 10:47:05 2017 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 125F8132DA2 for ; Tue, 5 Sep 2017 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, 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 0z9CjabJhMwL for ; Tue, 5 Sep 2017 10:47:00 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5F9132D62 for ; Tue, 5 Sep 2017 10:47:00 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id w204so15067312ywg.3 for ; Tue, 05 Sep 2017 10:47:00 -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=hdeG7XR4TFVf6ZYEIiqVAHaqb/s0+ybvGLJwZopxLLk=; b=SwEW9NdMu91BV2dIe4SnCYoVGYKHE9eED7LInM7Q47XHtddz3t/nujFAPSekyN6NQU z7cx9rfbCBtF3VJp1iO46QLIuCVZyreJv4eO67dPjPzIuFtNucz3aJUekbFBw7X5LoZx 8V5TndY8L5+s7qE71D7+/sR+Nt87DInWL2zapmPQcdQ2MUrh8eLozfWt4eOqdYIhmXbb ll2ZdBUdewdsM+eCovAwgQSxGYxSd61vWgzuTDllXSxMFXmEMweXj8fTGHLmY4LdfpHj 7o6uXJq8+yjtx/P9PsX3QlQLQY7j4sE2voJEuIaevg7tisZm8PeWOQhLmO98knSxXpRI 3EOQ== 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=hdeG7XR4TFVf6ZYEIiqVAHaqb/s0+ybvGLJwZopxLLk=; b=prJO/KGeF9N+TlZiXpqZmIEwS4kK49iX/06YNbruv4an9GS9uBPrhT1oWwkRLaJIiU kaeyDIn0p5wFAvcWmQzO4I1C+ZNqNmLb0FSqbY2ejTQCUDRA4oi1p1/bEaBZ6r02NiPM ilCYXz/N3WOarVdDokmlPqjE+S3kQrrvqnsGIWcryqvmzZbgD7q42GRcH0mQW1FYv1fz ESCqDEjSw69timCZ0pHU3AzEN1UJI9oTZ3GJzas2y1K+1eIyrXSOEEOFQeIENVl1/QMS TIN4iNuQroorAgtP29skjm6HldwtGldB90q3YehoQFFolNdlviEFQYaCnhANr2lWBMi2 sVgw== X-Gm-Message-State: AHPjjUgZHvO8dVgYPrgXOQGjZnKXZDu4mkzj8rTmdYUUmJKmed7aEapI 9K7F0DQShM88Oq5ppVVa38pda8IQzwajxPc= X-Google-Smtp-Source: ADKCNb6sUHNjeeWbYnvUcUS+ACZ6oYrsMTQFIBTF4bjqjzDrkCRpOqMFNmxnRKQq9Oqr4XA1yeqHi5UeXGAQBToWnIo= X-Received: by 10.37.132.14 with SMTP id u14mr4081350ybk.289.1504633619563; Tue, 05 Sep 2017 10:46:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 5 Sep 2017 10:46:18 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 5 Sep 2017 10:46:18 -0700 Message-ID: To: Ben Laurie Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="089e0826f364696061055874d067" 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: Tue, 05 Sep 2017 17:47:05 -0000 --089e0826f364696061055874d067 Content-Type: text/plain; charset="UTF-8" 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 > > >> >> >> 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? -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 >> >> > --089e0826f364696061055874d067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 9:04 AM, Ben Laurie <benl@google.com> 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:


If you w= ant to see comments in context -- which is a lot easier -- you
ca= n 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. Fo= r instance, in
the intro:

=C2=A0 Certifi= cate 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 e= xtensive 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<= /div>
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 req= uire
trusting the logs. This is implicitly acknowledged by propos= als that
RPs only accept certificates with >1 SCT.
=

The purpose of multiple SCTs i= s to avoid the death of a single log causing the death of a large number of= certificates. It is not about trust.
<= div>
That seems like the reason for the server to offer it, b= ut not for the client to require it.

Line 763
=C2=A0 =C2=A0Maximum C= hain Length: =C2=A0The longest chain submission the log is
=C2=A0= =C2=A0 =C2=A0 willing to accept, if the log chose to limit it.
N= it: chooses

Past te= nse seems correct?

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


<= /div>
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 requirement

"T= o avoid being overloaded by invalid submissions"

There seem like one way to preven= t this, but not the only one.

=C2=A0
Line 816
=C2=A0 =C2= =A0anchor used to verify the chain (even if it was omitted from the
=C2=A0 =C2=A0submission).=C2=A0 The log MUST present this chain for audi= ting upon
=C2=A0 =C2=A0request (see Section 5.6).=C2=A0 This prev= ents the CA from avoiding blame
What happens in cases of multiple= chains. For instance, say that the submitter provides superfluous certific= ates?

Not allowed.
=

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

= =C2=A0
=C2=A0

<= /div>

Line 837
=C2=A0 =C2=A0 =C2=A0 =C2=A0opaq= ue 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 b= e 1 byte.


Line 948
=C2=A0= =C2=A0"tbs_certificate".=C2=A0 The length of the "issuer_ke= y_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 sh= are 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=A0entr= y 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.
=C2=A0


Line 1552
=C2=A0 = =C2=A0TLS servers MUST use at least one of the three mechanisms listed
=C2=A0 =C2=A0below to present one or more SCTs from one or more logs = to each TLS
This needs to somehow be clear that it only applies t= o 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 T= LS servers have to be made clear?
=
I'm not sure what you mean. This document does not get t= o require that all TLS servers do CT. Was that your intent?

<= /div>
-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 r= eplace "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 different= logs
=C2=A0 =C2=A0 =C2=A0 makes it more difficult to mount this = attack.
Assuming that the server is malicious, why would it inclu= de multiple SCTs? It seems like requiring multiple SCTs does in fact provid= e this defense, but that's not an argument for servers to provide multi= ples.


Line 1627
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SerializedTransItem trans_item_lis= t<1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} TransItem= List;
Structurally, it's kind of a mess to have this be the p= lace that you make TransItems self-contained (by having a defined length fi= eld). What about other places I might want to concatenate TransItems. Why d= on't you instead make TransItem self-contained, like so:

=
struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VersionedT= ransType versioned_type;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint1= 6 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: TimestampedCertificateEntryDataV2;
= =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: SignedCertificateTimestampDataV= 2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_= sct_v2: SignedCertificateTimestampDataV2;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case signed_tree_head_v2: SignedTreeHeadDat= aV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case consis= tency_proof_v2: ConsistencyProofDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 case inclusion_proof_v2: InclusionProofDataV2;
=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 convent= ion.


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 incl= udes the "transparency_info" extension
=C2=A0 =C2=A0typ= e 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 t= o 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 with
=
=C2=A0 =C2=A0"extension_data" set to a "TransItemList&q= uot;.=C2=A0 The TLS server SHOULD
=C2=A0 =C2=A0ignore any "e= xtension_data" sent by the TLS client.=C2=A0 Additionally,
I= MPORTANT: The normative language here is kind of confusing. It SHOULD inclu= de 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 rig= ht logic. If the server knows that it has the SCT information in the certif= icate 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 c= ert/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 r= esumption uses the original
=C2=A0 =C2=A0session information.
Does this mean the client MUST abort the handshake if the server inc= ludes it?


Line 1668
=C2= =A0 =C2=A0o =C2=A0The TLS client includes the "transparency_info"= extension type in
=C2=A0 =C2=A0 =C2=A0 the ClientHello.
This condition is non-sensical, because if the client *doesn't* inclu= de the extension, the server cannot send the transparency_info extension at= all.


Line 1722
8.=C2=A0 = Clients
Given the imminent standardization of TLS 1.3, you need t= o 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 sc= ience fictional status of Gossip, this entire paragraph should be stricken<= /div>


Line 1747
=C2=A0 =C2=A0MU= ST implement all of the three mechanisms by which TLS servers may
=C2=A0 =C2=A0present SCTs (see Section 6).=C2=A0 TLS clients MAY also acce= pt SCTs via
=C2=A0 =C2=A0the "status_request_v2" extens= ion ([RFC6961]).=C2=A0 TLS clients that
IMPORTANT: This also need= s to be rewritten so it makes clear it's not a general levy on TLS clie= nts.

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 va= lidate an SCT, a TLS
IMPORTANT: Why is this a SHOULD and not a MU= ST? If you support CT at all, why 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 g= oing to cause new certs to fail even if they otherwise would have succeeded= (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
=C2=A0 =C2=A0commun= icating with.
IMPORTANT: This "Note" just mentions in p= assing a huge privacy issue. You need to be a lot clearer about this.
=

Line 1823
=C2=A0 =C2=A0"transparency_inf= o" and "status_request" TLS 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 the server is noncompliant if it has = given the server a chance to send the SCTs by every mechanism., otherwise t= he server might just want to send the SCT some other way. However, if serve= rs can optionally ignore transparency_info (it's a SHOULD above), then = you can have two compliant implementations with the server having a CT-comp= liant cert and yet the client declares it noncompliant. To fix this, you ne= ed to require the server to respond to "transparency_info"
<= div>

Line 1831
=C2=A0 =C2=A0"Ca= chedObject" of type "ct_compliant" in the "cached_info&= quot; extension.
=C2=A0 =C2=A0The "hash_value" field MU= ST be 1 byte long with the value 0.
You should explain why this i= s 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
=C2=A0 =C2=A0watches.=C2=A0 It may also wa= nt 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 n= ot a 2119 SHOULD?

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


Line 1864
<= div>=C2=A0 =C2=A08.=C2=A0 Either:
IMPORTANT: You seem to be missi= ng there part where you actually look at the entries to verify that they do= n'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 shou= ld be an explicit stage.
This is a pretty odd algorithm. If I und= erstand it correctly, 1-4 are setup steps and then 5-9 is supposed to be re= peated, 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 that the
=C2=A0 =C2=A0STH is = indeed the result of making a tree from all fetched entries.
IMPO= RTANT: 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 speci= fied in Section 4.13
=C2=A0 =C2=A0and a new log should be started= .=C2=A0 Certificates in the frozen log that
RFC 2119 SHOULD? Isn&= #39;t this a MUST, though?


Line 195= 8
=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 fiel= d 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?
<= br>

Line 2150
=C2=A0 =C2=A0(with the int= ention of actually running a CT log that will be
=C2=A0 =C2=A0ide= ntified 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 a= rrangements. Is it really that valuable to save a few bytes here?


Line 2163
=C2=A0 =C2=A0that the lo= g 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 certif= icate
=C2=A0 =C2=A0is not misissued, since appropriate monitors m= ight 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
=C2=A0 =C2=A0operating correctly.=C2=A0 As a log i= s allowed to serve an STH that's up
=C2=A0 =C2=A0to MMD old, = the maximum period of time during which a misissued
=C2=A0 =C2=A0= certificate can be used without being available for audit is twice
Nit: up to the MMD old


Line 2211<= /div>
=C2=A0 =C2=A0compute the proofs from the log) or communicate with= the log via
=C2=A0 =C2=A0proxies.
This also seems quit= e handwavy in light of the facts on the ground.

Line 2237
=C2=A0 =C2=A0 =C2=A0 and STHs can be store= d 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 nee= ds to be expanded. Who is this risk against? The log or someone else? If th= e log, what's the logs incentive?


Line 2243
=C2=A0 =C2=A0reduce the effectiveness of an attack w= here a CA and a log collude
=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



--089e0826f364696061055874d067-- From nobody Wed Sep 6 20:12:36 2017 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 A70AB13219E for ; Wed, 6 Sep 2017 20:12:33 -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 MBfj3kQc8ljE for ; Wed, 6 Sep 2017 20:12:32 -0700 (PDT) Received: from alcazar.beanwood.com (alcazar.beanwood.com [IPv6:2600:3c00:e000:6c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E12124319 for ; Wed, 6 Sep 2017 20:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1504753951; bh=ThyxulF8KZVOkdTSuZpq2tPm0pDHRjVsxLx7m0kyTkM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=EzxjBGIfn55NTlL3PSZ8unPJwbhn5VOMZafr22hh1ZXWgA0aKJSj85AAYFXqRua/x lqJK/2k+OwAfsnbNCYpWfvjE6qOW5V/8PtvcAgPdzpjJZAIrEHywVGpCM3CYoUTycA l0QrGeZDYxofVVDVSmQ0nRmOjrg2eyClr3NtkI/ecxbNwhLLxrI4pcCroDWPFqsWqu ENOh3CjmQT+FwZqi1RYnzsanWmbEYRi2c1XW/v9zagtErV7n+Fog3pJag2U614PPMx iJP5u8CwK/v1GeEx0rXcoBtRIdgvWnhRIhWzKHEqhFGwCcXW166Xs4cggYRlfQdq76 Q3p70NdjiobYg== Date: Wed, 6 Sep 2017 20:12:30 -0700 From: Andrew Ayer To: Eric Rescorla Cc: Ben Laurie , "trans@ietf.org" Message-Id: <20170906201230.9d9d0354db1fc448ee4d02f6@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 07 Sep 2017 03:12:34 -0000 On Tue, 5 Sep 2017 10:46:18 -0700 Eric Rescorla wrote: > Say that a CA spins up two subordinates that happen to share the same > key. I agree it's foolish. 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. Regards, Andrew From nobody Wed Sep 6 21:35:03 2017 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 8141A13218E for ; Wed, 6 Sep 2017 21:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, 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 zOlHiNG3k5-I for ; Wed, 6 Sep 2017 21:35:01 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC4A1321A3 for ; Wed, 6 Sep 2017 21:35:00 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w204so27225807ywg.3 for ; Wed, 06 Sep 2017 21:35:00 -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=B2JhjdI8HB8vOwr9Rg2V2Hdza+UUaJYPyjf7m3GyrfA=; b=BYcvph1vPmWepTqXkCGRfeHUsXUKcO9KAH3Uk55LlEG4yIELGBfLd+tU3QZUmMqEnx GTNK45Xq50RZK8mG96gTiX5a5rbVrhUyVt6Eu59Y3+GDFF38W24A1G+sZHfTOvbqhNsT gmYfL0ItAI4nW46SzHhbzIdd9I87uuMI9NwPmzQWf2HBQpHPcVQHHjhveYf8SN0wIRky FOB0JfbRaLVURUqR2AdWqIil6147n/lgVRHyVmUVyth5S+x7r4PVf+S3H4jQ/RpB/p42 /ZxF+3G24eX1gyacDOOTMAk6vLKyVyG/qUDopfyyEANQnKOBWioBkkUrtJOeHX95vx9Z rz/Q== 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=B2JhjdI8HB8vOwr9Rg2V2Hdza+UUaJYPyjf7m3GyrfA=; b=GJ31Lxf156+jCJXfK9BYQ/A9YnLvVdOamBoIbTn9LECfYng2dXwCyOx2PDTzvXa8S6 Rdp/w6083SLZ9tscYpd0p1fn3tvNxt7skVxXmm/Sy4PPOSbhk5NCBDBu1QVi366awmIn qj/+kkul8aJCHpfbOv6CT56/US1ZHmgUKKGUxf1GcG5a/gEKGYMx61R5+rNQWZQ8GSuv hvkwJxAoPNNw0zVE/0uLDXAiJnCWpnGQktbzgpIzX2XgRf1nJFl6R4KbtUOEkbZVzaoc 39dxeNF5ieBuWJbuUgZCASBRHM5NxdjkAjNi2N7OmLryy3ttYbyM/zwP3ecBMGOdr78E hK3A== X-Gm-Message-State: AHPjjUjpJTGCoeXF54iM4gLQ1t7X7suI7qJdKryjBHlwU3Ou4ouAPjSD XsizNBYnSYCyTvtHyL9tPjY/p+z9k78h X-Google-Smtp-Source: ADKCNb5fGYGu97MBoZ1tK5mn0QI1qT2n4g6VRQdOI6JDyAbVB8Z58hfxkz62iGjncmbozD7IoHe2WPrmD8srJkqQf48= X-Received: by 10.129.121.4 with SMTP id u4mr1172005ywc.71.1504758900209; Wed, 06 Sep 2017 21:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Wed, 6 Sep 2017 21:34:19 -0700 (PDT) In-Reply-To: <20170906201230.9d9d0354db1fc448ee4d02f6@andrewayer.name> References: <20170906201230.9d9d0354db1fc448ee4d02f6@andrewayer.name> From: Eric Rescorla Date: Wed, 6 Sep 2017 21:34:19 -0700 Message-ID: To: Andrew Ayer Cc: Ben Laurie , "trans@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0a8af4b853c6055891fbad" 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, 07 Sep 2017 04:35:02 -0000 --94eb2c0a8af4b853c6055891fbad Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 8:12 PM, Andrew Ayer wrote: > On Tue, 5 Sep 2017 10:46:18 -0700 > Eric Rescorla wrote: > > > Say that a CA spins up two subordinates that happen to share the same > > key. I agree it's foolish. > > 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. > Thanks. That's helpful. -Ekr > > Regards, > Andrew > --94eb2c0a8af4b853c6055891fbad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 6, 2017 at 8:12 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
On = Tue, 5 Sep 2017 10:46:18 -0700
Eric Rescorla <ekr@rtfm.com> wrot= e:

> Say that a CA spins up two subordinates that happen to share the same<= br> > key. I agree it's foolish.

That's not a problem, since the name of the CA is included in th= e
Issuer field of the TBSCertificate, which is part of the Merkle leaf
input along with the CA's public key hash.

Thanks. That's helpful.

-Ekr
=C2=A0

Regards,
Andrew

--94eb2c0a8af4b853c6055891fbad-- From nobody Thu Sep 7 03:24:59 2017 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 32256132715 for ; Thu, 7 Sep 2017 03:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILTBKSef4A0G for ; Thu, 7 Sep 2017 03:24:54 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C429132386 for ; Thu, 7 Sep 2017 03:24:54 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w204so29043914ywg.3 for ; Thu, 07 Sep 2017 03:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6oNexklUAFy2pLNkX4sFm03zyCW32MQbSNlsUjALMwc=; b=sKPYsUF54cWdJd2Hhifo8s5e1D2dKMH5CGHok6mgCrykSefkWgXZdpZPYIACl5nWYH QwFDoGj2aABNysL4bNcTsniq+WJiDhGIUeZWJr9IflCmWfSos7u9/yfdPltVjWS99G5c Lk0alAxFboLcf9FJ7tVt8iVGE/lHjbdwtyeyAubRmkOoqwfNICAZctymLiN+jE8fdYLg sWMe/XTVyNG4VeJAbC8yTziqr57oYHe6VFNHTK31WNeWybwN9F+aFRVVa2dyr9HM4TJn ZmHSyjFAkoS/VXPZs79kxRrUuAzsddj4+DjmYCIF7B9BstQ236EvO02jbTgnwtsB0+0s bzmw== 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=6oNexklUAFy2pLNkX4sFm03zyCW32MQbSNlsUjALMwc=; b=Sxi41GPBdpmgKp7BkHcncK0My1htRyc6SRq4eN2ISf65vQYXAY3bpKChGhhEyCsQPx zB7i/wtJiL4H1eU5H6XQ1djiG94kWVdeUduvpXomMKGijv7Nuebcjz2TxQP+lWA2q91G m9XLceq+snlOmhJgFBFK+nQA0Ht7/9jR1mFIyqIo2BJs00ce1DtA0PvH6Vn2p9VsiUnO zGkfDQzHCa2b9aYjxb3cEwPGUR7SkOJTangK6iCSuACp+IJ7ay/sUxGlT9dY5a/zU/fU FWo3Gfthn3XBZ7ZtAQtpVmbr+CDuSCINKn/9cWPZWYfRt2ej9U+5SP6kgcHhN0J9ZeeH GLQQ== X-Gm-Message-State: AHPjjUhqi+cEaQ9LWIceUFQxvB+Uq4DbJoLiM2ZHUHhkQauZrkqW98Ae U0ZLnuwo/KMxL4jrmfBckgD1zbmhuicKMIMJDugRd93q X-Google-Smtp-Source: ADKCNb47Y0SHJ5jgaizrt1UM68zfvNLgl4lRZg0M3XQpU4rKsYWStVP8Gnn4eVbyLcsv/oIypGCmMWtMceOjWBPmadQ= X-Received: by 10.37.172.129 with SMTP id x1mr1791025ybi.176.1504779892979; Thu, 07 Sep 2017 03:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.79.86 with HTTP; Thu, 7 Sep 2017 03:24:51 -0700 (PDT) In-Reply-To: References: From: Ben Laurie Date: Thu, 7 Sep 2017 11:24:51 +0100 Message-ID: To: Eric Rescorla Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="f403045da4c8fd4b2f055896dee3" 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, 07 Sep 2017 10:24:57 -0000 --f403045da4c8fd4b2f055896dee3 Content-Type: text/plain; charset="UTF-8" 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. > > >> >> >>> >>> >>> 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). Surely if you are making a new requirement for TLS compliance then you have to explicitly say so? > > -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 >>> >>> >> > --f403045da4c8fd4b2f055896dee3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 5 September 2017 at 18:46, Eric Rescorla <ekr@rtfm.com> wr= ote:


On Tue, S= ep 5, 2017 at 9:04 AM, Ben Laurie <benl@google.com> wrote:
=


On 4 September 2017 at 00:17, Eric Rescorla <ekr@rtfm.com> wr= ote:
=
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:


= 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 probl= ems.

-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-Le= vel:

1. This document makes a variety of claims ab= out the assurances that
clients get that only obtain if some as-y= et-to-be-specified
third-party verifiability mechanism is impleme= nted. 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 publ= icly
=C2=A0 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 al= so
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 num= ber of certificates. It is not about trust.

That seems like the reason for the ser= ver to offer it, but not for the client to require it.

Line 763
=C2=A0 =C2=A0Maximum Chain Length: =C2=A0T= he longest chain submission the log is
=C2=A0 =C2=A0 =C2=A0 willi= ng to accept, if the log chose to limit it.
Nit: chooses

Past tense seems correct?

I'm willi= ng to dert this to the RFC Editor.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
=C2=A0


Line 785
=C2=A0 =C2=A0accepted trust anchor, using only the chai= n of intermediate CA
=C2=A0 =C2=A0certificates provided by the su= bmitter.
Why is this a 2119 MUST? It seems wise, but not necessar= ily a conformance requirement

"To avoid b= eing overloaded by invalid submissions"
=

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

=C2= =A0
Line 816
=C2=A0= =C2=A0anchor used to verify the chain (even if it was omitted from the
=C2=A0 =C2=A0submission).=C2=A0 The log MUST present this chain for = auditing upon
=C2=A0 =C2=A0request (see Section 5.6).=C2=A0 This = prevents the CA from avoiding blame
What happens in cases of mult= iple chains. For instance, say that the submitter provides superfluous cert= ificates?

Not allowed.

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

Yep - and that's borne out by = practice.


=C2=A0
=C2=A0


Line 837
=C2=A0 =C2=A0 = =C2=A0 =C2=A0opaque LogID<2..127>;
This seems to be the fir= st use of the TLS specification language, but I don't see a cite. Pleas= e 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 ac= tual way a TBSCertificate can be 1 byte.


Line 948
=C2=A0 =C2=A0"tbs_certificate".=C2=A0 Th= e length of the "issuer_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 fo= olish.
=C2=A0return an empty



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

The response inclu= des an STH, which says how big the tree is. Probably should be the latest o= ne known to that server.
=C2=A0


=
Line 1552
=C2=A0 =C2=A0TLS servers MUST use at least one of = the three mechanisms listed
=C2=A0 =C2=A0below 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.
<= /div>

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 th= e 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 R= FC).

Surely if you are making a new requirement fo= r TLS compliance then you have to explicitly say so?
=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 moun= t this attack.
Assuming that the server is malicious, why would i= t include multiple SCTs? It seems like requiring multiple SCTs does in fact= provide this defense, but that's not an argument for servers to provid= e 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} Tr= ansItemList;
Structurally, it's kind of a mess to have this b= e the place that you make TransItems self-contained (by having a defined le= ngth field). What about other places I might want to concatenate TransItems= . Why don't you instead make TransItem self-contained, like so:

struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ver= sionedTransType 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: TimestampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_entr= y_v2: TimestampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case x509_sct_v2: SignedCertificateTimestam= pDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ca= se precert_sct_v2: SignedCertificateTimestampDataV2;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case signed_tree_head_v2: SignedT= reeHeadDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c= ase consistency_proof_v2: ConsistencyProofDataV2;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case inclusion_proof_v2: InclusionProofD= ataV2;
=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 appear= s not to have any explicit support for CT entries for intermediate certs. A= m I just supposed to glue together all the TransItems?

=

Line 1651
=C2=A0 =C2=A0Provided that a TLS cl= ient includes the "transparency_info" 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 wi= th
=C2=A0 =C2=A0"extension_data" set to a "TransIt= emList".=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 SHOU= LD include the extension but if it's included, it MUST consist of Trans= ItemList, 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 th= e 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 i= t 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, do= n'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 i= nfo is, and so has to always offer the extension.

=
Line 1658
=C2=A0 =C2=A0session is resumed, since s= ession resumption uses the original
=C2=A0 =C2=A0session informat= ion.
Does this mean the client MUST abort the handshake if the se= rver includes it?


Line 1668
=C2=A0 =C2=A0o =C2=A0The TLS client includes the "transparency_info= " 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 extens= ion at all.


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
<= div>=C2=A0 =C2=A0expected there will be a variety.
Given the some= what science fictional status of Gossip, this entire paragraph should be st= ricken


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

Line 1770
=C2=A0 =C2=A0In a= ddition 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, why would you not do this?
<= div>
Line 1791
=C2=A0 =C2=A0TLS clients MUST NOT co= nsider valid any SCT whose timestamp is in the
=C2=A0 =C2=A0futur= e.
What's the reason for this? If your clock is slightly wron= g, this is going to cause new certs to fail even if they otherwise would ha= ve succeeded (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
=C2=A0 = =C2=A0communicating with.
IMPORTANT: This "Note" just m= entions in passing a huge privacy issue. You need to be a lot clearer about= this.

Line 1823
=C2=A0 =C2=A0"tran= sparency_info" and "status_request" TLS extensions in the
=C2=A0 =C2=A0ClientHello.
IMPORTANT: This is not consiste= nt 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. Howeve= r, if servers can optionally ignore transparency_info (it's a SHOULD ab= ove), then you can have two compliant implementations with the server havin= g a CT-compliant cert and yet the client declares it noncompliant. To fix t= his, you need to require the server to respond to "transparency_info&q= uot;


Line 1831
=C2=A0 =C2= =A0"CachedObject" of type "ct_compliant" in the "c= ached_info" extension.
=C2=A0 =C2=A0The "hash_value&quo= t; 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 len= gth 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 &qu= ot;in order to do this" refer to? Clearly not how to keep copies.... P= resumably, how to poll the log.


Lin= e 1864
=C2=A0 =C2=A08.=C2=A0 Either:
IMPORTANT: You see= m 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 algorit= hm, that should be an explicit stage.
This is a pretty odd algori= thm. If I understand it correctly, 1-4 are setup steps and then 5-9 is supp= osed to be repeated, but I could just do this once and stop at 4.


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

Line 19= 44
=C2=A0 =C2=A0If it should become necessary to deprecate an alg= orithm used by a
=C2=A0 =C2=A0live log, then the log should be fr= ozen as specified in Section 4.13
=C2=A0 =C2=A0and a new log shou= ld be started.=C2=A0 Certificates in the frozen log that
RFC 2119= SHOULD? Isn't this a MUST, though?


=
Line 1958
=C2=A0 =C2=A0"transparency_info" TLS ext= ension.=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.gi= thub.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 |<= /div>
=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 algorithm= s?


Line 2150
=C2=A0 =C2= =A0(with the intention of actually running a CT log that will be
= =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 re= quire business arrangements. Is it really that valuable to save 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 guarante= e that the certificate
=C2=A0 =C2=A0is not misissued, since appro= priate monitors might not have checked
IMPORTANT: This is not cor= rect, 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
=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 misissued
=
=C2=A0 =C2=A0certificate can be used without being available for audit= is twice
Nit: up to the MMD old


Line 2211
=C2=A0 =C2=A0compute the proofs from the log) o= r communicate with the log via
=C2=A0 =C2=A0proxies.
Th= is 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 so= meone else? If the log, what's the logs incentive?

=

Line 2243
=C2=A0 =C2=A0reduce the effectivene= ss of an attack where a CA and a log collude
=C2=A0 =C2=A0(see Se= ction 6.1).
See my comments in 6.1 about this.


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




--f403045da4c8fd4b2f055896dee3-- From nobody Thu Sep 7 07:42:33 2017 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 2EA65132F32 for ; Thu, 7 Sep 2017 07:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, 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 NGZXKf6j7-no for ; Thu, 7 Sep 2017 07:42:27 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42957132F1B for ; Thu, 7 Sep 2017 07:42:27 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id w204so30932453ywg.3 for ; Thu, 07 Sep 2017 07:42:27 -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=I6W+36fBzhlSwdVrfpWQDkSWH051Ytp8Ofzy00f0Fko=; b=d3xZMb6VwoAT/rrlDESsfmH39Jw1kkNGW4ApXDstVW75xA7XipilCuzsyW4AEjov2L oGnJF+MvVovhrCgDMUrhhwRm38lpD60dTDLSzFwpwT9ob9hnaDuKIguyBFAosGBv/ljz SyrEWD2qFzrZZlZ8GhsuHB33g0x5NMm+uvm27Lb9WPWASVv4szSlax7UrVmLxzfTld/L giSHRy9IzJc9l9tbz4lWT6UZGmpoQKZmQnQsevBZdVzU6dc1J6CxGqubcu+oZHsZXUqV 5RdHSedmWKmTALPj7VNsOjmw5aFdXHbOPbvOnDCoKaeDduYU0Nim65Q24Vpy/AMG0nBQ PSTg== 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=I6W+36fBzhlSwdVrfpWQDkSWH051Ytp8Ofzy00f0Fko=; b=C4SQJZsq0vcQP1IE6gBLn6rHDRbliMqWNvXatFgrvwPw5oCCqvdnMmGpdctuMN9aGr 0xme+Y5EtK6jQgNNnC8GXEd7O8frA+nUMS99L1xZeztnwToQFo8ZOSWzRjw2zw75Xhk3 RdbMPNzkj2cQmZdYGk3HUf5tajCFeP83sxOabJGXWTr8sg4FFACzpnev+K7Xmp2bABEi h9y/BTFlkdWKhtpRR23W2YYlM52Kd4+LQTuXg32WCKuHp4QDhys3kZaOWMlr2IR+WlIM Fn9mBq/LH9PAMzNvDK6O7ZqMRkbJDFHZH682c2DZhEOUoLfOKU0yP8/VjPGm3MlfmYLE rNxw== X-Gm-Message-State: AHPjjUhci1ErQ9Ky8+NL6Gs8AtC10QVqHS7AQlw8S+bC5N/CHmTbqnP9 /R/jwAdZTDyraf4EvICFKRa7yPFuNkeZ X-Google-Smtp-Source: ADKCNb6VeQhVlpMLM5mpSx0+D0RgpOZu3Rx6W/1/ptaQNcuBnQlj1rR861rFvXLZCBbI5YYX18dwAVgchiI4KWq5f60= X-Received: by 10.13.203.67 with SMTP id n64mr2334230ywd.19.1504795346451; Thu, 07 Sep 2017 07:42:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 7 Sep 2017 07:41:45 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 7 Sep 2017 07:41:45 -0700 Message-ID: To: Ben Laurie Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="001a114e3dfa15d27305589a78f6" 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, 07 Sep 2017 14:42:32 -0000 --001a114e3dfa15d27305589a78f6 Content-Type: text/plain; charset="UTF-8" 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 >>>> >>>> >>> >> > --001a114e3dfa15d27305589a78f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


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


On Tue, Sep 5, 2017 = at 9:04 AM, Ben Laurie <benl@google.com> wrote:


On 4 September 2017 at 00:17, Eric R= escorla <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:


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 algori= thms 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 tha= t the changes to that section will be
modest if any.

High-Level:

1. This do= cument makes a variety of claims about the assurances that
client= s get that only obtain if some as-yet-to-be-specified
third-party= verifiability mechanism is implemented. For instance, in
the int= ro:

=C2=A0 Certificate Transparency aims to mitiga= te the problem of misissued
=C2=A0 certificates by providing appe= nd-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 Rich= ard Barnes's and my previous
comments should make clear, this= is only a property of CT if you also
have some mechanism for thi= rd-party verifiability of STHs, and this
document does not supply= that. In the actually deployed -- we can
debate deployable separ= ately the deployability of some of the
proposals for how to get t= his-- versions of CT, what clients get is
SCTs, which are effecti= vely 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 l= og causing the death of a large number of certificates. It is not about tru= st.

Tha= t seems like the reason for the server to offer it, but not for the client = to require it.

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

Past tense seems correct?
<= /div>

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


<= div>Line 785
=C2=A0 =C2=A0accepted trust anchor, using only the c= hain of intermediate CA
=C2=A0 =C2=A0certificates provided by the= submitter.
Why is this a 2119 MUST? It seems wise, but not neces= sarily a conformance requirement

"To avoi= d being overloaded by invalid submissions"

There seem like one way to preve= nt this, but not the only one.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Line 816
=C2=A0 =C2=A0anchor used to verify the chain (even if it was omitted fro= m the
=C2=A0 =C2=A0submission).=C2=A0 The log MUST present this c= hain for auditing upon
=C2=A0 =C2=A0request (see Section 5.6).=C2= =A0 This prevents the CA from avoiding blame
What happens in case= s of multiple chains. For instance, say that the submitter provides superfl= uous certificates?

Not a= llowed.

Hmm.= ..=C2=A0 So your theory is that the submitter does path construction
<= /div>

Yep - and tha= t's borne out by practice.

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

=C2=A0<= /div>
=C2=A0


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

See s1.2.
<= div>
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 b= e 1 byte.


Line 948
=C2=A0= =C2=A0"tbs_certificate".=C2=A0 The length of the "issuer_ke= y_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 happe= n to share the same key. I agree it's foolish.
=C2=A0return a= n empty



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

The response includes an STH, which says h= ow big the tree is. Probably should 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 lis= ted
=C2=A0 =C2=A0below to present one or more SCTs from one or mo= re logs to each TLS
This needs to somehow be clear that it only a= pplies to TLS servers that are compliant with this specification, as it'= ;s not a new requirement on all TLS servers.
<= br>
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?<= /div>

What I = meant is that if every time you mention a thing you have to say "but o= nly if you are conforming to this RFC" then you a) make the whole thin= g a lot more cumbersome, b) are stating the obvious (i.e. that you only hav= e 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:=C2=A0https://too= ls.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 wou= ld use here would be "CT-using TLS servers MUST..."

Su= rely if you are making a new requirement for TLS compliance then you have t= o 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&#= 39;s not the case.

-Ekr
=C2=A0
=C2=A0
=C2=A0<= /div>

-EKr



Line 1595
=C2=A0 =C2=A0been struck off for m= isbehavior, has had a key compromise, or is not
=C2=A0 =C2=A0know= n 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 misi= ssuance from clients.=C2=A0 Including SCTs from different 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_item_list<1..2^16-1>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} TransItemList;
S= tructurally, it's kind of a mess to have this be the place that you mak= e 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 versione= d_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_ent= ry_v2: TimestampedCertificateEntryDataV2;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_entry_v2: TimestampedCertifica= teEntryDataV2;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 case x509_sct_v2: SignedCertificateTimestampDataV2;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case precert_sct_v2: SignedCe= rtificateTimestampDataV2;
=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: InclusionProofDataV2;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 } data;
=C2=A0 =C2=A0 =C2=A0 } TransI= tem;
This is pretty much the universal TLS convention.
=

Line 1649
6.4. =C2=A0transparency_i= nfo 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 1= 651
=C2=A0 =C2=A0Provided that a TLS client includes the "tr= ansparency_info" extension
=C2=A0 =C2=A0type in the ClientHe= llo, the TLS server SHOULD include the
You need to provide an act= ual definition of what the client includes, and having the server ignore th= e contents is bad mojo. TLS convention is for the client to include an empt= y extension and the server to validate that it is in fact empty.
=

Line 1654
=C2=A0 =C2=A0"transp= arency_info" extension in the ServerHello with
=C2=A0 =C2=A0= "extension_data" set to a "TransItemList".=C2=A0 The TL= S server SHOULD
=C2=A0 =C2=A0ignore any "extension_data"= ; sent by the TLS client.=C2=A0 Additionally,
IMPORTANT: The norm= ative language here is kind of confusing. It SHOULD include the extension b= ut if it's included, it MUST consist of TransItemList, no? And surely o= nly SHOU
Also, I'm not sure this is the right logic. If the s= erver 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 shoul= d aim to send information at most once, so that it should only send the ext= ension if it contains information that's not in the cert/OCSP. as it pr= etty 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 alwa= ys offer the extension.


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


Line 1668
=C2=A0 =C2=A0o =C2=A0Th= e TLS client includes the "transparency_info" 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, th= e server cannot send the transparency_info extension at all.

=

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


<= /div>
Line 1739
=C2=A0 =C2=A0view.=C2=A0 The exact mechanisms= will be in separate documents, but it is
=C2=A0 =C2=A0expected t= here will be a variety.
Given the somewhat science fictional stat= us of Gossip, this entire paragraph should be stricken

=

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

=
Line 1770
=C2=A0 =C2=A0In addition to normal validatio= n of the server certificate and its
=C2=A0 =C2=A0chain, TLS clien= ts SHOULD validate each received SCT for which they
=C2=A0 =C2=A0= have the corresponding log's parameters.=C2=A0 To validate an SCT, a TL= S
IMPORTANT: Why is this a SHOULD and not a MUST? If you support = CT at all, why would you not do this?

Line 1791
=C2=A0 =C2=A0TLS clients MUST NOT consider valid any SCT whose time= stamp is in the
=C2=A0 =C2=A0future.
What's the rea= son for this? If your clock is slightly wrong, this is going to cause new c= erts to fail even if they otherwise would have succeeded (because the notBe= fore and notAfter are more conservative).


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

Line 1823
=C2=A0 =C2=A0"transparency_info" and "s= tatus_request" TLS extensions in the
=C2=A0 =C2=A0ClientHell= o.
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 c= hance 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 ig= nore transparency_info (it's a SHOULD above), then you can have two com= pliant implementations with the server having a CT-compliant cert and yet t= he client declares it noncompliant. To fix this, you need to require the se= rver to respond to "transparency_info"

<= br>
Line 1831
=C2=A0 =C2=A0"CachedObject" of = type "ct_compliant" in the "cached_info" extension.
=C2=A0 =C2=A0The "hash_value" field MUST be 1 byte long wi= th the value 0.
You should explain why this is one byte long (tha= t the PDU is defined as having a minimum length of 1). Also the server shou= ld be required to check it.


Line 18= 42
=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 f= ollow these steps for each log:
Why is this not a 2119 SHOULD?

Also, what does "in order to do this" refe= r to? Clearly not how to 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 bog= us 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 s= tage.
This is a pretty odd algorithm. If I understand it correctl= y, 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.


L= ine 1912
=C2=A0 =C2=A0STHs it receives, ensure that each entry ca= n be fetched and that the
=C2=A0 =C2=A0STH is indeed the result o= f making a tree from all fetched entries.
IMPORTANT: How do you v= erify MMD?

Line 1944
=C2=A0 =C2=A0If it = should become necessary to deprecate an algorithm used by a
=C2= =A0 =C2=A0live log, then the log should be frozen as specified in Section 4= .13
=C2=A0 =C2=A0and a new log should be started.=C2=A0 Certifica= tes in the frozen 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 up= date this extension
=C2=A0 =C2=A0type to point at this document.<= /div>
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| ECDS= A (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 actu= ally running a CT log that will be
=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. I= s it really that valuable to save a few bytes here?


Line 2163
=C2=A0 =C2=A0that the log has misbehav= ed, 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 = checked
IMPORTANT: This is not correct, because the client does n= ot know that the monitors 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 s= erve an STH that's up
=C2=A0 =C2=A0to MMD old, the maximum pe= riod of time during which a misissued
=C2=A0 =C2=A0certificate ca= n be used without being available for audit is twice
Nit: up to t= he MMD old


Line 2211
=C2= =A0 =C2=A0compute the proofs from the log) or communicate with the log via<= /div>
=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 expand= ed. Who is this risk against? The log or someone else? 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 collude
=C2=A0 =C2=A0(see Section 6.1).
See my com= ments in 6.1 about this.


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





--001a114e3dfa15d27305589a78f6--