On 5 November 2017 at 21:52, Richard Barnes <[email protected]> wrote: > > > On Sun, Nov 5, 2017 at 1:18 AM, Tom Ritter <[email protected]> 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 <[email protected]> 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
