[TLS]Resumption vs. RFC6066 maximum_fragment_length

[Viktor Dukhovni]

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 still support MFL, and
there is some history of completeness/correctness issues.  One
particular aspect of the specification seems unclear to me.

https://datatracker.ietf.org/doc/html/rfc6066#section-4
...
   The negotiated length applies for the duration of the session
   including session resumptions.
...

It seems to me that as a consequence:

- The initially negotiated value is implicitly still in force
  after resumption, even if (or especially if) the resumption
  ClientHello does not include the MFL extension.

- However, it is unclear whether the client is permitted to
  attempt to negotiate a new value as part of resumption, or what
  happens if the server does not "accept" the new value.

The current OpenSSL implementation (module some nits I'm reviewing fixes
for) *requires* the client to repeat an identical MFL extension during
resumption, if one was successfully negotiated initially.

I personally don't read the quoted terse text from RFC6066 to preclude
renegotiation of the MFL on resumption.  It seems more like "good till
revised" rather than "immutable" to me.  A server might therefore be
willing to:

- Accept a new value from the client, without aborting the handshake
  if it does not match the original choice.

- Decline a new proposed value, and thereby let the original stand.

Is there any sort of "consensus" interpretation of MFL vs. resumption?

- Is stuttering the original choice verbatim a hard requirement?
- Is the client allowed to skip sending MFL on resumption?
- MUST the server abort handshakes on resumption MFL mismatch?

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: HRR support (was something else)

[Martin Thomson]

On Thu, Jun 6, 2024, at 23:21, Nick Harper wrote:
> On Wed, Jun 5, 2024 at 6:25 AM Peter Gutmann  
> wrote:
>> There are embedded TLS 1.3 implementations [*] that, presumably for space/
>> complexity reasons and possibly also for attack surface reduction, only
>> support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.
>
> Those implementations are not compliant with RFC 8446. 

Yes.  You might reasonably rely on the MTI algorithm being supported, but you 
cannot rely on the ClientHello containing a key share for that algorithm.

Put differently, you might be able to get away with not implementing HRR if you 
only talk to a known set of peers who always send you key shares that you 
understand.  That's not the same as interoperably implementing TLS 1.3.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: HRR support (was something else)

[Nick Harper]

On Wed, Jun 5, 2024 at 6:25 AM Peter Gutmann 
wrote:

> Martin Thomson  writes:
>
> >Are you saying that there are TLS 1.3 implementations out there that don't
> >send HRR when they should?
>
> There are embedded TLS 1.3 implementations [*] that, presumably for space/
> complexity reasons and possibly also for attack surface reduction, only
> support the MTI algorithms (AES, SHA-2, P256) and don't do HRR.
>

Those implementations are not compliant with RFC 8446. Section 4.1.1
requires that a server respond with HRR if it selects an (EC)DHE group and
the client didn't offer a compatible key_share in the initial ClientHello.
(Likewise, section 4.1.3 requires that clients support HRR.)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

[David Benjamin]

Regarding 1343, the PR is a rule on the sender, not the receiver. After
all, it says "The sender MUST NOT". It is not a rule on the receiver.

We have interop problems *today* when one side sends too many KeyUpdates,
triggered by data received. The PR does not ask receivers to enforce
stuff, but (mostly) prevents senders from tripping receiver DoS limits and
thus causing an interop problem.

I say mostly because the scenario you mention is a good one. I hadn't
thought of that. But that scenario is not an interop problem introduced by
1343. It's a scenario that 1343 doesn't fully solve, but* still
dramatically improves*. Prior to 1343, a server with a buggy
update_requested policy would send 3GB / 16K = 196,608 KeyUpdates for every
4 GB of data sent by the client, assuming full records. This will very,
very easily trip DoS limits and quickly cause the connection to fail.

1343 clarifies that this update_requested policy is wrong sender behavior.
You're right that 1343 doesn't completely solve the problem. The server
will misinterpret the client's own KeyUpdates as response and send 1
KeyUpdate for every 4 GB of data. That is, however, an improvement by a
factor of 196,608x. It would take a lot more traffic to trip a DoS limit
under that scenario. Ideally we'd come up with an even better sender rule,
but I suspect we cannot do so without completely redesigning
updated_requested. During TLS 1.3's development, my position was that
update_requested was a mistake and we should remove it, precisely due to
its propensity for DoS and interop problems. I think that position has
proven to be the right one, but it's too late to remove the feature now.
1343 is the best option I see to fix it right now.

On Thu, Jun 6, 2024 at 1:46 PM Kyle Nekritz  wrote:

> I object to 1343 because I don't think it can be implemented without
> risking interop problems. There is nothing tying a KeyUpdate response to
> the KeyUpdate that requested it, or distinguishing it from an unrelated
> KeyUpdate. As an example of how this can cause practical problems, say we
> have two peers with the following policies:
>
> Client: sends KeyUpdate with update_not_requested every 4GB of data sent
> (which is a reasonable policy, effectively making sure the client doesn't
> violate its own data limits, and letting the peer handle theirs)
> Server: sends a KeyUpdate with update_requested every 1GB of data sent by
> either peer (similar to the motivating example in the issue)
>
> If, like in the example in the issue, the client is sending a large amount
> of data, and not reading anything from the server until it's done, and the
> server isn't sending any response application data, the server will send an
> update_requested KeyUpdate after 1GB of data from the client. The server
> will then be blocked from sending more KeyUpdates due to the proposed
> requirement. However once the client sends 4GB of data, it will send an
> update_not_requested KeyUpdate. To the server, this will appear to be a
> response to it's KeyUpdate request, and it will be free to send another
> update_requested KeyUpdate. However, to the client, this will appear as a
> redundant KeyUpdate, since the KeyUpdate it sent wasn't actually in
> response to the server's first KeyUpdate. If the client enforces the MUST
> NOT added in the PR, this will cause a failure.
>
> -Original Message-
> From: Sean Turner 
> Sent: Monday, June 3, 2024 11:38 AM
> To: TLS List 
> Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345
>
> !---|
>   This Message Is From an External Sender
>
> |---!
>
> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been
> submitted (and discussed) that include changes to normative language:
>
> - #1343: Forbid the sender from sending redundant update_requested
> KeyUpdates
> https://github.com/tlswg/tls13-spec/pull/1343
>
> - #1345: Forbid the sender from sending duplicate supported groups entries
> https://github.com/tlswg/tls13-spec/pull/1354
>
> The discussion so far seems to support consensus to merge these PRs. If
> you object, please do so on the issue or in response to this message.
> Absent any pushback, we will direct the editors to incorporate them in two
> weeks' time.
>
> Cheers,
> spt
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

[Kyle Nekritz]

I object to 1343 because I don't think it can be implemented without risking 
interop problems. There is nothing tying a KeyUpdate response to the KeyUpdate 
that requested it, or distinguishing it from an unrelated KeyUpdate. As an 
example of how this can cause practical problems, say we have two peers with 
the following policies:

Client: sends KeyUpdate with update_not_requested every 4GB of data sent (which 
is a reasonable policy, effectively making sure the client doesn't violate its 
own data limits, and letting the peer handle theirs)
Server: sends a KeyUpdate with update_requested every 1GB of data sent by 
either peer (similar to the motivating example in the issue)

If, like in the example in the issue, the client is sending a large amount of 
data, and not reading anything from the server until it's done, and the server 
isn't sending any response application data, the server will send an 
update_requested KeyUpdate after 1GB of data from the client. The server will 
then be blocked from sending more KeyUpdates due to the proposed requirement. 
However once the client sends 4GB of data, it will send an update_not_requested 
KeyUpdate. To the server, this will appear to be a response to it's KeyUpdate 
request, and it will be free to send another update_requested KeyUpdate. 
However, to the client, this will appear as a redundant KeyUpdate, since the 
KeyUpdate it sent wasn't actually in response to the server's first KeyUpdate. 
If the client enforces the MUST NOT added in the PR, this will cause a failure.

-Original Message-
From: Sean Turner  
Sent: Monday, June 3, 2024 11:38 AM
To: TLS List 
Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345

!---|
  This Message Is From an External Sender

|---!

Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been 
submitted (and discussed) that include changes to normative language:

- #1343: Forbid the sender from sending redundant update_requested KeyUpdates
https://github.com/tlswg/tls13-spec/pull/1343

- #1345: Forbid the sender from sending duplicate supported groups entries
https://github.com/tlswg/tls13-spec/pull/1354

The discussion so far seems to support consensus to merge these PRs. If you 
object, please do so on the issue or in response to this message.  Absent any 
pushback, we will direct the editors to incorporate them in two weeks' time.

Cheers,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[John Mattsson]

Hubert Kario wrote:
>Because NIST is a trend-setter, many other compliance organisations reuse 
>those curves
>(French ANSSI, German BSI, Japanese IPA, etc.).

I think IETF is also a very strong trend-setter among governments. Other 
governments follow NIST when they think NIST is doing a good job or when NIST 
algorithms is what is available on the market. They do the same with CFRG 
algorithms.

Dutch NCSC recommends secp384r1, secp256r1, curve448, and curve25519
https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1

French ANSSI recommends NIST P-curves but also approves X25519 X448 and 
Brainpool
file:///Users/emanjon/Downloads/anssi-guide-recommandations_de_securite_relatives_a_tls-v1.2.pdf

Japanese IPA recommends both P-256 and X25519
https://www.ipa.go.jp/security/crypto/guideline/gmcbt8005ufv-att/ipa-cryptrec-gl-3001-3.0.1.pdf

German BSI recommends Brainpool and writes that NIST P-curves can be used if 
Brainpool curves are not available.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=6

China recommends SM2 and Russia recommends GOST.

Government recommendations are not always suitable for industry. For military 
and government use cases performance and monetary costs are low priority. For 
many industry use cases performance and monetary costs are very important 
priorities that also affect security. If ephemeral key exchange is slow, the 
answer is often to use less ephemeral key exchange instead of decreasing 
performance.

I think it would make sense to make both P-256 and X25519 MTI. I think forcing 
any key shares in CH is wrong. I also think registering hybrids as code points 
is wrong. If TLS did the right thing like IKEv2 we would just need to register 
ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as “groups” and everybody would be 
happy because there favorite standalone of hybrid would be supported. If the 
Web want to use a single hybrid I think that should be discussed in W3C.

Cheers,
John Preuß Mattsson

From: Hubert Kario 
Date: Thursday, 6 June 2024 at 12:37
To: D. J. Bernstein 
Cc: tls@ietf.org 
Subject: [TLS]Re: Curve-popularity data?
On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:
> Andrei Popov writes:
>> I support this change, willing to implement it in the Windows TLS
>> stack. We have thousands of customers concerned about increased
>> latencies due to the enablement of TLS 1.3. The services they connect
>> to require NIST curves and HRR is required to get TLS clients to send
>> appropriate key shares.
>
> To clarify, when you say "require NIST curves", do you mean "require
> conformance with NIST SP 800-56A"?

really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.

> In other words, will another curve be allowed once it's added to NIST
> SP 800-56A? Maybe faster: would the short-term problem be addressed if
> we can convince NIST to announce that it will consider X25519 and X448
> for a revision of SP 800-56A, and doesn't intend to enforce conformance
> of cryptographic modules with SP 800-56A until the revisions are done?

Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.

> Or are you saying that, independently of NIST's decisions, the services
> in question are for some reason specifically requiring what's typically
> called the "NIST curves", namely the fifteen NSA curves that NIST
> standardized? Or the subset of those that NIST hasn't deprecated yet?

Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.).
Similarly
Common Criteria certifications, while they're international, they're
similarly
heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.

And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.

So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
and
P-384).

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjoh

[TLS]Re: Curve-popularity data?

[Ilari Liusvaara]

On Thu, Jun 06, 2024 at 12:36:28PM +0200, Hubert Kario wrote:
> 
> So, while I'd love to see x25519 in governmental standards, I think it's
> better to spend energy making sure that we deploy ML-KEM as soon as
> possible,
> in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256
> and
> P-384).

I think a good initial set of hybrids would be:

- x25519+mlkem768
- x448+mlmem1024
- p256+mlkem768
- p384+mlkem1024




-Ilari

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[A A]

On my computer (Windows 10 LTSC 2021 x64), run openssl in a Debian 12 VM user@debian:~$ openssl speed ecdhp256Doing 256 bits  ecdh's for 10s: 236351 256-bits ECDH ops in 10.13sversion: 3.0.11built on: Mon Oct 23 17:52:22 2023 UTCoptions: bn(64,64)compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/reproducible-path/openssl-3.0.11=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2CPUINFO: OPENSSL_ia32cap=0xfffa32234f8b:0x9840079c219c27eb  op  op/s 256 bits ecdh (nistp256)   0.s  23331.8 user@debian:~$ openssl speed ecdhx25519Doing 253 bits  ecdh's for 10s: 389226 253-bits ECDH ops in 10.12sversion: 3.0.11built on: Mon Oct 23 17:52:22 2023 UTCoptions: bn(64,64)compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/reproducible-path/openssl-3.0.11=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2CPUINFO: OPENSSL_ia32cap=0xfffa32234f8b:0x9840079c219c27eb  op  op/s 253 bits ecdh (X25519)   0.s  38461.106.06.2024, 18:22, "Hubert Kario" :On Thursday, 6 June 2024 00:57:52 CEST, A A wrote: "E.g. a client might also have legitimate reasons to nudge  servers to use a stronger curve than P-256 in the initial CH and  only fall back to weaker curves by explicit request via HRR.  Probably the reason for Chrome for requesting HRR for P-256 is  the attempt to nudge servers to use an algorithm which is  believed to provide advantages for the client-side  implementation (possibly both, speed/power or security or  bandwidth) in comparison to P-256."   About speed: https://bench.cr.yp.to/results-dh.html shows that  on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz;  hertz, supercop-20240425,   nistp256(P-256) needs 202616 cycles to generate a key pair,  535274 cycles to compute a shared secret; Curve25519 needs 101289cycles to generate a key pair, 109491  cycles to compute a shared secret;   And, X25519's key share only need 32 bytes, P-256 needs 65  bytes. Conclusion: P-256 neither has security nor performance  (power) advantage compare with X25519.That's not the performance delta I see in practice.Fedora 39, openssl-3.1.1-4.fc39.x86_64, i7-10850Hx25519 derive shared secret: 35062.2 op/sP-256 derive shared secret: 22741.1 op/s(run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself) 05.06.2024, 22:05, "Björn Haase"  : Hi Eric, Hi all,One more thing: we are finalizing RFC 8446-bis right now, so if there isWG consensus to require that clients offer all MTI curves in the key_sharesof their initial CH, then that would be a straightforward text change.  I think that we might rather keep a mechanism that preserves  the possibility of the client-side to express a preference  regarding a specific cipher suite / curve and accept other  curves only using the HRR-mechanism. E.g. a client might also have legitimate reasons to nudge  servers to use a stronger curve than P-256 in the initial CH and  only fall back to weaker curves by explicit request via HRR.  Probably the reason for Chrome for requesting HRR for P-256 is  the attempt to nudge servers to use an algorithm which is  believed to provide advantages for the client-side  implementation (possibly both, speed/power or security or  bandwidth) in comparison to P-256. Björn. Mit freundlichen Grüßen | Best Regards Dr. Björn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Liquid Analysis Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839  Gerlingen | Germany Phone: +49 7156 209 10377 bjoern.ha...@endress.com | www.ehla.endress.com  Endress+Hauser Conducta GmbH+Co.KG Amtsgericht Stuttgart HRA 201908 Sitz der Gesellschaft: Gerlingen Persönlich haftende Gesellschafterin: Endress+Hauser Conducta Verwaltungsgesellschaft mbH Sitz der Gesellschaft: Gerlingen Amtsgericht Stuttgart HRA 201929 Geschäftsführer: Dr. Manfred Jagiella Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu  informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.   Disclaimer: The information transmitted is intended only for the person or  entity to which it is addressed and may contain confidential,  proprietary, and/or privileged material. Any review, retransmission, dissemination or other  use of, or taking of any action in reliance upon, this  information by persons or entities other than the intended recipient is prohibited. If you receive  this in error, pleas

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Wednesday, 5 June 2024 22:00:44 CEST, D. J. Bernstein wrote:

Andrei Popov writes:

I support this change, willing to implement it in the Windows TLS
stack. We have thousands of customers concerned about increased
latencies due to the enablement of TLS 1.3. The services they connect
to require NIST curves and HRR is required to get TLS clients to send
appropriate key shares.


To clarify, when you say "require NIST curves", do you mean "require
conformance with NIST SP 800-56A"?


really depends on the deployment, some just want to use SP 800-56A curves,
some need actual, real, to the letter, legal compliance with FIPS 140-2 or
FIPS 140-3.


In other words, will another curve be allowed once it's added to NIST
SP 800-56A? Maybe faster: would the short-term problem be addressed if
we can convince NIST to announce that it will consider X25519 and X448
for a revision of SP 800-56A, and doesn't intend to enforce conformance
of cryptographic modules with SP 800-56A until the revisions are done?


Short-term problem won't be solved like that for everybody. For
deployments that require FIPS compliance, the implementation itself needs
to be certified. At this moment there's no way to get it certified, so we
are at least 2-3 years away from a certified implementation of x25519
being available even if NIST marked x25519 as approved tomorrow.


Or are you saying that, independently of NIST's decisions, the services
in question are for some reason specifically requiring what's typically
called the "NIST curves", namely the fifteen NSA curves that NIST
standardized? Or the subset of those that NIST hasn't deprecated yet?


Because NIST is a trend-setter, many other compliance organisations
reuse those curves (French ANSSI, German BSI, Japanese IPA, etc.). 
Similarly
Common Criteria certifications, while they're international, they're 
similarly

heavily influenced by what NIST and NSA recommends. All of them will have
a lot of inertia.

And to address what John Mattsson wrote in a separate email: yes, IETF is
international and should not be bound by particular government requirements
for IETF standards to be actually usable in practice, they do need to
take into account what governmental bodies require. What gets published
by IETF can be superset of what govs want.

So, while I'd love to see x25519 in governmental standards, I think it's
better to spend energy making sure that we deploy ML-KEM as soon as 
possible,
in hybrid mode, both with x25519 *and* NIST curves (at the very least P-256 
and

P-384).

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Curve-popularity data?

[Hubert Kario]

On Thursday, 6 June 2024 00:57:52 CEST, A A wrote:
"E.g. a client might also have legitimate reasons to nudge 
servers to use a stronger curve than P-256 in the initial CH and 
only fall back to weaker curves by explicit request via HRR. 
Probably the reason for Chrome for requesting HRR for P-256 is 
the attempt to nudge servers to use an algorithm which is 
believed to provide advantages for the client-side 
implementation (possibly both, speed/power or security or 
bandwidth) in comparison to P-256."
 
About speed: https://bench.cr.yp.to/results-dh.html shows that 
on amd64; Zen 4 (a60f12); 2023 AMD Ryzen 7 7700; 8 x 3800MHz; 
hertz, supercop-20240425,
 
nistp256(P-256) needs 202616 cycles to generate a key pair, 
535274 cycles to compute a shared secret;
Curve25519 needs 101289cycles to generate a key pair, 109491 
cycles to compute a shared secret;
 
And, X25519's key share only need 32 bytes, P-256 needs 65 
bytes. Conclusion: P-256 neither has security nor performance 
(power) advantage compare with X25519.


That's not the performance delta I see in practice.

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

(run `openssl speed ecdhp256; openssl speed ecdhx25519` to try yourself)



05.06.2024, 22:05, "Björn Haase" 
:

Hi Eric, Hi all,


One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change. 


I think that we might rather keep a mechanism that preserves 
the possibility of the client-side to express a preference 
regarding a specific cipher suite / curve and accept other 
curves only using the HRR-mechanism.


E.g. a client might also have legitimate reasons to nudge 
servers to use a stronger curve than P-256 in the initial CH and 
only fall back to weaker curves by explicit request via HRR. 
Probably the reason for Chrome for requesting HRR for P-256 is 
the attempt to nudge servers to use an algorithm which is 
believed to provide advantages for the client-side 
implementation (possibly both, speed/power or security or 
bandwidth) in comparison to P-256.


Björn.





Mit freundlichen Grüßen | Best Regards

Dr. Björn Haase

Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 
Gerlingen | Germany

Phone: +49 7156 209 10377
bjoern.ha...@endress.com | www.ehla.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu 
informieren, wenn wir personenbezogene Daten von Ihnen erheben.


Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

 


Disclaimer:

The information transmitted is intended only for the person or 
entity to which it is addressed and may contain confidential, 
proprietary, and/or privileged
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities
other than the intended recipient is prohibited. If you receive 
this in error, please contact the sender and delete the material 
from any computer.
This e-mail does not constitute a contract offer, a contract 
amendment, or an acceptance of a contract offer unless 
explicitly and conspicuously designated or stated as such.


 


,


--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?

[John Mattsson]

I agree with Richard that there is too much focus on NIST in this thread. The 
strength with IETF is that IETF does not follow any specific national 
regulation. It is impossible to follow all national regulations. That IETF uses 
a lot of of NIST algorithms is not because IETF has to, but because NIST 
algorithms typically are very good and selected in many yaer open projects with 
leading cryptographers from around the world. Similar to how X25519 and X448 
was selected by CFRG.

Cheers,
John

From: Blumenthal, Uri - 0553 - MITLL 
Date: Thursday, 6 June 2024 at 02:24
To: Richard Barnes , tls@ietf.org 
Subject: [TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?
NIST cannot prohibit a curve, or an algorithm. But they may not approve it – 
and for customers that require approved technology and algorithms, it would 
prevent them from using anything that’s not explicitly approved.

--
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.

 -  C. A. R. Hoare


From: Richard Barnes 
Date: Wednesday, June 5, 2024 at 20:20
To: tls@ietf.org 
Subject: [EXT] [TLS]Re: Is NIST actually prohibiting X25519?
As with the earlier thread, this message is off-topic for this list.   
Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves. On Wed, Jun 5, 2024 at 20: 14 D. J. Bernstein  
wrote: Andrei
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
As with the earlier thread, this message is off-topic for this list.

Regardless of what NIST does, the TLS protocol does and will support a variety 
of curves.


On Wed, Jun 5, 2024 at 20:14 D. J. Bernstein 
mailto:d...@cr.yp.to>> wrote:
Andrei Popov writes:
> This is a complicated compliance question. I'm not qualified to
> comment on this option.

I think it's worth investigating, considering the following NIST quote:

   Their associated key agreement schemes, X25519 and X448, will be
   considered for inclusion in a subsequent revision to SP 800-56A.  The
   CMVP does not intend to enforce compliance with SP 800-56A until
   these revisions are complete.

https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices

Does anyone have any documents showing that NIST has reneged on the
above announcement? Possibilities:

   * Yes: then I'd appreciate a pointer so that concerned members of the
 community can tell NIST what they think about this and, hopefully,
 get NIST to change course.

   * No: then the announcement and consistent handling of this by NIST
 would be another reason for IETF to not be dragged down by the
 current limitations of NIST SP 800-56A.

If nobody has ever tried asking NIST to approve an X25519 solution as
per the above announcement, surely that would be a useful experiment,
creating a path towards simplifying subsequent TLS WG discussions.

---D. J. Bernstein

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org