Re: [therightkey] Draft charter for a Transparency Working Group

Warren Kumari <warren@kumari.net> Fri, 13 December 2013 21:50 UTC

Return-Path: <warren@kumari.net>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0911AE3A6 for <therightkey@ietfa.amsl.com>; Fri, 13 Dec 2013 13:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nOxmjShK5Sv for <therightkey@ietfa.amsl.com>; Fri, 13 Dec 2013 13:50:37 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E671AE3A0 for <therightkey@ietf.org>; Fri, 13 Dec 2013 13:50:36 -0800 (PST)
Received: from [192.168.1.153] (unknown [66.84.81.105]) by vimes.kumari.net (Postfix) with ESMTPSA id DAC8A1B404B2; Fri, 13 Dec 2013 16:50:29 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CABrd9SQyRea2d3gUPYLu5CUL9bk6aGSmUxx1SZRhRKQMicECoQ@mail.gmail.com>
Date: Fri, 13 Dec 2013 16:50:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB9C423C-F082-480F-A3A7-66E3421BEFB0@kumari.net>
References: <CABrd9SSzGJy18tf_iR5jFNk-sJyX66OPhmM4H23K5X2ZpWniyQ@mail.gmail.com> <52A9AB84.6090609@cs.tcd.ie> <CABrd9STXJ-_hbfKV3NraQHvAFzcqZ9aCi4v=Pur82yLtCZk-MQ@mail.gmail.com> <52A9D752.2060303@cs.tcd.ie> <CABrd9SQyRea2d3gUPYLu5CUL9bk6aGSmUxx1SZRhRKQMicECoQ@mail.gmail.com>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1822)
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, Warren Kumari <warren@kumari.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [therightkey] Draft charter for a Transparency Working Group
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 21:50:38 -0000

On Dec 12, 2013, at 10:46 AM, Ben Laurie <benl@google.com> wrote:

> On 12 December 2013 15:33, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey

--
For every complex problem, there is a solution that is simple, neat, and wrong.
                -- H. L. Mencken