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

[Eric Rescorla <[e-mail]>]

On Fri, Jan 12, 2018 at 1:00 AM, Linus Nordberg <[e-mail]> wrot
>
>
> > 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.
>

Yeah, I think this document should provide some guidance here.


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


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

I am OK with leaving this text as-is.


> 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


OK.



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


The former.\

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

The second.
 \

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

A SHOULD Seems pretty silly if the answer is "no"


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

I don't think it's sensible to suggest that people do things we know they
won't.

-Ekr