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

[Blumenthal, Uri - 0553 - MITLL]

D. J. Bernstein wrote: 
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure. 

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy. 

This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU 
 
IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between 
time-marks 30:00 – 34:00. 

Update: there was a question from the audience about Dual EC_DRBG around 
time-mark 58:00. The answer was also interesting . 











smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

John Mattsson writes:
> We would not be prepared for PQC if it was not for the NSA.

Um, what?

The PQCrypto conferences started in 2006. The PQCRYPTO grant application
was filed in 2014---that's the project that produced the specifications
and software for Classic McEliece, Dilithium, FrodoKEM, Kyber, NewHope,
NTRU-HRSS, NTRU Prime, SABER, SPHINCS+, and more, with help from various
collaborators but definitely not from NSA. Integration plans were well
underway before NSA's first post-quantum appearance, which was


https://web.archive.org/web/20150815072948/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

in 2015 saying that NSA "recognizes that there will be a move, in the
not distant future, to a quantum resistant algorithm suite".

Notice the passive "recognizes" wording. NSA then changed this in


https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

to saying that NSA "will initiate a transition to quantum resistant
algorithms in the not too distant future". This "initiate" language
deceived many people, but looking at the original language (first link
above) shows NSA admitting that this transition was going to happen
anyway. The summary of this at the end of the year from

https://pqcrypto.eu.org/slides/32c3.pdf

was "NSA comes late to the party and botches its grand entrance".

Google's big experiment with NewHope, starting in July 2016, worked well
and didn't rely on NSA's nonexistent contributions. This was supposed to
ramp up: Google said it was excited to begin preparing for quantum
computers "to help ensure our users' data will remain secure long into
the future", and said it would hopefully replace NewHope with something
better within two years. It's important to realize why this failed: Ding
stood up at a conference saying he had a patent, and he wrote to Google
asking for money. See https://blog.cr.yp.to/20220129-plagiarism.html for
further information about what happened.

NTRU Prime already had a paper submitted in March 2016 with sizes easily
competitive with NewHope, plus initial software speeds that were fast
enough to be fine for typical applications. The NTRU patent was due to
expire in 2017. In short, we were already taking multiple paths to
deployment. This is something else that didn't rely on NSA's nonexistent
contributions. OpenSSH added NTRU Prime options in April 2019, matching
earlier work from TinySSH, and eventually made NTRU Prime the default.
Google deployed NTRU-HRSS.

So how exactly did NSA supposedly contribute to PQC?

Sure, it's now easy to find companies citing NSA's announcements as a
rationale to do some unspecified thing. When I pick random examples and
look at what those companies are actually doing, what I see is the
companies delaying deployment. Here's how I summarized this in a talk to
the Federal Reserve TechLab: "We'll form a committee to devise an action
plan to inventory current usage of cryptography to support future
assessment of the steps needed to build a best-practices playbook for
meeting the performance challenges of upgrading to post-quantum
cryptography, with a target date after I retire."

In May 2022, the White House---


https://www.whitehouse.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/

---ordered NIST, within 90 days of issuing a PQ standard, to "release a
proposed timeline for the deprecation of quantum-vulnerable cryptography
in standards, with the goal of moving the maximum number of systems off
quantum-vulnerable cryptography within a decade of the publication of
the initial set of standards". NIST took until 2024 to get a standard
issued, and then, 90 days later, issued a timeline basically saying that
everyone is free to delay the upgrade until 2035. Somehow I don't think
it's a coincidence that this matches NSA's announced 2035 date.

This matters for TLS WG planning because there's a clear risk of quantum
attacks being carried out before 2035. I have ten years of public bets,
at even odds, of a public RSA-2048 break by 2032; public technology
development continues to be on track for that, with the last few years
nicely visualized in graphs such as

https://sam-jaques.appspot.com/quantum_landscape_2023

from Sam Jaques. Also, my median estimate (obviously with many
uncertainties) is that attackers are 3 years ahead of the public. We
should not be fooled by the unjustified 2035 date, and we should not be
assigning any authority to NSA regarding this matter.

> D. J. Bernstein wrote:
> > More recently, NSA's Dickie George is on video claiming that NSA
> > generated the Dual EC points randomly and that Dual EC is secure.
> Do you have a link to the video?

Yes, https://blog.cr.yp.to/20220805-nsa.html (search for "Dickie")
includes full quotes, a note of the two ranges of times where the video
disc

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

[John Mattsson]

Blumenthal, Uri wrote:
>This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU
>IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between 
>time-marks 30:00 – 34:00.
Very interesting indeed... That Dual EC_DRBG was used in classified systems 
before being standardized could make sense. Government systems often has 
intercept as a feature. But Dual EC_DRBG was still designed for intercept.

Blumenthal, Uri wrote:
>But I seem to recall that NIST and ANSI standards allowed verifiable random 
>point generation (from the publication you >cited), so there was no need to 
>use the NSA random points, unless you were building devices for NSA:
Yes, but nobody did use any other points except the hostile nation state that 
backdoored the backdoor and used it to attack critical infrastructure in the 
US. It is a fact that many SIGINT agencies globally are trying to weaken 
security to enable intercept. It is excellent that Dan is constantly putting 
light on this fact.

A sad effect of SIGINT weakening security is that it enables and encourages 
attacks from hostile nation states on critical infrastructure. The Dual EC_DRBG 
backdoor was quickly backdoored by a hostile nation state.
https://blog.cryptographyengineering.com/2015/12/22/on-juniper-backdoor/
The lack of PFS in AKA has led to massive attacks on SIM card vendors and 
mobile operator databases. The keys are then used to passively and at scale 
eavesdrop on phone calls. SIGINT has actively been fighting introduction of PFS 
in AKA.
https://theintercept.com/2015/02/19/great-sim-heist/
The lack of e2e security and acceptable security protocols for phone calls 
encourages attacks by hostile nation states on critical infrastructure. The 
latest, but not first or last, example is the Salt Typhoon attack on the US. 
SIGINT has actively been fighting e2e and good security for phone calls. I hope 
Salt Typhoon will be a wakeup call.
https://www.washingtonpost.com/national-security/2024/10/11/china-hack-telecoms-salt-typhoon/
But be warned that many companies are selling "privacy theater"
https://propertyofthepeople.org/document-detail/?doc-id=21114562
https://edition.cnn.com/2024/01/12/tech/china-apple-airdrop-user-encryption-vulnerability-hnk-intl/index.html
https://www.wired.com/story/google-floc-age-privacy-theater/

Blumenthal, Uri wrote:
>Concur 100%. IMHO, CNSA 2.0 is also pretty good – except that I’d rather see a 
>DSA with smaller signature and public key >sizes (e.g., like HAWK?). Well, 
>maybe CNSA 2.x would include that. (And I’m not crazy about LMS/XMSS, but 
>that’s me – I >hate stateful signatures 😉).
I intentionally left out CNSA 2.0 as it is not a recommendation significantly 
surpassing what was typical in deployments at the time they were introduced. 
Stateful signatures are hard to recommend, best practice is to hybridize 
structured lattices, SHA-3 is technically superior to SHA-2, and AES-256 does 
not provides state-of-the-art security.


From: Blumenthal, Uri - 0553 - MITLL 
Date: Sunday, 15 December 2024 at 05:44
To: John Mattsson , tls@ietf.org 

Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure.

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy.

This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU
IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between 
time-marks 30:00 – 34:00.

The last comment I saw was:

"With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm 
immediately after security researchers discovered the potential for a trapdoor. 
In truth, I can think of no better way to describe our failure to drop support 
for the Dual EC DRBG algorithm as anything other than regrettable."
https://www.ams.org/journals/notices/201502/rnoti-p165.pdf

I didn’t dive into the EC_DRBG scandal (had more interesting things to deal 
with). But I seem to recall that NIST and ANSI standards allowed verifiable 
random point generation (from the publication you cited), so there was no need 
to use the NSA random points, unless you were building devices for NSA:

During the development of the ANSI standard based on the NIST publication, 
members of X9F1 (the ANSI-approved working group responsible for cryptographic 
tools) raised concerns about the potential that elliptic curve points used as 
parameters for the Dual EC_DRBG could harbor a trapdoor secret known only to, 
and exploitable only by, the person who generated the points. As a result, the 
X9F1 committee expanded the standard to include verifiable random point 
generation. Since the NSA was using the algorithm at the time and had generated 
elliptic curve points for protecting Department of Defense us

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

[Loganaden Velvindron]

On Sat, 14 Dec 2024 at 12:00, Viktor Dukhovni  wrote:
>
> On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:
>
> > You continue to violate list policy with unprofessional commentary on other
> > participants' motivations and repeatedly raising points that are out of
> > scope.  Please stop this behavior.  This is the last warning before we will
> > take action and temporarily ban you from the list; see BCP 94 [0].
> >
> > [0] https://datatracker.ietf.org/doc/html/rfc3934
>
> I personally find this threat excessive under the circumstances, however
> forceful, or insistent on being heard, Dan may be at times, history has
> shown that he is often enough ultimately proved right, years or decades
> later.  However "inconvenient", IMHO his voice should not be suppressed.
>
> If his strong view is that pure PQ KEMs (probably not just
> ML-KEM/Kyber), are too novel to be responsibly relied on without a
> classical fallback, then he should IMHO able to forcefully make that
> case.
>
I also think that this escalated quickly. I would suggest a peaceful resolution
is found off-list around beer, good food and a nice and quiet beach :-)

Maybe TLS WG needs to do an interim meeting in Mauritius to solve
thorny issues  :-)

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Blumenthal, Uri - 0553 - MITLL]

D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure.

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy. 

This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU 
 
IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between 
time-marks 30:00 – 34:00. 

The last comment I saw was:

"With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm 
immediately after security researchers discovered the potential for a trapdoor. 
In truth, I can think of no better way to describe our failure to drop support 
for the Dual EC DRBG algorithm as anything other than regrettable."
https://www.ams.org/journals/notices/201502/rnoti-p165.pdf 
 

I didn’t dive into the EC_DRBG scandal (had more interesting things to deal 
with). But I seem to recall that NIST and ANSI standards allowed verifiable 
random point generation (from the publication you cited), so there was no need 
to use the NSA random points, unless you were building devices for NSA: 
During the development of the ANSI standard based on the NIST publication, 
members of X9F1 (the ANSI-approved working group responsible for cryptographic 
tools) raised concerns about the potential that elliptic curve points used as 
parameters for the Dual EC_DRBG could harbor a trapdoor secret known only to, 
and exploitable only by, the person who generated the points. As a result, the 
X9F1 committee expanded the standard to include verifiable random point 
generation. Since the NSA was using the algorithm at the time and had generated 
elliptic curve points for protecting Department of Defense users, the 
NSA-generated points were included in the standard. In other words, any 
implementation that used the NSA-generated points would be deemed compliant. 
Shortly thereafter, NIST negotiated with ANSI to use the ANSI Random Number 
Generation Standard as the basis for an NIST Random Number Generation Standard. 
ANSI also approved submitting a version of this standard to the ISO. 
I think it is good with increased participation from government agencies in the 
IETF. Suite B, CNSA 1.0, and ZTA are all very good recommendations from NSA, 
significantly surpassing what was typical in deployments at the time they were 
introduced. We would not be prepared for PQC if it was not for the NSA.
https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
 


Concur 100%. IMHO, CNSA 2.0 is also pretty good – except that I’d rather see a 
DSA with smaller signature and public key sizes (e.g., like HAWK?). Well, maybe 
CNSA 2.x would include that. (And I’m not crazy about LMS/XMSS, but that’s me – 
I hate stateful signatures 😉). 







smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

I would also be against a temporarily ban at this point, but hopefully the 
warning will help reduce unprofessional commentary and personal attacks in the 
future. Commentaries on other participants' motivations should not be forbidden 
in general, and I don't think they are according to any IETF policy.

- If someone wants to argue that participants paid by company X are defending 
the use of weak crypto for business reasons just because they have massive 
deployments of that weak cryptography, I think they should be allowed to.

- If someone wants to argue that professor Y is promoting his/hers/their 
algorithm for personal fame, I think they should be allowed to.

- If someone wants to argue that participants paid by SIGINT agency Z are 
intentionally weakening security, I think they should be allowed to.

One of my regrets from the Snowden discussions is not speaking up against the 
demands to remove Kevin Igoe as CFRG chair just because he represented NSA. 
While me and Kevin did not always get along, I did not see him doing anything 
in his role as CFRG chair that motivated the demands to remove him from the 
position. I think we should encourage that participants clearly show who they 
are representing. The idea that people are representing themselves in the IETF 
has nothing to do with reality and would never ever hold in court.

Instead of continuing this thread. Could we please just start adoption calls 
for both draft-connolly-tls-mlkem-key-agreement and 
draft-kwiatkowski-tls-ecdhe-mlkem. I cannot speak for other companies, but for 
Ericsson, migration to PQC is a top priority and we would very much want RFCs 
for quantum-resistant key exchange in TLS 1.3, DTLS 1.3, QUIC, EAP-TLS 1.3, 
DTLS-SRTP, etc. as soon as possible.

Cheers,
John

On 2024-12-14, 08:59, "Viktor Dukhovni"  wrote:
On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:

> You continue to violate list policy with unprofessional commentary on other
> participants' motivations and repeatedly raising points that are out of
> scope.  Please stop this behavior.  This is the last warning before we will
> take action and temporarily ban you from the list; see BCP 94 [0].
>
> [0] https://datatracker.ietf.org/doc/html/rfc3934

I personally find this threat excessive under the circumstances, however
forceful, or insistent on being heard, Dan may be at times, history has
shown that he is often enough ultimately proved right, years or decades
later.  However "inconvenient", IMHO his voice should not be suppressed.

If his strong view is that pure PQ KEMs (probably not just
ML-KEM/Kyber), are too novel to be responsibly relied on without a
classical fallback, then he should IMHO able to forcefully make that
case.

If there is nevertheless a demonstrable plurality of reputable
cryptographers on record as saying that *pure* PQ KEMs are (despite
initial implementation bugs) strong enough to move towards deployment,
then Dan's view may not prevail, but I do not find his posts to be
beyond the pale.

There were also (with IIRC Dan instrumental in bringing these to light)
some early side-channel issues in AES, that AFAIK still apply to some
reference pure software AES implementations, and when used securely, AES
is hardware assisted, or slower if counter-measures are implemented.

The AES issues were unfortunate, and ideally would have been identified
prior to standardisation, but proved "fixable".  If we're in luck
that'll also be true with Kyber, but arguments for some caution don't
come across as unfounded.

--
Viktor.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated 
> the Dual EC points randomly and that Dual EC is secure.

Do you have a link to the video? Such a comment is surprising as it is a very 
bad PR strategy. “No comment” is a far better strategy. The last comment I saw 
was:

"With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm 
immediately after security researchers discovered the potential for a trapdoor. 
In truth, I can think of no better way to describe our failure to drop support 
for the Dual EC DRBG algorithm as anything other than regrettable."
https://www.ams.org/journals/notices/201502/rnoti-p165.pdf

Analysing Dual_EC_DRBG objectively, a backdoor is the only rational requirement 
that could have led to its design. In addation to having a backdoor, it is a 
really bad DRBG being both slow and non-uniform. It is also a fact that 
Dual_EC_DRBG is not secure as the backdoor was backdoored, enabling serious 
attacks by a hostile nation state on US critical infrastructure.
https://web.archive.org/web/20151222092252/https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/


D. J. Bernstein wrote:
> Yes, NSA has deep cryptographic expertise. This does _not_ mean that we 
> should be trusting NSA's recommendations. An internal NSA history book (which 
> NSA successfully kept secret for many years) shows NSA deciding to manipulate 
> public standards to make sure they were "weak enough" for NSA to break. See 
> https://blog.cr.yp.to/20220805-nsa.html for quotes and further examples.

I don’t know why you (and the IETF) are so obsessed with NSA, there are very 
good reasons to take recommendations from SIGINT with a grain of salt and force 
them to provide thorough motivation, but there are _many_ SIGINT agencies 
globally. Snowden publicly said that GCHQ is “worse” than NSA, and I have heard 
a person with a background in SIGINT stating that French SIGINT is the “worst”. 
Then we have very active SIGINT from a lot of other countries such as China, 
Russia, Iran, and North Korea, etc. According to Research Nester and Mordor 
Intelligence, North America only has 32% of the global SIGINT market share and 
Asia Pacific is the fastest growing market.
https://www.researchnester.com/reports/signals-intelligence-market/5134/market-share
https://www.mordorintelligence.com/industry-reports/signals-intelligence-sigint-market

I think it is good with increased participation from government agencies in the 
IETF. Suite B, CNSA 1.0, and ZTA are all very good recommendations from NSA, 
significantly surpassing what was typical in deployments at the time they were 
introduced. We would not be prepared for PQC if it was not for the NSA.
https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Viktor Dukhovni]

On Fri, Dec 13, 2024 at 08:24:24PM -0800, Joseph Salowey wrote:

> You continue to violate list policy with unprofessional commentary on other
> participants' motivations and repeatedly raising points that are out of
> scope.  Please stop this behavior.  This is the last warning before we will
> take action and temporarily ban you from the list; see BCP 94 [0].
> 
> [0] https://datatracker.ietf.org/doc/html/rfc3934

I personally find this threat excessive under the circumstances, however
forceful, or insistent on being heard, Dan may be at times, history has
shown that he is often enough ultimately proved right, years or decades
later.  However "inconvenient", IMHO his voice should not be suppressed.

If his strong view is that pure PQ KEMs (probably not just
ML-KEM/Kyber), are too novel to be responsibly relied on without a
classical fallback, then he should IMHO able to forcefully make that
case.

If there is nevertheless a demonstrable plurality of reputable
cryptographers on record as saying that *pure* PQ KEMs are (despite
initial implementation bugs) strong enough to move towards deployment,
then Dan's view may not prevail, but I do not find his posts to be
beyond the pale.

There were also (with IIRC Dan instrumental in bringing these to light)
some early side-channel issues in AES, that AFAIK still apply to some
reference pure software AES implementations, and when used securely, AES
is hardware assisted, or slower if counter-measures are implemented.

The AES issues were unfortunate, and ideally would have been identified
prior to standardisation, but proved "fixable".  If we're in luck
that'll also be true with Kyber, but arguments for some caution don't
come across as unfounded.

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Joseph Salowey]

Hi Dan,

You continue to violate list policy with unprofessional commentary on other
participants' motivations and repeatedly raising points that are out of
scope.  Please stop this behavior.  This is the last warning before we will
take action and temporarily ban you from the list; see BCP 94 [0].

[0] https://datatracker.ietf.org/doc/html/rfc3934

Joe and Sean


On Fri, Dec 13, 2024 at 6:17 PM D. J. Bernstein  wrote:

> Adding antitrust-pol...@ietf.org; but I'm replying to a tls@ietf.org
> message, and the antitrust issues here are clearly relevant to an
> ongoing TLS discussion, so I'm also keeping tls@ietf.org.
>
> Rob Sayre writes:
> > I think you can find Brad Biddle saying "the process is fine" about all
> of
> > these legal issues on YouTube. But, he did have to take the time to
> address
> > the point, so I can see why it might come up again.
>
> He claimed in 2021 that "Our current antitrust compliance strategy is
> solid", but IETF LLC admitted in
>
>
> https://mailarchive.ietf.org/arch/msg/antitrust-policy/f1iHM9p8N-U8p_pXen2ruDqjPPQ/
>
> that other lawyers say he's simply wrong: "we received private feedback
> from other lawyers that, from the perspective of antitrust litigators,
> our current processes and procedures would not provide strong mitigation
> of antitrust risk and that could only be achieved with a detailed
> compliance policy".
>
> Notice the word "not". Or simply check the actual antitrust rules for
> standardization organizations in, e.g.,
>
>
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)
> https://obamawhitehouse.archives.gov/omb/circulars_a119
>
> (where https://uscode.house.gov/statutes/pl/108/237.pdf gives power to
> OMB A-119 under antitrust law) and see for yourself the rules that IETF
> _clearly_ flunks, such as "each objector is advised of the disposition
> of his or her objection(s) and the reasons why" and "the organisations
> would also need to have objective and non-discriminatory procedures for
> allocating voting rights as well as, if relevant, objective criteria for
> selecting the technology to be included in the standard".
>
> Why, then, do we have IETF LLC sounding convinced that everything is
> fine? This is partially explained in the first link above: in short, the
> corporation found yet another lawyer to review
>
> https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
>
> and to say that it sounded fine.
>
> Given the documented disagreement between lawyers on this topic, you'd
> think that the corporation (1) would refrain from portraying its
> position as something non-controversial and (2) would try hard to
> understand _why_ the lawyers are coming to different conclusions.
>
> Did the review consider the specific rules for standards-development
> organizations? Did it consider US law _and_ EU law? One can't tell from
> the information provided. But what one can see is that the last link
> above makes various claims that will be debunked in court. For example:
>
> * "Participants engage in their individual capacity, not as company
>   representatives." (Counterexample: See the Cisco incident in this
>   TLS discussion, condoned by IETF LLC and by the WG chairs.)
>
> * "IETF procedural rules, which include robust appeal options, are
>   well-documented in public materials, and rigorously followed."
>   (Counterexample: This Kyber/ML-KEM spec simply ignores BCP 79.)
>
> * "IETF activities are conducted with extreme transparency, in
>   public forums." (Many IETF activities are public, but the
>   back-room deals aren't. The reason such deals can influence IETF
>   decisions is that IETF doesn't follow objective procedures.)
>
> * "Decision-making requires achieving broad consensus via these
>   public processes." (No, not with the OMB A-119 definition of
>   consensus.)
>
> * "IETF participants use their best engineering judgment to find the
>   best solution for the whole Internet, not just the best solution
>   for any particular network, technology, vendor, or user." (In this
>   TLS discussion we've seen ~"do it because NSA wants it", ~"do it
>   because I want it", and non-response to engineering objections.)
>
> In other words, the lawyer who thought things were fine was reviewing a
> fictional version of IETF. A lawyer starting from the facts of how IETF
> actually operates would naturally end up with a different conclusion.
>
> ---D. J. Bernstein
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Adding antitrust-pol...@ietf.org; but I'm replying to a tls@ietf.org
message, and the antitrust issues here are clearly relevant to an
ongoing TLS discussion, so I'm also keeping tls@ietf.org.

Rob Sayre writes:
> I think you can find Brad Biddle saying "the process is fine" about all of
> these legal issues on YouTube. But, he did have to take the time to address
> the point, so I can see why it might come up again.

He claimed in 2021 that "Our current antitrust compliance strategy is
solid", but IETF LLC admitted in


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

that other lawyers say he's simply wrong: "we received private feedback
from other lawyers that, from the perspective of antitrust litigators,
our current processes and procedures would not provide strong mitigation
of antitrust risk and that could only be achieved with a detailed
compliance policy".

Notice the word "not". Or simply check the actual antitrust rules for
standardization organizations in, e.g.,


https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)
https://obamawhitehouse.archives.gov/omb/circulars_a119

(where https://uscode.house.gov/statutes/pl/108/237.pdf gives power to
OMB A-119 under antitrust law) and see for yourself the rules that IETF
_clearly_ flunks, such as "each objector is advised of the disposition
of his or her objection(s) and the reasons why" and "the organisations
would also need to have objective and non-discriminatory procedures for
allocating voting rights as well as, if relevant, objective criteria for
selecting the technology to be included in the standard".

Why, then, do we have IETF LLC sounding convinced that everything is
fine? This is partially explained in the first link above: in short, the
corporation found yet another lawyer to review

https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/

and to say that it sounded fine.

Given the documented disagreement between lawyers on this topic, you'd
think that the corporation (1) would refrain from portraying its
position as something non-controversial and (2) would try hard to
understand _why_ the lawyers are coming to different conclusions.

Did the review consider the specific rules for standards-development
organizations? Did it consider US law _and_ EU law? One can't tell from
the information provided. But what one can see is that the last link
above makes various claims that will be debunked in court. For example:

* "Participants engage in their individual capacity, not as company
  representatives." (Counterexample: See the Cisco incident in this
  TLS discussion, condoned by IETF LLC and by the WG chairs.)

* "IETF procedural rules, which include robust appeal options, are
  well-documented in public materials, and rigorously followed."
  (Counterexample: This Kyber/ML-KEM spec simply ignores BCP 79.)

* "IETF activities are conducted with extreme transparency, in
  public forums." (Many IETF activities are public, but the
  back-room deals aren't. The reason such deals can influence IETF
  decisions is that IETF doesn't follow objective procedures.)

* "Decision-making requires achieving broad consensus via these
  public processes." (No, not with the OMB A-119 definition of
  consensus.)

* "IETF participants use their best engineering judgment to find the
  best solution for the whole Internet, not just the best solution
  for any particular network, technology, vendor, or user." (In this
  TLS discussion we've seen ~"do it because NSA wants it", ~"do it
  because I want it", and non-response to engineering objections.)

In other words, the lawyer who thought things were fine was reviewing a
fictional version of IETF. A lawyer starting from the facts of how IETF
actually operates would naturally end up with a different conclusion.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Deirdre Connolly writes:
> I wrote it because I wanted to use it. Enough.

Don't proposals to IETF always claim that there will be users? This is
content-free, and not a valid argument for IETF endorsement.

Back in March, the first message announcing the draft similarly didn't
give a technological rationale for the draft. I promptly raised security
objections; those weren't answered.

There was, however, more information after Eric Rescorla asked what the
motivation was for the draft. Specifically, your answer claimed that
this is what NSA wants:

> In the more concrete scope, FIPS / CNSA 2.0 compliance guidelines
> 
> currently are a big 'maybe' at best for 'hybrid solutions', and the
> timetables for compliant browsers, servers, and services are to exclusively
> use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be
> demand for pure ML-KEM key agreement, not hybrid (with no questions that
> come along with it of whether it's actually allowed or not).

How does this NSA-dominated statement of the document's rationale match
the new statement "I wrote it because I wanted to use it"? I'm puzzled.

This rationale was preceded by a few lines objecting to hybrids "in the
long-term". That obviously isn't a rationale for a current draft.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Deirdre Connolly]

> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of
this spec.

No. I proposed this document because I want to be able to negotiate PQ-only
key establishment without hybrid. It got codepoints and now is getting more
support, which is nice. I wrote it because I wanted to use it. Enough.

On Fri, Dec 13, 2024 at 6:07 PM D. J. Bernstein  wrote:

> > > > Security is not easy to evaluate. Asking random users to make
> > > > security decisions is a recipe for disaster. Blaming users for the
> > > > resulting failures simply perpetuates the problem.
> > And you would have a point if this was a decision between a known broken
> > scheme and a known to be secure construction.
>
> The point is much broader than that extreme case. Beyond merely avoiding
> demonstrated attacks, the TLS WG has made many decisions designed to
> proactively reduce security risks. Random example: RFC 8446 says that
> the new TLS 1.3 KDF design "allows easier analysis by cryptographers".
>
> Looking at what has been broken is useful (see some examples below), but
> conflating not-publicly-demonstrated-to-be-broken with "secure" would be
> a dangerous regression from established WG practices.
>
> > As it stands, ML-KEM is a secure cryptographic scheme
>
> https://kyberslash.cr.yp.to demonstrated fast recovery of secret keys
> from the reference Kyber/ML-KEM software in various environments.
>
> After two rounds of patches for that, the reference Kyber/ML-KEM
> software was broken again by https://github.com/antoonpurnal/clangover
> in various environments, prompting further patches. That was in June.
>
> As far as I know, the reference Kyber/ML-KEM software maintainers never
> issued a security announcement telling users that the previous software
> was broken and that an upgrade is required. But the KyberSlash demo is
> online with full reproduction instructions. There's no actual dispute
> about the break.
>
> > certainly secure enough that a sophisticated user might want to choose
> > it over 0x11ec.
>
> Why does it make sense to take that security risk?
>
> The answer we keep hearing boils down to various claims that NSA is
> throwing a lot of money at this. Even if that's true---where exactly is
> the evidence? how do we reconcile this with NSA in
>
>
> https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>
> asking for two cryptographic layers "to mitigate the ability of an
> adversary to exploit a single cryptographic implementation"?---it's not
> a valid argument for IETF to endorse something. As I said before, it
> sounds crazy to let NSA buy IETF endorsement of specs that violate
> normal common-sense security practices.
>
> > With the United States government, there is at least one such, fairly
> large
> > user who would like to make that decision, and while you can say many
> > things about the NSA, lack of cryptographic expertise is not one of them.
>
> So we should standardize Dual EC for TLS, releasing full Dual EC output?
> Page 60 of
>
>
> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-90a.pdf
>
> repeats NSA's claim that Dual EC's unpredictability is "assured by the
> difficulty of finding a solution to ... the elliptic curve discrete
> logarithm problem". Pages 90--91 repeat NSA's claim that "certain
> guarantees can be made about the uniform distribution" of outputs from
> Dual EC if, and only if, one _doesn't_ truncate more output bits. More
> recently, NSA's Dickie George is on video claiming that NSA generated
> the Dual EC points randomly and that Dual EC is secure.
>
> Yes, NSA has deep cryptographic expertise. This does _not_ mean that we
> should be trusting NSA's recommendations. An internal NSA history book
> (which NSA successfully kept secret for many years) shows NSA deciding
> to manipulate public standards to make sure they were "weak enough" for
> NSA to break. See https://blog.cr.yp.to/20220805-nsa.html for quotes and
> further examples.
>
> > By recommending 0x11ec, the average user will be guided to make the
> > slightly more conservative choice, but I do not feel like it would be a
> > dereliction of my duty as a cryptographer to merely allow the use of pure
> > ML-KEM, a statement I would not make about RC4.
>
> To clarify: Are you claiming that lattice-based cryptography has held
> up better than RC4? If so, are you talking about marketing, or about
> security?
>
> > > BCP 188 says that "The IETF Will Work to Mitigate Pervasive
> > > Monitoring". This implies an obligation to proactively address
> > > security risks. Rubber-stamping specs, rather than evaluating
> > > security, is contrary to that; even worse, it's inviting attackers
> > > to once again manipulate the standardization process.
> > No rubberstamping is taking place. If we were rubberstamping things, we
> > wouldn't be having this discussion.
>
> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of
>

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

[D. J. Bernstein]

> > > Security is not easy to evaluate. Asking random users to make
> > > security decisions is a recipe for disaster. Blaming users for the
> > > resulting failures simply perpetuates the problem.
> And you would have a point if this was a decision between a known broken
> scheme and a known to be secure construction.

The point is much broader than that extreme case. Beyond merely avoiding
demonstrated attacks, the TLS WG has made many decisions designed to
proactively reduce security risks. Random example: RFC 8446 says that
the new TLS 1.3 KDF design "allows easier analysis by cryptographers".

Looking at what has been broken is useful (see some examples below), but
conflating not-publicly-demonstrated-to-be-broken with "secure" would be
a dangerous regression from established WG practices.

> As it stands, ML-KEM is a secure cryptographic scheme

https://kyberslash.cr.yp.to demonstrated fast recovery of secret keys
from the reference Kyber/ML-KEM software in various environments.

After two rounds of patches for that, the reference Kyber/ML-KEM
software was broken again by https://github.com/antoonpurnal/clangover
in various environments, prompting further patches. That was in June.

As far as I know, the reference Kyber/ML-KEM software maintainers never
issued a security announcement telling users that the previous software
was broken and that an upgrade is required. But the KyberSlash demo is
online with full reproduction instructions. There's no actual dispute
about the break.

> certainly secure enough that a sophisticated user might want to choose
> it over 0x11ec.

Why does it make sense to take that security risk?

The answer we keep hearing boils down to various claims that NSA is
throwing a lot of money at this. Even if that's true---where exactly is
the evidence? how do we reconcile this with NSA in


https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf

asking for two cryptographic layers "to mitigate the ability of an
adversary to exploit a single cryptographic implementation"?---it's not
a valid argument for IETF to endorse something. As I said before, it
sounds crazy to let NSA buy IETF endorsement of specs that violate
normal common-sense security practices.

> With the United States government, there is at least one such, fairly large
> user who would like to make that decision, and while you can say many
> things about the NSA, lack of cryptographic expertise is not one of them.

So we should standardize Dual EC for TLS, releasing full Dual EC output?
Page 60 of


https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-90a.pdf

repeats NSA's claim that Dual EC's unpredictability is "assured by the
difficulty of finding a solution to ... the elliptic curve discrete
logarithm problem". Pages 90--91 repeat NSA's claim that "certain
guarantees can be made about the uniform distribution" of outputs from
Dual EC if, and only if, one _doesn't_ truncate more output bits. More
recently, NSA's Dickie George is on video claiming that NSA generated
the Dual EC points randomly and that Dual EC is secure. 

Yes, NSA has deep cryptographic expertise. This does _not_ mean that we
should be trusting NSA's recommendations. An internal NSA history book
(which NSA successfully kept secret for many years) shows NSA deciding
to manipulate public standards to make sure they were "weak enough" for
NSA to break. See https://blog.cr.yp.to/20220805-nsa.html for quotes and
further examples.

> By recommending 0x11ec, the average user will be guided to make the
> slightly more conservative choice, but I do not feel like it would be a
> dereliction of my duty as a cryptographer to merely allow the use of pure
> ML-KEM, a statement I would not make about RC4.

To clarify: Are you claiming that lattice-based cryptography has held
up better than RC4? If so, are you talking about marketing, or about
security?

> > BCP 188 says that "The IETF Will Work to Mitigate Pervasive
> > Monitoring". This implies an obligation to proactively address
> > security risks. Rubber-stamping specs, rather than evaluating
> > security, is contrary to that; even worse, it's inviting attackers
> > to once again manipulate the standardization process.
> No rubberstamping is taking place. If we were rubberstamping things, we
> wouldn't be having this discussion.

The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of
this spec. As I wrote before: 'The draft author claimed at the outset
that hybrids were currently a "big 'maybe' at best" under "FIPS / CNSA
2.0 compliance guidelines" and would be prohibited by 2033. Scott's
message was simply explicit about the money flow ("more importantly for
my employer, that's what they're willing to buy. Hence, Cisco will
implement it"). There have been many similar claims about what NSA
supposedly requires.'

Obviously the people who have already spoken up to object, including me,
aren't su

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

[Rob Sayre]

On Fri, Dec 13, 2024 at 11:29 AM Sophie Schmieg  wrote:

> Answers inline. I will only bother to answer questions others might have
> as well, and ignore the rather laughable legal speculation.
>

I don't agree with Daniel, but let's not say words like "laughable". It's
just an insult.

I think you can find Brad Biddle saying "the process is fine" about all of
these legal issues on YouTube. But, he did have to take the time to address
the point, so I can see why it might come up again.


> With the United States government, there is at least one such, fairly
> large user who would like to make that decision, and while you can say many
> things about the NSA, lack of cryptographic expertise is not one of them.
>

True.



thanks,
Rob
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Sophie Schmieg]

Answers inline. I will only bother to answer questions others might have as
well, and ignore the rather laughable legal speculation.



> "I do not see a security concern with having the option for RC4 in TLS.
> TLS has ways of negotiating algorithms. If one side believes RC4 to be
> insufficiently secure, they can negotiate CBC."
>
> Here are three basic problems with the generic argument that IETF should
> delegate security decisions to users:
>
> * Security is not easy to evaluate. Asking random users to make
>   security decisions is a recipe for disaster. Blaming users for the
>   resulting failures simply perpetuates the problem.
>
>
And you would have a point if this was a decision between a known broken
scheme and a known to be secure construction.
As it stands, ML-KEM is a secure cryptographic scheme, certainly secure
enough that a sophisticated user might want to choose it over 0x11ec.
With the United States government, there is at least one such, fairly large
user who would like to make that decision, and while you can say many
things about the NSA, lack of cryptographic expertise is not one of them.
By recommending 0x11ec, the average user will be guided to make the
slightly more conservative choice, but I do not feel like it would be a
dereliction of my duty as a cryptographer to merely allow the use of pure
ML-KEM, a statement I would not make about RC4.

* BCP 188 says that "The IETF Will Work to Mitigate Pervasive
>   Monitoring". This implies an obligation to proactively address
>   security risks. Rubber-stamping specs, rather than evaluating
>   security, is contrary to that; even worse, it's inviting attackers
>   to once again manipulate the standardization process.
>

No rubberstamping is taking place. If we were rubberstamping things, we
wouldn't be having this discussion. This is also far from the first time
this topic has come up, and least from what I did see, the draft has been
discussed on its merits thoroughly, both on list and in meetups, and has
prevailed.
-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Sophie Schmieg writes:
> I do not see a security concern with having the option for pure ML-KEM in
> TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
> be insufficiently secure, they can negotiate 0x11EC (which equally should
> be adopted).

"I do not see a security concern with having the option for RC4 in TLS.
TLS has ways of negotiating algorithms. If one side believes RC4 to be
insufficiently secure, they can negotiate CBC."

Here are three basic problems with the generic argument that IETF should
delegate security decisions to users:

* Security is not easy to evaluate. Asking random users to make
  security decisions is a recipe for disaster. Blaming users for the
  resulting failures simply perpetuates the problem.

* BCP 188 says that "The IETF Will Work to Mitigate Pervasive
  Monitoring". This implies an obligation to proactively address
  security risks. Rubber-stamping specs, rather than evaluating
  security, is contrary to that; even worse, it's inviting attackers
  to once again manipulate the standardization process.

* IETF standards are subject to a legal obligation to follow
  "objective criteria for selecting the technology to be included in
  the standard". By itself, this doesn't contradict a "standardize
  everything and let the users decide" approach; but IETF certainly
  doesn't endorse _all_ proposed technology specs, so it needs to be
  able to point to the criteria that it uses to select _some_ specs.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Jay Daley]

Hi Daniel

> On 13 Dec 2024, at 13:49, D. J. Bernstein  wrote:
> 
> Jay Daley writes:
>> I took your note to me as invoking the escalation path that RFC 9680
>> provides information on and consulted with counsel and the response
>> is, as previously conveyed, that your concern should be addressed
>> through the standards process.
> 
> Thanks for your message. I have three clarification questions, on-list
> for transparency.
> 
> First, am I correctly understanding that IETF LLC is refusing to take
> corrective action regarding the Cisco incident that I pointed out?

As set out in BCP 101 (RFC 8711) the IETF LLC has "no authority over the 
standards development activities of the IETF" and explicitly has no role in the 
part of the standards process around conflict resolution "no changes are made 
to the appeals chain".  As this is clearly an issue of the IETF standards 
process, there is no concept of IETF LLC "corrective action".

> Second, is IETF LLC going to provide transparency regarding its
> rationale for this? 

This question appears to be based on the misconception that the IETF LLC could 
take "corrective action" and if it chooses not to then it should explain why 
not.  As explained above, we can’t do something we can’t do.

> The comments I've seen from IETF LLC aren't saying
> anything explicitly about the incident.

It would be inappropriate for the IETF LLC to make an explicit statement about 
the comment made to this list that you are concerned about,  as that would 
violate the limitations above regarding the role of the IETF LLC.

> Third, is there a mechanism to appeal this decision to IETF LLC?

Yes, you can appeal any action I take (including this non-action ) to the IETF 
LLC Board.  I suggest sending any appeal to llc-bo...@ietf.org which reaches 
the LLC Board only (I am not a board member).  For full disclosure, please note 
that one of the chairs of this WG is an IETF LLC board member 
(https://www.ietf.org/administration/llc-board/ for further details).

> A
> generic reference to "the standards process" doesn't distinguish actions
> by IETF LLC from actions by other parties; the reason I sent email to
> you in the first place was to request IETF LLC action.

I understand why you may have thought that the IETF LLC could be asked to 
intervene as many other SDOs operate under a different model where the legal 
entity has that level of authority.  The IETF however is quite different as the 
authority over the standards process is delegated by the IETF community to the 
IESG and the IETF LLC sits outside of that. That is why the standards process 
appeal chain (as pointed to by the WG chairs in their recent message) is to the 
IESG and not the IETF LLC.

Jay

-- 
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Sean Turner writes:
> Scott is not an author of this draft

The draft author claimed at the outset that hybrids were currently a
"big 'maybe' at best" under "FIPS / CNSA 2.0 compliance guidelines" and
would be prohibited by 2033. Scott's message was simply explicit about
the money flow ("more importantly for my employer, that's what they're
willing to buy. Hence, Cisco will implement it").

There have been many similar claims about what NSA supposedly requires.
I think the overall discussion can reasonably be summarized as follows:

* Pro-hybrid: Non-hybrid PQ is frivolously incurring security risks.
* Anti-hybrid: NSA is throwing a lot of money at non-hybrid PQ.

Should we be letting NSA buy IETF endorsement of specs that violate
normal common-sense security practices? This sounds crazy to me: it's
contrary to BCP 188, and contrary to any notion that IETF is making
decisions based on objective technology evaluation. But it seems that
the WG chairs are allowing the do-what-NSA-wants position.

What I find really amazing here is that we don't have evidence showing
that NSA is in fact insisting on non-hybrids. It seems that _rumors_ of
money are good enough to drive IETF action.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Jay Daley writes:
> I took your note to me as invoking the escalation path that RFC 9680
> provides information on and consulted with counsel and the response
> is, as previously conveyed, that your concern should be addressed
> through the standards process.

Thanks for your message. I have three clarification questions, on-list
for transparency.

First, am I correctly understanding that IETF LLC is refusing to take
corrective action regarding the Cisco incident that I pointed out?

Second, is IETF LLC going to provide transparency regarding its
rationale for this? The comments I've seen from IETF LLC aren't saying
anything explicitly about the incident.

Third, is there a mechanism to appeal this decision to IETF LLC? A
generic reference to "the standards process" doesn't distinguish actions
by IETF LLC from actions by other parties; the reason I sent email to
you in the first place was to request IETF LLC action.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Dan Harkins]

  +1 for adoption

  Dan.

On 12/12/24 2:06 PM, Filippo Valsorda wrote:

2024-12-07 18:36 GMT+01:00 Watson Ladd :
Having MLKEM without a hybrid as an option in TLS when the 
interoperable choice is a hybrid is not going to exclude people.


Furthermore we didn't hybridize x25519 and RSA. It's clear some 
people believe ML-KEM is secure enough for their uses.


Agreed on both counts, +1 to adoption.

___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Sophie Schmieg]

+1 for adoption, and not commenting on the silliness of the counterargument
brought up here, because it is silly.

I do not see a security concern with having the option for pure ML-KEM in
TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
be insufficiently secure, they can negotiate 0x11EC (which equally should
be adopted).

On Thu, Dec 12, 2024 at 2:11 PM Filippo Valsorda 
wrote:

> 2024-12-07 03:19 GMT+01:00 D. J. Bernstein :
>
> 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.
>
>
> hahahahahahahahahahahaha
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Filippo Valsorda]

2024-12-07 03:19 GMT+01:00 D. J. Bernstein :
> 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.

hahahahahahahahahahahaha
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Sean Turner]

Hi Daniel,

Joe and I have reviewed the thread and believe that while Scott’s email is in a 
grey area with respect to Section 6.1 of RFC 9680 (an informational RFC that 
provides “Antitrust Guidelines for IETF Participants”), we do not believe that 
email should impact this draft being discussed on the TLS list. This draft has 
been around for about nine months and the idea of doing “pure” PQ cipher suites 
for ML-KEM and ML-DSA has been around for at least a year longer than this 
thread. As Scott is not an author of this draft, we do think it is not helpful 
to the rest of the community who do want these cipher suites specified to 
stifle discussions.

We should note that draft-connolly-tls-mlkem-key-agreement is not a WG draft at 
this point, so if you would like to appeal the decision to allow discussions 
about draft-connolly-tls-mlkem-key-agreement on the TLS list you can do so via 
the process outlined in s6.5 of RFC 2026.

If you have thoughts about how RFC 9680 might be improved or IETF processes 
improved to address antitrust risks please send those comments to 
antitrust-pol...@ietf.org. Discussions about the contents of RFC 9860 are not 
relevant to this mailing list and are considered off-topic; see our monthly 
reminder email [1].

Joe & Sean

[1] https://mailarchive.ietf.org/arch/msg/tls/9W7sx80XWO_RjAVBIFuaAUyAvns/

> On Dec 12, 2024, at 15:43, Jay Daley  wrote:
> 
> Hi Daniel
> 
>> On 13 Dec 2024, at 06:28, D. J. Bernstein  wrote:
>> 
>> RFC 9680 coauthor writes:
>>> 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.
>> 
>> RFC 9680 says that it's "generally inappropriate" to discuss "market
>> opportunities for specific companies". What's the IETF process for
>> addressing violations of RFC 9680?
> 
> RFC 9680 is not a policy but an informational document, including information 
> on an escalation path for antitrust concerns, and so there is no concept of 
> “violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
> for the topics to avoid because there is a vast grey area here.  The decision 
> on whether or not any specific action is inappropriate rests with the IETF 
> community through its structure and processes.  
> 
> The role of IETF Counsel is to provide advice to IETF leadership to support 
> their formal decision making role as set out in these processes, but neither 
> they nor I have any powers beyond that.  I took your note to me as invoking 
> the escalation path that RFC 9680 provides information on and consulted with 
> counsel and the response is, as previously conveyed, that your concern should 
> be addressed through the standards process.
> 
> I believe you will be getting an email in due course from the WG chairs that 
> explains that further and addresses the rest of your points.
> 
> Jay
> 
> -- 
> Jay Daley
> IETF Executive Director
> exec-direc...@ietf.org
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Filippo Valsorda]

2024-12-07 18:36 GMT+01:00 Watson Ladd :
> Having MLKEM without a hybrid as an option in TLS when the interoperable 
> choice is a hybrid is not going to exclude people.
> 
> Furthermore we didn't hybridize x25519 and RSA. It's clear some people 
> believe ML-KEM is secure enough for their uses.

Agreed on both counts, +1 to adoption.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Jay Daley]

> On 13 Dec 2024, at 09:43, Jay Daley  wrote:
> 
> Hi Daniel
> 
>> On 13 Dec 2024, at 06:28, D. J. Bernstein  wrote:
>> 
>> RFC 9680 coauthor writes:
>>> 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.
>> 
>> RFC 9680 says that it's "generally inappropriate" to discuss "market
>> opportunities for specific companies". What's the IETF process for
>> addressing violations of RFC 9680?
> 
> RFC 9680 is not a policy but an informational document, including information 
> on an escalation path for antitrust concerns, and so there is no concept of 
> “violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
> for the topics to avoid because there is a vast grey area here.  The decision 
> on whether or not any specific action is inappropriate rests with the IETF 
> community through its structure and processes.  
> 
> The role of IETF Counsel is to provide advice to IETF leadership to support 
> their formal decision making role as set out in these processes, but neither 
> they nor I have any powers beyond that.  I took your note to me as invoking 
> the escalation path that RFC 9680 provides information on and consulted with 
> counsel and the response is, as previously conveyed, that your concern should 
> be addressed through the standards process.

For the avoidance of doubt - by "note to me" I meant copying me in and 
specifically addressing me in your message to the WG list, not something 
offlist.

Jay


-- 
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Jay Daley]

Hi Daniel

> On 13 Dec 2024, at 06:28, D. J. Bernstein  wrote:
> 
> RFC 9680 coauthor writes:
>> 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.
> 
> RFC 9680 says that it's "generally inappropriate" to discuss "market
> opportunities for specific companies". What's the IETF process for
> addressing violations of RFC 9680?

RFC 9680 is not a policy but an informational document, including information 
on an escalation path for antitrust concerns, and so there is no concept of 
“violations of RFC 9680”.  RFC 9680 carefully says “generally inappropriate” 
for the topics to avoid because there is a vast grey area here.  The decision 
on whether or not any specific action is inappropriate rests with the IETF 
community through its structure and processes.  

The role of IETF Counsel is to provide advice to IETF leadership to support 
their formal decision making role as set out in these processes, but neither 
they nor I have any powers beyond that.  I took your note to me as invoking the 
escalation path that RFC 9680 provides information on and consulted with 
counsel and the response is, as previously conveyed, that your concern should 
be addressed through the standards process.

I believe you will be getting an email in due course from the WG chairs that 
explains that further and addresses the rest of your points.

Jay

-- 
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

RFC 9680 coauthor writes:
> 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.

RFC 9680 says that it's "generally inappropriate" to discuss "market
opportunities for specific companies". What's the IETF process for
addressing violations of RFC 9680?

As part of messages to tls@ietf.org advocating IETF action, a Cisco
employee claimed market opportunities for Cisco: "There are people whose
cryptographic expertise I cannot doubt who say that pure ML-KEM is the
right trade-off for them, and more importantly for my employer, that’s
what they're willing to buy." The message was from a Cisco address and
also went out of its way to specifically name Cisco in the text.

I find it perfectly clear how antitrust litigation can address this. I
don't find it clear that there are effective IETF procedures to address
this. I sent email requesting IETF LLC attention to this Cisco incident;
the response didn't acknowledge the incident and didn't suggest specific
followup procedures beyond this vague "appropriate IETF process" note.
Hence my question above.

> If your concern is that the IETF processes contain an overlooked
> antitrust risk

That's certainly an issue too. One of my messages quoted, e.g.,


https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)

asking whether there are "objective criteria for selecting the
technology to be included in the standard". My message continued by
asking where IETF's objective criteria are for deciding what to select,
and where the documentation is that demonstrates systematic enforcement
of those criteria.

RFC 9680 quotes BCP 9 text claiming that BCP 9 is designed to "provide a
fair, open, and objective basis for developing, evaluating, and adopting
Internet Standards". However, BCP 9 later contradicts this: first it
waters the claim down to just "reasonably" objective, and then it admits
that "there is no algorithmic guarantee". Furthermore, anyone trying to
find a statement of criteria in BCP 9 finds

* broad non-objective criteria (e.g., "considered to be useful"),
* no explanation of how different criteria are weighted, and
* open-ended flexibility for the decision-makers (e.g., "IESG may").

The specific situation at hand illustrates the problem. How does anyone
figure out whether Cisco's claim of market opportunities is relevant to
the BCP 9 criteria? This isn't an isolated incident---we've seen such
claims being raised again and again as arguments to override BCP 188
concerns, other security concerns, and other technical concerns.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Santosh Chokhani]

FWIW and probably not relevant, DoD CAC has never used DSA.

FORTEZZA used DSA.

-Original Message-
From: Alicja Kario [mailto:hka...@redhat.com] 
Sent: Monday, December 9, 2024 2:23 PM
To: D. J. Bernstein 
Cc: tls@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement

On Saturday, 7 December 2024 23:32:03 CET, D. J. Bernstein wrote:
> Watson Ladd writes:
>> Having MLKEM without a hybrid as an option in TLS when the 
>> interoperable choice is a hybrid
>
> Some previous messages claim that there's a split between customers 
> demanding hybrids and customers demanding non-hybrids so "we'll end up 
> standardizing both". If the claim is true (I'm skeptical about the 
> non-hybrid part) and IETF acts on it (which is what I'm objecting to), 
> then how exactly does a hybrid end up as "the interoperable choice"?

same way that when DOD CAC was using DSA, long after no commercial CA was using 
DSA, the public Internet servers that would accept those CAC's were perfectly 
happy using RSA server keys so that regular browsers were able to connect to 
them, even without use of a CAC

If no browser will implement pure ML-KEM (and it very much looks so), then they 
will have to provide support for secp256r1MLKEM768 group to allow connections 
from regular browsers: hybrids will be the interoperable choice
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Jay Daley]

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  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 +, 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
exec-direc...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Salz, Rich]

As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen 
(barring Q-day happening and the current hybrid key exchanges no longer making 
sense).

Since the draft has “N” for the recommended column, I’m also pretty sanguine 
about it.

As for people implementing it instead of hybrid, well, the working group can 
help to prevent that by moving ahead with the hybrid draft (hint, hint).

Which one?  Yours or Panos et al? :)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Deirdre Connolly]

Pursuant to this thread, preliminary support for MLKEM768-only has been
merged into rustls (I contributed):

https://github.com/rustls/rustls/pull/2259

On Thu, Dec 5, 2024 at 4:10 PM Scott Fluhrer (sfluhrer)  wrote:

> How do we proceed with this draft?
>
>
>
> This draft is quite boring (which is good from a cryptographical
> perspective); it just says ‘take ML-KEM and insert it as a key agreement
> into TLS in the obvious way’.
>
>
>
> 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?
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Alicja Kario]

On Saturday, 7 December 2024 23:32:03 CET, D. J. Bernstein wrote:

Watson Ladd writes:

Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid


Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hybrids so "we'll end up
standardizing both". If the claim is true (I'm skeptical about the
non-hybrid part) and IETF acts on it (which is what I'm objecting to),
then how exactly does a hybrid end up as "the interoperable choice"?


same way that when DOD CAC was using DSA, long after no commercial CA was
using DSA, the public Internet servers that would accept those CAC's were
perfectly happy using RSA server keys so that regular browsers were
able to connect to them, even without use of a CAC

If no browser will implement pure ML-KEM (and it very much looks so), then
they will have to provide support for secp256r1MLKEM768 group to allow
connections from regular browsers: hybrids will be the interoperable choice
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Alicja Kario]

+1 for adoption

While I'm stronly against wide deployment of pure ML-KEM at this moment in
time, I'm very much in favour of adoption of this document, having
stable definitions for such codepoints, even if they will get doployed only
in closed networks is still useful.

On Thursday, 5 December 2024 22:08:45 CET, Scott Fluhrer (sfluhrer) wrote:

How do we proceed with this draft?
 
This draft is quite boring (which is good from a 
cryptographical perspective); it just says ‘take ML-KEM and 
insert it as a key agreement into TLS in the obvious way’.
 
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?


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Watson Ladd writes:
> Having MLKEM without a hybrid as an option in TLS when the interoperable
> choice is a hybrid

Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hybrids so "we'll end up
standardizing both". If the claim is true (I'm skeptical about the
non-hybrid part) and IETF acts on it (which is what I'm objecting to),
then how exactly does a hybrid end up as "the interoperable choice"?

Procedurally, IETF should bar this claim on antitrust grounds, and make
the decision on technology grounds. Security is job #1 (see BCP 188, for
example, and the name of the WG); non-hybrids are a security threat (see
SIKE, for example, or KyberSlash); counterarguments such as cost don't
hold up to examination (see https://blog.cr.yp.to/20240102-hybrid.html);
a technology-based decision will end up prohibiting non-hybrids. This
does make it possible to aim for a hybrid as "the interoperable choice",
but also means that, given the security risks, non-hybrids won't be
allowed even as an option. As an analogy, see RFC 7465.

> is not going to exclude people.

There's an internal NSA history book that's perfectly clear about NSA's
anti-competitive goals for low-security standards: "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."

NSA isn't bound by antitrust law, but IETF is. The law doesn't wait for
anti-competitive effects to be demonstrated: it proactively imposes
various pro-competitive procedural constraints, including specific
constraints on standards-development organizations, such as transparency
requirements that obviously aren't being followed here.

> Furthermore we didn't hybridize x25519 and RSA.

Did IETF receive any RSA+X25519 drafts? Citation needed.

> It's clear some people believe ML-KEM is secure enough for their uses.

Back in 2013 and 2014, there were claims on this mailing list and on the
UTA mailing list about RC4 (1) not being so bad for security (e.g., "For
TLS 1.0, a case can be made that RC4 is the best choice, or the
least-worst") and (2) being important to keep for compatibility with the
WG's previous standards. The WG went ahead and banned RC4 anyway.

> There also is no protocol police: code points for this will exist
> regardless of what the IETF does with the draft.

I've quoted specific proposals for WG adoption of non-hybrid drafts. If
those proposals are being withdrawn, great.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrei Popov]

  *   We don’t see any need for SecP256r1MLKEM768 at all, I think that should 
stay RECOMMENDED=N.
What would be the reason for dis-recommending SecP256r1MLKEM768?

A large number of Microsoft’s online properties are subject to regulatory 
regimes that prevent the use of X25519; these will need P256+MLKEM and 
P384+MLKEM.

Cheers,

Andrei

From: John Mattsson 
Sent: Friday, December 6, 2024 11:17 PM
To: Andrey Jivsov ; TLS@ietf.org
Subject: [EXTERNAL] [TLS] Re: draft-connolly-tls-mlkem-key-agreement

For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and 
make that the default choice. We would like X25519MLKEM768 published as an RFC, 
be RECOMMENDED=Y, and MTI asap. This is already the de facto standard. All 
standalone ECC (secp256r1, secp384r1, x25519, x448) should soon be made 
RECOMMENDED=N and secp256r1 and x25519 should soon be removed from MTI.
We want standalone MLKEM1024 for customers wanting compliance with CNSA 2.0. We 
are fine with RECOMMENDED=N, but we would like it published as an RFC.

We don’t see any need for SecP256r1MLKEM768 at all, I think that should stay 
RECOMMENDED=N.

In the future we would like to see one or more backup algorithms (BIKE, Classic 
McEliece, FrodoKEM, HQC, etc…) to MLKEM standardized and some of them 
hybridized with X25519 be made RECOMMENDED=Y.

Cheers,
Another

From: Andrey Jivsov mailto:cry...@brainhub.org>>
Date: Friday, 6 December 2024 at 21:45
To: TLS@ietf.org<mailto:TLS@ietf.org> mailto:tls@ietf.org>>
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I second D.J. Bernstein's concerns, but my other issue with giving options like 
this is that they will creep up into MTI sets or default sets, with higher 
priority than hybrids.

I find it less ideal that the document on pure ML-KEM (or signature) and 
hybrids are disassociated, causing the progress of standardization of the pure 
version to bring these other concerns.

So, as long as everyone is on the same page that pure is just one option, 
perhaps for strict compliance with CNSA 2.0, then there is no issue from my 
perspective, but that's a (mildly) controversial part.

On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Scott Fluhrer (sfluhrer) writes:
> 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?

See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur security risks without improving deployment.
Regarding "less controversial", you might have missed previous TLS WG
messages such as

https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/

where various people (including me, obviously) already objected. Also,
you might have missed BSI writing in


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile

that its post-quantum KEM recommendations are only "in combination with
a classical key derivation mechanism"; commentator Matt Green writing in

https://x.com/matthew_d_green/status/1742521204026622011

that NSA's "stance against hybrid encryption makes absolutely zero
sense"; and NSA itself in


https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf

asking for two cryptographic layers "to mitigate the ability of an
adversary to exploit a single cryptographic implementation".

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Watson Ladd]

Having MLKEM without a hybrid as an option in TLS when the interoperable
choice is a hybrid is not going to exclude people.

Furthermore we didn't hybridize x25519 and RSA. It's clear some people
believe ML-KEM is secure enough for their uses.

There also is no protocol police: code points for this will exist
regardless of what the IETF does with the draft.

Sincerely,
Watson

On Sat, Dec 7, 2024, 9:26 AM D. J. Bernstein  wrote:

> Salz, Rich writes:
> > The IETF has lawyers who are familiar with how the IETF works, and
> > that legal counsel finds our processes acceptable level of risk.
>
> RFC 9680 was issued in October 2024 and says that it's "intended to
> educate IETF participants about how to reduce antitrust risks in
> connection with IETF activities". Sounds like the lawyers are worried.
> More to the point, they _should_ be worried.
>
> > The IETF has long accepted that saying "we have customers who want
> > this" as a metric into its decisions. If Foo.Com says they have
> > customers for RFC X, then the IETF community believes it is more
> > likely that Foo.Com will implement RFC X. Market acceptance is
> > important to what the IETF considers success.
>
> The whole point of antitrust law is to put constraints on _how_ market
> success can be pursued, so praising market success is missing the point.
> Take any corporation (whether for-profit or not) that lost an antitrust
> case, and look at its briefs; you'll see that it argued, unsuccessfully,
> that what it was doing was healthy market activity.
>
> As one of many examples of the constraints that antitrust law places on
> standards-development organizations, look at
>
>
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)
>
> asking, inter alia, whether "the procedure for adopting the standard in
> question is transparent". Saying that IETF is pursuing market success
> does nothing to answer this transparency question, or any of the other
> procedural questions asked by antitrust law.
>
> The same link also asks whether there are "objective criteria for
> selecting the technology to be included in the standard". Where are
> IETF's objective criteria for deciding what to select? Where's the
> documentation demonstrating systematic enforcement of those criteria?
>
> As illustrated by this discussion, IETF allows a company to push for a
> standard by simply claiming, without evidence or quantification or a
> technological rationale, that there are customers for the standard.
> History shows that IETF is more likely to act on such claims from large
> companies than from small companies.
>
> Yes, of course a company pushing for something to be standardized will
> claim that the standard will have customers. This is content-free beyond
> the company name---and IETF doesn't follow procedures that demand more
> information. Evidently the IETF "metric" is not the market prospects of
> what's being proposed for standardization, but rather the size of the
> company pushing for it. That's inherently anti-competitive, rewarding
> the existing big players instead of establishing a level playing field.
>
> A court will want to know how IETF procedures stop a large company or a
> cartel from manipulating IETF's decision-making process to suppress
> competition. What the court will instead see is evidence of IETF often
> allowing its process to be manipulated without even asking questions.
>
> > Please don't quote other lawyers to us.
>
> You're complaining about my providing a link to
>
>
> https://www.google.com/books/edition/Handbook_on_Antitrust_Aspects_of_Standar/zin5tgAACAAJ
>
> from the American Bar Association? I think this is a great starting
> point for WG participants who want to learn more about the topic.
>
> ---D. J. Bernstein
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Salz, Rich writes:
> The IETF has lawyers who are familiar with how the IETF works, and
> that legal counsel finds our processes acceptable level of risk.

RFC 9680 was issued in October 2024 and says that it's "intended to
educate IETF participants about how to reduce antitrust risks in
connection with IETF activities". Sounds like the lawyers are worried.
More to the point, they _should_ be worried.

> The IETF has long accepted that saying "we have customers who want
> this" as a metric into its decisions. If Foo.Com says they have
> customers for RFC X, then the IETF community believes it is more
> likely that Foo.Com will implement RFC X. Market acceptance is
> important to what the IETF considers success.

The whole point of antitrust law is to put constraints on _how_ market
success can be pursued, so praising market success is missing the point.
Take any corporation (whether for-profit or not) that lost an antitrust
case, and look at its briefs; you'll see that it argued, unsuccessfully,
that what it was doing was healthy market activity.

As one of many examples of the constraints that antitrust law places on
standards-development organizations, look at


https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)

asking, inter alia, whether "the procedure for adopting the standard in
question is transparent". Saying that IETF is pursuing market success
does nothing to answer this transparency question, or any of the other
procedural questions asked by antitrust law.

The same link also asks whether there are "objective criteria for
selecting the technology to be included in the standard". Where are
IETF's objective criteria for deciding what to select? Where's the
documentation demonstrating systematic enforcement of those criteria?

As illustrated by this discussion, IETF allows a company to push for a
standard by simply claiming, without evidence or quantification or a
technological rationale, that there are customers for the standard.
History shows that IETF is more likely to act on such claims from large
companies than from small companies.

Yes, of course a company pushing for something to be standardized will
claim that the standard will have customers. This is content-free beyond
the company name---and IETF doesn't follow procedures that demand more
information. Evidently the IETF "metric" is not the market prospects of
what's being proposed for standardization, but rather the size of the
company pushing for it. That's inherently anti-competitive, rewarding
the existing big players instead of establishing a level playing field.

A court will want to know how IETF procedures stop a large company or a
cartel from manipulating IETF's decision-making process to suppress
competition. What the court will instead see is evidence of IETF often
allowing its process to be manipulated without even asking questions.

> Please don't quote other lawyers to us.

You're complaining about my providing a link to


https://www.google.com/books/edition/Handbook_on_Antitrust_Aspects_of_Standar/zin5tgAACAAJ

from the American Bar Association? I think this is a great starting
point for WG participants who want to learn more about the topic.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Salz, Rich]

The IETF has long accepted that saying "we have customers who want this" as a 
metric into its decisions. If Foo.Com says they have customers for RFC X, then 
the IETF community believes it is more likely that Foo.Com will implement RFC 
X. Market acceptance is important to what the IETF considers success.

The IETF has lawyers who are familiar with how the IETF works, and that legal 
counsel finds our processes acceptable level of risk.

Please don't quote other lawyers to us.
/r$


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and 
make that the default choice. We would like X25519MLKEM768 published as an RFC, 
be RECOMMENDED=Y, and MTI asap. This is already the de facto standard. All 
standalone ECC (secp256r1, secp384r1, x25519, x448) should soon be made 
RECOMMENDED=N and secp256r1 and x25519 should soon be removed from MTI.

We want standalone MLKEM1024 for customers wanting compliance with CNSA 2.0. We 
are fine with RECOMMENDED=N, but we would like it published as an RFC.

We don’t see any need for SecP256r1MLKEM768 at all, I think that should stay 
RECOMMENDED=N.

In the future we would like to see one or more backup algorithms (BIKE, Classic 
McEliece, FrodoKEM, HQC, etc…) to MLKEM standardized and some of them 
hybridized with X25519 be made RECOMMENDED=Y.

Cheers,
Another

From: Andrey Jivsov 
Date: Friday, 6 December 2024 at 21:45
To: TLS@ietf.org 
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I second D.J. Bernstein's concerns, but my other issue with giving options like 
this is that they will creep up into MTI sets or default sets, with higher 
priority than hybrids.

I find it less ideal that the document on pure ML-KEM (or signature) and 
hybrids are disassociated, causing the progress of standardization of the pure 
version to bring these other concerns.

So, as long as everyone is on the same page that pure is just one option, 
perhaps for strict compliance with CNSA 2.0, then there is no issue from my 
perspective, but that's a (mildly) controversial part.

On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Scott Fluhrer (sfluhrer) writes:
> 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?

See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur security risks without improving deployment.
Regarding "less controversial", you might have missed previous TLS WG
messages such as

https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/

where various people (including me, obviously) already objected. Also,
you might have missed BSI writing in


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile

that its post-quantum KEM recommendations are only "in combination with
a classical key derivation mechanism"; commentator Matt Green writing in

https://x.com/matthew_d_green/status/1742521204026622011

that NSA's "stance against hybrid encryption makes absolutely zero
sense"; and NSA itself in


https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf

asking for two cryptographic layers "to mitigate the ability of an
adversary to exploit a single cryptographic implementation".

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

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 +, 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

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Scott Fluhrer (sfluhrer)]

> Which one?  Yours or Panos et al? :)

I don’t care – we just need something reasonable, and those both qualify…


From: Salz, Rich 
Sent: Friday, December 6, 2024 5:58 PM
To: Scott Fluhrer (sfluhrer) ; Andrey Jivsov 
; TLS@ietf.org
Subject: Re: [TLS] Re: draft-connolly-tls-mlkem-key-agreement

As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen 
(barring Q-day happening and the current hybrid key exchanges no longer making 
sense).

Since the draft has “N” for the recommended column, I’m also pretty sanguine 
about it.

As for people implementing it instead of hybrid, well, the working group can 
help to prevent that by moving ahead with the hybrid draft (hint, hint).

Which one?  Yours or Panos et al? :)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Deirdre Connolly]

> Hence, Cisco will implement it; I am essentially just asking for code
points.


Code points have been allocated:


https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-05.html#name-iana-considerations


On Fri, Dec 6, 2024, 5:23 PM Scott Fluhrer (sfluhrer)  wrote:

> Well, I am on the same page that ‘pure ML-KEM’ should be one option.
> While I would agree with you that hybrid makes sense (and should be another
> option), I am not as inclined as some people to say “and that is so clearly
> the right trade-off that we should forbid any other option”.  There are
> people whose cryptographic expertise I cannot doubt who say that pure
> ML-KEM is the right trade-off for them, and more importantly for my
> employer, that’s what they’re willing to buy.  Hence, Cisco will implement
> it; I am essentially just asking for code points.
>
>
>
> As for it accidentally becoming “MTI”, well I’m pretty sure that won’t
> happen (barring Q-day happening and the current hybrid key exchanges no
> longer making sense).
>
>
>
> As for people implementing it instead of hybrid, well, the working group
> can help to prevent that by moving ahead with the hybrid draft (hint, hint).
>
>
>
> *From:* Andrey Jivsov 
> *Sent:* Friday, December 6, 2024 3:44 PM
> *To:* TLS@ietf.org
> *Subject:* [TLS] Re: draft-connolly-tls-mlkem-key-agreement
>
>
>
> I second D.J. Bernstein's concerns, but my other issue with giving options
> like this is that they will creep up into MTI sets or default sets, with
> higher priority than hybrids.
>
>
>
> I find it less ideal that the document on pure ML-KEM (or signature) and
> hybrids are disassociated, causing the progress of standardization of the
> pure version to bring these other concerns.
>
>
>
> So, as long as everyone is on the same page that pure is just one option,
> perhaps for strict compliance with CNSA 2.0, then there is no issue from my
> perspective, but that's a (mildly) controversial part.
>
>
>
> On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein  wrote:
>
> Scott Fluhrer (sfluhrer) writes:
> > 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?
>
> See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
> than ECC+PQ, would incur security risks without improving deployment.
> Regarding "less controversial", you might have missed previous TLS WG
> messages such as
>
> https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
> https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
> https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/
>
> where various people (including me, obviously) already objected. Also,
> you might have missed BSI writing in
>
>
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile
>
> that its post-quantum KEM recommendations are only "in combination with
> a classical key derivation mechanism"; commentator Matt Green writing in
>
> https://x.com/matthew_d_green/status/1742521204026622011
>
> that NSA's "stance against hybrid encryption makes absolutely zero
> sense"; and NSA itself in
>
>
> https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
> <https://web.archive.org/web/20220524232250/https:/www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf>
>
> asking for two cryptographic layers "to mitigate the ability of an
> adversary to exploit a single cryptographic implementation".
>
> ---D. J. Bernstein
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Scott Fluhrer (sfluhrer)]

Well, I am on the same page that ‘pure ML-KEM’ should be one option.  While I 
would agree with you that hybrid makes sense (and should be another option), I 
am not as inclined as some people to say “and that is so clearly the right 
trade-off that we should forbid any other option”.  There are people whose 
cryptographic expertise I cannot doubt who say that pure ML-KEM is the right 
trade-off for them, and more importantly for my employer, that’s what they’re 
willing to buy.  Hence, Cisco will implement it; I am essentially just asking 
for code points.

As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen 
(barring Q-day happening and the current hybrid key exchanges no longer making 
sense).

As for people implementing it instead of hybrid, well, the working group can 
help to prevent that by moving ahead with the hybrid draft (hint, hint).

From: Andrey Jivsov 
Sent: Friday, December 6, 2024 3:44 PM
To: TLS@ietf.org
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement

I second D.J. Bernstein's concerns, but my other issue with giving options like 
this is that they will creep up into MTI sets or default sets, with higher 
priority than hybrids.

I find it less ideal that the document on pure ML-KEM (or signature) and 
hybrids are disassociated, causing the progress of standardization of the pure 
version to bring these other concerns.

So, as long as everyone is on the same page that pure is just one option, 
perhaps for strict compliance with CNSA 2.0, then there is no issue from my 
perspective, but that's a (mildly) controversial part.

On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Scott Fluhrer (sfluhrer) writes:
> 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?

See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur security risks without improving deployment.
Regarding "less controversial", you might have missed previous TLS WG
messages such as

https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/

where various people (including me, obviously) already objected. Also,
you might have missed BSI writing in


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile

that its post-quantum KEM recommendations are only "in combination with
a classical key derivation mechanism"; commentator Matt Green writing in

https://x.com/matthew_d_green/status/1742521204026622011

that NSA's "stance against hybrid encryption makes absolutely zero
sense"; and NSA itself in


https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf<https://web.archive.org/web/20220524232250/https:/www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf>

asking for two cryptographic layers "to mitigate the ability of an
adversary to exploit a single cryptographic implementation".

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrey Jivsov]

I second D.J. Bernstein's concerns, but my other issue with giving options
like this is that they will creep up into MTI sets or default sets, with
higher priority than hybrids.

I find it less ideal that the document on pure ML-KEM (or signature) and
hybrids are disassociated, causing the progress of standardization of the
pure version to bring these other concerns.

So, as long as everyone is on the same page that pure is just one option,
perhaps for strict compliance with CNSA 2.0, then there is no issue from my
perspective, but that's a (mildly) controversial part.

On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein  wrote:

> Scott Fluhrer (sfluhrer) writes:
> > 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?
>
> See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
> than ECC+PQ, would incur security risks without improving deployment.
> Regarding "less controversial", you might have missed previous TLS WG
> messages such as
>
> https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
> https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
> https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/
>
> where various people (including me, obviously) already objected. Also,
> you might have missed BSI writing in
>
>
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile
>
> that its post-quantum KEM recommendations are only "in combination with
> a classical key derivation mechanism"; commentator Matt Green writing in
>
> https://x.com/matthew_d_green/status/1742521204026622011
>
> that NSA's "stance against hybrid encryption makes absolutely zero
> sense"; and NSA itself in
>
>
> https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>
> asking for two cryptographic layers "to mitigate the ability of an
> adversary to exploit a single cryptographic implementation".
>
> ---D. J. Bernstein
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[D. J. Bernstein]

Scott Fluhrer (sfluhrer) writes:
> 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?

See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur security risks without improving deployment.
Regarding "less controversial", you might have missed previous TLS WG
messages such as

https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/
https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/
https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/

where various people (including me, obviously) already objected. Also,
you might have missed BSI writing in


https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile

that its post-quantum KEM recommendations are only "in combination with
a classical key derivation mechanism"; commentator Matt Green writing in

https://x.com/matthew_d_green/status/1742521204026622011

that NSA's "stance against hybrid encryption makes absolutely zero
sense"; and NSA itself in


https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf

asking for two cryptographic layers "to mitigate the ability of an
adversary to exploit a single cryptographic implementation".

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

+1

From: Russ Housley 
Date: Thursday, 5 December 2024 at 22:20
To: Scott Fluhrer (sfluhrer) 
Cc: IETF TLS 
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
I hope so.  Can we start an adoption call?

Russ


On Dec 5, 2024, at 4:08 PM, Scott Fluhrer (sfluhrer) 
 wrote:

How do we proceed with this draft?

This draft is quite boring (which is good from a cryptographical perspective); 
it just says ‘take ML-KEM and insert it as a key agreement into TLS in the 
obvious way’.

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?


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Russ Housley]

I hope so.  Can we start an adoption call?

Russ

> On Dec 5, 2024, at 4:08 PM, Scott Fluhrer (sfluhrer) 
>  wrote:
> 
> How do we proceed with this draft?
>  
> This draft is quite boring (which is good from a cryptographical 
> perspective); it just says ‘take ML-KEM and insert it as a key agreement into 
> TLS in the obvious way’.
>  
> 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?
> 

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Salz, Rich]

Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of 
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of any 
kind can be done. Where do IANA preallocations start bumping up against "well 
we're doing something completely different anyway"?

Your co-chairs have 8447bis in WGLC, :)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[David Benjamin]

On Fri, Nov 1, 2024 at 2:02 PM Alicja Kario  wrote:

> On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
> >>  Tangentially, this is registering a `NamedGroup` /
> >> `SupportedGroup`, but of course it's not a group, it's a KEM
> >> scheme over which no Diffie-Hellman of any kind can be done.
> >> Where do IANA preallocations start bumping up against "well
> >> we're doing something completely different anyway"?
> >
> > The deciding factor for these registries isn't the names of the
> > fields but what the protocol does with them. If we started a new
> > registry for KEMs, it wouldn't be useful in TLS because TLS 1.3
> > specifically needs a codepoint in the NamedGroup enum.
> >
> > The FFDH range isn't treated special because of naming but
> > because of some mistakes that RFC 7919 made where the
> > implementation actually needs to categorize codepoints. The
> > group naming is unfortunate but the last ill-advised rename from
> > curve to group was incredibly expensive. If we want to rename it
> > again, "KEM" or "KeyAgreement" or "KeyExchange" or
> > "KeyShareType" would have been a much better name, but given how
> > problematic the last rename was, I'm not very thrilled about the
> > prospect.
>
> actually the FFDH range is special, see section 4 of RFC 7919:
>
>If a compatible TLS server receives a Supported Groups extension from
>a client that includes any FFDHE group (i.e., any codepoint between
>256 and 511, inclusive, even if unknown to the server), and if none
>of the client-proposed FFDHE groups are known and acceptable to the
>server, then the server MUST NOT select an FFDHE cipher suite.
>

Right, we're saying the same thing. The FFDH range is special because a
mistake in RFC 7919 led to the receiver needing to categorize codepoints it
didn't understand. Specifically, the mistake was using the same cipher
suite values as the old TLS 1.2 DHE construction, where groups are chosen
by server fiat and without negotiation. (That mistake makes RFC 7919
basically useless in solving the negotiation problem. See
https://mailarchive.ietf.org/arch/msg/tls/mWWEJdw_SxAIlvZQnsr1_GiAhQY/ )


> but yes, it should have been renamed then to something like
> Key Exchange Algorithms, not to Supported Groups..., but like they say,
> hindsight is 20-20.
>
> > See also
> > https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/
> >
> > David
> >
> > On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly
> >  wrote:
> > If there's a choice to be made I favor the 512 513 514 choices
> >
> > On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly
> >  wrote:
> > Ah, oops!
> >
> > Tangentially, this is registering a `NamedGroup` /
> > `SupportedGroup`, but of course it's not a group, it's a KEM
> > scheme over which no Diffie-Hellman of any kind can be done.
> > Where do IANA preallocations start bumping up against "well
> > we're doing something completely different anyway"?
> >
> >
> > On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:
> > I made a mistake and you're right " 261, 262, and 263 are
> > assigne to the MLKEM512, MLKEM768, and MLKEM1024" wrong.
> >
> > We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Alicja Kario]

On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
 Tangentially, this is registering a `NamedGroup` / 
`SupportedGroup`, but of course it's not a group, it's a KEM 
scheme over which no Diffie-Hellman of any kind can be done. 
Where do IANA preallocations start bumping up against "well 
we're doing something completely different anyway"?


The deciding factor for these registries isn't the names of the 
fields but what the protocol does with them. If we started a new 
registry for KEMs, it wouldn't be useful in TLS because TLS 1.3 
specifically needs a codepoint in the NamedGroup enum.


The FFDH range isn't treated special because of naming but 
because of some mistakes that RFC 7919 made where the 
implementation actually needs to categorize codepoints. The 
group naming is unfortunate but the last ill-advised rename from 
curve to group was incredibly expensive. If we want to rename it 
again, "KEM" or "KeyAgreement" or "KeyExchange" or 
"KeyShareType" would have been a much better name, but given how 
problematic the last rename was, I'm not very thrilled about the 
prospect.


actually the FFDH range is special, see section 4 of RFC 7919:

  If a compatible TLS server receives a Supported Groups extension from
  a client that includes any FFDHE group (i.e., any codepoint between
  256 and 511, inclusive, even if unknown to the server), and if none
  of the client-proposed FFDHE groups are known and acceptable to the
  server, then the server MUST NOT select an FFDHE cipher suite.

but yes, it should have been renamed then to something like
Key Exchange Algorithms, not to Supported Groups..., but like they say,
hindsight is 20-20.

See also 
https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/


David

On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly 
 wrote:
If there's a choice to be made I favor the 512 513 514 choices 

On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly 
 wrote:

Ah, oops!

Tangentially, this is registering a `NamedGroup` / 
`SupportedGroup`, but of course it's not a group, it's a KEM 
scheme over which no Diffie-Hellman of any kind can be done. 
Where do IANA preallocations start bumping up against "well 
we're doing something completely different anyway"?



On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:
I made a mistake and you're right " 261, 262, and 263 are 
assigne to the MLKEM512, MLKEM768, and MLKEM1024" wrong.


We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.



--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Deirdre Connolly]

> The FFDH range isn't treated special because of naming but because of
some mistakes that RFC 7919 made where the implementation actually needs to
categorize codepoints.

Gotcha, cheers.

I'm definitely not advocating another name change, it's not worth it

On Fri, Nov 1, 2024, 1:03 PM David Benjamin  wrote:

> > Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
> of any kind can be done. Where do IANA preallocations start bumping up
> against "well we're doing something completely different anyway"?
>
> The deciding factor for these registries isn't the names of the fields but
> what the protocol does with them. If we started a new registry for KEMs, it
> wouldn't be useful in TLS because TLS 1.3 specifically needs a codepoint in
> the NamedGroup enum.
>
> The FFDH range isn't treated special because of naming but because of some
> mistakes that RFC 7919 made where the implementation actually needs to
> categorize codepoints. The group naming is unfortunate but the last
> ill-advised rename from curve to group was incredibly expensive. If we want
> to rename it again, "KEM" or "KeyAgreement" or "KeyExchange" or
> "KeyShareType" would have been a much better name, but given how
> problematic the last rename was, I'm not very thrilled about the prospect.
>
> See also
> https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/
>
> David
>
> On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly 
> wrote:
>
>> If there's a choice to be made I favor the 512 513 514 choices
>>
>> On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly 
>> wrote:
>>
>>> Ah, oops!
>>>
>>> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
>>> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
>>> of any kind can be done. Where do IANA preallocations start bumping up
>>> against "well we're doing something completely different anyway"?
>>>
>>>
>>> On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:
>>>
 I made a mistake and you're right " 261, 262, and 263 are assigne to
 the MLKEM512, MLKEM768, and MLKEM1024" wrong.

 We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.

 ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[David Benjamin]

> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
of any kind can be done. Where do IANA preallocations start bumping up
against "well we're doing something completely different anyway"?

The deciding factor for these registries isn't the names of the fields but
what the protocol does with them. If we started a new registry for KEMs, it
wouldn't be useful in TLS because TLS 1.3 specifically needs a codepoint in
the NamedGroup enum.

The FFDH range isn't treated special because of naming but because of some
mistakes that RFC 7919 made where the implementation actually needs to
categorize codepoints. The group naming is unfortunate but the last
ill-advised rename from curve to group was incredibly expensive. If we want
to rename it again, "KEM" or "KeyAgreement" or "KeyExchange" or
"KeyShareType" would have been a much better name, but given how
problematic the last rename was, I'm not very thrilled about the prospect.

See also
https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/

David

On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly 
wrote:

> If there's a choice to be made I favor the 512 513 514 choices
>
> On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly 
> wrote:
>
>> Ah, oops!
>>
>> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
>> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
>> of any kind can be done. Where do IANA preallocations start bumping up
>> against "well we're doing something completely different anyway"?
>>
>>
>> On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:
>>
>>> I made a mistake and you're right " 261, 262, and 263 are assigne to the
>>> MLKEM512, MLKEM768, and MLKEM1024" wrong.
>>>
>>> We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.
>>>
>>> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Deirdre Connolly]

If there's a choice to be made I favor the 512 513 514 choices

On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly 
wrote:

> Ah, oops!
>
> Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but
> of course it's not a group, it's a KEM scheme over which no Diffie-Hellman
> of any kind can be done. Where do IANA preallocations start bumping up
> against "well we're doing something completely different anyway"?
>
>
> On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:
>
>> I made a mistake and you're right " 261, 262, and 263 are assigne to the
>> MLKEM512, MLKEM768, and MLKEM1024" wrong.
>>
>> We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.
>>
>>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Deirdre Connolly]

Ah, oops!

Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of
course it's not a group, it's a KEM scheme over which no Diffie-Hellman of
any kind can be done. Where do IANA preallocations start bumping up against
"well we're doing something completely different anyway"?


On Fri, Nov 1, 2024, 11:47 AM Salz, Rich  wrote:

> I made a mistake and you're right " 261, 262, and 263 are assigne to the
> MLKEM512, MLKEM768, and MLKEM1024" wrong.
>
> We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

[Salz, Rich]

I made a mistake and you're right " 261, 262, and 263 are assigne to the 
MLKEM512, MLKEM768, and MLKEM1024" wrong.

We'll notify IANA to pick 512 513 514 or 4584 4585 4586.  Or something.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org