Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

The points brought up in this thread have already been discussed, after which the chairs decided there was rough consensus to deprecate FFDHE and RSA and moved the document to WGLC. In particular, Hubert suggested last December to add a warning that FFDHE should be preferred over RSA, even though t

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

> Telling people that they shouldn't use the only things they can use means that the advice is unactionable, thus will be ignored. Yep, that's precisely what people are suggesting. If someone has a legacy system that cannot be upgraded, or they need to interface with such systems, they can ignore

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

> the latter is basically unexploitable with properly behaving hosts in TLSv1.2 Well, right, that's the trick. The issue that people have pointed out with FFDHE is that it's very easy to have a host that is not properly behaving (see RFC 7919, which is referenced in our draft). On Wed, Dec 21,

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

Sounds good, thanks! On Mon, Dec 19, 2022 at 3:46 PM Rob Sayre wrote: > On Mon, Dec 19, 2022 at 2:52 PM Martin Thomson wrote: > >> On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote: >> >> You might need to clarify that TLS 1.1 and earlier are wholly >> depr

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

> You might need to clarify that TLS 1.1 and earlier are wholly deprecated though, just to be sure. We do mention that in the body of the document. Are you suggesting that we also add that to the abstract and intro? On Sun, Dec 18, 2022 at 2:55 AM Martin Thomson wrote: > On Sun, Dec 18, 2022, a

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

ersion > number) is not mentioned in the doc title, in the abstract or in the > introduction. > > > > Thanks, > > Yaron > > > > *From: *TLS on behalf of Carrick Bartle < > cbartle...@gmail.com> > *Date: *Thursday, 15 December 2022 a

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

The fact that there are long product lifecycles makes the case for deprecation rather than against it. Imagine that we do not deprecate DHE. That means that next year, someone will be fully within the standard to create a long-lived product that uses DHE with TLS 1.2 and nothing more secure than th

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

ely based on the inability to negotiate groups. On Thu, Dec 15, 2022 at 4:26 PM Peter Gutmann wrote: > Carrick Bartle writes: > > >In the situation you've described, they've been told they shouldn't use > RSA > >either, so clearly it doesn't matter to

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

In the situation you've described, they've been told they shouldn't use RSA either, so clearly it doesn't matter to them what we've deprecated or not. We should deprecate insecure algorithms; the fact that there's a spectrum of insecurity among deprecated algorithms does not detract from the fact t

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

> Wouldn’t be the first case an RFC gets misinterpreted. I don't think the IETF's decisions should be dictated by the risk that someone might potentially misread their documents. That's always a risk. Someone might misread RFC 8446 as saying "use SSL 3.0 only." Does that mean the IETF shouldn't pu

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

> I certainly am, especially given that there are no security reasons driving it. Could you describe your reasoning behind this statement? From my read, supporters of deprecation have made it pretty clear that the motivation behind deprecating DHE is security considerations: there is no way to sec

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

Hi David, My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is out of scope for this document. Carrick On Tue, Dec 13, 2022 at 10:06 AM David Benjamin wrote: > Small clarification question: is this about just FFDHE in TLS 1.2, i.e. > the TLS_DHE_* cipher suites, or a

Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

> NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange. > > > Yes, but this has no bearing on why it's deprecated. +1. The PQ KEMs aren't relevant here. > On Mar 2, 2022, at 10:31 AM, David Benjamin wrote: > > On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 -

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

Sorry, I'm not sure what you mean? > On Aug 28, 2021, at 6:20 PM, Rob Sayre wrote: > > On Sat, Aug 28, 2021 at 5:29 PM Carrick Bartle <mailto:cbartle...@icloud.com>> wrote: > All the ciphersuites mentioned in the draft under discussion are already > listed as

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

In the revision of this draft (https://tools.ietf.org/pdf/draft-bartle-tls-deprecate-ffdh-00.pdf), which was unfortunately not the revision sent out on this call for adoption, we cite invalid curve attacks as a reason to advise against ECDH: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10

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

All the ciphersuites mentioned in the draft under discussion are already listed as not recommended because they don't offer forward secrecy. > On Aug 27, 2021, at 11:01 AM, Rob Sayre wrote: > > On Fri, Aug 27, 2021 at 9:42 AM Filippo Valsorda > wrote: > > If a co

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

> > which is a main reason cited for deprecating RSA in > > draft-aviram-tls-deprecate-obsolete-kex. > > Have the authors look at Post-Quantum KEMs? I'm not sure why PQ KEMs are relevant here. > On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL > wrote: > > > Regardless of th

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

I've submitted a PR that addresses this issue: https://github.com/vasilvv/tls-cross-sni-resumption/pull/3 <https://github.com/vasilvv/tls-cross-sni-resumption/pull/3> In general though, I support publication of this draft. > On Aug 11, 2021, at 3:50 PM, Carrick Bartle > wro

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

SNI," ideally with a reference to the current best practice of how to do that. > On Aug 11, 2021, at 3:25 PM, David Benjamin wrote: > > On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle <mailto:cbartle...@icloud.com>> wrote: >> - Ticket-based PSKs carry over the se

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

ring the initial handshake also applies to the PSK? Because, AFAICT, the literal ticket isn't required to contain the server certificate. > On Aug 11, 2021, at 2:13 PM, David Benjamin wrote: > > On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle > mailto:40icloud@dmarc.ietf.org&g

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

> Notably, it still relies on the server certificate being re-validated > against the new SNI at the > session resumption time. Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.) > However, in the absence of additional signals, it discourages using a > session tick

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

I support adoption. > On Jul 29, 2021, at 2:50 PM, Joseph Salowey wrote: > > This is a working group call for adoption of Deprecating Obsolete Key > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00 >

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

I've posted a revision here: https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/ <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdh/> > On Jul 30, 2021, at 11:56 AM, Carrick Bartle > wrote: > > Sorry, the title will be changed in the next

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one? Either way, I would support deprecating FFDHE completely. > On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni wrote: > > On Fri, Jul 30, 2021 at 07:30:31PM +, Scott Fluhrer (

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

Hi Martin, Actually, a clarification question (more relevant to the other thread : are you opposed to fully deprecating FFDHE? If so, why? > On Jul 29, 2021, a

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

Sorry, the title will be changed in the next version, which I'll be posting as soon as possible. You are correct about the scope of the work. > On Jul 29, 2021, at 5:41 PM, Martin Thomson wrote: > > I support the *contents* of this document. The title, however, I can't agree > to. So I want

Re: [TLS] Editorial: chronological order in ECH draft

e disappointed if any restructuring were > > limited to just getting the time sequence straightened out. > > > > On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote: > >> Hi all, > >> > >> I'm bringing > >> https://github.com/tl

Re: [TLS] Editorial: chronological order in ECH draft

se a scattered piecemeal throughout. So I would be > disappointed if any restructuring were limited to just getting the time > sequence straightened out. > > On Thu, Jun 24, 2021, at 09:04, Carrick Bartle wrote: >> Hi all, >> >> I'm bringing https://github

[TLS] Editorial: chronological order in ECH draft

Hi all, I'm bringing https://github.com/tlswg/draft-ietf-tls-esni/issues/412 to the list since it looks like we're (hopefully) getting close to the end game with ECH. The ECH draft is currently organized such that it describes all client behavior and then all server behavior. Personally, I fin

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

: > > On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote: >>> I'm not sure what you are implying might be impossible. Are you suggesting >>> that it might be impossible to get a name for which you could get a >>> certificate? >> >> No. I'm

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

7;m likely not the right person to ask - I'd guess that > the people who might have a use-case for this are smaller > hosters where the default listener on 443 is very minimal. I > don't know how common those are, but I'd suspect they are > fairly rare. And likely those wit

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

ertificate, ECH won't be possible in cases where the client-facing server doesn't have a name. > On Apr 20, 2021, at 6:40 PM, Martin Thomson wrote: > > On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote: >> This does sound unusual. That said, if this sort of set-up i

Re: [TLS] Authenticating the client-facing server with an IP-based certificate

> we're talking about a host that fronts for multiple different names, so I'm > finding it hard to imagine how finding a name usable for this purpose would > be challenging. This does sound unusual. That said, if this sort of set-up is possible (which presumably it is), it seems unfortunate to

Re: [TLS] Don't Split HelloRetryRequest

> I absolutely agree both that we seem to be almost > happily adding complexity I don't think you have to assume bad intent (or negligence). Several people brought up valid concerns and we're trying to address them. > On Apr 1, 2021, at 4:46 AM, Stephen Farrell wrote: > > > I'm not sure I ag

Re: [TLS] draft-les-white-tls-preferred-pronouns

Thank you! > On Apr 1, 2021, at 11:13 AM, Lars Eggert wrote: > > The Internet Engineering Task Force (IETF) prides itself on its open > philosophy, where anyone can submit a proposal or comment on work in > progress, regardless of financial resources, industry credentials, race, > gender, sex

Re: [TLS] Solving HRR woes in ECH

That sounds cool. > On Mar 25, 2021, at 6:28 PM, Nick Sullivan > wrote: > > Hi Chris, > > HRR in ECH does seem challenging. This may be tangential to the PR you > linked, but there may be a way to reduce the likelihood of HRR by moving even > more of the handshake negotiation into DNS. The H

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

> Which is not nearly as strong as "MUST NOT", which is what I take > deprecation to mean. Am I wrong about the intended meaning of > "deprecation"? That's my understanding as well. > On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni wrote: > > On Tue

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Oh, never mind, presumably you're referring to the proposal in this thread. > On Mar 9, 2021, at 4:47 PM, Carrick Bartle > wrote: > >> The proposal on the table is to deprecate FFDHE. > > Sorry, the title of the document is incorrect and will be changed. The ac

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote: > >>> Because there are still many TLS (non-web) implementations that don't >>> do ECDHE. >> >> I'm confused: if those implementations don't do ECDHE, what's wrong >> w

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

x27;t do ECDHE, what's wrong with prohibiting the way it's used? >* In practice security improves more when you raise the ceiling, > rather the floor. This sort of suggests that we should never deprecate anything, ever, no? > On Mar 8, 2021, at 7:57 PM, Viktor Dukho

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

> I think the blanket prohibition of reuse of ECDHE keys is maybe not really > justified. Why is that? > IMO that's the part that should have deprecation of RSA cipher suites done at > the same time. RSA seems to me to be too off-topic for this draft. (It also seems to me that RSA is still to

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

;The most straightforward mitigation > against the attack is to remove support for TLS-DH(E) entirely, as most major > client implementations have already stopped supporting them" > > On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle <mailto:cbartle...@icloud.com>> wrote:

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

ps.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 >> https://weakdh.org/ >> >> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle >> wrote: >>> Agreed. I'll change the title to reflect

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a draft, I'll remove all mention of 1.0/1.1. > On Mar 8, 2021, at 8:34 AM, John Mattsson > wrote: > > +1 for forbidding more old crap. > > Lack of forward secrecy should imply at least NOT RECOMMENDED. > > Does it make

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Agreed. I'll change the title to reflect that. > On Mar 8, 2021, at 7:33 AM, Martin Thomson wrote: > > Well overdue. We should do this. > > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the > document content. I only see static or semi-static DH and ECDH key excha

Re: [TLS] Moving the ECH interop target

Fine by me. > On Feb 24, 2021, at 10:07 AM, Christopher Wood wrote: > > The WG previously decided to make draft-ietf-tls-esni-09 the official target > for interop. The diff between this version and the current editor's copy of > the draft is below: > > > https://tools.ietf.org/rfcdiff?url1

Re: [TLS] [ECH] Reverting the config ID change

han > > On Wed, 17 Feb 2021 at 17:41, Carrick Bartle <mailto:cbartle...@icloud.com>> wrote: > Numerous ways a client can "stick out" have been identified, to the point > where it's trivial to block connections using real ECH, regardless of the > length of th

Re: [TLS] [ECH] Reverting the config ID change

Numerous ways a client can "stick out" have been identified, to the point where it's trivial to block connections using real ECH, regardless of the length of the config_id, which was why I thought we'd largely dropped the attempt not to stick out. > On Feb 17, 2021, at 8:35 AM, Jonathan Hoyla

Re: [TLS] [ECH] Reverting the config ID change

onger config_id is, in all cases, a major privacy trade-off. > On Feb 16, 2021, at 4:34 PM, Eric Rescorla wrote: > > > > On Tue, Feb 16, 2021 at 4:21 PM Carrick Bartle <mailto:cbartle...@icloud.com>> wrote: >> It's not significant extra complexity to hav

Re: [TLS] [ECH] Reverting the config ID change

> It's not significant extra complexity to have this field bigger and it > basically makes it impossible to have any structure. What do you mean by structure? How does a byte not provide sufficient "structure"? > On Feb 16, 2021, at 3:33 PM, Eric Rescorla wrote: > > > > On Tue, Feb 16, 2

Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

I also support adoption. > On Dec 3, 2020, at 4:17 PM, David Schinazi wrote: > > I support adoption of draft-vvv-tls-cross-sni-resumption. > > David > > On Thu, Dec 3, 2020 at 1:49 PM Salz, Rich > wrote: > > > Hmmm... I think it probably goes in this d

Re: [TLS] TLS WG GitHub interaction

I support this proposal. GitHub offers a lot more tools for organization than emails do, which makes reviewing issues considerably easier. > On Oct 21, 2020, at 3:51 PM, Christopher Wood wrote: > > RFC 8874 describes several different methods for using GitHub, ranging from > the lightweight "

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

> applications that can afford the CPU a) Not all applications can afford the CPU b) It's not just about CPU; there are use cases where bandwidth is also an issue. > On Sep 29, 2020, at 5:29 PM, Watson Ladd wrote: > > On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL > mailto:u

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

That’s good for them. Does this imply that the TLS group > also needs to make the same decision? > > Ciao > Hannes > > From: Carrick Bartle > Sent: Monday, September 21, 2020 6:19 PM > To: Hannes Tschofenig > Cc: Carrick Bartle ; Filippo Valsorda > ; tls@ietf.

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

> Ciao > Hannes > > From: TLS On Behalf Of Carrick Bartle > Sent: Monday, September 21, 2020 5:31 AM > To: Filippo Valsorda > Cc: tls@ietf.org > Subject: Re: [TLS] The future of external PSK in TLS 1.3 > > I'm also fine with marking psk_ke as not recommended to be

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

I'm also fine with marking psk_ke as not recommended to be consistent with the non-PFS ciphers, but there are plenty of valid use cases that justify keeping dhe_psk_ke as recommended for external PSKs. Several of these use cases are detailed in draft-ietf-tls-external-psk-guidance-00. > On Se

Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

Cool, I'll propose some text in the cases you mentioned. > On Aug 20, 2020, at 6:10 AM, Christopher Wood wrote: > > On Wed, Aug 19, 2020, at 6:42 PM, Carrick Bartle wrote: >> Thanks for the feedback! I've posted a bunch of PRs and issues, as >> you've

Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00

t >> diminish the entropy of the PSK? Why is it not sufficient to put that >> sort of information in the identity? > > It is probably desirable to use the identity for this purpose since, well, > its application-specific identifying information. This is just commenting on > th

Re: [TLS] Possible blocking of Encrypted SNI extension in China

Weird. Thanks for the update. How are you confirming that it's blocked from inside-out? > On Aug 13, 2020, at 10:30 AM, David Fifield wrote: > > On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote: >> Most of the functions of the Great Firewall work bidirectionally, and >> the ESNI

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

> I gtend to start with the abstract: "TLS allows > client/server applications to communicate over the > Internet in a way that is designed to prevent > eavesdropping, tampering, and message forgery." It seems clear that TLS proxies obey the letter, if not the spirit, of that statement. However

[TLS] Review of draft-ietf-tls-external-psk-guidance-00

Hi everyone, A few thoughts on draft-ietf-tls-external-psk-guidance-00: Isn’t the rerouting attack described in Section 4 not possible if "A" uses the SNI extension and "C" aborts the connection on mismatch? If so, it might be worth mentioning that as a potential mitigation (as the Selfie paper

Re: [TLS] Bikeshedding ECHO

I agree that it’s misleading and potentially confusing to newcomers. ETCH sounds like a good alternative. > On May 11, 2020, at 3:52 PM, Nick Harper > wrote: > > I see how the name ECHO can be confusing and support renaming it. All of the > proposed replacement names are fine with me. > >

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

No. > On Mar 4, 2020, at 8:06 AM, Sean Turner wrote: > > one more time ... > > All, > > The purpose of this message is to help the chairs judge consensus on the way > forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the > client-initiated ticket request mechanism [0] s

Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

No. > On Mar 4, 2020, at 8:06 AM, Sean Turner wrote: > > one more time ... > > All, > > The purpose of this message is to help the chairs judge consensus on the way > forward for draft-ietf-tls-ticketrequests. The issue at hand is whether the > client-initiated ticket request mechanism [0] s

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

> I agree with Watson's reasoning. Same. > On Feb 21, 2020, at 2:22 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > > I agree with Watson's reasoning. > > We know now all we need to to start working on generic mechanisms. > > Regards, > Uri > > Sent from my iPhone > >> On Feb 21, 2020, at 1

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

sues in the document, if you find anything else, we'll happily > look at those too. > > Nick > > On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle > mailto:40icloud@dmarc.ietf.org>> > wrote: > TL;DR: I find it difficult to understand the second-to-last paragrap

Re: [TLS] Call for Adoption: draft-stebila-tls-hybrid-design

I also support adoption of this draft. The concerns raised in the other thread on this topic ([TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design) are irrelevant within the context of adopting an informational draft, as it would be a "timely publication" of "general infor

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

TL;DR: I find it difficult to understand the second-to-last paragraph of the Introduction, so I took a stab at revising it. Let me know if I should put it in a pull request. This is the paragraph I'm referring to: "These dependencies cause problems in practice. Server operators often want to

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

> At a high level, I think that this would be easier if it were more clearly > framed as *recommendations* I'm brand new to the IETF, so please forgive me if I'm totally off base here, but my understanding is that Informational RFCs are explicitly not recommendations (let alone mandates)? Per