Re: [Eligibility-discuss] On 3797 alternatives

Donald Eastlake <d3e3e3@gmail.com> Fri, 02 June 2023 21:47 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC5C151534 for <eligibility-discuss@ietfa.amsl.com>; Fri, 2 Jun 2023 14:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBQ0P2gm8H4C for <eligibility-discuss@ietfa.amsl.com>; Fri, 2 Jun 2023 14:47:05 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3515CC15152C for <eligibility-discuss@ietf.org>; Fri, 2 Jun 2023 14:47:05 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4f3b4ed6fdeso3432809e87.3 for <eligibility-discuss@ietf.org>; Fri, 02 Jun 2023 14:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685742423; x=1688334423; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O5C9rbGy+iFtDswHXhsEwGd9JlhS3fsFrY93UAYDJY0=; b=kHofMQJ3yiq7R9yMbmW4ul5B5KW7/nKOVJOqkQ9Jm9k6ebnsnAaOxO+t7ebuP76VoL Xh6JzUfE5d9Xxys4CmuAyhhg4LxsAqWVaVozGR9Xv1suiHDXyN+akN5h89KU5VhLfGQZ RIJd96iimUWjU7QSMzxdEh8XOSnF3qO8ZmtogIQp5pCtz7x8Igfx/OYVDHaaR8quDHx5 JXQtNQk6ByovkqZcdLeeOS+UsBtlRdnVGqjdoxxuhgt4nsLR+sR6SwMGL15bE6pRD+gq 4L+1t0jYjX8/oBN6d6ctS8nwRPBEOik3B7EGHJ1UxCuz8M/bSfMe0+iYAyWRwoch18sn kj1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685742423; x=1688334423; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O5C9rbGy+iFtDswHXhsEwGd9JlhS3fsFrY93UAYDJY0=; b=UKJZ8qAjx1Ag8/myf4vogESR/dWLZHj2dXO7JEgALaJuiCRfd1d/R4yRFJLcnBtrAi jZt0YmkPTgPvhqjtHOjh2TeGXbkJhc1tuw7gJosT/vN5AH6XLCGak+4cULBKvRxZwNww 3bMzVlzRNNBoLTaj3rn1YB8ccQ0GX86DVBRxZnfBOu31Mpg/yOaTg7oF/Qo8IySlTUUk xsvwLLNCoLCB/ZdncpNNs+zzGYnfu5vp9YA9Uz19Y0fTZIIs4lwG6SdEtNqe+WxcDv/j Kz4EXQ7SMUszshUNqqVTVQU1VehoC+GLTJnisu5tqUofg4Pd1GYHpZxRBdmxueT3zPYW UPpQ==
X-Gm-Message-State: AC+VfDx11vnKVOBDFRAVdhECZJT6HyOQLc0BjDs+lKlbb26r4wzct6uf wwCwhfhHwWnOeXo0mwNSAgvnSpyLHaYgyPiOhxVHn0n4
X-Google-Smtp-Source: ACHHUZ56RJwmQQkKVHlkppLWbAMr8xdxOzyQ0bDHDg4xXoExivAvwWA+2LEo04vZOvLg8E+Hqpc9eB/S1XJuFVVEBuw=
X-Received: by 2002:a19:ae0e:0:b0:4f6:8eb:50ca with SMTP id f14-20020a19ae0e000000b004f608eb50camr2304878lfc.33.1685742422843; Fri, 02 Jun 2023 14:47:02 -0700 (PDT)
MIME-Version: 1.0
References: <54F373CD-1E97-42BC-9AAB-0451ABD9D448@eggert.org> <1229DD7D-3640-4EFD-8058-D0EC18020038@eggert.org> <18537EEF-4E16-4C48-8456-02A8FB0C8CFC@vpnc.org> <4a8f2bb4-25c3-5514-f13f-8db1804619a6@joelhalpern.com> <0531CD69-AAA4-4657-9B90-B50F76D997B7@vpnc.org> <ffa1d82b-a22b-f68f-5000-6a1ca437d147@joelhalpern.com> <B953359D-72A9-4032-857E-490AEAF60C4A@vpnc.org> <2745cf30-098d-4a3a-9e9e-3c3c44179176@app.fastmail.com> <CAF4+nEGL0_h-iagUxhyxh2FJdz=QUi5JQr6XdPj-Q=q8Rov0XQ@mail.gmail.com> <9d9b0e70-c7ca-4602-8862-33165522497c@app.fastmail.com> <896FF479-E5B7-4A31-95AE-376CCE2591C9@akamai.com> <CABcZeBN7XyRknvkg9TfvTCx3rGEpLtWynE7-eaufhmcEmnDHtA@mail.gmail.com> <30f8a4a3-2a3c-4560-abe5-63ee0c4366d4@app.fastmail.com> <9DCA0EF0-8E99-4A33-ABAB-45997C96002F@akamai.com> <CABcZeBOS1zAmS664bQAiAZPhN5-Hr6OTbv6UZu+Ai9zwsps_CQ@mail.gmail.com> <09B9FC9D-9124-41CB-A47A-2B36FCFF688B@akamai.com> <CABcZeBNn4UvwX3H2Go_0Hb-6=mjD5jpi=9709rNJn3-R-pCnZg@mail.gmail.com> <1E2309D2-4413-4A43-847F-C2FFAAB44A6E@akamai.com> <CABcZeBPqntox9kA2C+vx+62U6O5HYJKt7CGqBMb=yUsCmDqZ=Q@mail.gmail.com> <79752801-b405-445b-a782-784823a00118@betaapp.fastmail.com>
In-Reply-To: <79752801-b405-445b-a782-784823a00118@betaapp.fastmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 02 Jun 2023 17:46:50 -0400
Message-ID: <CAF4+nEFV9t+UJSHk5wop8C9=J54hQX0hFGe3BYrHUpLA8_zXGA@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: Eric Rescorla <ekr@rtfm.com>, "Salz, Rich" <rsalz@akamai.com>, "eligibility-discuss@ietf.org" <eligibility-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bf2d805fd2c7e4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/zgx1aOcu1PWkdSCmU68GGz-j2Sc>
Subject: Re: [Eligibility-discuss] On 3797 alternatives
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF eligibility procedures <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2023 21:47:09 -0000

Hi Martin,

I'm fine with assuming a single attacker but I am concerned about over
complicating things to, say, block the attacker from inducing a bias of say
1 part in a million.

Below are some numbers which, while not directly applicable to the attack
you are talking about, are, I think, indicative of the miniscule biases we
may be talking about.

It depends a bit but I think that when you make many selections of n items
from a population p with replacement (which is approximately true if p>>n)
and do this t times, obviously the expected number of times a particular
item would be chosen is t*(n/p). Making some simplifying assumptions, the
standard deviation of the number of times a particular item would be chosen
is, I think, SQRT(t*(n/p)*(1-(n/p))). Assume you are selecting 10 items
from 200, about what the current nomcom selection is. Using those
equations, with an abysmal 10 bits of entropy, that is selection 10 at
random from 200 and doing it randomly just 1024 times, the expected number
of times an entry would be selection is 51.2 and the standard deviation of
the number of times it is selected is 6.97 or 13.6% of the expected value,
which I would consider unacceptable. Move up to 20 bits, that is selecting
randomly 2**20 or 1,048,576 times, and the expected number of times an item
is selected is 52,429 but the standard deviation in the number of times it
is selected is only 223 or 0.426% of the expected value which I would
consider marginal at best. With 30 bits, this is selecting randomly 2**30
times, the expected number of times selected is 53,687,091 with a standard
deviation of 7,142 or just 0.013% of the expected value, which I consider
acceptable. But RFC 3797 and rfc3793bis recommend a minimum of 40 bits of
entropy which implies about 2**40 or 1.1E12 selections so the expected
times an item is selected is 5.5E10 with a standard deviation of 228,532 or
just 0.00042% of the expected value. So, even though it takes a minimum of
54 bits of entropy to do completely random selection of 10 items from 200,
with just 40 bits of entropy, under the assumptions above, the probability
of a particular item being selected will deviate from perfect randomness
only by an insignificant amount, as asserted in RFC 3797 and rfc3797bis.

So, what is a reasonable estimate of the amount of bias that can be
introduced by the attack you hypothesize?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Thu, Jun 1, 2023 at 10:01 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Thu, Jun 1, 2023, at 05:54, Eric Rescorla wrote:
> >> Given the common practice of choosing several large-scale lottery
> systems this seems infeasible to me. YMMV of course.
> >
> > This also matches my intuition, though I don't have any analysis to
> support it.
>
> Let's take Mega Millions (https://en.wikipedia.org/wiki/Mega_Millions).
> Assuming that balls are chosen with close to uniform distribution - a
> reasonable assumption in this case, I hope -  the amount of entropy in a
> draw is just over 28 bits.  Enumerating a space of that size is costly, but
> feasible if you assume that the computations involved are relatively
> lightweight.
>
> So we might dispense with the notion that some influence on NomCom results
> is conditional on being able to predict a single lottery, even if
> predicting the lottery outcome would clearly provide someone more direct
> and tangible value.  It is more about being able to bias the outcome.
>
> Given knowledge of all possible outcomes, the attacker only has to pick
> the most favourable outcome of those available to them.  Their computation
> cost increases basically in proportion to the number of volunteers they
> control (for Paul's approach, anyway; for 3797 it's a tiny bit more
> complex, effort might depend on the total pool size).  That is, the
> attacker is able to choose from the most favourable subset of 2^v options
> out of a total space of 2^{e+v}, using computation proportional to v.2^e.
>
> To give you an idea of the bounds on potential volunteer control, I found
> one company domain name in the emails of 188 eligible volunteers; another
> company appeared 148 times.  The actual number of people who currently work
> at those companies is likely fewer, but I also didn't consider
> subsidiaries.  That's a lot of potential control.
>
> It's hard to know whether knowledge of possible outcomes would be enough
> to justify an attack like this over just stuffing the NomCom with as many
> people as possible.
>
> Computational bounds are easier to reason about.  If the attacker cannot
> enumerate a good proportion of the 2^{e+v} space, then they don't guarantee
> that the bias they introduce is in their favour.
>
> The entropy in a single lottery tends to be fairly small relative to a
> reasonable computation target - Mega Millions is more than 5 bits stronger
> than Tatts Lotto, as used last year - but most lotteries will have in the
> order of million to one prize to ticket ratios, so they will probably want
> in excess of 20 bits to ensure that they retain the appeal of a big
> return.  So I'd say that 3 lotteries would be adequate for our purposes.  >
> 2^60 work is more than we'd allow for something that matters more than this.
>
> On other entropy sources: Picking stocks is highly unlikely to provide the
> same advantage as a lottery.  A stock or index rarely has a big range.  The
> Dow Jones has a 6k range over the past year and is usually down to two
> decimal places.  That's 19 bits at best, but the values are far from
> uniform, especially over a shorter period (S&P over the past month was 14
> bits at best).  The same goes for contests, like horse races, where picking
> a winner is not the same as choosing uniformly at random, therefore the
> entropy could be low.  Running an analysis on the basis of the favourite
> winning is too easy.
>
>
>