[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Jay Daley <[e-mail]>]

Daniel

I’m writing in response to your request below.  I am told that your email server may require me to agree to terms before delivery, which I will not be doing, so it may be that this response is not delivered directly.

While I am an author of RFC 9680 it is an IETF consensus document and therefore represents the view of IETF community as a whole.  

If your concern is that the IETF processes contain an overlooked antitrust risk, then please note that it is the view of the IETF, as stated in RFC 9680, that "the IETF structure and processes are designed to mitigate antitrust risks" and that "compliance with BCPs and other relevant policies … facilitates compliance with antitrust law".  This is a view that has been thoroughly checked with multiple sets of counsel [1].  If you want to see a change to the IETF processes to address a perceived antitrust risk then you should follow the IETF process for making that happen. 

If, on the other hand, your concern is that there has been a failure of IETF processes that has created an antitrust risk, then the appropriate course of action is to follow the appropriate IETF process for addressing that. 

Given my role is only to support the IETF standards process, any more detailed explanation of any of that process, is best left to others.

[1]  https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/

Jay

> On 7 Dec 2024, at 15:19, D. J. Bernstein <[e-mail]> wrote:
> 
> I'm adding an RFC 9680 coauthor to the To line to request IETF LLC
> attention to the antitrust issues here.
> 
> Scott Fluhrer (sfluhrer) writes:
>> There are people whose cryptographic expertise I cannot doubt who say
>> that pure ML-KEM is the right trade-off for them
> 
> Please note that antitrust law forces standardization organizations to
> follow procedures that prevent anti-competitive activities. Here's an
> introduction to the topic from the American Bar Association:
> 
>    https://www.google.com/books/edition/Handbook_on_Antitrust_Aspects_of_Standar/zin5tgAACAAJ
> 
> Having a company influencing IETF decisions by making claims about what
> customers are demanding---with no explanation of _why_ those demands are
> being made, and no opportunity for IETF review of the merits of those
> rationales---is exposing IETF to antitrust litigation. Even if the
> specific incident at hand isn't meant to suppress competition, it shows
> that IETF doesn't have the requisite procedural protections in place, so
> it provides evidence helpful for _anyone_ who decides to sue IETF about
> _any_ standardization topic.
> 
> As a side note, the "could still be construed as representing their
> employer" part of RFC 9680 is certainly triggered by a message that's
> adding weight to its argument by explicitly invoking the company's name
> (in this case: "Cisco will implement it").
> 
>> I am essentially just asking for code points.
> 
> Hmmm. If the only request were for allocation from an open namespace
> (which apparently has been done already), then why make claims about the
> supposed desirability of omitting normal hybrid defenses? I also don't
> see how the collective-action text ("I understand that people want to
> discuss the hybrid KEM draft more (because there are more options there)
> - can we at least get the less controversial part done?") can be
> interpreted as merely an administrative allocation request. One followup
> said "Can we start an adoption call?" and another said "+1".
> 
> Furthermore, email dated 24 Oct 2024 03:15:38 +0000, in the analogous
> context of ML-DSA, said that "Cisco" has "some customers who want ML-DSA
> only", and concluded that "we'll end up standardizing" that.
> 
> The ML-DSA discussion sounded like some people think that NSA refuses to
> authorize U.S. government purchasing of hybrids (outside some special
> circumstances). I asked whether that's true---whether NSA has in fact
> banned hybrids. I quoted an official NSA statement saying "hybrid
> solutions may be allowed or required due to protocol standards, product
> availability, or interoperability requirements"; I said this "will be
> triggered if, e.g., the TLS WG issues an RFC requiring all PQ in TLS to
> be hybrid"; I haven't seen a counterargument.
> 
> Now the WG is again being told, again without a rationale, that some
> unspecified cryptographic experts with money are demanding non-hybrids.
> Even if it's true that NSA is banning hybrids (is it?), I'm opposed to
> non-hybrids on security grounds and on BCP 188 grounds. But the more
> basic point is that IETF's decisions on the topic have to comply with
> IETF's procedural obligations under antitrust law.
> 
> ---D. J. Bernstein

-- 
Jay Daley
IETF Executive Director
[e-mail]