Re: [Eligibility-discuss] Discussion of draft-ietf-elegy-rfc8989bis and IETF 115

[Brian E Carpenter <[e-mail]>]

Donald,
On 06-Nov-22 06:57, Donald Eastlake wrote:
> Hi Martin,
> 
> See below.
> 
> On Thu, Oct 6, 2022 at 4:54 PM Martin Duke <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi Donald, thanks for the review. Comments inline. I've deleted nits to which I have no objection and will be in the nits PR:
> 
>     https://github.com/ietf-wg-elegy/rfc8989bis/pull/8 <https://github.com/ietf-wg-elegy/rfc8989bis/pull/8>
> 
> 
> Thanks.
> 
>     On Wed, Oct 5, 2022 at 11:17 AM Donald Eastlake <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>            -- eligibility requirements.  The actual NomCom is selected at random
>            -- from the pool of eligible volunteers, with restrictions to ensure
>            -- that no more than two volunteers with the same primary affiliation
>            -- are chosen.
> 
>         I don't see any need to mention the affiliation restriction in this
>         document which should just focus on nomcom volunteer pool eligibility.
>         Any additional restrictions on the random selection should stay in RFC
>         8713 and successors. Suggest replacing the last sentence with "The
>         actual NomCom is selected at random from the pool of eligible
>         volunteers.  Thus, it is important that members of the pool be IETF
>         participants likely to have knowledge of IETF processes and Tao."
> 
> 
>     It's useful background when we discuss the probability of NomCom capture.
> 
> 
> Yes, useful background...
> 
> My point of view is that "no more than two with the same sponsor" isn't an eligibility requirement. It has no effect on whether someone is in the pool from which the nomcom is selected. It is a restriction on selection from that pool. Since IETF members participate as individuals, all those who meet the criterion to be in the pool would, ideally, be treated equally. The current selection restriction is unfair to anyone from a sponsor who sponsors many IETF participants who qualify to be in the pool, but it is necessary for appearance sake. 

I really don't understand that comment. It is IMHO nothing to do with appearance. It was added because we had good reason to fear that some companies would try to obtain an unfair advantage by encouraging large numbers of employees to volunteer. While it is true (by definition) that people participate as individuals, it is also true (by observation) that some companies fund a large number of participants.

I think the main point of having random selection is not to ensure fairness towards participants; it's to avoid intrinsic bias in the NomCom. The two-per-employer rule is part of that.

    Brian

> Initially there was no such restriction. There were nomcoms with three people from the same sponsor (and a significant probability that there could have been a nomcom with even more voting members having the same sponsor) and most people acknowledged that this looked terrible. As I say, it has nothing to do with the eligibility criteria. Too many with the same sponsor looks terrible whether the pool of volunteers from which the nomcom is 
> selected is 50 people or 500 people.
> (Actually "treated equally" above could be stretched to cover some sort of complex weighted choice system where the more active you were in the IETF, the more likely you would be to be chosen -- but I am NOT about to propose anything like that. Simplicity is a virtue.)
> 
>            --
>            -- Section 4.14 of [RFC8713] requires that volunteers must have attended
>            -- three of the previous five in-person meetings.  In practice, this has
>            -- meant that the volunteer picked up their registration badge.
> 
>         Comment: While this has been true, I think it was because, with
>         hand-written blue sheets, it was impractical to get a significantly
>         better indication of attendance. The current hybrid meeting
>         technology with automatic blue sheets makes it much easier to enforce
>         a much more solid attendance requirement. See further comments below.
> 
> 
>     OK, I see no suggested change here. 
> 
>            -- [RFC8989] specified an experiment in the wake of six consecutive
>            -- fully online meetings from 2020 to 2021, where the traditional
>            -- interpretation of the requirement would have resulted in no eligible
>            -- volunteers.  It extended the attendance requirement to define meeting
>            -- attendance as including logging in to at least one session of a
>            -- fully-online IETF meeting.
> 
>         In my opinion, that is an absurdly lax attendance requirement for a
>         meeting. See further comments below.
> 
> 
>     This is a bigger discussion that I won't address in a nits PR. It'd be great if
>     you could file a github issue or start a separate thread specifically about this.
> 
> 
> Will file an issue.
> 
>         Why would the eligibility criterion be loosely based on RFC 8989 rather
>         than loosely based on the first principles?
> 
> 
>     "loosely" is gone. This is a factual statement of where the normative text came
>     from.
> 
> 
>            -- Further, the NomCom can now fully complete its business using online
>            -- tools.
>            --
>            -- Counting remote attendance lowers the barriers to entry.
> 
>         Add "but decreases the average knowledge of IETF processes, spirit,
>         and leadership by those eligible. Thus, a balance is required between
>         openness and qualifications."
> 
> 
>     I am somewhat sympathetic to this sentiment, but think it would be controversial and do not have data to back it up (as if there were a way to measure these things). There are certainly exemplary community members who usually attend remotely. If we end up restricting the criteria more, I'm happy to revisit this text.
> 
> 
> Ok.
> 
>            --                                                          As IETF is
>            -- committed to having a no-fee remote option
>            -- ([I-D.draft-ietf-shmoo-remote-fee]), the only required investment is
>            -- to log on once per meeting at a specific time (sometimes a locally
>            -- inconvenient hour).
> 
>         The above sentence seems unnecessary. I don't see how it matters much,
>         for the purposes of this document, whether or not there is a no-fee
>         remote option nor whether the IETF is committed to it.
> 
> 
>     The text is about how hard it is to get your agents qualified for NomCom, so the minimum cost of attendance is relevant.
> 
>            --                      While this document does not formally impose a
>            -- requirement for the NomCom to function entirely remotely, including
>            -- remote-only attendees in the pool is likely to effectively require a
>            -- remote component to NomCom operations.
>            --
>            -- Finally, it is historically difficult to recruit volunteers for
>            -- NomCom, so overly restrictive criteria work against getting a deep
>            -- talent pool.
> 
>         In my opinion, the above sentence is just plain false. Volunteers to
>         serve on the nomcom are only hard to recruit if you have excessive
>         goals.  My opinion is that the nomcom worked fine for years and years
>         in its early times with a volunteer pool around 50 or 60. Even with
>         that a volunteer has only about an 18% chance of being chosen. I can
>         see someone wanting >100 in the pool. But I don't see any need for
>          >200.
> 
> 
>     I'm not interested in arguing the historical record of NomCom recruitment, so I deleted the clause.
> 
> 
> Thanks.
> 
>         The idea that the world is divided into "the IETF community" and "not
>         the IETF community" by a line seems wrong to me. There is really a
>         spectrum from people with deep, full-time, long-term participation, to
>         people who have just read a few messages on one IETF mailing list or
>         stopped by one meeting of one WG.
> 
>         It seems to me that fundamental principles for nomcom pool eligibility
>         would be things like
> 
>           + A pool generally biased towards those more familiar with the
>             spirit, processes, and leaders of the IETF.
> 
>           + A large enough pool membership that each pool member has < 10%
>             chance of being chosen so they do not feel entitled to a vote.
> 
>           + A sufficiently dynamic pool, implemented through a sufficiently
>             short time horizon, that you get a reasonable number of new pool
>             members each year.
> 
> 
>     Again, a much bigger discussion that deserves its own thread or GitHub issue. If we are really going to revisit this thing from first principles, that may be worthwhile but will put some time pressure on the next NomCom.
> 
> 
> Ok.
> 
>         [Long critique of paths omitted]
> 
> 
>            --
>            -- 6.  Security Considerations
>            --
>            -- The threat model associated with NomCom eligibility is that an
>            -- organization or group of organizations would attempt to obtain a
>            -- majority of NomCom positions, in order to select an IETF leadership
>            -- in support of an agenda that might be self-serving and against the
>            -- interests of the community as a whole.
>            --
>            -- Note that [RFC8713] lets the Chair decide the NomCom voting
>            -- requirement, so a simple majority may be inadequate.  However, 7 of
>            -- 10 forms a quorum, so at worst seven NomCom members working together
>            -- can almost certainly impose their will.
> 
>         I don't think the exact vote is particularly important.
> 
> 
>     It's just setting up the problem.
> 
> 
>            -- Whatever the merits of admitting remote attendees, it reduces the
>            -- minimum cost of creating a NomCom-eligible volunteer from three
>            -- flights and ~5 days of travel over the course of a year, to zero
>            -- financial cost and the time required to log in three times over the
>            -- course of a year.  Some organizations might not be deterred in either
>            -- case, while others might now find such an attack to be feasible.
> 
>         While it is not a huge change in the effort required, replacing the
>         absurdly lax attendance requirement with a stricter requirement, as I
>         have suggested above, does help a little.
> 
> 
>     OK
> 
> 
>            -- 6.1.  A Surge of Volunteers
>            --
>            -- A large number of "legitimate" volunteers makes it quite difficult to
>            -- control 6 of 10 NomCom slots.  Setting aside limitations on the
>            -- number of selections from any organization, basic probability shows
>            -- that to have even a 50% chance of controlling 6 or more NomCom
>            -- positions, an attacker needs somewhat roughly 60% of the volunteer
>            -- pool.  For example, if there are 300 "legitimate" volunteers, an
>            -- attacker must produce 365 volunteers to exceed a 50% chance of NomCom
>            -- capture (see Appendix A).
>            --
>            -- A sudden surge in the number of volunteers, particularly of people
>            -- that no one recognizes as a part of the community is an early-warning
>            -- system for leadership to further investigate.
> 
>         Sure, but who is supposed to notice this? And how does the leadership
>         intervene if they think there is an actual problem?
> 
> 
>     Do you have suggested text here? I'm not sure this document needs to specify countermeasures and name names.
> 
> 
> Well, you could have something like "In case of an extraordinary surge in nominees or good evidence of substantial abuse of process, the IESG should take such steps as it deems necessary to maintain the integrity of the nomcom selection process." I suspect people would be uncomfortable with that so I am sure about including it. But on the other hand, I believe that some people sort of believe a guideline like that is generally in effect and that we can afford to be relaxed about process things because, if disaster strikes, the IESG will take appropriate action. On the third hand, while being relaxed about process and having a "do the right thing" attitude can be beneficial in many areas, as I can testify as a former nomcom Chair and many other nomcom Chairs can corroborate, when it comes to nomcom process, for some reason many IETF members are almost fanatic sticklers for enforcing the letter of the rules...so it might be really nice to leave yourself an escape hatch.
> 
>            -- While loosening eligibility criteria lowers the cost to an attacker
>            -- of producing eligible volunteers, it also increases the number of
>            -- "legitimate" volunteers that increases the difficulty and
>            -- detectability of an attack.
> 
>         The above seems correct except for the last bit. How does more
>         legitimate volunteers make an attack easier to detect? I would think
>         it provides a bigger dataset for the attack to hide in so I would
>         think it decreases the detectability of an attack.
> 
> 
>     Good point.
> 
>            -- 6.2.  The Two-Per-Organization Limit
>            --
>            -- The two-per-organization limit in [RFC8713] complicates such an
>            -- attack.  To circumvent it, an organization must either (1) coordinate
>            -- with at least two like-minded organizations to produce a NomCom
>            -- majority, (2) incentivize members of other organizations (possibly
>            -- through a funding agreement) to support its agenda, or (3) propose
>            -- candidates with false affiliations.
> 
>         Nope. You are assuming some sort of "good faith" attackers.
> 
>         Here is the sort of attack I would envisage: assume that Alphaland (a
>         fictitious country listed in RFC 3797) has a highly patriotic populace
>         and there is a large Technical University of Alphaland. They just go
>         to the campus and urge these patriotic students (and professors or
>         whatever), who all want to help Alphaland companies to have a higher
>         profile and more control in the IETF, to register for and attend WG
>         slots at IETF meetings. The at-most two with the same sponsor
>         provision has no effect: Each student or whoever just says they are a
>         one person consulting company and maybe the Technical University of
>         Alphaland has some work study courses under which the student actually
>         gets a consulting contract and gets paid a little. Once you remote /
>         virtualize things, it is a whole different ball game, and you have to
>         be very careful and/or have effective circuit breaker mechanisms
>         since, sooner or later, there will be abuse.
> 
> 
>     The scenario you describe is a false affiliation, since clearly their primary affiliation is the University.
> 
> 
> Is it? What if they "hired contractors" from the general unemployment pool? Could you prove this falseness? How would a court interpret "affiliation"?
> 
> Virtualizing things frequently makes more difference than you might think.  When essentially all telephones were physical devices hardwired at specific physical locations, there was almost no problem with swatting (which is almost always done using VOIP, https://en.wikipedia.org/wiki/Swatting <https://en.wikipedia.org/wiki/Swatting>), much, much less problem with spam calls, etc. Handing in a paper ballot with wet ink signature and fingerprints on it really isn't the same as emailing a PDF. I'm not saying that you cannot compensate for the security problems with virtualization or that there isn't cheating with the non-virtual, just that virtualization can weaken security more than you might think.
> 
>            -- While the IETF does not routinely confirm the affiliation of
>            -- volunteers, as part of an investigation it could eliminate volunteers
>            -- who have misrepresented said affiliation.  Publishing the list of
>            -- volunteers and affiliations also gives the community an opportunity
>            -- to review the truth of such claims.
>            --
>            -- Assuming that 300 legitimate volunteers are all from different
>            -- organizations, three conspiring organizations would need 771
>            -- volunteers (257 per organization) for a 50% chance of NomCom capture
>            -- (see Appendix A).
> 
>         As above, against a serious adversary, the 2 persons per sponsor limit
>         has no effect. I think this Section 6.2 should be dropped.
> 
>     Including this section shows the attacker's benefit in falsifying affiliations, which indicates why the community might want to have early warning systems for these issues.
> 
>     Put another way, the affiliation limit does provide a useful benefit in mitigating this threat, though it absolutely does not solve it by itself.
> 
> 
>            -- 6.3.  One Year of Participation
>            --
>            -- Attendance at 3 meetings requires at least 1 year.  Given the volume
>            -- of volunteers necessary to capture the process, an attack requires a
>            -- surge in attendees over the course of a year.  IETF leadership SHOULD
>            -- analyze unexplained surges in attendance to look for signs of
>            -- manipulating the eligibility requirements (e.g. logging in to a
>            -- single session and then immediately logging out).  In the event of
>            -- malfeasance, the leadership would then have months to adjust policy
>            -- in response before the NomCom cycle begins.
> 
>         I think you want to say "abuse of process" or "manipulation" rather
>         than "malfeasance".  "Malfeasance" typically implies misconduct or
>         corruption by a public official.
> 
> 
>         I think a section is missing from the Security Considerations about
>         the greater difficulty of positive identification in a virtual
>         environment.  Something like the following:
> 
>             6.X.  Security of Identities
> 
>             Personal recognition in an in-person environment has always been
>             acknowledged as the most security form of identification.  Remote
>             access / virtualization makes secure identification of persons more
>             difficult. It will be only a few years before real-time deep fake
>             video software will be widely available on home computers.  There
>             has already been one case of attempted IETF Working Group consensus
>             manipulation through sock puppets. Nevertheless, it is felt that
>             alertness to this issue and prompt investigation and, if warranted,
>             action, will be a sufficient defense.
> 
> 
>       I guess I'm not sure what the threat model here is. Would an attacker claim to
>     be  Donald Eastlake in order to gain eligibility for NomCom?
> 
> 
> Probably more likely someone would claim to be 100 different people, all with adversarial-AI generated appearance and voice and name...
>