> On 10 Sep 2024, at 00:17, Andrei Popov wrote:
>
> This makes sense, however shouldn’t draft-kwiatkowski-tls-ecdhe-mlkem-01 be
> on the Standards track?
> Also, what is the thinking behind “Recommended: N” for the code points?
The draft-ietf-tls-hybrid-design draft is on the Informational tra
* A few IETF ago we wanted to add codepoints to hybrid-design for
X25519Kyber768Draft00, but the working group felt that a separate document was
more appropriate.
This makes sense, however shouldn’t draft-kwiatkowski-tls-ecdhe-mlkem-01 be on
the Standards track?
Also, what is the thinking be
On Mon, Sep 9, 2024 at 10:56 PM Andrei Popov wrote:
> Yes, we need SecP384 hybrids.
>
> More generally, I see two separate hybrid key exchange drafts under
> discussion in the TLS WG:
> - draft-ietf-tls-hybrid-design-10 refers to pre-standard Kyber;
> - draft-kwiatkowski-tls-ecdhe-mlkem-01 define
Yes, we need SecP384 hybrids.
More generally, I see two separate hybrid key exchange drafts under discussion
in the TLS WG:
- draft-ietf-tls-hybrid-design-10 refers to pre-standard Kyber;
- draft-kwiatkowski-tls-ecdhe-mlkem-01 defines hybrids with ML-KEM 768.
Both drafts are on the Informational
Would it be appropriate to write an RFC on how to make cross-organization mTLS
work reliably and at scale? Would this group/mailing list be the right people
to work with to make that happen?
You should also ask the UTA working group if they are interested.
___
I've been doing a lot of work lately to support organizations that do mTLS
between each other. The problem I've found is that there is a huge amount
of ignorance on TLS in general and mTLS in particular.
Would it be appropriate to write an RFC on how to make cross-organization
mTLS work reliably a
Hey 涛叔,
Sorry for the late reply. Was taking time to read through and try to
understand completely what you were saying.
On 9/5/24 17:53, 涛叔 wrote:
Yes, the native HTTPS Proxy with CONNECT has similar feature. However, the ECH
based SNI Proxy
still has some benefits.
First, we setup one DNS
Alicja Kario writes:
> But then you may also want to add
> https://github.com/openssl/openssl/issues/23860#issuecomment-2103073417
> (while upstream OpenSSL have decided not to call it a vulnerability,
> it's because they consider local side-channels outside of their threat
> model and we didn't tr
As you wish. I've updated the PR.
On Monday, 9 September 2024 16:30:33 CEST, Kris Kwiatkowski wrote:
+1. No need for x448.
On 09/09/2024 14:29, Filippo Valsorda wrote:
If P-386+ML-KEM-1024 is there for CNSA compliance, I see no
need to provide an Edwards counterpart to it: there is no
Edwards
+1. No need for x448.
On 09/09/2024 14:29, Filippo Valsorda wrote:
If P-386+ML-KEM-1024 is there for CNSA compliance, I see no need to provide
an Edwards counterpart to it: there is no Edwards National Security
Algorithm Suite. Also, isn't X448 TLS deployment nearly non-existent?
2024-09-09 1
On Monday, 9 September 2024 14:49:08 CEST, D. J. Bernstein wrote:
Alicja Kario writes:
We haven't actually performed
an attack in which we extracted the private key.
[ ... ]
In practice, what we've shown is that the implementation is _likely_
vulnerable to microarchitectural side-channel att
If P-386+ML-KEM-1024 is there for CNSA compliance, I see no need to provide an
Edwards counterpart to it: there is no Edwards National Security Algorithm
Suite. Also, isn't X448 TLS deployment nearly non-existent?
2024-09-09 15:16 GMT+02:00 Alicja Kario :
> Not explicitly, but it is definied in
Not explicitly, but it is definied in other protocols, like CMS where it
was asked for explicitly.
I can remove it, but I think that omiting it will make the document
appear more biased towards NIST curves than Edwards ones...
On Monday, 9 September 2024 15:09:45 CEST, Bas Westerbaan wrote:
Did
As far as I’m concerned – no need: P384 (or no ECC at all, aka – no hybrid)
would suffice.
TNX
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
Did anyone ask for X448?
On Mon, Sep 9, 2024 at 3:00 PM Alicja Kario wrote:
> On Monday, 9 September 2024 02:04:48 CEST, kris wrote:
> > Hello,
> >
> > I'm sorry, possibly I've missed some emails.
> > If there is an interest I propose we add it to existing draft,
> > publish version -03 and requ
On Monday, 9 September 2024 02:04:48 CEST, kris wrote:
Hello,
I'm sorry, possibly I've missed some emails.
If there is an interest I propose we add it to existing draft,
publish version -03 and request a code point.
The repo is here:
https://github.com/post-quantum-cryptography/draft-kwiatkows
Alicja Kario writes:
> We haven't actually performed
> an attack in which we extracted the private key.
[ ... ]
> In practice, what we've shown is that the implementation is _likely_
> vulnerable to microarchitectural side-channel attacks.
The top of Appendix A of https://cr.yp.to/papers.html#sa
If you were referring to the graph on Cloudflare Radar: that's just eyeball
-> edge.
On Mon, Sep 9, 2024 at 2:34 PM Bas Westerbaan wrote:
> Both.
>
> On Mon, Sep 9, 2024 at 2:32 PM Kris Kwiatkowski
> wrote:
>
>> Sweet!
>> Does this migration includes also cloudflare->origin (egress) connections
Both.
On Mon, Sep 9, 2024 at 2:32 PM Kris Kwiatkowski wrote:
> Sweet!
> Does this migration includes also cloudflare->origin (egress) connections
> or just eyeballs->cloudflare?
>
> Cheers,
> Kris
> On 06/09/2024 12:02, Bas Westerbaan wrote:
>
> Hi all,
>
> We are planning to replace X25519Kyber
Sweet!
Does this migration includes also cloudflare->origin (egress) connections or
just eyeballs->cloudflare?
Cheers,
Kris
On 06/09/2024 12:02, Bas Westerbaan wrote:
Hi all,
We are planning to replace X25519Kyber768Draft00 (0x6399)
with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 a
On Monday, 9 September 2024 08:44:46 CEST, D. J. Bernstein wrote:
John Mattsson writes:
ignoring the mandatory point validation
Exactly! That's how the real world works. The NSA/NIST approach fills
ECDH and signatures with traps for the implementors; implementors fall
into the traps; the NSA/N
21 matches
Mail list logo
