[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

[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: Disallowing reuse of ephemeral keys

[Thom Wiggers]

Hi all,

> Peter Gutmann  wrote:
> 
> Richard Barnes  writes:
> 
>> 3 seems like it encodes the expectation of most people for what the protocol
>> means.  If you're using a cipher suite labeled something like "ECDHE", it's
>> reasonable to expect that it's actually ephemeral,
> 
> I'd support 3 as well for the same reason, it says (EC)DH-Ephemeral, not
> (EC)DH-Possibly-Ephemeral-But-We-Cant-Guarantee-Anything-Who-Knows-What-You-
> Might-Get-Are-You-Feeling-Lucky.

I also agree with this point. If we include a MUST be ephemeral in RFC8446bis, 
then we send the clear signal that this is the way to do things. It is also the 
version of TLS 1.3 that was analyzed by the provable security people (though I 
don’t expect that it makes a difference other than make the proofs more 
complicated). 

If we put this change in -bis, then the applications that don’t use true 
ephemeral keys will still be compliant with (though then superseded) 
RFC8446-not-bis, right? So even if we had a Protocol Police then those 
committing this particular Protocol Crime have some defense. ;-)

Cheers,

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

[TLS] Re: Disallowing reuse of ephemeral keys

[Bas Westerbaan]

I prefer 2.

On Thu, Dec 12, 2024 at 6:37 PM Joseph Salowey  wrote:

> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys.  This was the consensus of the working group during the development
> of TLS 1.3.  There has been more recent discussion on the list to forbid
> reuse for ML-KEM/hybrid key exchange.  There are several possible options
> here:
>
>
>1.
>
>Keep things as they are (ie. say nothing, as was done in previous TLS
>versions, to forbid the reuse of ephemeral keys) - this is the default
>action if there is no consensus
>2.
>
>Disallow reuse for specific ciphersuites.  It doesn’t appear that
>there is any real difference in this matter between MLKEM/hybrids and ECDH
>here except that there are many more ECDH implementations (some of which
>may reuse a keyshare)
>3.
>
>Update 8446 to disallow reuse of ephemeral keyshares in general.  This
>could be done by revising RFC 8446bis or with a separate document that
>updates RFC 8446/bis
>
>
> We would like to know if there are folks who think the reuse of keyshares
> is important for HTTP or non-HTTP use cases.
>
>
> Thanks,
>
>
> Joe, Deirdre and Sean
>
> ___
> 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: Disallowing reuse of ephemeral keys

[Stephen Farrell]

Hiya,

On 12/12/2024 17:59, Richard Barnes wrote:

My preference order would be 3 > 1 >> 2.


I agree with the above for reasons already stated on the list.

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Disallowing reuse of ephemeral keys

[Loganaden Velvindron]

On Thu, 12 Dec 2024 at 21:37, Joseph Salowey  wrote:
>
> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral 
> keys.  This was the consensus of the working group during the development of 
> TLS 1.3.  There has been more recent discussion on the list to forbid reuse 
> for ML-KEM/hybrid key exchange.  There are several possible options here:
>
>
> Keep things as they are (ie. say nothing, as was done in previous TLS 
> versions, to forbid the reuse of ephemeral keys) - this is the default action 
> if there is no consensus
>
> Disallow reuse for specific ciphersuites.  It doesn’t appear that there is 
> any real difference in this matter between MLKEM/hybrids and ECDH here except 
> that there are many more ECDH implementations (some of which may reuse a 
> keyshare)
>
> Update 8446 to disallow reuse of ephemeral keyshares in general.  This could 
> be done by revising RFC 8446bis or with a separate document that updates RFC 
> 8446/bis
>
>

I would favour option 3.

___
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: Disallowing reuse of ephemeral keys

[Scott Fluhrer (sfluhrer)]

Open questions about ephemeral key reuse (and I don't know the answers; that's 
why they're open questions) - the answers to these questions may help us guide 
us as to whether to forbid it or not:

- To what extent do the proofs of security for TLS 1.3 depend on the non-reuse 
of key shares (either (EC)DH or KEM or hybrid)?  I asked this question about 5 
years ago (at a NIST conference, not on this list), and I believe the answer 
was "yes", at the time, but the proofs may have advanced (or I might have 
misunderstood the answer).

- To what extent was we concerned about ultralow power devices (battery 
powered)?  After all, reusing previous keys would use less power than creating 
new ones - not a huge amount of power (both ML-KEM and ECDH are fairly power 
efficient), but I could see someone making the case.  Would we take that case 
seriously?  (One could make a similar case about performance, but given the 
overhead of doing a TLS exchange, that's a lesser concern, at least IMHO).

> -Original Message-
> From: Stephen Farrell 
> Sent: Friday, December 13, 2024 7:20 AM
> To: tls@ietf.org
> Subject: [TLS] Re: Disallowing reuse of ephemeral keys
> 
> 
> Hiya,
> 
> On 12/12/2024 17:59, Richard Barnes wrote:
> > My preference order would be 3 > 1 >> 2.
> 
> I agree with the above for reasons already stated on the list.
> 
> Cheers,
> S.

___
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]

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

[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

[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: Disallowing reuse of ephemeral keys

[Martin Thomson]

On Fri, Dec 13, 2024, at 23:19, Stephen Farrell wrote:
> On 12/12/2024 17:59, Richard Barnes wrote:
>> My preference order would be 3 > 1 >> 2.
>
> I agree with the above for reasons already stated on the list.

As do I.

___
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