Subject: [Trans] Gossip: Unsticking a client caught with potential evidence of log misbehavior

From: Tom Ritter <[email-masked]>
Date: Mon, 19 Oct 2015 18:26:04 -0500

Hi all,

So as we're working through the Gossip draft we ran into a problem we're
not really sure how to solve. The gist of it is that a client can wind
up in a state where it has a piece of data that it is pretty suspicious
of, and it might be evidence of log misbehavior - but it's also private
data and it has no way to share it with the world.

We have not addressed this in the -01 draft, it's an open question with no
text currently.

Here are some ways that situation can arise (not exhaustive, but the
draft will have an exhaustive list):

A client has a Cert+SCT and wants an inclusion proof. Every time it
sends it up to the log (via an appropriately privacy-preserving
mechanism, such as a DNS proxy), it gets the equivalent of a 500 error,
even through other inclusion proof requests succeed.

A client has an older STH and it wants a consistency proof to a newer
STH that it can pollinate. But it gets an error on every request, even
though other consistency proof requests succeed.

A client knows a log has shut down, and it has the 'final STH'. It has
an older STH and wants to resolve it to the final STH, but again - errors.

We've been working off the assumption that some data would get out to
auditors and the auditors would detect the misbehavior - but here the
client has a piece of data that is privacy-sensitive, so it can't just
broadcast it widely. But it also could be evidence of log misbehavior -
and the fact that it gets other successful responses from the log makes
it even more suspicious.

What should it do?

I've been talking about the possibility of an 'escape valve' where a
client would release private information to an auditor-of-last-resort of
its choosing (well, chosen by the developer of the client probably)
after a sufficiently rigorous attempt to resolve it in a private
manner... but that's not very satisfying. And it's even less satisfying
to wave our hand and leave the criteria for releasing it undefined
(because it ties so much into the algorithm for how to release data in
any circumstance.)

We even talked about UI/UX.  This is such a crazy and rare situation
that there's no hope of explaining it to users.  It's also something
disconnected from any browsing session, so it's not possible to put a
link on an intersitial as Chrome has done. The closest analogy is
bug/crash reporting, either active (Windows/Apple sometimes asks if you
want to submit queued error reports) or general browser opt-in (I
believe Chrome/Firefox have some mechanism where you 'share data with
the company to make the experience better').

-tom

---

From: Ben Laurie <[email-masked]>
Date: Tue, 20 Oct 2015 08:58:15 +0000

> the company to make the experience better').

How about reporting it to the alleged origin? Presumably there's no privacy
issue there (the user visited the site already) ... the origin would then
have to do something with that report - I can imagine that browser vendors
would operate public endpoints for them to be forwarded to, for example.

Seems like the same kind of issue as HPKP reporting (see
https://tools.ietf.org/html/rfc7469#section-2.1.4).

---

From: Robin Wilton <[email-masked]>
Date: Tue, 20 Oct 2015 12:53:54 +0000

A couple of thoughts in line...

On 20 Oct 2015, at 09:58, Ben Laurie <[email-masked]> wrote:

> How about reporting it to the alleged origin? Presumably there's no privacy issue there (the user visited the site already) ... the origin would then have to do something with that report - I can imagine that browser vendors would operate public endpoints for them to be forwarded to, for example.

This seems like an appropriate and privacy-preserving first step. The question then would be how to act on the various possible responses from the origin.

For instance, if the origin appears to take no action, and the symptom persists, that might be a suitable trigger for the “escape valve” Tom describes - i.e. reporting to a pre-specified auditor.

I think we need to bear in mind that the ultimate goal here is better behaviour through transparency. If it’s not appropriate, under these circumstances, to forfeit some degree of origin privacy by invoking at least one auditor, then I think we need to consider how to mitigate the risk that the origin is a bad actor.

> 
> Seems like the same kind of issue as HPKP reporting (see https://tools.ietf.org/html/rfc7469#section-2.1.4).
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Katriel Cohn-Gordon <[email-masked]>
Date: Tue, 20 Oct 2015 14:22:11 +0100

On Tue, Oct 20, 2015 at 1:53 PM, Robin Wilton <[email-masked]> wrote:

> If it’s not appropriate, under these circumstances, to forfeit some degree
> of origin privacy by invoking at least one auditor, then I think we need to
> consider how to mitigate the risk that the origin is a bad actor.

​The context for this attack is a colluding malicious CA and log server,
right?​ If so, is CT even intended to handle a colluding website, CA and
log server?

(Incidentally, since a log server knows when it is releasing proof of
cheating, I suppose malicious servers would generally opt to error instead
of proving their misbehaviour.)

---

From: Eran Messeri <[email-masked]>
Date: Tue, 20 Oct 2015 14:46:16 +0100

+1 for reporting it backed to the alleged origin - the problem Tom
describes is significant as the client would want to hold onto these
suspicious pieces of information until it is confident it has been
reported, but has no way of knowing if the report has been acknowledged by
the 'genuine' origin.

One option is to not prescribe when clients drop such pieces of
information, so clients are free to re-send it multiple times or even
forever, until an out-of-band signal (i.e. a client software update) is
received to indicate to the client that this information has been received
and acted upon.

On Tue, Oct 20, 2015 at 2:22 PM, Katriel Cohn-Gordon <[email-masked]>
wrote:

>> If it’s not appropriate, under these circumstances, to forfeit some
>> degree of origin privacy by invoking at least one auditor, then I think we
>> need to consider how to mitigate the risk that the origin is a bad actor.
>
>

---

From: Tom Ritter <[email-masked]>
Date: Tue, 20 Oct 2015 10:22:18 -0500

On 20 October 2015 at 08:46, Eran Messeri <[email-masked]> wrote:
> +1 for reporting it backed to the alleged origin - the problem Tom describes
> is significant as the client would want to hold onto these suspicious pieces
> of information until it is confident it has been reported, but has no way of
> knowing if the report has been acknowledged by the 'genuine' origin.
>
> One option is to not prescribe when clients drop such pieces of information,
> so clients are free to re-send it multiple times or even forever, until an
> out-of-band signal (i.e. a client software update) is received to indicate
> to the client that this information has been received and acted upon.

So reporting it back to the origin is an appropriate solution for a
subset of situations.  If I have an SCT+certificate I want to resolve
to a STH, but can't, I can report it up to the origin via SCT
Feedback.  We also (or will) have guidelines for submitting it
multiple times, and ensuring that it's reported on a connection that
'looks okay' (we have some notes in 7.1.1)

There are (at least) two cases that aren't covered by "report it to
the origin". (Maybe more, but I can only think of two right now.)

- The origin doesn't implement SCT Feedback.
- The data I have is an older STH, which is not tied to any specific origin.

-tom

---

From: Eran Messeri <[email-masked]>
Date: Tue, 20 Oct 2015 16:32:28 +0100

On Tue, Oct 20, 2015 at 4:22 PM, Tom Ritter <[email-masked]> wrote:

> describes
> information,
 This is a hard one - if a domain operator isn't interested in learning
about attacks against their domain, can anything be done about that?
My suggestion for this case is to make it easy to delegate SCT Feedback -
so domain owners can allow other domains which operate SCT Feedback to
receive SCTs on their behalf. How does that sound?

> - The data I have is an older STH, which is not tied to any specific
I think this case is less sensitive from a privacy perspective and so could
be gossiped with any servers that do implement SCT Feedback?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 20 Oct 2015 18:49:53 +0000

> - The origin doesn't implement SCT Feedback.

If it turns out that feedback is essential and the origin doesn't implement
feedback, in the medium term we can assume it doesn't care about CT.

Then why do you care? Can't you freely gossip the STH?

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 21 Oct 2015 15:52:58 +0200

Eran Messeri <[email-masked]> wrote
Tue, 20 Oct 2015 16:32:28 +0100:

| On Tue, Oct 20, 2015 at 4:22 PM, Tom Ritter <[email-masked]> wrote:
| 
| > On 20 October 2015 at 08:46, Eran Messeri <[email-masked]> wrote:
| > > +1 for reporting it backed to the alleged origin - the problem Tom
| > describes
| > > is significant as the client would want to hold onto these suspicious
| > pieces
| > > of information until it is confident it has been reported, but has no
| > way of
| > > knowing if the report has been acknowledged by the 'genuine' origin.
| > >
| > > One option is to not prescribe when clients drop such pieces of
| > information,
| > > so clients are free to re-send it multiple times or even forever, until
| > an
| > > out-of-band signal (i.e. a client software update) is received to
| > indicate
| > > to the client that this information has been received and acted upon.
| >
| > So reporting it back to the origin is an appropriate solution for a
| > subset of situations.  If I have an SCT+certificate I want to resolve
| > to a STH, but can't, I can report it up to the origin via SCT
| > Feedback.  We also (or will) have guidelines for submitting it
| > multiple times, and ensuring that it's reported on a connection that
| > 'looks okay' (we have some notes in 7.1.1)
| >
| > There are (at least) two cases that aren't covered by "report it to
| > the origin". (Maybe more, but I can only think of two right now.)
| >
| > - The origin doesn't implement SCT Feedback.
| >
|  This is a hard one - if a domain operator isn't interested in learning
| about attacks against their domain, can anything be done about that?
| My suggestion for this case is to make it easy to delegate SCT Feedback -
| so domain owners can allow other domains which operate SCT Feedback to
| receive SCTs on their behalf. How does that sound?

Scary because we want the end user to trust that the same-origin
principle is indeed followed if they're going to play along with SCT
Feedback. Opening up for delegation sounds like bad news wrt this.

Impractical since the browser would have to know which domain that
example.com has delegated its SCT Feedback to.

Susceptible of blocking since it cannot be performed in the same TLS
stream as the ordinary https request.

| > - The data I have is an older STH, which is not tied to any specific
| > origin.
| >
| I think this case is less sensitive from a privacy perspective and so could
| be gossiped with any servers that do implement SCT Feedback?

We have STH Pollination for STH's but only if the STH is fresh, defined
in the draft as no older than 14 days. I think Tom means that "older"
implies "not fresh".

---

From: Tom Ritter <[email-masked]>
Date: Wed, 21 Oct 2015 21:16:03 -0500

> Feedback. Opening up for delegation sounds like bad news wrt this.

I am less concerned about this aspect of delegation. A server can
always share data out of band width a third party.  And they can even
delegate it to a third party without us knowing.  So enabling a
mechanism that makes it _easy_ to delegate it does not worry me as
much as it does you =)

> example.com has delegated its SCT Feedback to.

This is an engineering problem I don't see a neat solution to. So
obviously the solution is a new HTTP header! SCT-Feedback:
https://uncle-neds-discount-hanggliding-and-sct-feedback-correlator.website/google.com/
;)

> stream as the ordinary https request.

But this one does worry me very much.  We mention it down in
https://tools.ietf.org/html/draft-ietf-trans-gossip-01#section-10.2.1
and I'm hopeful we will get implementations that multiplex gossip
traffic as much as they can so it is much more difficult to block.

> in the draft as no older than 14 days. I think Tom means that "older"

Yes.  The risk here is admittedly less than that of a SCT, but I do
still worry about it.
Would it solve the problem if we had an additional one-week grace
period?  Where we say "You resolve older STHs into a fresh STH - but
if you encounter an error trying to resolve a STH that is between 2
and 3 weeks old, you pollinate it anyway?"

What are the implications of that... So a log could refuse to resolve
a consistency proof, and the client would pollinate it. A website
(colluding with the log) could identify that client individually
(because no one else would be pollinating that STH.)  Separately, if
website A receives old-STH, and website B receives it as well, they
can do some pretty reliable cross-origin linkage.  But they can't
actually induce a client to pollinate old-STH without either the log's
help (by refusing to resolve a consistency proof) or without blocking
the consistency proof resolution.

Are there more? That seems like it could be acceptable to me from a
privacy POV... And it seems like it would solve the problem... I can't
think of a way you receive (no-maliciously) an older-then-three-week
STH.

-tom

---

From: Ben Laurie <[email-masked]>
Date: Thu, 22 Oct 2015 10:23:35 +0000

> mechanism that makes it _easy_ to delegate it does not worry me as

I totally agree.

> https://uncle-neds-discount-hanggliding-and-sct-feedback-correlator.website/google.com/

Quite so.

> traffic as much as they can so it is much more difficult to block.

It does seem like it is possible to make life quite tricky for attackers...

---

From: Ben Laurie <[email-masked]>
Date: Thu, 22 Oct 2015 10:25:43 +0000

On Thu, 22 Oct 2015 at 03:16 Tom Ritter <[email-masked]> wrote:

> I can't

You can end up with one if you receive a fresh one and then go to sleep for
4 weeks...

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 Oct 2015 18:48:42 -0400

>> https://uncle-neds-discount-hanggliding-and-sct-feedback-correlator.website/google.com/

I can't tell how much people are kidding around here -- i see Tom's
winky emoticon, at least.

But which version of the site should get to declare where the delegation
should happen -- the version that has the bogus cert with SCTs from the
colluding logs, or the "real" version?

     --dkg

---

From: Tom Ritter <[email-masked]>
Date: Fri, 23 Oct 2015 00:11:43 -0500

> colluding logs, or the "real" version?

The header should not persist, it should be required to be present on
every response to keep the delegation occuring.  So assume the fake
server sets it, and you give some SCT feedback to the delegated
attacker.  Later when you visit the site, and no longer see the
header, you give SCTs to the real site.  I don't think this changes
the threat model, as we assume the attacker cannot forever-middle a
user.

I tend to like HTTP headers, but I do recognize there's a ton of them.

> You can end up with one if you receive a fresh one and then go to sleep for

That's true. It seems different from the client receiving a 4-week old
STH via the network though.

If you start up and have a 4-week old STH in your store - you can
presume that you recived it when it was fresh. And if you cannot
resolve with a consistency proof - it seems 'safer' to me in some way.
If you receive a 4-week old STH from a site, I might assume they're
trying to load me with a tracking STH.

But in general we're back in the bucket of "What do I do with this."
Do we share it with websites via STH Pollination even though it can
enable very reliable cross-origin linkage?  I don't think we can,
because (besides the privacy issue) we don't want to require the
website to resolve consistency proofs nor do we want the website to
give 4-week old STHs to other clients.  Do we share it with an
auditor-of-last-resort (after failing to resolve a consistency proof),
thinking that the privacy implications of a STH are much lesser than
the near-certainly of cross-origin linkage?

-tom

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Oct 2015 09:24:48 +0000

> colluding logs, or the "real" version?

If you report every SCT you've seen to whichever site the session with a
new SCT says, then eventually the good guy gets to see the bogus SCTs,
right?

In fact, you probably only need to report the previous SCT to the next
SCT...

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Oct 2015 09:26:59 +0000

> the near-certainly of cross-origin linkage?

The problem with discarding old STHs is it makes an attacker's job easier:
now they only have to isolate their victim until the STH expiry age, and
all evidence is gone.