Re: [Eligibility-discuss] On 3797 alternatives

Donald Eastlake <d3e3e3@gmail.com> Tue, 30 May 2023 20:36 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 E6984C1516F8 for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 May 2023 13:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.848
X-Spam-Level:
X-Spam-Status: No, score=-6.848 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dUuxvVUldS3i for <eligibility-discuss@ietfa.amsl.com>; Tue, 30 May 2023 13:36:50 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 7C3D7C14CE5D for <eligibility-discuss@ietf.org>; Tue, 30 May 2023 13:36:50 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-970028cfb6cso942933066b.1 for <eligibility-discuss@ietf.org>; Tue, 30 May 2023 13:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685479008; x=1688071008; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ykheio8HEE/2SODshnjq2rMWjNTHfxjn5toYsGtN39Q=; b=IGdHaQxsBCpwxvyj+w28k+vFcM5Pj8NFrCuj6JBFVuzJvsEc6pJy37w2roopSp6Qds JY05tz5BQj/v26cBjhi8Ix/qXr0c/OX9c0v1Jl4v93cKf5UnykYyBe2jsc6LtR+GV+qA BjqBUncsJ7eKMxbO5AvgaRUctewfZ+2wcXSkJ3McWGsZUkH2PCoAWOoXZh7buKaCm43+ 2sTmxoib5pk+u5REDOyxPsfpfxUlj727QuUAKTiFS3KNUxRPaoETCnzLZlaDAPIJt7Hs Ag7tJzaLhmGxSLeGcuv7n1qypAtoLy0AECo6KfeTLqpWhr77Zttmu8ykmYzTVQMDXLuA 4VmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685479008; x=1688071008; h=content-transfer-encoding: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=ykheio8HEE/2SODshnjq2rMWjNTHfxjn5toYsGtN39Q=; b=PtFPxezihOrD/yBGXEBBfqWmHSDJGdSrSlY9I0z3M/LXciLbZUaKY4sVcp34qYZVQz OlhIuZp9dwlNOnaEuSF/yrYj8EAcoAZzgi7HIRMPzyG5CwqcTjNpQMaQdpP8yOQrt88L SN+Y5iQrP7p6dV6U1RBPEJyqn4s3WOs7nG6QSNCVlXqjyLRYOlM0idXyGlSv2C9x7Dij 08hlE3QV/iaO3Uinvggs6RWyOOnxsMmwPHFiWBjWO9DUdrZ8KtmMkSo0+dk8p30FvNg/ gwcwB8soF0KWiJWucWXEq17/cfkNv+txJLmqapvYGLnkam9B8L3KDJSGt5xV8ULpEE+2 X+xA==
X-Gm-Message-State: AC+VfDxkiQ2Depz8eS22rH0owR+5peMPOd6y/S+OURcCaxg7tYReHAuT KRSdHsvPX/voQTJJVuezh1UoSZwwjpwtNHRUSNlVqEdKH3U=
X-Google-Smtp-Source: ACHHUZ6qATL2Ga2vMpnpSjfBo3SbGKQYBwt3GEE0QOblFiDNpmQni6qqWUZ03eikNmzmrBq33h1l8TKR5pEJQrzYKOM=
X-Received: by 2002:a17:907:7207:b0:965:ffda:b9d2 with SMTP id dr7-20020a170907720700b00965ffdab9d2mr3164556ejc.11.1685479008325; Tue, 30 May 2023 13:36:48 -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>
In-Reply-To: <2745cf30-098d-4a3a-9e9e-3c3c44179176@app.fastmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 30 May 2023 16:36:36 -0400
Message-ID: <CAF4+nEGL0_h-iagUxhyxh2FJdz=QUi5JQr6XdPj-Q=q8Rov0XQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: eligibility-discuss@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/Ku-8ToFbrN7iLD_z-YBNlf571fI>
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: Tue, 30 May 2023 20:36:51 -0000

Hi Martin,

On Tue, May 30, 2023 at 7:51 AM Martin Thomson <mt@lowentropy.net> wrote:

I am replying just to your point below which seems equally applicable
to 3797 and Paul's draft even if the entropy in the method in Paul's
draft is increased to about what it is in 3797:

> Ekr's point about requirements is important.  We want an outcome
> that is hard to predict.  Our threat model allows an attacker to
> know the set of candidates and to manipulate it.  Therefore, in
> addition to being independently verifiable, any selection procedure
> needs to inject sufficient entropy.  We do this so that it is
> infeasible to alter the inputs in such a way as to alter the outcome
> toward an attacker's preferred choice, even with low
> probability[*].  This means the analysis in 3797 is flawed.  That
> concentrates on ensuring that the amount of entropy exceeds the
> number of permutations possible in the outcome, where what is needed
> is entropy sufficient to make an enumeration of possible outcomes
> impractical.

I disagree. First of all, you are assuming one attacker. If there is
more than one, they interfere with each other and none can predict the
results of some attempted manipulation. Furthermore, the attacker
cannot practically add people, since there is no need to announce the
list before it is closed to additional volunteers. They could possibly
remove people by having volunteers that they would direct to decline
to serve.

If you have enough entropy that the probability of each possible set
of selections deviates only insignificantly from random, then all an
attacker can do to try to get a particular person selected is (1) make
the pool smaller or (2) stuff the pool with ringers who will decline
to serve if selected. But, if you re-randomize, I think 2 is no better
than 1. Say the attacker wants a particular person selected and they
stuff in 10 ringers and the total number of volunteers in the pool is
100. Say the person the attacker wants selected in not in the initial
10 selectees but 5 of them are ringers who the attacker directs to
decline to serve. The probability of the person the attacker wants
selected to be selected in the next round is 1 in 90, exactly what it
would have been if those 5 ringers were not in the pool and 5 people
had already been selected. So, the attacker has gained nothing in the
case of enough entropy at each stage.

Large amounts of publicly trusted entropy are not that easy to
collect. I am inclined, based on your points, to change rfc3797bis to
recommend enough entropy to be able to produce all possible selections
but no more than that.

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

>
> ...
>