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

[Linus Nordberg <[e-mail]>]

Hi Ekr, hi group,

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/

Eric Rescorla <[e-mail]> wrote
Sat, 14 Oct 2017 17:03:36 -0700:

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

Ekr: What privacy implications are you refering to here?


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

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

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