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

[Richard Barnes <[e-mail]>]

On Sun, Nov 5, 2017 at 1:18 AM, Tom Ritter <[e-mail]> wrote:

> 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 <[e-mail]> 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?
>

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