Re: AD Sponsorship of draft-moonesamy-recall-rev

John C Klensin <john-ietf@jck.com> Sat, 20 April 2019 18:44 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D87F1201FA; Sat, 20 Apr 2019 11:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 8ku9dNE5XcXd; Sat, 20 Apr 2019 11:44:35 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D500B1200FC; Sat, 20 Apr 2019 11:44:34 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hHuyS-0001xX-5S; Sat, 20 Apr 2019 14:44:28 -0400
Date: Sat, 20 Apr 2019 14:44:21 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alissa Cooper <alissa@cooperw.in>
cc: Aaron Falk <aafalk@akamai.com>, Adrian Farrel <adrian@olddog.co.uk>, S Moonesamy <sm+ietf@elandsys.com>, IESG <iesg@ietf.org>, ietf@ietf.org
Subject: Re: AD Sponsorship of draft-moonesamy-recall-rev
Message-ID: <A88B303ADC96DADCB138B3E7@PSB>
In-Reply-To: <A18C5417-F40B-4DC4-B6AB-BA0A592D15D3@cooperw.in>
References: <6.2.5.6.2.20190405085139.0d5c39b0@elandnews.com> <54510B49-175B-4CE6-9319-1F9A4803940E@cooperw.in> <033d01d4f52f$c6f2dca0$54d895e0$@olddog.co.uk> <BB40F115-46E8-4EF3-ABDE-15ABB33B4ACA@akamai.com> <C11980900F520E0EFCC83CEB@PSB> <A18C5417-F40B-4DC4-B6AB-BA0A592D15D3@cooperw.in>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZUEGY4W1OAxjqT6rbA4gXjpM24w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 18:44:45 -0000

Alissa,

Just focusing on this one comment...

--On Thursday, April 18, 2019 12:50 -0400 Alissa Cooper
<alissa@cooperw.in> wrote:

>...
> The proposal in this draft can also be trivially gamed by a
> single or small handful of individuals creating a set of 10
> email accounts, registering them to participate remotely, and
> having them join remote sessions.

I note first that leaving the number at 20 wouldn't change that
scenario significantly, if one had the skills and motivation to
set up 10 such accounts, one could almost as easily set up 20 or
50.  Second, the requirement is a little more complicated: one
would not only have to set up those accounts but, if the 3 of 5
rule is preserved, they would have to join remote sessions
during at least three consecutive IETF meetings, taking up most
of a year.   If one were trying to disrupt the IETF, mount a DoS
attack, or impose large costs on the community, the need to work
that far in advance would be a significant deterrent given that
other, faster and easier mechanisms are readily available.

>  Even if all this would
> result in is a series of recall committees being forced to be
> constituted to deal with recall petitions that get rejected,
> this could be a significant tax on our community. I think
> analyzing the countervailing benefits of this proposal against
> this tax or analyzing the costs and benefits of doing identity
> verification to overcome it are important tasks that would
> require the kind of discussion a WG can provide, and also
> require a clear understanding of what the problem statement is.

We may need to agree to disagree, but let me suggest a different
way to look at this:

Keep in mind that, as far as I know, we still have a rule that
all substantive community decisions, including technical reviews
in WGs and IETF Last Calls, get made on mailing lists.  I feel
as if that principle is eroding, but that might be just me and
is a different topic in any event.  Suppose there is a bad guy
who wants to disrupt the IETF and prevent anything from getting
done.  So, following your scenario above, they set up a number
of fake email accounts identities.  Ten would probably be enough
given how easily our mailing lists can be led into repeated
discussions and down ratholes by a single person pushing an idea
that is a little off-target or close to one that was considered
earlier and rejected, but, as pointed out above, once someone
decides to create a few such accounts, twenty or fifty is not
much harder than ten and they don't need to be (and shouldn't
be) created all as once.   Now those virtual people show up on
the IETF list and a selection of WG and other discussion lists,
advocating positions that are either unacceptable or
slightly-plausible but short of complete nonsense.   They could
even draw candidate topics and possible threads from discussions
of the past, e.g., "SMTP is obsolete and attack-prone and it is
time to replace it with..." or "the failure, after 24 years, of
IPv6 to deploy, be the primary protocol at that layer, and
restore unique addresses and the end to end model indicates that
we should drop it and make another plan focused on...".

One could think about identity verification as a counterattack,
but I note that is another noise-inducing topic with which we
have had a good deal of contentious experience.   Other
counterattacks include revocation of posting rights, but that
has to be done one mail account at a time (unless we can prove
that that all have the same origin and identify that origin,
something we have massively failed to do with, e.g., spammers)
and is also very expensive of community time.

That alternate approach may be a little bit harder for some
would-be evildoers than the one you posit because it requires
either typing in messages or setting up and using a script
generator, but if someone decides to disrupt the IETF (or impose
taxes on the community), it has the huge advantage of
almost-instant gratification.  That attack has been available
since the IETF got large enough that all participants ceased to
know each other personally, certainly since the early 1990s.
Despite some claims of deployment of "sock puppets", it has
never been used effectively, or even, AFAICT, attempted in a
serious way.

Bottom line: An attack roughly equivalent to the one you
outline, one that requires less calendar-time delay before
causing the IETF to feel significant pain, does not depend on
details of the recall procedure, has been available for a
quarter-century and has never been attempted.  Unless your
analysis shows that the proposed change to the recall procedure
would measurably and significantly increase the risk relative to
what has been available for years, I suggest that we move on.

best,
   john