[TLS] Re: ML-DSA in TLS

[Salz, Rich]

To clarify, my draft I linked to (and future profiles) are instantiations of 
the CNSA 2.0 advisory and FAQ as it applies to specific protocols relevant to 
NSS; specifically, the drafts document how we expect vendors to configure 
protocols in a CNSA 2.0 compliant way.

Thanks, that’s interesting.  As the IETF is premised that everyone is working 
as an individual (one of the myths we tell ourselves), you might consider 
having an official link to your draft.

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

The question at hand is whether CNSA 2.0 will _tolerate_ ECC+PQ (of
course assuming the PQ algorithm is on the CNSA 2.0 list).

Some people seem to think that purchasers under NSA control won't buy
ECC+PQ products unless the ECC part is removed, and therefore the TLS WG
has to adopt PQ along with ECC+PQ.

I think the TLS WG should instead prioritize security. This means, e.g.,
rejecting the proposals for the WG to adopt non-hybrid Dilithium, even
if there are crystal-clear orders from NSA to adopt it.

But I also haven't seen any such orders. CNSA 2.0 states that "hybrid
solutions may be allowed or required due to protocol standards, product
availability, or interoperability requirements". This will be triggered
if, e.g., the TLS WG issues an RFC requiring all PQ in TLS to be hybrid.

aebe...@uwe.nsa.gov writes:
> we expect

"Expect" is ambiguous: it doesn't distinguish recommendations from
requirements or from predictions.

"We" is also ambiguous. For example, does "we" include the NSA office
that recommends multiple independent cryptographic layers to mitigate
"the ability of an adversary to exploit a single cryptographic
implementation", in NSA's words?

If NSA wants to prohibit ECC+PQ then it's perfectly capable of issuing
an unambiguous official statement saying so.

---D. J. Bernstein

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David Benjamin]

I did notice one odd thing about the TLS-LTS protocol change (keep in mind
this document is *not* deployment considerations, but a whole new
incompatible mode for TLS 1.2), regarding domain separation. Unless TLS LTS
can fully enforce that the same key is never used for TLS 1.2 LTS and
regular TLS 1.2 (on both the authenticating side and the relying party
side), we need to worry about the security of the two protocols deployed
together.

TLS-LTS changes the signature payload to include the whole transcript so
far:
https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.1-11.1.1

It also changes the syntax of the ServerDHParams:
https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.2-2.1.1

Now, signing a transcript is definitely a good move, and TLS's DHE
construction was very much broken. This is why TLS 1.3 fixed both of these.
But when we change the signing payload, we need to think about
domain-separation. It should not be possible to take a signature generated
in one context and substitute it in another context. The TLS 1.2
ServerKeyExchange signing payload is already fragile. ECDHE and DHE param
formats are different, but the cipher suite is not bound into the
signature. I don't have the paper off-hand, but I recall there was a near
miss where the ECDHE and DHE payloads already nearly overlapped. Given that
the new client_server_hello_hash fully overlaps with the old client_random
(totally under the client's control) and then the new params overlap with
the old server_random (totally under the server's control), it's... not
immediately obvious to me whether this is fine.

In comparison, TLS 1.3 prepends a context string and also includes a
64-byte prefix to clear the old client and server randoms. The former
allows domain separation with future signing payloads, and the latter works
around TLS 1.2's lack of a context string. This avoids needing to reason
about overlapping payloads and who controls what, except the minimum needed
to convince ourselves the 64-byte prefix separates from TLS 1.2 well
enough. (Would be nice to avoid that too, but we can't change TLS 1.2's
lack of a context string, only make sure we fix this going forward.)
https://www.rfc-editor.org/rfc/rfc8446#section-4.4.3

Additionally, if making an incompatible change to TLS 1.2 anyway, rather
than adding dh_q to the parameters, I think we've since learned that
negotiating named values is the way to go, hence the addition of FFDH
values into the NamedGroup registry. (Though there are some other issues
with using the same cipher suite values. RFC 7919 did not actually work to
save TLS 1.2 DHE.)

Of course, details like this are not adoption concerns. Adoption is just a
question of whether the WG wants to take on a document as a starting point.
I.e., normally, the question we should answer here is "do we want to extend
TLS 1.2 to apply the smaller protocol fixes?". However, there was talk in
the thread of not wanting to change the protocol anymore, in which case we
would be unable to, say, apply TLS 1.3's fix to this.

On Wed, Nov 20, 2024 at 12:58 PM Yaron Sheffer 
wrote:

> -1. The TLS working group, and this document in particular, has
> consistently ignored the products of the UTA working group. Specifically,
> RFC 9325 [1] published a mere two years ago is not even referenced in the
> draft, let alone a comparison made with these deployment recommendations
> that were made by the very same IETF. (Yes you can hear my frustration
> coming through).
>
>
>
> Thanks,
>
> Yaron
>
>
>
> [1] https://datatracker.ietf.org/doc/rfc9325/
>
>
>
>
>
> On 20/11/2024, 19:27, "Andrew Campling" 
> wrote:
>
> +1, especially given the previous discussion on this topic on the list
> back in 2016.
>
>
>
>
>
> Andrew
>
>
>
> -Original Message-
>
> From: Salz, Rich 
>
> Sent: 05 November 2024 19:01
>
> To: Sean Turner ; TLS List 
>
> Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support
>
>
>
> I strongly support adoption.
>
>
>
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be bothered
> by the impliciation that *THIS ONE WAY* is the only way to get long-term
> support, especially if it's seen to contradict our encouragement of TLS
> 1.3. But that is an editorial issue that can be easily fixed.
>
>
>
> I would like to see this adopted, a short change cycle, and then advanced
> in the same cluster with our TLS 1.2 is frozen document.
>
>
>
>
>
> ___
>
> 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: ML-DSA in TLS

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

Hi all!

To clarify, my draft I linked to (and future profiles) are instantiations of 
the CNSA 2.0 advisory and FAQ as it applies to specific protocols relevant to 
NSS; specifically, the drafts document how we expect vendors to configure 
protocols in a CNSA 2.0 compliant way.

Cheers,
Alie


Alison Becker, PhD
Center for Cybersecurity Standards (CCSS)
National Security Agency (NSA)

From: Salz, Rich 
Sent: Wednesday, November 20, 2024 10:00 AM
To: Deirdre Connolly ; Alison Becker (GOV) 

Cc: TLS@ietf.org 
Subject: Re: [TLS] Re: ML-DSA in TLS


> In other words, does CNSA 2.0 tolerate ECC, by effectively ignoring its 
> presence, or not?



>From 
>https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html:



"In order to meet the goal of a consistent security level for the entire cipher 
suite, CNSA TLS implementations MUST only use the algorithms listed in this 
document." That's ML-KEM-1024 and ML-DSA-87 only.

It would be better if that statement were in the official CNSA document [1], 
such as a FAQ or something, and not in an IETF document submitted by an 
individual. For example in the CNSA 2.0 FAQ [2] there is a section on “Hybrids” 
in the which gives a subtly different opinion.  Taken together, my answer to 
Andrey is “it seems to, yes” Perhaps we can get official clarification?

[1] 
https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF

[2] FAQ 
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Andrey Jivsov]

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

>
>
> On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein  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: Adoption call for TLS 1.2 Update for Long-term Support

[Yaron Sheffer]

-1. The TLS working group, and this document in particular, has consistently ignored the products of the UTA working group. Specifically, RFC 9325 [1] published a mere two years ago is not even referenced in the draft, let alone a comparison made with these deployment recommendations that were made by the very same IETF. (Yes you can hear my frustration coming through). Thanks,    Yaron [1] https://datatracker.ietf.org/doc/rfc9325/  On 20/11/2024, 19:27, "Andrew Campling"  wrote:+1, especially given the previous discussion on this topic on the list back in 2016.   Andrew -Original Message-From: Salz, Rich  Sent: 05 November 2024 19:01To: Sean Turner ; TLS List Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support I strongly support adoption. I do not understand why anyone would be opposed to the IETF making deployment recommendations. I can understand why someone might be bothered by the impliciation that *THIS ONE WAY* is the only way to get long-term support, especially if it's seen to contradict our encouragement of TLS 1.3. But that is an editorial issue that can be easily fixed. I would like to see this adopted, a short change cycle, and then advanced in the same cluster with our TLS 1.2 is frozen document.  ___TLS mailing list -- tls@ietf.orgTo 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]

Alicja Kario writes:
> Or:
> Auditor sees that P + Q system is more complex to implement and validate
> than a simple Q system, therefore ML-DSA security > ML-DSA+Ed25519 security.

Therefore the deployment of CECPQ2b = ECC+SIKE should have been replaced
with just SIKE? What's next, advocating the null cipher on the basis of
how simple it is?

See https://blog.cr.yp.to/20240102-hybrid.html for further analysis of
the anti-hybrid arguments from NSA and GCHQ. The TLS WG can and should
investigate the details and make its own decisions.

> And even if I don't belive it, I won't be able to provide sufficient
> arguments to convince the customer that the auditor is wrong.

Then why is ECC+PQ such a popular way to deploy PQ, with decision-makers
repeatedly pointing to the risk reduction? And why does

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

show another NSA program using two independent cryptographic layers "to
mitigate the ability of an adversary to exploit a single cryptographic
implementation", in NSA's words?

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

[Alicja Kario]

On Tuesday, 19 November 2024 12:19:06 CET, D. J. Bernstein wrote:

Alicja Kario writes:

We can't use hybrid if we don't have a specification how to put hybrid
keys into X.509 certificates.


Take a specification of how to put a Dilithium key into certificates.
Modify the spec as follows: replace Dilithium with the trivial
Ed25519+Dilithium concatenation.

This immediately produces a spec of how to put Ed25519+Dilithium into
certificates. Compared to the original spec, the modified spec is less
scary and does a better job of encouraging rapid deployment. So why
spend time on the original spec?


until you write this I-D, we don't have it


And that there are no technical reasons for not specifying use of pure
PQ signatures.


I disagree. Specifying ECC+PQ in TLS, and skipping the specification of
just PQ in TLS, reduces security risks.

https://cr.yp.to/talks.html#2016.02.24 said "Pre-quantum signature
system P needs to be replaced with post-quantum signature system Q. Make
auditors happier: Replace P with P + Q. P + Q public key concatenates P
public key, Q public key. P + Q signature concatenates P signature, Q
signature. ... Auditor sees very easily that Ed25519+SPHINCS-256
security >= Ed25519 security." I was using software updates as an
example (later I discussed KEMs and also mentioned keeping an ECC layer
for those), and commented that keeping ECC had "unnoticeable cost".


Or:
Auditor sees that P + Q system is more complex to implement and validate
than a simple Q system, therefore ML-DSA security > ML-DSA+Ed25519 
security.


And even if I don't belive it, I won't be able to provide sufficient
arguments to convince the customer that the auditor is wrong.

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

[D. J. Bernstein]

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". ECC+PQ in TLS is compliant with CNSA 2.0, as long as the
PQ part is one of the CNSA 2.0 algorithms. ECC+PQ wouldn't be taking
NSA/NIST ECC "alone", so the stated prohibition doesn't apply.

To be clear, I'm not saying that this compatibility should be factored
into the TLS WG decision. On the contrary, I would encourage the TLS WG
to make this decision on security grounds even if there were an official
NSA statement that (1) indisputably banned all use of hybrids, (2)
committed billions of dollars to anti-hybrid purchasing, and (3) said
that NSA no longer accepts what it wrote in

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

about mitigating "the ability of an adversary to exploit a single
cryptographic implementation".

> > In other words, does CNSA 2.0 tolerate ECC, by effectively ignoring its
> > presence, or not?
> From https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html:

That I-D isn't CNSA 2.0, nor is it labeled as an official NSA statement.
The draft has an author from NSA and says it complies with CNSA 2.0; but
saying that the draft doesn't allow X isn't evidence that CNSA 2.0
disallows X or that NSA disallows X.

Obviously there's a pattern of NSA and GCHQ saying things to discourage
hybrids. The most extreme statement I've seen is

   
https://web.archive.org/web/20220524232249/https://twitter.com/mjos_crypto/status/1433443198534361101/photo/1

where an NSA employee back in 2021 said that NSA "does not expect to
approve" hybrids. But there was then backlash, followed by the official
NSA statement that "hybrid solutions may be allowed or required due to
protocol standards, product availability, or interoperability
requirements".

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

[Eric Rescorla]

On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein  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] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

+1, especially given the previous discussion on this topic on the list back in 
2016. 


Andrew

-Original Message-
From: Salz, Rich  
Sent: 05 November 2024 19:01
To: Sean Turner ; TLS List 
Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

I strongly support adoption.

I do not understand why anyone would be opposed to the IETF making deployment 
recommendations. I can understand why someone might be bothered by the 
impliciation that *THIS ONE WAY* is the only way to get long-term support, 
especially if it's seen to contradict our encouragement of TLS 1.3. But that is 
an editorial issue that can be easily fixed.

I would like to see this adopted, a short change cycle, and then advanced in 
the same cluster with our TLS 1.2 is frozen document.


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

[TLS] Re: ML-DSA in TLS

[Salz, Rich]

> In other words, does CNSA 2.0 tolerate ECC, by effectively ignoring its 
> presence, or not?

From 
https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html:

"In order to meet the goal of a consistent security level for the entire cipher 
suite, CNSA TLS implementations MUST only use the algorithms listed in this 
document." That's ML-KEM-1024 and ML-DSA-87 only.
It would be better if that statement were in the official CNSA document [1], 
such as a FAQ or something, and not in an IETF document submitted by an 
individual. For example in the CNSA 2.0 FAQ [2] there is a section on “Hybrids” 
in the which gives a subtly different opinion.  Taken together, my answer to 
Andrey is “it seems to, yes” Perhaps we can get official clarification?
[1] 
https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
[2] FAQ 
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org