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

[Stephen Farrell <[e-mail]>]

Hiya,

On 9/6/24 16:35, D. J. Bernstein wrote:
> Various people, including me, have expressed unanswered concerns on
> [e-mail] regarding the proposed WG.

IMO your questions about the charter were fully answered. Perhaps you
don't like the answers, but that does not mean you weren't answered.

> 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.

I think that's just nonsense. ADs do not have the kind of influence over
WGs that you seem to assume above (as I said before) so whether or not
an AD has a conflict of interest as asserted is just not a reason to not
form a WG.

If you feel an AD has a conflict then the right course of action would
be to discuss that with the IESG and/or on [e-mail] and not to
suggest we stop work on SSH in the IETF.

And FWIW, while I have significant problems with Deb's (former?) sponsor
having influence over the output of the IETF, I have to say that I think
Deb herself has acted fully correctly in all the discussion around this
WG.

> The traditional goal of publicly coordinating protocol development would
> be better served by an ssh-protocol mailing list independent of IETF.

You are wrong IMO. We've had a history of friction whenever SSH work has
been attempted in the last decade or two. Fixing that would better serve
the community, compared to your suggested misdirected protest.

> 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. 

Again, your questions about the charter were answered IMO. (If you want
to dispute that I'd suggest we start off-list - regurgitating supposed
non-discussion on the list is likely counterproductive - if we find
something relevant that wasn't answered we can bring that to the list.)

> 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.

Yes, if you have a complaint, the IESG and the broader IETF community
is where to process that. Suggesting we basically stop all new work in
the security area in the meantime is really a bit silly but is what
you seem to be proposing.

Cheers,
S.

> 
> ---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.
> 
> 
> _______________________________________________
> Ssh mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]