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? -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
