On Friday, 7 June 2024 08:42:51 CEST, Viktor Dukhovni wrote:
As is well known, the RFC6066 maximum_fragment_length (MFL) extension has a
few serious deficiencies, that led to its subsequent deprecation in
favour of RFC8449 record_size_limit (RSL).
Nevertheless a number of TLS implementations sti
On Fri, Jun 07, 2024 at 01:04:33PM +0200, Hubert Kario wrote:
> On the other hand the RFC states (section 1.1):
>
> ...
> A client that requests
> session resumption does not in general know whether the server will
> accept this request, and therefore it SHOULD send the same extensions
>
Hubert Kario writes:
> Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
> x25519 derive shared secret: 35062.2 op/s
> P-256 derive shared secret: 22741.1 op/s
The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from current code, I tried the script below on a Comet Lake (Inte
On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote:
Hubert Kario writes:
Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850H
x25519 derive shared secret: 35062.2 op/s
P-256 derive shared secret: 22741.1 op/s
The Intel Core i7-10850H microarchitecture is Comet Lake. To see numbers
from c
But X25519, X448, which are mark as safe in safecurves are protected against certain side-channel and other attacks, not only performance advantage. 07.06.2024, 22:33, "Hubert Kario" :On Friday, 7 June 2024 15:54:17 CEST, D. J. Bernstein wrote: Hubert Kario writes: Fedora 39, openssl-3.1.1-4.fc39.x
Hubert Kario wrote:
>Such small differences in performance should absolutely have no effect on
>IETF selecting an algorithm or not.
I completely disagree. As long as people argue that we need symmetric rekeying
and reuse of key share because the ephemeral key exchange algorithms are slow,
I thin
On Friday, 7 June 2024 17:29:35 CEST, John Mattsson wrote:
Hubert Kario wrote:
Such small differences in performance should absolutely have no effect on
IETF selecting an algorithm or not.
I completely disagree. As long as people argue that we need
symmetric rekeying and reuse of key share be
>so we should also remove X448, as it's much slower than X25519?
That does not follow from what I said. I think the important metric is
performance/security. P-256 does basically not have any benefits compared to
X25519 (excepts a few bits of security more) but these are quite irrelevant
compar
Does X448 actually provide "a huge advantage" in security (practically
speaking) over X25519?
On a classical computer, the best known attack against X25519 requires circa
2^126 point addition operations - that is generally accepted as being
infeasible. Attacking X448 requires far more point ad
Since I was quoted, I should say that my words may have made more sense in
context, and if not I apologize. To be clear, we do not anticipate supporting
hybrid in NSS due to the increased development time and validation burden. In
those cases where it is necessary due to protocol constraints,
On Fri, Jun 7, 2024 at 8:52 AM John Mattsson wrote:
> >so we should also remove X448, as it's much slower than X25519?
>
> That does not follow from what I said. I think the important metric is
> performance/security. P-256 does basically not have any benefits compared
> to X25519 (excepts a few
>I really do not understand this argument, given that the DoD has explicitly
>said they aren't doing that.
I think it is a bit unclear what CNSA 2.0 says:
- They say that CNSA 2.0 compliant browsers need to support ML-KEM-1024 by 2025.
- The also say that “NSA does not approve using pre-standardi
Hubert Kario writes:
> I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
> option?
Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line:
op op/s
256 bits ecdh (nistp256) 0.0001s 12184.
On Friday, 7 June 2024 19:08:22 CEST, D. J. Bernstein wrote:
Hubert Kario writes:
I think the openssl compile is missing the `enable-ec_nistp_64_gcc_128`
option?
Results on the same Comet Lake of a fresh run of the script with that
option added to the Configure line:
Eric Rescorla writes:
> I'm struggling to understand what people think is at stake here.
The WG will soon be faced with decisions regarding which curve+PQ
hybrids to recommend for TLS. Regarding the curve-choice part of that,
some context factors that have been raised (such as interoperability and
On Fri, Jun 7, 2024 at 2:40 PM D. J. Bernstein wrote:
> Eric Rescorla writes:
> > I'm struggling to understand what people think is at stake here.
>
> The WG will soon be faced with decisions regarding which curve+PQ
> hybrids to recommend for TLS.
As has been noted elsewhere, the relevant IANA
Eliminating P256 will not be possible, primarily due to FIPS 140 compliance
concerns. From what I have heard from NIST, there are no current plans on
adding X25519 to the NIST approved curves, mostly in order to encourage
people to transition to PQC instead of ECC. From that point of view, I
would
As has been noted elsewhere, the relevant IANA registries are Specification
Required. The TLS WG doesn't need to do anything for a curve+PQ hybrid to be
used with TLS.
Then why has it adopted a draft?
I asked these of you a few days ago and you did not reply.
_
Richard Barnes writes:
> The TLS WG doesn't need to do anything for a curve+PQ hybrid to
> be used with TLS.
As I said, the WG will be faced with decisions regarding which of the
curve+PQ hybrids to _recommend_ for TLS. Sure, more things will be
registered, but the question of what to recommend is
Sophie Schmieg writes:
> From what I have heard from NIST, there are no current plans on
> adding X25519 to the NIST approved curves, mostly in order to encourage
> people to transition to PQC instead of ECC.
Sorry, which document are you referring to? This isn't in line with the
NIST announcement
On Fri, Jun 7, 2024 at 11:41 AM D. J. Bernstein wrote:
> Eric Rescorla writes:
> > I'm struggling to understand what people think is at stake here.
>
> The WG will soon be faced with decisions regarding which curve+PQ
> hybrids to recommend for TLS.
It's important to distinguish between two sen
On 6/7/24 2:36 PM, Eric Rescorla wrote:
On Fri, Jun 7, 2024 at 11:41 AM D. J. Bernstein wrote:
Eric Rescorla writes:
> I'm struggling to understand what people think is at stake here.
The WG will soon be faced with decisions regarding which curve+PQ
hybrids to recommend for T
Hi folks,
Adding a bit more color to the original discussion.
We, at Cloudflare, have been scanning our customer's origin servers [1] for
TLS 1.3 key exchange algorithm support. As part of this effort (motivation:
measuring post-quantum readiness), we also send empty or unknown keyshare
in the Cl
Eric Rescorla writes:
> It's important to distinguish between two senses of the word "recommend".
I'd expect the first wave of proposals to be asking the WG to say
Recommended=Y for various curve+PQ hybrids.
There will be an annoyingly large number of options on the PQ side---for
example, for dif
On Fri, Jun 7, 2024 at 6:34 PM Syed Suleman Ahmad
>
> So far we have seen that HRR incompatibility is NOT related to the choice
> of keyshare, or whether the first Client Hello fits in a single packet or
> not. It is simply lack of HRR support.
>
While the aggregate stats are good to check, what
25 matches
Mail list logo
