[Ssh] COI question (was: RE: Re: WG Review: Secure Shell Maintenance (sshm))

[Roman Danyliw <[e-mail]>]

Hi Dr. Bernstein,

The IESG has received your note [2] about obligations for recusal under the IESG Conflict of Interest Policy (COI) [1] regarding Deb Cooley in her capacity as responsible AD for a potential Secure Shell Maintenance (SSHM) WG.

Per [2], you specifically asked:

> > Also, sorry to have to ask this, but aren't you obliged to recuse
> > yourself from all decisions on reducing the level of IETF involvement in
> > cryptographic standardization? When cryptographic standardization began,
> > NSA adopted a secret policy of trying to reduce competition in this
> > space so as to reduce security:

As we understand your argument, you believe there is an obligation for recusal due to an inherent perception of conflict of interest for Deb for most matters related to cryptography in the IETF by virtue of her employment history with the US National Security Agency.

The IESG assesses that this question has already been answered in the negative by the 2023 NomCom [3] and the IAB’s confirmation of the NomCom’s choice.  Making technical judgements and facilitating processes around the use of cryptography in the IETF, and upholding community consensus policies set in BCPs (e.g., BCP188 “Pervasive Monitoring is an Attack”) are core responsibilities of a Security Area Director.  With full knowledge of Deb’s employment and the core responsibilities for a SEC AD, and assessing the community feedback on the candidates, the 2023 NomCom chose Deb as the Security Area Director. 

The IESG is satisfied that the NomCom expects Deb (like all Area Directors) to recuse herself from specific decisions that might raise a Conflict Of Interest concern, and is confident that she will do so should that situation arise.  With respect to this chartering process, the IESG assesses that no such decision has been required thus far, rendering the question moot in this context. 

Regards,
Roman 
(as IETF Chair, for the IESG)

[1] https://www.ietf.org/about/groups/iesg/iesg-coi-policy/
[2] https://mailarchive.ietf.org/arch/msg/ssh/_Abq1Dr8ddG8UAJmqMdR-8KKkgY/
[3] https://datatracker.ietf.org/nomcom/2023/

> -----Original Message-----
> From: D. J. Bernstein <[e-mail]>
> Sent: Friday, September 6, 2024 11:36 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Ssh] Re: WG Review: Secure Shell Maintenance (sshm)
> 
> To the IESG, cc'ing [e-mail]:
> 
> Various people, including me, have expressed unanswered concerns on
> [e-mail] regarding the proposed WG.
> 
> My preliminary conclusion, given what I've seen so far, is that forming a WG
> under these ADs would be a disservice for the community that has built ssh,
> and a disservice for the users relying on ssh for security.
> The traditional goal of publicly coordinating protocol development would be
> better served by an ssh-protocol mailing list independent of IETF.
> 
> It's possible that this conclusion will be changed by further information, but I'm
> in any case surprised to see a WG proposal being pushed forward when major
> concerns still haven't been answered. The concerns aren't simply with details of
> how a WG will run, but with the more basic question of whether a WG should
> be formed in the first place.
> 
> One of the concerns is with the appearance of an AD conflict of interest
> contrary to the explicit purpose of IESG's COI policy. I expressed this concern
> briefly on [e-mail], and then in much more detail in a complaint to IESG
> dated 17 Aug 2024 03:34:56 +0200. IESG hasn't responded to the complaint.
> I'm quoting below the portions of the complaint relevant to the specific AD
> assigned to the proposed WG.
> 
> ---D. J. Bernstein
> 
> 
> D. J. Bernstein writes:
> > As background, https://www.ietf.org/about/groups/iesg/iesg-coi-policy/
> > observes that IESG duties "may be — or may appear to be — incompatible
> > or in conflict with ... the interests of an organization of which the
> > Covered Individual is an employee, director, owner, or otherwise has a
> > business or other current or future financial interest."
> >
> > The policy says that its purpose is "to prevent Covered Individuals
> > from using their IESG roles or the IESG’s resources or decisions to
> > prioritize their own personal interests or the interests of their
> > related third parties over the best interest of the IETF community."
> >
> > As an example of how some third parties have interests opposed to the
> > best interest of the IETF community, consider RFC 7258, "Pervasive
> > Monitoring Is an Attack", explicitly labeled as the consensus of the
> > IETF community, and in particular saying "The IETF Will Work to
> > Mitigate Pervasive Monitoring". This RFC was triggered by news
> > articles in 2013 regarding mass surveillance by NSA and GCHQ. Several
> > years later, the European Court of Human Rights held that GCHQ's activites
> were illegal:
> >
> >
> > https://www.theguardian.com/uk-news/2021/may/25/gchqs-mass-data-
> sharin
> > g-violated-right-to-privacy-court-rules
> >
> > It's unclear what actual effect this court decision had on GCHQ.
> > Certainly the court decision has no power over NSA.
> >
> > My blog post https://blog.cr.yp.to/20220805-nsa.html covers much more
> > of what's known about NSA's cryptographic sabotage. In particular,
> > when cryptographic standardization began, NSA adopted a secret policy
> > of trying to reduce competition in this space so as to reduce security:
> >
> > > Narrowing the encryption problem to a single, influential algorithm
> > > might drive out competitors, and that would reduce the field that
> > > NSA had to be concerned about. Could a public encryption standard be
> > > made secure enough to protect against everything but a massive brute
> > > force attack, but weak enough to still permit an attack of some
> > > nature using very sophisticated (and expensive) techniques?
> >
> > See pages 232-233 of https://archive.org/details/cold_war_iii-nsa, an
> > internal NSA book that was partially declassified in 2013 as a result
> > of journalists forcing declassification-review procedures. There has
> > never been a public statement from NSA revoking the above policy, nor
> > would such a statement be credible given NSA's long history of sabotage.
> >
> > One cryptographic mechanism that NSA manipulated NIST, ISO, and ANSI
> > into standardizing was Dual EC, a backdoored standard for generating
> > random numbers using elliptic curves. Various other NSA-proposed
> > standards for elliptic-curve cryptography (ECC) turned out to be
> > filled with traps for implementors---traps that continue to cause
> > exploitable problems, as illustrated by CVE-2023-6135 in Firefox. For
> > more about Dual EC, see https://cr.yp.to/papers.html#dual-ec; for many
> > further ECC failures, see https://cr.yp.to/papers.html#safecurves.
> >
> > Within IRTF, CFRG spent two years investigating ECC options in detail.
> > CFRG ended up selecting X25519, which is an encryption system that I
> > had designed, and Ed25519, a signature system that I had co-designed.
> > CFRG issued informational RFCs describing these cryptosystems. Various
> > IETF protocols added appropriate options; X25519 is now used in most
> > TLS connections, for example.
> >
> > To be clear, this was IETF directly competing with NSA and other
> > organizations in setting ECC standards, and doing so successfully,
> > with a major influence not just on IETF protocols but also outside
> > IETF. This influence was good for the end users. The research
> > explaining security advantages of X25519/Ed25519 over NSA ECC have
> > been repeatedly confirmed by direct real-world comparisons: the
> > "Minerva" attacks and the recent breaks of "5G Subscription Concealed
> > Identifiers" worked against implementations of NSA ECC while failing
> > against implementations of
> > X25519/Ed25519 in the same software.
> >
> > Of course, there have been many other IETF RFCs on cryptography at
> > various layers, and there is a continuing demand for further RFCs,
> > most obviously in the context of post-quantum cryptography. There is
> > ongoing controversy about which post-quantum choices are best, as
> > illustrated by
> >
> >
> > https://www.nxp.com/company/blog/conservative-post-quantum-security-wi
> > th-frodokem:BL-POST-QUANTUM-SECURITY-WITH-FRODOKEM
> >
> > indicating that FrodoKEM is under consideration for standardization by
> > ISO, whereas NIST has removed FrodoKEM from consideration.
> >
> > Now imagine an NSA employee saying that IETF and IRTF should stop
> > independently evaluating cryptography, and should instead endorse
> > whatever NSA endorses. By far the simplest explanation for this is the
> > same NSA policy---again, contrary to IETF interests:
> >
> > > Narrowing the encryption problem to a single, influential algorithm
> > > might drive out competitors, and that would reduce the field that
> > > NSA had to be concerned about. Could a public encryption standard be
> > > made secure enough to protect against everything but a massive brute
> > > force attack, but weak enough to still permit an attack of some
> > > nature using very sophisticated (and expensive) techniques?
> >
> > For purposes of evaluating conflicts of interest under IESG policy, it
> > really doesn't matter whether the people involved claim that this
> > isn't the reason for their actions; the fact that there _appears_ to
> > be a conflict of interest is enough to force recusal.
> >
> > https://datatracker.ietf.org/person/Deb%20Cooley says that IETF
> > security-area director Deb Cooley worked for NSA for "37+ years",
> > retired in December 2023, and is still "working as a Stand-by Active
> > Reservist at NSA/CSD". NSA is listed as a current disclosure for
> > Cooley on https://www.ietf.org/about/groups/iesg/iesg-coi-policy/. The
> > slides
> >
> >
> > https://datatracker.ietf.org/meeting/120/materials/slides-120-saag-cry
> > ptography-at-the-ietf
> >
> > wildly understate IETF/IRTF activity in cryptography (e.g., claiming
> > that "CFRG does not analyse or evaluate cryptography itself") and
> > proposes to "limit publication of crypto RFCs". The brief discussion
> > at the meeting was enough for various people to give examples of how
> > the details of this proposal were (1) unclear and (2) inconsistent
> > with useful IETF/IRTF activity.
> >
> > The proposal certainly didn't reach consensus at the meeting. It
> > hasn't shown up on the SAAG mailing list. It also didn't acknowledge
> > previous statements on the SAAG mailing list that sound opposed to the
> > whole idea of the proposal. For example, in April 2024, Rich Salz
> > wrote "I agree with Dan. We should certainly work on/with NIST
> > algorithms, but it is wrong for the IETF to cede crypto control to that singular
> US Agency."
> >
> > The context of the April 2024 discussion is important for this
> > complaint. TinySSH and then OpenSSH added support for post-quantum
> > cryptography---using sntrup761, which I co-designed, and which, unlike
> > NIST's new ML-KEM standard, isn't in a patent minefield. OpenSSH 9.0
> > in April 2022 made this default---the first major post-quantum deployment.
> > Simon Josefsson wrote an I-D documenting what was deployed.
> >
> > If there had been a working group then surely the I-D would have been
> > an RFC by now. But there wasn't a working group, so progress depended
> > on AD support. There were some AD claims opposing the I-D for reasons
> > that didn't stand up to examination. I raised objections on SAAG to
> > those AD claims. There was clear support for the I-D: e.g., Stephen
> > Farrell wrote "I think sntrup761 is credible enough so that, given
> > it's deployment, there's a benefit in documenting that as per the draft".
> >
> > Eventually there was an AD proposal to (re-)form an ssh working group.
> > There's now an [e-mail] mailing list discussing proposals for a
> > charter. Some of the proposed charter text sounded too narrow to allow
> > consideration of this I-D. Various people objected to that. There was
> > then a puzzling AD response:
> >
> >
> > https://mailarchive.ietf.org/arch/msg/ssh/WC6ZZ9yFiCrLH8PRbDuUyiccwNI/
> >
> > I asked for clarification:
> >
> >
> > https://mailarchive.ietf.org/arch/msg/ssh/2t2NAaeX8BUCc37KghTjitU7lKc/
> >
> > There was an even more puzzling AD reply---not answering any of the
> > clarification questions, and instead sounding like another effort to
> > limit publication of crypto RFCs:
> >
> >
> > https://mailarchive.ietf.org/arch/msg/ssh/j0TybNBJqCrviS2FdxwTwkdJO64/
> >
> > I asked for clarification of the reply:
> >
> >
> > https://mailarchive.ietf.org/arch/msg/ssh/zivwujXjdICXl5s48P1gX0LGHCY/
> >
> > At the end of the same message, I wrote the following:
> >
> > > Also, sorry to have to ask this, but aren't you obliged to recuse
> > > yourself from all decisions on reducing the level of IETF
> > > involvement in cryptographic standardization? When cryptographic
> > > standardization began, NSA adopted a secret policy of trying to
> > > reduce competition in this space so as to reduce security:
> > >
> > > > Narrowing the encryption problem to a single, influential
> > > > algorithm might drive out competitors, and that would reduce the
> > > > field that NSA had to be concerned about. Could a public
> > > > encryption standard be made secure enough to protect against
> > > > everything but a massive brute force attack, but weak enough to
> > > > still permit an attack of some nature using very sophisticated (and
> expensive) techniques?
> > >
> > > See pages 232-233 of https://archive.org/details/cold_war_iii-nsa,
> > > an internal NSA book that was partially declassified in 2013 as a
> > > result of journalists forcing declassification-review procedures.
> > > It's not as if there has been a statement revoking the above policy,
> > > nor would such a statement be credible given the long history of
> > > sabotage. It's hard to imagine how anything short of recusal would
> > > address the appearance of a conflict of interest here.
> >
> > There was then a ludicrous AD reply, saying that "Every IETF
> > participant is acting as individual and does not represent any current
> > or former employer" and wildly mischaracterizing the
> > conflict-of-interest question as a "personal attack against an individual":
> >
> >
> > https://mailarchive.ietf.org/arch/msg/ssh/o6VE5SAai2lqJLXzpdRxs1Zdruw/
> >
> > This reply is making a mockery of the IESG conflict-of-interest policy.
> > The policy recognizes and tries to protect against the possibility of
> > IETF interests being overridden by other interests, including the
> > interests of employers of area directors. It has to be possible to
> > have a conflict-of-interest question raised and addressed without
> > being mischaracterized as a personal attack.