[Ssh] Re: WG Review: Secure Shell Maintenance (sshm)

["D. J. Bernstein" <[e-mail]>]

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-sharing-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-with-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-cryptography-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.