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

[Eric Rescorla <[e-mail]>]

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