On Sun, Dec 15, 2024, 10:16 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> >It is obvious that pure PQ KEMs are the future
>
> I am not sure about that. X25519MLKEM768 is already quickly becoming the
> new de facto standard (google.com, ericsson.com,
>
> government.se, etc. are alre
Right. I understood what you meant (I think!). But injecting yet another
legal term into this discussion is not a good idea. It's also not a good
idea for another reason: it sounds condescending if you know what the legal
term means.
thanks,
Rob
On Sun, Dec 15, 2024 at 1:33 PM Eric Rescorla wro
On 15/12/2024 22:26, John Mattsson wrote:
draft-farrell-tls-pqg-00 states:
We recommend taking no action at all at this point in time in
relation to signatures.
I disagree with such a recommendation. I don't see any reason for
such a recommendation and migrating PKI takes time.
That's fin
Angela Robinson from NIST recently summarized the situation as.
"The key-derivation methods described in NIST SP 800-56C are currently only
applicable to shared secrets established during a key establishment scheme as
specified in NIST SP 80056A or 800-56B, or to Z = Z’||T which is the
combinat
D. J. Bernstein wrote:
> More recently, NSA's Dickie George is on video claiming that NSA generated
> the Dual EC points randomly and that Dual EC is secure.
Do you have a link to the video? Such a comment is surprising as it is a very
bad PR strategy. “No comment” is a far better strategy.
We actually have RECOMMENDED = Y/N/D and MTI = MUST/SHOULD. I agree wih EKR
that this is enough.
Stephen Farrell wrote:
>so we ought give such folks guidance to not turn that on
I don't see any reason to give such guidance for the key exchange algorithms in
draft-connolly-tls-mlkem-key-agreement
I’m with Ekr on this – his points are right on. And disagree with Stephen –
Eric explained why clearly enough.
On Sun, Dec 15, 2024 at 12:13 PM Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> wrote:
Hiya,
Answering a few points at once:
On 15/12/2024 17:05, Eric Rescorla wrote:
> I don'
Yes, I'm aware of the legal definition of "attractive nuisance", and I'm
using it in a metaphorical sense, which I think is appropriate here.
-Ekr
On Sun, Dec 15, 2024 at 1:21 PM Rob Sayre wrote:
> On Sun, Dec 15, 2024 at 12:22 PM Eric Rescorla wrote:
>
>> Moreover, as the
>> discussion so f
On Sun, Dec 15, 2024 at 12:22 PM Eric Rescorla wrote:
> Moreover, as the
> discussion so far shows, trying to draw these distinctions has
> a high risk of being an attractive nuisance.
>
I think you mean "high tendency to rathole" (agree). "Attractive nuisance"
is not that:
https://en.wikipedi
All other guidance about TLS configuration has been in UTA unless it's been
deprecating weak algorithms. Most recently the TLS WG wanted the "1.2 is
frozen" draft split into two parts, and the other part given to UTA.
>> I would express the guidance this way: Use a hybrid that combines PQ
>> an
On Sun, Dec 15, 2024 at 12:13 PM Stephen Farrell
wrote:
>
> Hiya,
>
> Answering a few points at once:
>
> On 15/12/2024 17:05, Eric Rescorla wrote:
> > I don't think it's a good use of the WG's time to put out this kind
> > of guidance statement. Rather, we should simply adopt some subset of
> >
Hiya,
Answering a few points at once:
On 15/12/2024 17:05, Eric Rescorla wrote:
I don't think it's a good use of the WG's time to put out this kind
of guidance statement. Rather, we should simply adopt some subset of
the proposed drafts. The Recommended column in the code point
registry serv
I think we ought to consider it our duty to
develop guidance for those deploying e.g. TLS now that we're
adding a plethora of new ciphersuites, some useful, some way
less so, and some possibly even risky.
So, you want a consensus in guidance? What to recommend for what use case?
> Thus
>It is obvious that pure PQ KEMs are the future
I am not sure about that. X25519MLKEM768 is already quickly becoming the new de
facto standard (google.com, ericsson.com,
government.se, etc. are already using it, likely thanks to Cloudflare).
Do you seriously expect governments and standards b
If that draft is useful, it probably belongs in the UTA working group, not TLS.
I would express the guidance this way: Use a hybrid that combines PQ and
“classic” algorithms, so that if one is broken you’re still safe. If you are
required to use only PQ, so be it.
__
Perhaps useful: I’m a customer of cryptography but not a cryptographer. I
have learned a tremendous amount about the open issues and state of play by
reading this discourse. Someone could blog it, and that kind of blog tends
to get on YComb and be widely read. But I think it would be of great hel
On Sun, 15 Dec 2024 at 16:39, John Mattsson wrote:
> Agree. I think the best way to do that is to adopt and publish
> draft-kwiatkowski-tls-ecdhe-mlkem as standard track, and make X25519MLKEM768
> RECOMMENDED=Y and MTI as soon as possible.
>
I agree with this 100%. I am a little baffled by the W
I don't think it's a good use of the WG's time to put out this kind of
guidance statement. Rather, we should simply adopt some subset of the
proposed drafts. The Recommended column in the code point registry serves
as the TLS WG's recommendation.
-Ekr
On Sun, Dec 15, 2024 at 7:30 AM Stephen Far
Blumenthal, Uri wrote:
>It is obvious that pure PQ KEMs are the future
I am not sure about that. X25519MLKEM768 is already quickly becoming the new de
facto standard (google.com, ericsson.com, government.se, etc. are already using
it, likely thanks to Cloudflare). It is already compliant with NI
John Mattsson writes:
> We would not be prepared for PQC if it was not for the NSA.
Um, what?
The PQCrypto conferences started in 2006. The PQCRYPTO grant application
was filed in 2014---that's the project that produced the specifications
and software for Classic McEliece, Dilithium, FrodoKEM, Ky
This is an initial stab at the type of guidance I think the TLS
WG ought develop.
Cheers,
S.
Forwarded Message
Subject: New Version Notification for draft-farrell-tls-pqg-00.txt
Date: Sun, 15 Dec 2024 07:28:35 -0800
From: internet-dra...@ietf.org
To: Stephen Farrell
A new v
Hiya,
On 15/12/2024 02:33, Blumenthal, Uri - 0553 - MITLL wrote:
Stephen, I don’t think attempting to develop consensus in this case
would be either useful or productive.
Strongly disagree. I think we ought consider it our duty to
develop guidance for those deploying e.g. TLS now that we're
a
Blumenthal, Uri wrote:
>This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU
>IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between
>time-marks 30:00 – 34:00.
Very interesting indeed... That Dual EC_DRBG was used in classified systems
before being standardized could
On Sun, Dec 15, 2024 at 02:33:34AM +, Blumenthal, Uri - 0553 - MITLL wrote:
> It is obvious that pure PQ KEMs are the future, when CRQC becomes
> “more” real. Some respected cryptographers are convinced that it is
> the optimal solution for now as well. Some other respected
> cryptographers i
24 matches
Mail list logo
