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

[Tom Ritter <[e-mail]>]

On 24 February 2018 at 14:45, Eric Rescorla <[e-mail]> wrote:
>
>
> 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.

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