[TLS] Re: ML-DSA in TLS

[aebe...@uwe.nsa.gov]

Yep I mistakenly forgot to change the category to "info" instead of "std". It 
will be fixed in a future update.

Alie

From: Andrey Jivsov 
Sent: Wednesday, November 20, 2024 2:35 PM
To: Eric Rescorla 
Cc: tls@ietf.org 
Subject: [TLS] Re: ML-DSA in TLS

Given that the series of Suite B RFCs were Informational, it stands to reason 
that a document of the type that e.g. prohibits hybrids because of internal 
policies of any organization, a viewpoint which is not strongly shared by IETF, 
should not be a standards-track document. For what I see, no-hybrids policy 
increases complexity in real-world systems that need to expose a hybrid and its 
components as a separate option, and this is especially difficult for systems 
that must have a single option acceptable to everyone.

TLS https://datatracker.ietf.org/doc/html/rfc5430
IPSec https://datatracker.ietf.org/doc/html/rfc6380
SMIME https://datatracker.ietf.org/doc/html/rfc6318
OpenPGP: there was pushback on Standards-track, and it only could get standards 
track after we made sure that Brinpool curves are supported 
https://www.rfc-editor.org/rfc/rfc6637.html

(The difference in practice may not be significant, but I still think that 
Informational is correct)

On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:


On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
includes the following note: "Even though hybrid solutions may be
allowed or required due to protocol standards, product availability, or
interoperability requirements, CNSA 2.0 algorithms will become mandatory
to select at the given date, and selecting CNSA 1.0 algorithms alone
will no longer be approved."

This looks 100% compatible with a TLS WG decision saying "PQ in TLS has
to be hybrid".

Without addressing the question of what CNSA 2.0 requires, I don't think
the TLS WG making that decision is really on the table here. As a reminder,
the relevant TLS registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)
operates under an "Expert Review" policy with the standard being quite
low.

  Note:  The role of the designated expert is described in RFC 
8447.
  The designated expert [RFC8126] 
ensures that the specification is
  publicly available.  It is sufficient to have an Internet-Draft
  (that is posted and never published as an RFC) or a document from
  another standards body, industry consortium, university site, etc.
  The expert may provide more in-depth reviews, but their approval
  should not be taken as an endorsement of the supported group.

So, the question isn't so much whether a given algorithm can be used with
TLS but rather (1) whether the WG adopts it (2) whether it's standards track,
(3) whether we mark it Recommended and (4) whether it's mandatory to
implement. We certainly could mark ML-KEM Recommended=N (or
even D), but  the policy isn't to forbid code point registration
just because we don't have confidence in the algorithm; I don't think we should
change that in this case.

-Ekr
___
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: ML-DSA in TLS

[D. J. Bernstein]

Scott Fluhrer (sfluhrer) writes:
> Might I ask what are we arguing about?

This thread is on a draft proposing Dilithium for TLS rather than
ECC+Dilithium for TLS.

There are proposals to have the TLS WG adopt the draft (e.g., "I support
the adoption"). There are circular arguments saying that standardizing
the draft is important because someone says it's important (e.g., "we'll
end up standardizing [because of] some customers who want ML-DSA only").

There are counterarguments saying that this is creating unnecessary
security risks, in the same way that non-hybrid KEM deployment would be
creating unnecessary security risks.

Specific points under discussion include the question of what weight the
TLS WG should put on an NSA ban of hybrids, and the question of whether
NSA has in fact banned hybrids.

> Does the TLS working group feel the need to prohibit pure ML-DSA as
> authentication?

This would be taking a useful step against an unnecessarily risky
proposal. This step would also help focus attention on what's best for
moving PQ deployment forward, namely ECC+PQ.

> Even though, after Q-day happens (whenever that will be), that might
> be what people want?

"Concretely, think about a demo showing that spending a billion dollars
on quantum computation can break a thousand X25519 keys. Yikes! We
should be aiming for much higher security than that! We don't even want
a billion-dollar attack to be able to break _one_ key! Users who care
about the security of their data will be happy that we deployed
post-quantum cryptography. But are the users going to say 'Let's turn
off X25519 and make each session a million dollars cheaper to attack'?
I'm skeptical. I think users will need to see much cheaper attacks
before agreeing that X25519 has negligible security value."

Analogous comments apply to Ed25519. The quote is from a much more
comprehensive analysis of the anti-hybrid arguments from NSA and GCHQ:
https://blog.cr.yp.to/20240102-hybrid.html

For both encryption and signatures, sure, looking farther and farther
into the future makes it more and more plausible that ECC will be shown
to be really cheap to break, making it plausible that people will decide
to remove it. But it's baffling to see the possibility of a far-future
simplification being used as an argument to incur security risks today.

---D. J. Bernstein

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

[TLS] Re: ML-DSA in TLS

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: D. J. Bernstein 
> Sent: Thursday, November 21, 2024 10:06 AM
> To: tls@ietf.org
> Subject: [TLS] Re: ML-DSA in TLS
> 
> Scott Fluhrer (sfluhrer) writes:
> > Might I ask what are we arguing about?
> 
> This thread is on a draft proposing Dilithium for TLS rather than
> ECC+Dilithium for TLS.

Yes, I've been following the thread.

My real question is "why is there such push-back from such a small change?"  I 
would understand it if there were a real security vulnerability at stake, 
however if we believe that ML-DSA has a real security vulnerability, we ought 
to abandon it entirely (and I would agree that would be unreasonable)

You make the point that having ECC as a back-up is a reasonable trade-off (and 
I would personally agree with you on that).  However, not everyone feels that 
way, and I don’t believe that it is reasonable for the working group to demand 
that everyone make that same trade-off (especially since, from the working 
group's perspective, allowing such differing trade-offs is just assigning a few 
additional code points).

On a side note: if this working group feels that having hybrid/composite 
certificates is the way to go, we need to tell that to the LAMPS working group. 
 LAMPS provides tools for TLS to use - if we want something from that tool, we 
ought to inform them.  If they don't hear of any need, they might abandon their 
efforts.

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

[TLS] Re: ML-DSA in TLS

[Scott Fluhrer (sfluhrer)]

Might I ask what are we arguing about?  Does the TLS working group feel the 
need to prohibit pure ML-DSA as authentication?  Even though, after Q-day 
happens (whenever that will be), that might be what people want?

If you go through the TLS ML-DSA draft, all they do is define three code points 
(for the three ML-DSA parameter sets), that’s it.  That sounds like a 
reasonable addition, even if it were to turn out to be useful only in a few 
networks with private CAs.

From: Andrey Jivsov 
Sent: Wednesday, November 20, 2024 3:36 PM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS

Given that the series of Suite B RFCs were Informational, it stands to reason 
that a document of the type that e.g. prohibits hybrids because of internal 
policies of any organization, a viewpoint which is not strongly shared by IETF, 
should not be a standards-track document. For what I see, no-hybrids policy 
increases complexity in real-world systems that need to expose a hybrid and its 
components as a separate option, and this is especially difficult for systems 
that must have a single option acceptable to everyone.

TLS https://datatracker.ietf.org/doc/html/rfc5430
IPSec https://datatracker.ietf.org/doc/html/rfc6380
SMIME https://datatracker.ietf.org/doc/html/rfc6318
OpenPGP: there was pushback on Standards-track, and it only could get standards 
track after we made sure that Brinpool curves are supported 
https://www.rfc-editor.org/rfc/rfc6637.html

(The difference in practice may not be significant, but I still think that 
Informational is correct)

On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:


On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
includes the following note: "Even though hybrid solutions may be
allowed or required due to protocol standards, product availability, or
interoperability requirements, CNSA 2.0 algorithms will become mandatory
to select at the given date, and selecting CNSA 1.0 algorithms alone
will no longer be approved."

This looks 100% compatible with a TLS WG decision saying "PQ in TLS has
to be hybrid".

Without addressing the question of what CNSA 2.0 requires, I don't think
the TLS WG making that decision is really on the table here. As a reminder,
the relevant TLS registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)
operates under an "Expert Review" policy with the standard being quite
low.

  Note:  The role of the designated expert is described in RFC 
8447.

  The designated expert [RFC8126] 
ensures that the specification is

  publicly available.  It is sufficient to have an Internet-Draft

  (that is posted and never published as an RFC) or a document from

  another standards body, industry consortium, university site, etc.

  The expert may provide more in-depth reviews, but their approval

  should not be taken as an endorsement of the supported group.
So, the question isn't so much whether a given algorithm can be used with
TLS but rather (1) whether the WG adopts it (2) whether it's standards track,
(3) whether we mark it Recommended and (4) whether it's mandatory to
implement. We certainly could mark ML-KEM Recommended=N (or
even D), but  the policy isn't to forbid code point registration
just because we don't have confidence in the algorithm; I don't think we should
change that in this case.

-Ekr
___
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: [EXT] Re: ML-DSA in TLS

[D. J. Bernstein]

Blumenthal, Uri - 0553 - MITLL writes:
> Given how the two (KEM and DSA) are used, and what threats may exist
> against each of them, I think it’s perfectly fine to use PQ instead of
> ECC+PQ here.

Hmmm. I don't see where your previous anti-hybrid argument
(https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ)
distinguishes encryption from signatures.

Are you saying that you're now in favor of hybrids for encryption but
not for signatures? What's the relevant difference?

On the pro-hybrid side, here's the common-sense argument again, where I
again don't see a difference between signatures and encryption:

   * With ECC+PQ encryption, an attacker with a PQ break still has to
 break the ECC encryption. This makes ECC+PQ less risky than PQ for
 encryption.

   * With ECC+PQ signatures, an attacker with a PQ break still has to
 break the ECC signatures. This makes ECC+PQ less risky than PQ for
 signatures.

See also https://blog.cr.yp.to/20240102-hybrid.html for a more detailed
analysis, again covering both cases. Of course, the concrete examples
(such as SIKE) vary between signatures and encryption.

---D. J. Bernstein

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

[TLS] Re: [EXT] Re: ML-DSA in TLS

[Blumenthal, Uri - 0553 - MITLL]

Scott Fluhrer (sfluhrer) writes:
> My real question is "why is there such push-back from such a small change?"

For the same reason there would have been pushback if the KEM rollouts
had done PQ instead of ECC+PQ: that would have been reckless from a
security perspective. 
Given how the two (KEM and DSA) are used, and what threats may exist against 
each of them, I think it’s perfectly fine to use PQ instead of ECC+PQ here. 
> however if we believe that ML-DSA has a real security vulnerability,
> we ought to abandon it entirely

We're not talking about the extreme case of deploying something today
that has already been broken. We're talking about managing _risks_ of
_future_ attacks. 
My crystal ball says that ECC will get broken before PQ, at least in case of 
ML-DSA. 







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: [EXT] Re: ML-DSA in TLS

[Blumenthal, Uri - 0553 - MITLL]

Are you saying that you're now in favor of hybrids for encryption but
not for signatures? What's the relevant difference? 
No, I’m still for non-hybrid PQ KEM and signatures. But I recognize (though 
disagreeing with) the arguments of those who want hybrid KEMs. I do not buy the 
arguments for hybrid signatures at all. 
On the pro-hybrid side, here's the common-sense argument again, where I
again don't see a difference between signatures and encryption:

* With ECC+PQ encryption, an attacker with a PQ break still has to
break the ECC encryption. This makes ECC+PQ less risky than PQ for
encryption. 
And adding another KEM based on a different math concept, e.g., code-based – 
would decrease the risk even more. So, why not ECC+Kyber+McEliece? Where do you 
draw the line? I draw it on PQ itself, willing to put my eggs into the Lattice 
basket. 
* With ECC+PQ signatures, an attacker with a PQ break still has to
break the ECC signatures. This makes ECC+PQ less risky than PQ for
signatures. 
This boils down to the need to maintain infrastructure, codebase, etc. for ECC 
and PQ, plus the possible intricacies of their interactions – vs. the concern 
that the PQ part would fail while the ECC part would not . One line of thought 
says “the longer it’s been around – the less likely it is to fail, so ECC will 
last at least until CRQC”. Another view is – “ECC has been around for so long 
that there’s bound to be a breakthrough”. 
In short, you strengthened my conviction that hybrid KEMs don’t make practical 
sense (diminishing returns), because we know enough now about the accepted PQ 
algorithms to be reasonably certain that they won’t be the weakest part. 
As I understand, that’s the position that GCHQ and NSA took – unless you really 
believe that they secretly aim to weaken the crypto used by US and GB military 
& (especially) civilian government departments/organizations. 

See also https://blog.cr.yp.to/20240102-hybrid.html 
 for a more detailed
analysis, again covering both cases. Of course, the concrete examples
(such as SIKE) vary between signatures and encryption. 
I did. For how long has SIKE been around? Compared to, e.g., NTRU? How many 
Classic PKC systems came up and got broken? 







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: ML-DSA in TLS

[Tim Hollebeek]

Yes, the thread on this draft got hijacked by a completely off-topic discussion 
about composite and hybrid.

 

To be clear, the draft says absolutely nothing about either of those two 
topics, and to be even more clear, does not at all imply in any way that pure 
ML-DSA is superior or is the only option. It just says that if you need ML-DSA 
for TLS, here’s how you do it.

 

People who want to discuss composite / hybrid, which by the way I personally am 
also in favor of and actually prefer for many use cases, should move those 
discussions to threads about the appropriate drafts. 

 

ML-DSA support for TLS is obvious and straightforward. We should explain and 
standardize the right way to do it, to prevent people from inventing a plethora 
of slightly different, non-standard implementations out of necessity because 
IETF failed to publish a straightforward draft in a timely manner.

 

Let’s get back on topic and get this done.

 

-Tim

 

From: Scott Fluhrer (sfluhrer)  
Sent: Thursday, November 21, 2024 8:55 AM
To: Andrey Jivsov ; Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS

 

Might I ask what are we arguing about?  Does the TLS working group feel the 
need to prohibit pure ML-DSA as authentication?  Even though, after Q-day 
happens (whenever that will be), that might be what people want?

 

If you go through the TLS ML-DSA draft, all they do is define three code points 
(for the three ML-DSA parameter sets), that’s it.  That sounds like a 
reasonable addition, even if it were to turn out to be useful only in a few 
networks with private CAs.

 

From: Andrey Jivsov mailto:cry...@brainhub.org> > 
Sent: Wednesday, November 20, 2024 3:36 PM
To: Eric Rescorla mailto:e...@rtfm.com> >
Cc: tls@ietf.org  
Subject: [TLS] Re: ML-DSA in TLS

 

Given that the series of Suite B RFCs were Informational, it stands to reason 
that a document of the type that e.g. prohibits hybrids because of internal 
policies of any organization, a viewpoint which is not strongly shared by IETF, 
should not be a standards-track document. For what I see, no-hybrids policy 
increases complexity in real-world systems that need to expose a hybrid and its 
components as a separate option, and this is especially difficult for systems 
that must have a single option acceptable to everyone.

 

TLS https://datatracker.ietf.org/doc/html/rfc5430

IPSec https://datatracker.ietf.org/doc/html/rfc6380

SMIME https://datatracker.ietf.org/doc/html/rfc6318

OpenPGP: there was pushback on Standards-track, and it only could get standards 
track after we made sure that Brinpool curves are supported 
https://www.rfc-editor.org/rfc/rfc6637.html 

 

(The difference in practice may not be significant, but I still think that 
Informational is correct)

 

On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla mailto:e...@rtfm.com> > wrote:

 

 

On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein mailto:d...@cr.yp.to> > wrote:

https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
 

 
includes the following note: "Even though hybrid solutions may be
allowed or required due to protocol standards, product availability, or
interoperability requirements, CNSA 2.0 algorithms will become mandatory
to select at the given date, and selecting CNSA 1.0 algorithms alone
will no longer be approved."

This looks 100% compatible with a TLS WG decision saying "PQ in TLS has
to be hybrid". 

 

Without addressing the question of what CNSA 2.0 requires, I don't think

the TLS WG making that decision is really on the table here. As a reminder,

the relevant TLS registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)

operates under an "Expert Review" policy with the standard being quite

low.

  Note:  The role of the designated expert is described in RFC 8447 
 .
  The designated expert [RFC8126  ] 
ensures that the specification is
  publicly available.  It is sufficient to have an Internet-Draft
  (that is posted and never published as an RFC) or a document from
  another standards body, industry consortium, university site, etc.
  The expert may provide more in-depth reviews, but their approval
  should not be taken as an endorsement of the supported group.

So, the question isn't so much whether a given algorithm can be used with

TLS but rather (1) whether the WG adopts it (2) whether it's standards track,

(3) whether we mark it Recommended and (4) whether it's mandatory to

implement. We certainly could mark ML-KEM Recommended=N (or

even D), but  the policy isn't to forbid code point registration

just because we don't have confidence in the algorithm; I don't think we should

ch

[TLS] Re: ML-DSA in TLS

[Stephen Farrell]

Hiya,

Without going into the details, I'm generally sympathetic to djb's
argument here, but also do recognise ekr's "we allow anyone to get
a RECOMMENDED=N code point" as valid.

That said, if the WG adopt *anything* with RECOMMENDED=Y in this
space (incl. for KEMs) then I think the onus is on the WG to write
down guidance for the entire space, especially as there will be
codepoints for non-hybrids.

In summary: I don't think we should go back to previous policies
where we'd try prevent registration of non-hybrids, but I do think
we really need to try reach consensus on guidance text for the whole
slew of PQ possibilities for TLS. (And IMO that guidance would be
along the lines of djb's argument.)

Cheers,
S.

PS: It seems pretty ironic to me that ambiguities in NIST and NSA text
are turning out such a barrier to getting PQ stuff done when at the
same time they're some of the entities trying to (again IMO) rush a
pile of things here. (To be clear: for me, everything PQ except hybrid
KEMs is a thing for which we ought hasten much more slowly.)



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: ML-DSA in TLS

[D. J. Bernstein]

Scott Fluhrer (sfluhrer) writes:
> My real question is "why is there such push-back from such a small change?"

For the same reason there would have been pushback if the KEM rollouts
had done PQ instead of ECC+PQ: that would have been reckless from a
security perspective.

Consider CECPQ2b, which applied ECC+SIKE to real user data. Replacing
ECC+SIKE with SIKE is a very small code change to skip the "ECC+" part,
but this would have had much larger security consequences against
attacks known today: the change would have made the connections
exploitable in seconds even _without_ a quantum computer.

Of course, that wasn't known back then. Many people were enthusiastic
about SIKE (see, e.g., https://eprint.iacr.org/2021/543), praising its
small keys and how secure it supposedly was. Only a few people (me, for
example) were on record sounding alarm bells about SIKE. Fortunately,
the cryptographic community's habitual overconfidence was overridden by
common-sense security practices. Those practices include keeping an ECC
layer just in case the PQ layer goes horribly wrong.

> I would understand it if there were a real security vulnerability at stake,

This is like claiming in 2021 that there's no vulnerability in SIKE,
ergo might as well simplify ECC+SIKE to SIKE.

https://cr.yp.to/papers.html#qrcsp accumulates attack data for the 69
round-1 submissions to the NIST competition, and finds that 48% have
been broken already. That's counting only mathematical breaks, ignoring
all the implementation breaks such as KyberSlash.

> however if we believe that ML-DSA has a real security vulnerability,
> we ought to abandon it entirely

We're not talking about the extreme case of deploying something today
that has already been broken. We're talking about managing _risks_ of
_future_ attacks. The reason to upgrade from ECC to ECC+PQ is to
simultaneously address (1) the risks of quantum attacks by year Y for
various Y and (2) the risks of the PQ parts being broken.

> I don’t believe that it is reasonable for the working group to demand
> that everyone make that same trade-off

Laissez-faire is a security disaster, as illustrated by the history of
TLS, not to mention the broader history of security. TLS 1.3 learned
from this and prohibited various things that were allowed before.

I'm not saying that more options are always worse. I'm saying that one
has to look at the details, rather than resorting to generic arguments
such as "more options are better" or "I've heard that someone will pay
for this ergo IETF should allow it".

> allowing such differing trade-offs is just assigning a few additional
> code points

I quoted two examples of proposals of non-hybrid adoption and non-hybrid
standardization. Have those proposals been withdrawn?

There are more possibilities, as ekr noted. Some are easier than others,
but the WG's top priority should be security. RFC 7465, banning RC4,
took more work than leaving RC4 in place, but was still the right thing
to do from a security perspective.

---D. J. Bernstein

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