Re: [TLS] Require deterministic ECDSA

Strong support for this. TLS will be deployed with broken implementations and on broken systems. Anything the spec can do to limit or prevent damage is more than appropriate. However, agreed that a SHOULD makes more sense, to avoid having discussions about OpenSSL not being compliant because of a

Re: [TLS] Static DH timing attack

I feel like there should be nothing controversial in the context of TLS. * Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a MUST NOT, because they can't be implemented securely. * Reusing ephemeral shares for ECDHE and DHE ought to be a MUST NOT in all TLS versions, beca

Re: [TLS] Static DH timing attack

2020-09-12 05:48 GMT+02:00 Peter Gutmann : > Filippo Valsorda writes: > > >I feel like there should be nothing controversial in the context of TLS. > > > > Non-ephemeral FFDHE ciphersuites in TLS 1.0–1.2 (TLS_DH_*) ought to be a > > MUST NOT, because they

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-19 13:48 GMT+02:00 Peter Gutmann : > John Mattsson writes: > > >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and > >especially psk_ke are both marked as RECOMMENDED. If used in the initial > >handshake, both modes have severe privacy problems, > > PSK is used a

Re: [TLS] The future of external PSK in TLS 1.3

nes > > *From:* Carrick Bartle > *Sent:* Monday, September 21, 2020 6:19 PM > *To:* Hannes Tschofenig > *Cc:* Carrick Bartle ; Filippo > Valsorda ; tls@ietf.org > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > >> Can you justify your reasonin

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 12:02 GMT+02:00 Peter Gutmann : > Taking "SCADA/IoT/etc" to be a placeholder for M2M or more > generally "non-web use", [...] "The web" and "resource-constrained use cases which can't afford ECDH" feels like a false dichotomy, and it sounds unlikely that most M2M cases would fit the l

Re: [TLS] Recommending ALPN / backwards compatibility

2021-05-08 05:11 GMT-04:00 ml+ietf-...@esmtp.org : > On Fri, Apr 30, 2021, Martin Thomson wrote: > > An existing application protocol might not have been assigned an > > ALPN identifier. For other protocols the ALPN identifier might > > not have been part of the

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

(I am listed as author to one of the drafts, but haven't contributed significantly since suggesting the deprecation on the list, so I am going to renounce authorship and express my support for the adoption instead.) As a TLS implementer, I don't want the specs to tell me what is *technically po

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

2021-08-27 05:08 GMT+02:00 Joseph Salowey : > Thanks for all the discussion on this topic. There are several modes that > TLS 1.2 can operate with respect to DH. Below is a proposal on cases to > merge some of the cases covered by this draft into the obsolete keyex draft. > I'd like to see if

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

2021-08-27 15:13 GMT+02:00 Blumenthal, Uri - 0553 - MITLL : >> Thanks for all the discussion on this topic. There are several modes that >> TLS 1.2 can operate with respect to DH. Below is a proposal on cases to >> merge some of the cases covered by this draft into the obsolete keyex draft. >>

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

lementations doesn't show something is unsafe, I don't think there is progress to be made in the discussion. Blaming the implementers is not particularly interesting to me. Anyway, I don't have an opinion on SHOULD NOT vs MUST NOT, as long as it leads to Recommended: N in t

Re: [TLS] Flags Extension: why only for TLS 1.3?

2021-11-04 11:12 GMT-04:00 David Benjamin : > Indeed it's *because* there is still an existing 1.2 deployment that we > should be judicious with backports. Today, nearly every TLS implementation > needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it > is not possible for

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

This is excellent, especially the explicit decision to make concrete primitive choices, which allow the scheme to be both secure and efficient. I have an implementation at filippo.io/mlkem768/xwing which passes the test vectors in draft-connolly-cf

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

+1 to adoption. I found myself unsure of how many tickets to send in the new Go implementation, which is notoriously averse to configuration knobs, and would love to have the client pick. 2018-11-07 14:47 GMT+0700 Sean Turner : > At TLS@IETF103, there was consensus in the room to adopt draft-woo

Re: [TLS] TLS Impact on Network Security draft updated

Before any technical or wording feedback, I am confused as to the nature of this document. It does not seem to specify any protocol change or mechanism, and it does not even focus on solutions to move the web further. Instead, it looks like a well edited blog post, presenting the perspective of

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-12-12 06:51 GMT-05:00 Hubert Kario : > On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: > > On Wed, Dec 11, 2019 at 9:22 AM Ilari Liusvaara > > wrote: > > > >> On Wed, Dec 11, 2019 at 02:21:48PM +0100, Hubert Kario wrote: > >>> On Saturday, 7 December 2019 11:20:17 CET, Ilar

Re: [TLS] Bikeshedding ECHO

As a data point, I was fairly confused when ECHO came up in conversation, and had to stop to ask what it was. I think I would have had a better chance of figuring it out from context or search if it were called ECH, but don't have a strong preference for any specific name. ECH does have a remar

[TLS] Add max_early_data_size to TicketEarlyDataInfo

Hello, Cloudflare's current (not definitive) plan for 0-RTT is essentially to decide whether or not to answer to requests in the 0.5 flight on a case-by-case basis. That obviously requires reading all of them and caching the ones we don't want to answer. To mitigate the obvious DoS concern we pla

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

2016-10-07 22:06 GMT+ David Benjamin : > Units is a little interesting. For those purposes, this limit would > kick in whether or not the early data could be decrypted, so the server- > side limit would be measured in ciphertext, possibly even including > record headers. (Although any inaccurac

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I'm definitely for 1.3. I get where 4 is coming from, but 1.2 is not going anywhere soon, and we spent the last 10 years training people that the high-numbered one is bad, and that the 1.x ones are cool. I really don't want to have the following conversation, with the exact same people the propon

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

2024-04-15 20:14 GMT+02:00 Joseph Salowey : > Should the draft deprecate these ClientCertificateTypes and mark the entries > (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' > discouraged? Oh, yes. ___ TLS mailing list TLS@ietf.org

Re: [TLS] [EXT] Re: Deprecating Static DH certificates in the obsolete key exchange document

2024-04-21 23:26 GMT+02:00 Blumenthal, Uri - 0553 - MITLL : > I see two possibilities: > > 1. Nobody in the real world employs static DH anymore – in which case this > draft is useless/pointless; or > 2. On private networks people employ static DH to implicitly authenticate > their peers (a-l

[TLS]Re: Curve-popularity data?

I expect X25519 to be the most commonly *selected *(as opposed to supported) TLS key exchange on the open Internet, due to browsers preferring it for its marginal performance benefit. This is not a popularity contest though and that's not the most useful metric for choosing the ECC component of

[TLS]Re: Curve-popularity data?

2024-06-03 12:07 GMT+02:00 Martin Thomson : > Some numbers from our telemetry. This is purely connection-volume-based (so > sites with lots of connections will be over-represented), but overall fairly > stable. > > Key exchange: > ECDHE 99.21%, RSA 0.76%, ECDHE+KYBER: 0.03% > ECDHE curve: X25

[TLS]Re: Curve-popularity data?

2024-06-03 14:38 GMT+02:00 Bas Westerbaan : > We're not just a server, but also a client proxying requests to our > customer's origins. We routinely scan customer's origin servers for their > support of keyshares. [...] > > We also measure server support for each. (We send just the single keysha

[TLS]Re: Curve-popularity data?

2024-06-03 15:34 GMT+02:00 Bas Westerbaan : > More importantly, there are servers that will HRR to X25519 if presented a > P-256 keyshare. (Eg. BoringSSL's default behaviour.) Unfortunately I don't > have data at hand how often that happens. Are you saying that some of the 97.6% of servers that

[TLS]Re: Curve-popularity data?

2024-06-05 15:17 GMT+02:00 Peter Gutmann : > Nick Harper writes: > > >I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves > >be present in the key_share extension if that extension is non-empty. > > Just because it's possible to rules-lawyer your way around something does

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

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

[TLS] Re: MLKEM or Khyber KX

We (Go) also generate fresh keys for each handshake and would warmly welcome it being a MUST in the IETF specification of the ML-KEM TLS hybrids.___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

2025-01-07 14:16 GMT+01:00 John Mattsson : > Alicja Kario wrote: > >Can you point to examples of people actually using x448 (TLS group ID 30) in > >practice? > > I think that is the wrong question. If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I see no reason to

[TLS] Re: Disallowing reuse of ephemeral keys

I support some variation of 2 or 3, depending on what encounters the most resistance. I agree there is no technical reason to disallow it for e.g. X25519MLKEM768 and not X25519, but in practice it might be easier to set a new rule for something that's still being rolled out and still a draft. B

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

2024-12-07 18:36 GMT+01:00 Watson Ladd : > Having MLKEM without a hybrid as an option in TLS when the interoperable > choice is a hybrid is not going to exclude people. > > Furthermore we didn't hybridize x25519 and RSA. It's clear some people > believe ML-KEM is secure enough for their uses. A

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

2024-12-07 03:19 GMT+01:00 D. J. Bernstein : > Having a company influencing IETF decisions by making claims about what > customers are demanding---with no explanation of _why_ those demands are > being made, and no opportunity for IETF review of the merits of those > rationales---is exposing IETF t

[TLS] Re: Changing WG Mail List Reputation

2024-10-25 14:30 GMT+02:00 Sean Turner : > • Repetition of arguments without providing substantive new information > • Requesting an unreasonable amount of work to provide information Personally, the reason I find the list (and generally the IETF) unwelcoming is that arguments can easily prevail

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Joining the chorus to support adoption and a speedy path to WGLC. We have already shipped X25519MLKEM768 in Go 1.24.___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

I supported and support prohibiting key reuse, and seem to remember multiple other supporting voices not named John. My impression (which could be mistaken because these debates are really painful to keep track of) is actually that objections are in the rough, if we count From headers rather tha

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

I support adoption. I also would like to prohibit key reuse, but opposing adoption feels like a bad way to reach that outcome: if the document is published by the ISE or just lives on as a widely deployed draft, the WG will have no say in what requirements it has. It also seems clear to me the

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

2025-04-02 17:39 GMT+02:00 Salz, Rich : > Opposing adoption to force the document to be published in a way that can't > be "Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process. > > I am not aware of any of those opposed who are doing it for this reason. > Perhaps speculating