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.

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

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,

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

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,

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

* 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 reasoning? > > Which p

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

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

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

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

r implementations 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

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

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

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

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