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

[Linus Nordberg <[e-mail]>]

Hi Ekr, hi group,

Naturally, I failed at including all our comments and questions in my
last email. Let me try again, listing them all, including those in my
previous email.


Most of the issues in the AD review have been addressed in upcoming -05
(see [0] for the current status of the document). Apart from a couple of
clarifying questions to Ekr, there are two particular questions we'd
like to ask the working group -- please see "WG:" below.

[0] https://github.com/ln5/draft-ietf-trans-gossip/


> 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?

Yes.


> 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"

HSTS and HPKP are special, they often have subtly different behavior
than other things. For example, they are generally shared from the
normal browsing context into a Private Browsing Mode, which is different
from nearly every other thing that can enable tracking.

We're under the impression that browser makers are keeping an eye out
for actual uses of HSTS and HPKP for tracking, and if it becomes a
problem, they may close the Private Brrowsing Mode population behavior.


> 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.

What privacy implications are you refering to here?


> 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.

This paragraph describes certificates that chain to a somewhat-publicly
trusted, but still locally added trust root. We were under the
impression that the Issuer field in CA certificates is required to be
unique. Even if it's not required to be unique, the Issuer name, the
public nature of the intermediate, and the signature all combine to
enable a unique identification of the certificate chain in question.


> 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?

The choice of 14 days _was_ arbitrary. However, you can't substitue any
number in there for the same result. The other component, besides
everyone using the same configuration, is that the timeframe must be
_short_ enough that seeing a STH on the tail end of it is not rare.

If we had chosen a 720 day window, it would be very rare for a client to
have a particular STH on the tail of the window. A client could be fed a
719-day-old STH on a.com, and when they pollinate it on b.com, they can
be recognized cross-domain with a much greater chance.

We guessed that 14 days was an appropriate number.

WG: Should we perform real-world measurements before picking a number
for STH freshness or will our guess be good enough for an experimental
RFC if we add text along the lines of the above explanation?


> 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.

"Google Chrome provides the option to sign in with your Google Account
and synchronize your Chrome data across multiple devices. Synced data
can include bookmarks, saved passwords, open tabs, browsing history,
extensions and other settings. In Advanced sync settings, you can choose
which types of data to synchronize with this device. By default, all
syncable data types are enabled."

https://www.google.com/chrome/browser/privacy/whitepaper.html#signin


> 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?

Are you questioning why it could be considered reasonable to share
gossip data with any of the suggested types of third party
organisations? Or why an HTTPS client might do auditing?


> 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.

Yes. "Ecosystem value" is the only value provided by STH Pollination.


> 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.

Do you think that the document is lacking text on _why_ a client has the
greatest chance of detecting an attack when $foo? Or are you asking for
reasoning about how large the chance of detecting an attack might be?


> 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?

We've tried to clarify this in text, but the cache should be slightly
larger than the maximum valid STHs. So if an attacker tries to flush the
cache, they will have to use invalid STHs to flush it, and we only need
one of those to detect a compromised log.


> 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?

We have no idea.

WG: Do you know of any HTTPS client planning on implementing _any_ of
the methods described in this document?


> 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.

Okay, but it's still part of the HTTP standard, is it not? It seems like
it's still a valid example of a measure that would achieve our desired
goal here.


> 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?

We don't and we'd prefer not to try and specify one, but if we needed
to, we could point to specific sections of STH Pollination and say "Do
something like that."


> 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?

Prevents an int overflow that would reset a counter from the 'abnormal'
situation to a 'normal' situation. You could move it into a checked
increment, but the idea is if you've attempted to fetch a proof
UINT16_MAX number of times already, we can omit further attempts.


> 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

Yea, seems unlikely we'd reach it, but we're guarding against an int
overflow.