On Dec 12, 2013, at 10:46 AM, Ben Laurie <[email protected]> wrote: > On 12 December 2013 15:33, Stephen Farrell <[email protected]> wrote: >> >> >> On 12/12/2013 03:23 PM, Ben Laurie wrote: >>> I want to generate standards-track RFC(s) for 6962-bis, but other >>> stuff could proceed in parallel. I don't want to hold up 6962-bis for >>> that other stuff, though. >> >> What requirements are there to be able to also >> use a 6962bis log instance or piece of s/w for >> another transparency-for-X thing? >> >> If there are none or its ok as a best-effort >> thing then working in parallel seems ok, but if >> there's a strong desire to be able to use the >> same log instance or s/w for more than one >> thing, aren't there dangers there? > > CT is tightly linked to CAs as an anti-spam measure, and so I don't > think it can be used for other things. > > I think it is possible to define a more generic mechanism, with some > parameter choices (e.g. do you have the logs issue signatures on > timestamps and later order the log, as in CT, or do you order before > issuing a signature on a Merkle proof?), for other things, but that's > a distraction from progress on CT, which is urgent. > > Spam is a particularly thorny issue, and I suspect anti-spam measures > are tightly linked to the log's purpose. I have ideas for DNSSEC and > binaries, but they are not completely generic. A log with no mechanism > to control ingress of loggable things is trivial to DoS into > uselessness.
Yup, but I think you should be able to mitigate some of the spam issues by forcing the inserter to do some work — for example, when I input a DNSSEC record I have to solve a CAPTCHA…. Yes, there are many weaknesses with captchas (automated solvers, mules, etc), but (AFAICT) all you need to do is raise the cost enough that this is not an attractive attack. DoSing the log doesn’t *provide access*, it simply denies service to those wanting to insert information, so, unless I’m very mistaken, the main incentive to DoS is giggles / being an ass… Or am I completely missing something? W > >> I've no particular opinion as to what's right >> here btw, but its a fairly typical way in which >> a WG might trip up and can lead to the WG >> convincing themselves to step back to start >> from use-cases, blah, requirements, blah, >> architecture, blah etc. after a big and non-fun >> argument. >> >> Better to figure it out and have some sort of >> consensus on that kind of thing up front if >> possible. >> >> S. > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
