Re: [Eligibility-discuss] NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt

[Eric Rescorla <[e-mail]>]

On Mon, May 29, 2023 at 3:40 PM Joel Halpern <[e-mail]> wrote:

> Whether or not the procedure in that (draft-hoffman-...) is useful for
> other people I can't say.  But it removes may elements that the
> community felt were important in defining the nomcom process and rfc
> 3797.  For example, you removed all of the challenge periods and
> challenge criteria.  And your educed the random numbers to one source,
> without specifying anything about the required degree of randomness in
> that source.  While I am not expert on the matter, the reason that was
> stated for having multiple sources was to get enough reliable randomness
> into the mix.
>

Just to follow up on Joel's point, there are actually two issues in terms of
randomness:

1. Getting enough different sources that there is a low risk one was
compromised.
2. Getting enough entropy that the attacker cannot get a material advantage.

To see the second point, consider the case where there is only a single
bit of unknown entropy. The attacker could then strategically
add/delete/challenge
candidate values until both values (0/1) produced good outcomes for them.

I don't have a calculation immediately to hand for how much is enough.
Ideally
you would like it to be much larger than N choose M where N is the number
of candidate names and M is the number of chosen, but my (unverified)
intuition is that it's sufficient to simply have the entropy be
sufficiently large
that it's not possible to search any significant fraction of the space. I do
not believe that a single stock would be sufficient because there are a
relatively small number of plausible values.

-Ekr



> Yours,
>
> Joel
>
> PS: discussing here because you posted here; probably should be moved to
> gendispatch.
>
> On 5/29/2023 6:27 PM, Paul Hoffman wrote:
> > By a weird coincidence, I was creating a new, simpler choosing protocol
> when this discussion came up. A colleague was seeing if RFC 3979 fit their
> need to select m of n people, but had problems with the implementation of
> 3797. When I looked at draft-eastlake-rfc3797bis-02, I saw that the
> pitfalls that were in 3797 were still there, and this spurred me to come up
> with something as good but simpler.
> >
> > Please see <
> https://datatracker.ietf.org/doc/draft-hoffman-genarea-random-candidate-selection/>.
> It may be of interest for the discussion of draft-eastlake-rfc3797bis.
> Please note that the proposal could be turned into an RFC even if the IETF
> wants to keep using the protocol in draft-eastlake-rfc3797bis; there is
> good reason to have a simpler protocol defined for others who want to have
> the same result as what we have for NomCom, but using an
> easier-to-understand alternative.
> >
> > --Paul Hoffman
> >
>
> --
> Eligibility-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eligibility-discuss
>