On 24 February 2018 at 14:45, Eric Rescorla <[email protected]> wrote: > > > On Fri, Jan 12, 2018 at 1:00 AM, Linus Nordberg <[email protected]> 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.
I'm sending https://github.com/tomrittervg/draft-ietf-trans-gossip/commit/1389c9c6f9cab15851b88f0d0ca21ca2b6c9d89e to Linus for this. >> > 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." I believe we addressed the organic/non-organic with https://github.com/ln5/draft-ietf-trans-gossip/commit/7c2c55b8e4c2de092f95675185446d85d36361d7 >> > 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.\ Hm. I tried to loosen the language to be less suggestive that any of these are by default reasonable, and suggest that they could be reasonable in different situations. https://github.com/tomrittervg/draft-ietf-trans-gossip/commit/077d99346b027bfeae11a276afb435bb32f1f63d >> > 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. Without reviewing an implementation and browsing habits, I don't know how I would go about quantifying that. If we assumed an unbounded cache size, a user that never cleared their history, used the browser daily, an open and populated system for STH Pollination, and the misbehaving log issued a 'bad' STH: the chances of it getting detected seem to be near-certain. If the misbhaving log didn't issue a STH; but the website in question participated in SCT Feedback; and auditors polled it, then again: near-certain. But if users clear their history, or get attacked in private browsing mode; or they use their browser infrequently; or the browser sets a very low cache size for the data it stores and the attacker wants to flush it.... the chances will go down. >> > 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" I don't have strong feelings about the clients regularly getting a STH directly from the log. I'm fine with removing it, but I think Linus liked this, so I'll let him think about it. >> > 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. We're not actually saying they should use Pipelining, we're saying it's an example of the type of technique we would like them to use (along with SPDY - which doesn't really exist anymore I think - and HTTP/2). It's illustrative. -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
