Re: [Trans] AD Review: draft-ietf-trans-gossip-04

Hey all,

EKR asked me to take a look at this document in preparation for IETF LC and
IESG processing.  Full comments below. tl;dr: The document is pretty
scattered right now, and could benefit from a tighter focus.

--Richard

=====

Overall, it's hard to evaluate this document without a clearer idea of what
it's supposed to cover.  The intro sections seem to be pretty clear
(detecting split views and MMD violations), but then there's a bunch of
other stuff that gets raised later (e.g., STH vetting, benefits to servers).

Let's start from the top and talk about what the overall transparency
system needs.  6962bis already gives auditors the ability to verify that a
log is presenting a single consistent history to that auditor, and gives
clients the ability to verify that SCTs and STHs come from a log.  That
leaves us a few additional things to assure:

1. That the log gives the same history to all auditors (so that there is a
single canonical sequence of STHs)
2. That every inclusion proof the client sees is to an STH on the main
sequence
3. That every SCT the client sees is covered by an STH within the MMD

Note that the server benefits allegedly provided by SCT feedback are
already provided by CT monitors.  Or, if we want to provide that benefit
via feedback, we should just skip the log and SCT and send the cert chain.

---

How do the mechanisms presented square against these requirements?

- SCT feedback is a pretty OK way to address (3)
- STH pollination is kind of the right shape for (1), but should run
between auditors instead of client/server
- TAR is a huge privacy cost to address (3); might have some utility for
(2) assuming STH discipline

For (1), all you really need is a way for auditors to talk to each other.
STH pollination accomplishes that, but only probabilistically, and only if
a lot of other people do work.  Why not just make this deterministic?  For
example, if every auditor pings every other one on a fixed schedule, it's
very easy to detect when one of them is impaired.  The STH pollination
endpoint as described could support this use case, but of course you would
want to actually describe its use in this way, and the resulting security
properties.

For (2), you need a way for the client to vet the STHs it gets with an
auditor, whether it gets them via TransItems or fetching.  Ideally this
could be done real-time, so that the client could abort the handshake.  For
example, you could send the client the entire history of STHs, or do some
OCSP-like check.  The former seems possible if "STH discipline" is
implemented for 6962bis, but this document makes no mention of the
possibility.  For off-line, ecosystem protection, STH discipline would make
TAR more acceptable, since the constraints on STHs would make them less of
a privacy risk.

For (3), you need some way to smuggle SCTs back to an auditor.  TAR with
SCTs is not really plausible outside of the Googlebot use case, and once
you remove that, TAR ~= STH pollination.  As far as SCT feedback, note that
the privacy issues here (around server tracking) are unnecessary to meet
the need here -- only the auditor needs to see the SCTs, not the server.
If you had a way for clients to encrypt SCTs to specific auditors, you
would no longer have an issue with server tracking.

---

Net of those considerations, I would be happiest if this doc got refactored
to more directly address the needs:

1. Repurpose STH pollination as a way for auditors to send STHs to each
other
1.a. Adapt the STH pollination endpoint so that it can provide feedback on
the validity of the STH
1.b. Add some notes about how real-time STH checking can be done
2. Add a through-encryption modality for SCT feedback
3. Constrain TAR to only be used for STHs, and only for logs that implement
STH discipline

On Sat, Oct 14, 2017 at 8:03 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> I reviewed this document on Phabricator. A richer version of this review
> can be found at:
>
> https://mozphab-ietf.devsvcdev.mozaws.net/D14
>
> I'm reviewing this draft against an Experimental standard. For the reasons
> indicated in this review, I do not believe that this actually represents a
> set of viable mechanisms for ensuring that CT is publicly verifiable. In
> addition, I have marked a number of places where I believe changes are
> required.
>
> *INLINE COMMENTS*
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-382>
> draft-ietf-trans-gossip.txt:166
> We want some side of the partitioned tree, and ideally both sides, to
> see the other side.
>
> Note: there can be any number of partitions.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-383>
> draft-ietf-trans-gossip.txt:169
> Disseminating information about a log poses a potential threat to the
> privacy of end users. Some data of interest (e.g. SCTs) is linkable
> to specific log entries and thereby to specific websites, which makes
>
> , after e.g.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-384>
> draft-ietf-trans-gossip.txt:202
> corresponding to the SCT. This is because the site's logs would
> already indicate that the client is accessing that site. In this way
> a site can accumulate records of SCTs that have been issued by
>
> This is not necessarily the case. Consider the situation where I contact a
> site from location A, retrieve an SCT, and then when I start my browser in
> location B, don't visit the site, but send the SCT. This links the two
> locations. You need to also restrict the delivery of SCT Feedback to
> organic connections to the site. The text doesn't seem to contemplate
> non-organic feedback but it doesn't prohibit it either.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-385>
> draft-ietf-trans-gossip.txt:271
> | + SCT -> +----------+ |
> v | Cert [& SCT]
> +----------+ |
>
> Why not inclusion proofs and STHs. This seems permitted by 6962-bis.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-386>
> draft-ietf-trans-gossip.txt:364
> remaining SCTs together with a locally constructed certificate chain
> which is trusted (i.e. terminated in a pre-loaded or locally
> installed Trust Anchor) in an sct_feedback object or equivalent data
>
> , after i.e..
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-387>
> draft-ietf-trans-gossip.txt:373
> example.com.) They MUST NOT be sent to any Subject Alternate Names
> specified in the certificate. In the case of certificates that
> validate multiple domain names, the same SCT is expected to be stored
> IMPORTANT: I don't understand what this means from an HTTP perspective.
> What does "sent" refer to? SNI? Host: header? Suppose I have SCTs for
> a.example.com and I connect to b.example.com which presents a certificate
> with SANs for {a, b}.example.com. I would ordinarily be permitted to send
> requests to a.example.com per http://httpwg.org/specs/rfc7540.html#reuse.
> Is it permitted to send them that way here?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-388>
> draft-ietf-trans-gossip.txt:413
> Gossip would be performed normally for third party domains only when
> the user revisits the first party domain. In lieu of 'double-
>
> Is this supposed to be the result of following the previous advice to
> double-key?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-389>
> draft-ietf-trans-gossip.txt:417
> treats other security mechanisms that can enable tracking (such as
> HSTS and HPKP.)
>
> What is that manner? As far as I can tell, it's "do nothing special"
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-390>
> draft-ietf-trans-gossip.txt:434
> The data sent in the POST is defined in Section 8.1.1. This data
> SHOULD be sent in an already-established TLS session. This makes it
> hard for an attacker to disrupt SCT Feedback without also disturbing
>
> See above about the privacy implications of creating a new connection.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-391>
> draft-ietf-trans-gossip.txt:441
> empty body if it was able to process the request. An HTTPS client
> who receives any other response SHOULD consider it an error.
>
> s/who/which/
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-392>
> draft-ietf-trans-gossip.txt:443
> Some clients have trust anchors or logs that are locally added (e.g.
> by an administrator or by the user themselves). These additions are
>
> , after e.g.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-393>
> draft-ietf-trans-gossip.txt:468
> actually preserve user privacy. The Issuer field in the certificate
> describes the signing certificate. And if the certificate is being
> submitted at all, it means the certificate is logged, and has SCTs.
>
> describes, yes, but doesn't uniquely identify.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-394>
> draft-ietf-trans-gossip.txt:544
> the HTTPS server SHOULD perform an additional check in the more
> advanced mode:
>
> It would be clearer if you merged these paragraphs, and started this
> sentence with "Instead"...
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-395>
> draft-ietf-trans-gossip.txt:655
> concerns explained below. Suggestions for the policy can be found in
> Section 11.3.
>
> Also by central push.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-396>
> draft-ietf-trans-gossip.txt:673
> validity window not to be personally identifiable data, and STHs
> outside this window to be personally identifiable.
>
> 14 just seems like a random number here. There's nothing that makes these
> STHs personally identifiable other than that you told everyone else not to
> save after 14, right?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-397>
> draft-ietf-trans-gossip.txt:688
> attempt any heuristic to detect a shutdown. Instead the client MUST
> be informed about the shutdown from a verifiable source (e.g. a
> software update). The client SHOULD be provided the final STH issued
>
> , after e.g.
>
> Is a final STH from the log a verifiable source?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-398>
> draft-ietf-trans-gossip.txt:733
> Anonymity networks such as Tor also present a mechanism for a client
> to anonymously retrieve a proof from an auditor or log.
> IMPORTANT: Neither of these mechanisms is generally usable, so I don't
> think this SHOULD is reasonable
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-399>
> draft-ietf-trans-gossip.txt:799
> browser that is "logged in to" a provider of various internet
> services. Another equivalent arrangement is a trusted party like a
> corporation to which an employee is connected through a VPN or by
>
> What's an example of this? Just because I'm logged into (say) Google
> doesn't mean I'm providing them with my browsing data.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-400>
> draft-ietf-trans-gossip.txt:804
> proofs from that third party could be considered reasonable from a
> privacy perspective. The HTTPS client may also do its own auditing
> and might additionally share SCTs and STHs with the trusted party to
>
> Why would this be the case?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-403>
> draft-ietf-trans-gossip.txt:907
> be able to attack all users of the webserver (who do not have a
> Trusted Auditor relationship) with impunity. Additionally, users who
> wish to have the strongest measure of privacy protection (by
> IMPORTANT: This seems like kind of a dealbreaker, given that pretty much
> the whole rest of CT has been designed under the assumption that servers
> will do basically nothing (hence SCTs in certs and OCSP). I get that this
> is an experimental draft, but it seems like the TRANS WG needs to have a
> common understanding of what servers will and will not do
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-401>
> draft-ietf-trans-gossip.txt:932
> Unlike SCT Feedback, the STH Pollination mechanism is not hampered if
> only a minority of HTTPS servers deploy it. However, it makes an
> assumption that an HTTPS client performs Proof Fetching (such as the
>
> I'm not sure that this is true. Say that only one server deploys it. Maybe
> you meant that there is still ecosystem value.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-402>
> draft-ietf-trans-gossip.txt:951
> Servers who did not deploy SCT Feedback could be attacked without
> risk of detection.
>
> Well, as long as there wasn't some other mechanism such as the one Richard
> proposed.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-406>
> draft-ietf-trans-gossip.txt:991
> The interactions of the mechanisms is thus outlined:
>
> This whole section seems to assume that this is the exhaustive set of
> transparency mechanisms, but that's not true. It needs to somehow be
> rewritten to make clear that this is in the absence of doing anything else.
> I've noted several places below, but it's not the whole list.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-404>
> draft-ietf-trans-gossip.txt:994
> HTTPS clients can be attacked without risk of detection if they do
> not participate in any of the three mechanisms.
>
> This isn't true. For instance, the client could in theory download the
> entire log.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-405>
> draft-ietf-trans-gossip.txt:996
> HTTPS clients are afforded the greatest chance of detecting an attack
> when they either participate in both SCT Feedback and STH Pollination
>
> "greatest chance" isn't that encouraging. Please actually quantify this in
> some way.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-407>
> draft-ietf-trans-gossip.txt:1000
> (Participating in SCT Feedback is required to prevent a malicious log
> from refusing to ever resolve an SCT to an STH, as put forward in
> Section 10.1). Additionally, participating in SCT Feedback enables
>
> This isn't true. Again see above about downloading the entire log.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-408>
> draft-ietf-trans-gossip.txt:1027
> of the log to the two most recent STHs and then force the log to
> present a consistency proof. (Which it cannot.) This attack can be
> detected by CT auditors participating in STH Pollination, as long as
>
> Again, not the only way. You could download the whole log, etc.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-409>
> draft-ietf-trans-gossip.txt:1137
> on a client or server. They would be interested in flushing that
> data, i.e. tricking the target into gossiping or pollinating the
> incriminating evidence with only attacker-controlled clients or
>
> , after i.e.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-410>
> draft-ietf-trans-gossip.txt:1160
> be in addition to the expected set, and will be evidence of the
> attack.
>
> Why can't an attack add a lot of STHs to the cache?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-411>
> draft-ietf-trans-gossip.txt:1210
> The below Deletion Algorithm Section 11.3.2 is recommended to make it
> more difficult for the attacker to perform a flushing attack.
>
> "in Section 11.3.2"
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-412>
> draft-ietf-trans-gossip.txt:1237
> information in any other than the following two channels: to the
> server associated with the SCT itself; or to a Trusted Auditor, if
> one exists.
>
> As above, what does it mean to be "the server"
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-413>
> draft-ietf-trans-gossip.txt:1283
> from a CT log that it doesn't accept SCTs from. An HTTPS client
> SHOULD regularly request an STH from all logs it is willing to
> accept, even if it has seen no SCTs from that log.
>
> Is any HTTPS client actually planning to do this?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-414>
> draft-ietf-trans-gossip.txt:1321
> STHs it can issue. It must 'save' one of its STHs each MMD to
> perform the attack.
>
> This only applies to a compliant log.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-415>
> draft-ietf-trans-gossip.txt:1400
> Clients, HTTPS servers, and CT auditors. It is not a requirement for
> technique of implementation, so long as privacy considerations
> established above are obeyed.
>
> "as the privacy considerations"
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-416>
> draft-ietf-trans-gossip.txt:1431
> SHOULD send gossip data in an already established TLS session. This
> can be done through the use of HTTP Pipelining, SPDY, or HTTP/2.
>
> My understanding is that almost nobody currently does pipelining.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-417>
> draft-ietf-trans-gossip.txt:1533
> with SCTs received from other clients, and act upon them at some
> period of time
>
> This all seems pretty vague. Do you provide specific algorithms?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-418>
> draft-ietf-trans-gossip.txt:1716
> indexes.insert(r)
> }
> IMPORTANT: This algorithm does not terminate if the number of STHs inside
> the validity window is < MAX_STH_TO_GOSSIP and is extremely inefficient if
> you have a total of MAX_STH_TO_GOSSIP entries in the list.
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-419>
> draft-ietf-trans-gossip.txt:1752
> && now() - sth.timestamp > LOG_MMD
> && sth.proof_attempts != UINT16_MAX
> // Only fetch a proof is we have never received a proof
>
> What does this check do?
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-420>
> draft-ietf-trans-gossip.txt:2081
> if(r not in indexes)
> indexes.insert(r)
> }
> IMPORTANT: This algorithm has terrible performance when
>
> len(indexes) == MAX_SCT_RECORDS_TO_GOSSIP
>
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-421>
> draft-ietf-trans-gossip.txt:2142
> num_feedback_loop_failures = 0
> if(num_submissions_succeeded != UINT16_MAX )
> num_submissions_succeeded++
>
> Is this because the limit might be as high as UINT16_MAX
>
> View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D14#inline-422>
> draft-ietf-trans-gossip.txt:2377
> uint rndIndex1 = rand() % all_sct_stores.length
> uint rndIndex2 = rand() % all_sct_stores[rndIndex1].observed_records.length
>
> IMPORTANT: state that rand() has to be a CSPRNG.
>
> *REPOSITORY*
> rIETFREVIEW ietf-review
>
> *REVISION DETAIL*
> https://mozphab-ietf.devsvcdev.mozaws.net/D14
>
> *EMAIL PREFERENCES*
> https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/
>
> *To: *ekr-moz, ekr
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>