[TLS] Re: TLS client puzzles revival

[David Venhoek]

Hi All,

Thanks for the feedback. Just to clarify a few points, yes this would
be intended as a last resort solution. We think the negative impact on
interactive clients (and in particular, browsers) can be mitigated in
large part by asking user permission before spending compute. That
would probably also make servers hesitant to overuse the puzzles. In
the end, the goal is that the mere presence of this option makes dos
attacks against the handshake in particular economically
uninteresting, such that the mere presence of a mitigation mechanism
means we hopefully almost never need it.

Thanks also for the suggestions for alternate solutions to try now. We
are in discussions with the attacked party to see if we can try those
out now, to see what impact they will have.

The long lead time before this would be usable "in the wild" for us
would be exactly the reason to move forward with this now. By its very
nature, a solution like this needs long lead times, so waiting until
we see large scale concrete attacks that we cant immediately mitigate
other ways is going to mean a very painful decade for anyone in the
crosshairs of attackers. Especially with the coming transition to
post-quantum cryptography, this scares me a little, as these might
change the (d)dos attack picture in unexpected ways and (as far as I
am aware) we have little in the way of formal methods to prove there
are no (d)dos-able vulnerabilities in the handshake.

Thank you Bas for the concrete numbers, and for the perspective of
comparing bandwidth in vs compute. We are planning to do some
modelling in the coming months to better understand the impact and how
the client puzzles can and cannot mitigate the problems. We will come
back once we have some concrete numbers and models to share on that.

Kind regards,
David Venhoek


On Fri, Nov 1, 2024 at 2:55 PM Joseph Birr-Pixton  wrote:
>
> On Fri, 1 Nov 2024 at 11:50, Bas Westerbaan 
>  wrote:
>>
>> Here we're not accounting for the new bottleneck on server upload which 
>> these post-quantum signatures add. But that's a bandwidth issue — not a 
>> compute one.
>
>
> On top of that, the HRR/ClientHello Cookie extension already in TLS1.3 can 
> also provide this kind of effect: the server can require the client to echo 
> up to 16KB of data in its retry. This means an equivalent to the "Echo Client 
> Puzzle Type" in this draft is already deployable today.
>
> Cheers,
> Joe

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

[TLS] Re: Adoption call for RFC 9147bis

[Muhammad Usama Sardar]

On 05.12.24 11:03, Ben Smyth wrote:

If they aren't in the model, then analysis is only good up to KeyUpdate. 


Sure, I completely agree. We have no guarantees on what is not in the 
formal model. More precisely, I would like the FATT to comment on the 
following:


Since issues have already been found by David, does FATT expect more 
potential issues around KeyUpdate and post-handshake messages that have 
/not/ yet been found? If yes:


 * (at least) one example of such potential issue.
 * What kind of tools are most suitable for such an analysis? I suspect
   a standard model checker (e.g., SPIN) would do (in contrast to
   symbolic security analysis tools, like ProVerif and Tamarin).


(OpenJDK got KeyUpdate wrong, there were use cases with no security.)
Sounds interesting. Do you have a pointer for me which describes the 
problem precisely?


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: MLKEM or Khyber KX

[Viktor Dukhovni]

On Thu, Dec 05, 2024 at 02:32:21PM -0800, Watson Ladd wrote:
> On Thu, Dec 5, 2024 at 7:31 AM Viktor Dukhovni  wrote:
> >
> > On Sat, Nov 02, 2024 at 07:12:02AM +, John Mattsson wrote:
> >
> > > Eric Rescorla wrote:
> > > >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys?
> > >
> > > No reuse of ephemeral keys is always bad.
> >
> > But ML-KEM is specifically designed (IND-CCA2, via FO transform) to
> > support key reuse, without immediate advantage to the attacker.
> 
> Having two identical Client Hellos is bad for the security proofs in
> TLS. While MLKEM keys aren't the only part of the ClientHello,
> (ClientRandom is also), reuse potentially breaks assumptions in the
> symbolic analysis. That's different from a break of IND-CCA2: IND-CCA2
> is fine if you send the same message again and get the same answer,
> while having two of the same session is a problem for TLS. (What is
> the meaning of "same"? Good question).

[ This is of course a digression from TLS to the side topic of whether
  KEM key reuse is "always bad", after this, I shan't comment on it
  further. ]

Sure, but the key that's reused in KEMTLS is the server's public key,
and even the client's keyshare is unique each time, see Figure 2 of:

https://thomwiggers.nl/publication/kemtls/kemtls.pdf

The server's long-term KEM public key is sent to the client encrypted in
a key derived from the KEM shared secret obtained from the encap of the
client's (ideally ephemeral) keyshare public key, and given a random
server nonce, the rest of the handshake is not repeated even if the
client key happens to be reused (a bad choice in general, but perhaps OK
in some narrow use-cases).

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

[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

[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

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

[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: Adoption call for RFC 9147bis

[Salz, Rich]

>> If you object to the adoption of this document please respond to this 
>> thread by December, 9 2024.

>Based on this, I would have expected only those objecting to respond. 

Yes, it is often the case that "if you object please post" is the construction 
used in the email. The IETF community generally ignores that and posts their 
view.

Part of the reason for the construction is to just confirm consensus from a 
recent meeting. Part of the reason why people post support is that there is 
concern that if there is a flurry of "objection" posts, there is a risk that 
the earlier consensus view might not be remembered.  Shrug.  People. :)

___
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
> 
>
> 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: Adoption call for RFC 9147bis

[Ben Smyth]

On Fri, 6 Dec 2024, 10:06 Muhammad Usama Sardar, <
muhammad_usama.sar...@tu-dresden.de> wrote:

> On 05.12.24 11:03, Ben Smyth wrote:
>
> If they aren't in the model, then analysis is only good up to KeyUpdate.
>
> Sure, I completely agree. We have no guarantees on what is not in the
> formal model. More precisely, I would like the FATT to comment on the
> following:
>
> Since issues have already been found by David, does FATT expect more
> potential issues around KeyUpdate and post-handshake messages that have
> *not* yet been found? If yes:
>
>- (at least) one example of such potential issue.
>
>
Post-handshake client authentication is one aspect that could be
investigated. Another could be security under a new key. It's plausible
flaws may exist, we just don't believe there are; any issues would be more
likely to arise in corner cases.

>
>- What kind of tools are most suitable for such an analysis? I suspect
>a standard model checker (e.g., SPIN) would do (in contrast to symbolic
>security analysis tools, like ProVerif and Tamarin).
>
> Unsure standard model checkers would help, symbolic security tools seem
the most useful, plus they only require extension of existing models.

> (OpenJDK got KeyUpdate wrong, there were use cases with no security.)
>
> Sounds interesting. Do you have a pointer for me which describes the
> problem precisely?
>

OpenJDK's TLS 1.3 implementation was vulnerable to attack for large data
volumes after closure in one direction:

* Method tryKeyUpdate() "Do[es]n't bother to kickstart if...the connection
is not duplex-open."

Safe AES-GCM operation is upper-bound by about 395 gigabytes of plaintext
under the same key, thereafter OpenJDK was vulnerable to attack, it's been
patched:
https://github.com/openjdk/jdk/commit/14aad787a81368ced426c2a9cb301f4ff0c37c3f

(The official report doesn't reveal much:
https://www.cve.org/CVERecord?id=CVE-2023-21930)

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

[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Salz, Rich]

 [1] https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/
Thanks for pointer to this. It looks like a more detailed version of 
tls12-frozen draft. Is there a good reason not to merge the two documents? Is 
it due to different WGs? or different intended status? or something else?

It was originally one document, but the TLS WG thought that the 
application/deployment considerations were better handled in UTA, which agreed 
and adopted “their half.” :)

Do we have an I-D which defines how long do we consider as long-term 
connections? or I-D which gives recommendations or best practices for how long 
do we consider TLS 1.3 to provide excellent security?

We have this: https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/
___
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: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Muhammad Usama Sardar]

A few quick questions. Sorry if I am missing something obvious or some 
background.


On 04.12.24 08:04, Valery Smyslov wrote:

note, that UTA WG has issued a WGLC for draft-ietf-uta-require-tls13-02 (New 
Protocols Must Require TLS 1.3) [1].

  [1]https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/
Thanks for pointer to this. It looks like a more detailed version of 
tls12-frozen draft. Is there a good reason not to merge the two 
documents? Is it due to different WGs? or different intended status? or 
something else?



On 04.12.24 10:36, John Mattsson wrote:


as-is, TLS 1.3 does not provide excellent security for long-term 
connections.


Do we have an I-D which defines /how long/ do we consider as long-term 
connections? or I-D which gives recommendations or best practices for 
/how long /do we consider TLS 1.3 to provide excellent security?


---

Considering the following two statements in I-D, I have two questions:


  For TLS it is important to note that the focus of these efforts is
  TLS 1.3 or later.  Put bluntly, post-quantum cryptography for TLS 1.2
  WILL NOT be supported.


To me the two sentences are contradicting. Which one of the following is 
intended?


1. (My understanding from 1st sentence) Some PQC support for TLS 1.2
   will still continue but it will not be the focus.
2. (My understanding from 2nd sentence) We will exclusively work on PQC
   for TLS 1.3 or later.

What does the capitalization of WILL NOT mean? I did not find any such 
capitalization in RFC 2119 and RFC 8174. Please add the relevant RFC in 
section 2 or define it.



  This
  document specifies that outside of urgent security fixes, no new
  features will be approved for TLS 1.2.


If the intention of draft was #2 above, cross-reading with this 
sentence, are we implying that PQC is not an urgent security issue?




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]

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

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