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

[Tom Ritter <[e-mail]>]

On 5 November 2017 at 21:52, Richard Barnes <[e-mail]> wrote:
>
>
> 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?

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.

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

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