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

From: Tom Ritter <[email-masked]>
Date: Sun, 5 Nov 2017 00:18:27 -0500

I'm going to cherry pick a single thing to ask about before we try to
address everything.

On 16 October 2017 at 16:41, Richard Barnes <[email-masked]> wrote:
> As far as SCT feedback, note that the
> privacy issues here (around server tracking) are unnecessary to meet the
> need here -- only the auditor needs to see the SCTs, not the server.  If you
> had a way for clients to encrypt SCTs to specific auditors, you would no
> longer have an issue with server tracking.
>
> ...
>
> 2. Add a through-encryption modality for SCT feedback

This is an interesting idea. However, I'm worried it's infeasible
because of abuse concerns.

A client needs to pass the (encrypted) SCT through a third party to
prevent the auditor from knowing who visited a particular site. But
the third party has no assurance that the payload is a valid SCT and
not garbage, so there's DOS concerns. Even if we waved the crypto
magic wand (I would be surprised if there wasn't a crypto primitive
for this problem, I didn't search), the third party is essentially
opening itself to being given every SCT in the log.

Attempts at putting a cap on the data received open the doors to
flooding attacks that would fill up any cap before the client can
provide its data.

Am I thinking about the design the same way you were? Do you think
this is a problem, and if so, know how you'd work around it?

-tom

---

From: Richard Barnes <[email-masked]>
Date: Sun, 5 Nov 2017 22:52:46 -0500

> this is a problem, and if so, know how you'd work around it?

TBH, I don't think I had considered the DoS issues.  Now that you mention
it, I'm not sure I really buy the premises of the operational model the
document presumes for servers.  If I were building a server, why would I
not just ship off a batch to the auditor whenever my storage fills up?
Assuming that's in the realm of plausible server architectures, now you're
relying on the server's altruism to protect the log from DoS, and altruism
rarely scales.  And even if all the servers are well-behaved, a malefactor
can spam the auditor's SCT feedback endpoint directly if he wants to.

In other words, the auditor has a DoS problem here regardless of
through-encryption.  The only question is whether it has to just check
signatures or also decrypt; one public-key operation or two.

--Richard

---

From: Tom Ritter <[email-masked]>
Date: Sun, 5 Nov 2017 23:07:29 -0600

On 5 November 2017 at 21:52, Richard Barnes <[email-masked]> wrote:
> document presumes for servers.  If I were building a server, why would I not
> just ship off a batch to the auditor whenever my storage fills up?

You could do that.

> Assuming
> that's in the realm of plausible server architectures, now you're relying on
> the server's altruism to protect the log from DoS, and altruism rarely
> scales.

The  *log* from DOS? Or the auditor? I confess I hadn't really
considered DOSing auditors. I think when I was actively working on
this doc, auditors hadn't really been implemented yet, and in my mind
internet-scale auditors keep a copy of the tree indexable, and
immediately discard data they have already seen, so it's 'hard' to DOS
them. But that's not how they work today and I don't even know if
that's feasible.

> And even if all the servers are well-behaved, a malefactor can spam
> the auditor's SCT feedback endpoint directly if he wants to.

Yes.

> signatures or also decrypt; one public-key operation or two.

Yes.

My point about DOS was not that one could DOS the auditor (you can
with or without as you note), but that one could DOS the SCT Feedback
server. Without encryption, example.com rejects all cert+SCTs that
aren't for example.com and doesn't store them. With encryption, it
accepts data for any address on the internet. (And if it sets a
storage limit, that's where you run into flooding attacks.)

-tom

---

From: Tom Ritter <[email-masked]>
Date: Wed, 8 Nov 2017 15:24:28 -0600

We reviewed ekr's and Richard's feedback; thanks for the detailed review.

For all (or nearly all) of the non-important issues we believe we can
make appropriate changes or address the concerns adequately. We're not
sending those right now, just to avoid a deluge of words and things to
review on the list.

For the important items:

    IMPORTANT: I don't understand what this means from an HTTP perspective...

We believe we can explain this adequately along with the non-important items.

    IMPORTANT: Neither of these mechanisms is generally usable, so I
don't think this SHOULD is reasonable...

This is a fair point. We suggest the following changes and hope they
will address this concern

Change from 'A client SHOULD perform proof fetching' to 'A client
SHOULD attempt proof fetching'

Additionally, we would integrate two new points regarding DNS:
1) The UA should first probe and learn if the network supports these DNS queries
2) If the network does not support these DNS queries then periodically
re-probe and if it does eventually support it, you can go through your
backlog.

We'd also mention the Tor option further up as it is a simple solution
from the POV of this draft, although most browsers haven't deployed it
for being a more difficult solution technically.

    IMPORTANT: This seems like kind of a dealbreaker...

Yes. We think our wording is incorrect and that leads to your comment.
We would like to suggest how we would change the wording and see if
you have the same assessment.

   If SCT Feedback is not deployed by a webserver, malicious logs will
   be able to attack all users of the webserver (who do not have a
   Trusted Auditor relationship) with impunity.

This is not true. It assumes an auditor cannot recognize a log
partition that is perpetuated by an actively malicious log. In
actuality, an auditor can (and should) be able to recognize that it
has recent STHs that can't be resolved via a consistency proof and
recognize that situation is perpetuating and is bad. If an auditor can
do that, malicious logs _can_ be detected via STH Pollination
(assuming Proof Fetching occurs) - making the document incorrect.

What is true:

   If SCT Feedback is not deployed by a webserver, the webserver may
never learn that it was the target of an attack.

The auditors would learn that the log was malicious but not what
domain names it attacked.

We would change the document to reflect the true statement, and update
various mentions and phrases to adequately convey that SCT Feedback is
necessary to learn _who_ is attacked by a malicious log, but not
necessary to learn that a particular log _is_ malicious and has
performed an attack so long as STH Pollination and Proof Fetching
occurs.

    IMPORTANT: This algorithm does not terminate...
    IMPORTANT: state that rand() has to be a CSPRNG.

You're correct, we can fix these easily enough.

    IMPORTANT: This algorithm has terrible performance...

Also correct. We'd be happy to review a suggestion that improves
performance, but I'm nervous about shuffling algorithms. In general,
we can add a note about more carefully considering these cases during
implementation when MAX_XXX_RECORDS_TO_GOSSIP is large.

With regards to Richard's suggestions: we intend to rev the doc to
address all of the minor and major issues as adequately as we can. We
aren't very excited about refactoring the document entirely though. If
the group thinks it's valuable mostly as-is, we'd be happy to see it
published. If the WG thinks it would be better to refactor it, strip
out major components and so on - we think that'd be a valuable effort
and would be happy to comment and provide feedback.

-tom

---

From: Melinda Shore <[email-masked]>
Date: Wed, 8 Nov 2017 12:35:00 -0900

> and would be happy to comment and provide feedback.

Thanks, Tom.  We'll spend some time during the meeting
discussing this and take the results of that discussion
to the mailing list.

Melinda