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
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
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
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
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/NIST responses sound like "This security failure
is _your_ fault! Rea
in 2014. I know
because I found the issues.
>
>
> Cheers,
>
> John
>
>
>
> *From: *D. J. Bernstein
> *Date: *Sunday, 8 September 2024 at 13:23
> *To: *tls@ietf.org
> *Subject: *[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs
> #1360
>
>
ussion is a bit to general for TLS.
Cheers,
John
From: D. J. Bernstein
Date: Sunday, 8 September 2024 at 13:23
To: tls@ietf.org
Subject: [TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
Eric Rescorla writes:
> I do not think we need to make Curve25519 MTI. The purpose of M
Eric Rescorla writes:
> I do not think we need to make Curve25519 MTI. The purpose of MTIs is to
> provide a minimum baseline for interoperability, and we have that already
> with the existing MTI. That's entirely compatible with most people
> preferring X25519 because they believe it's better than
I do not think we need to make Curve25519 MTI. The purpose of MTIs is to
provide a minimum baseline for interoperability, and we have that already
with the existing MTI. That's entirely compatible with most people
preferring X25519 because they believe it's better than the MTI.
-Ekr
On Mon, Aug
I also support *not* making Curve 25519 MTI.
On Mon, Aug 26, 2024 at 10:18 AM Richard Barnes wrote:
> My feelings exactly match Rich's here.
>
> On Mon, Aug 26, 2024 at 10:15 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote:
>
>> I am also opposed to the merge. 8446bis changes are editorial an
My feelings exactly match Rich's here.
On Mon, Aug 26, 2024 at 10:15 AM Salz, Rich wrote:
> I am also opposed to the merge. 8446bis changes are editorial and
> clarifications, not semantic ones.
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubsc
I am also opposed to the merge. 8446bis changes are editorial and
clarifications, not semantic ones.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Andrei Popov writes:
>I support *not* making Curve 25519 MTI in TLS 1.3.
Same here, there's already enough new stuff required by 1.3 without adding even
more.
Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf
I support *not* making Curve 25519 MTI in TLS 1.3.
Cheers,
Andrei
-Original Message-
From: Sean Turner
Sent: Monday, August 26, 2024 6:23 AM
To: TLS List
Subject: [EXTERNAL] [TLS]Consensus Call: -rfc8446bis PRs #1360
Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that
14 matches
Mail list logo
