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 t
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 stan
> -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 rath
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
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.
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 a
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 hyb
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
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 t
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 a
10 matches
Mail list logo
