Re: [TLS] Working Group Last Call for SSLKEYLOG File
This document does a good job of documenting current practice, and hence I support (and my thanks to Martin for addressing an issue I communicated to him off-list). I think that timestamping and/or autosegmenting entries in the file format would be a useful extension (current implementations, such as Wireshark, need to linearly search through potentially large SSLKEYLOG files). Y(J)S (usually just lurking on this list) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption Call for draft-davidben-tls-key-share-prediction
I support adoption of this document. Y(J)S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS]Re: I-D Action: draft-ietf-tls-svcb-ech-04.txt
Bootstrapping is REALLY not appropriate, since this is not TLS with ECH enabling itself, but rather a DNS mechanism enabling ECH. But the document is ready for LC. Y(J)S -Original Message- From: Salz, Rich Sent: Tuesday, August 20, 2024 8:00 PM To: tls@ietf.org Subject: [TLS]Re: I-D Action: draft-ietf-tls-svcb-ech-04.txt I read the document [1]. I think it's ready for WGLC. I suggest one change. I find the use of "bootstrapping" in the title misleading. I suggest "Enabling TLS Encrypted ClientHello via DNS Service Bindings." [1] https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org CAUTION: This email originated from outside the organization. Do not follow guidance, click links or open attachments unless you recognize the sender and know the content is safe. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS
All, I fully support standardizing the SSLKEYLOGFILE Format. While it is a debugging tool, that doesn’t mean it doesn’t have to be standardized. Where I work we maintain a large set of protocol analysis tools used to verify correct operation of various programs, and document variant behaviors. This often requires visibility into the internal operation of various browsers and apps. So, while it is fine for some company’s program to output arbitrary debug files for their own development, this wouldn’t enable others to understand these files. The documentation really doesn’t have to be produced by the IETF, as long as everyone abides by it. But I don’t know of anywhere else with broad enough remit to mandate a behavior for all applications using TLS. Y(J)S From: Aaron Zauner Sent: Tuesday, February 25, 2025 12:27 AM To: Martin Thomson Cc: Bellebaum, Thomas ; tls@ietf.org Subject: [EXTERNAL] [TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS Hey, On Mon 24. Feb 2025 at 22:54, Martin Thomson mailto:m...@lowentropy.net>> wrote: On Tue, Feb 25, 2025, at 06:56, Aaron Zauner wrote: > To be clear; I agree with that in principle but have the feeling that > the discussion around an applicable threat model misses the issue of > what should be in IETF and what should be in development docs, > debugging tools etc entirely. I'm not currently working on maintaining > a crypto lib as many of you are but you can't honestly tell me it's not > possible to work on your end without IETF guidance on debug specifics > that allow encrypted traffic detail export -- which you already have in > place for debug and dev anyway. This also misses the point. The existence of this format (it will exist whether the IETF publishes a document or not) has enabled interoperation between a number of tools. The point of moving this work to the IETF was to transfer governance from what was ad hoc to something recognized and respected by the community of people who build the interoperating tools. Some people view interoperable standards as somehow changing the demand and availability of the thing they document. Maybe that's true in some markets, but my experience is that the demand is what causes the creation of standards, not the other way around. Also, if there were not already interoperation and you were concerned that interoperation would cause problems, this might be problematic, but this is a case where that interoperation already exists I understand your point and just like config formats I see why you'd want to have a published document. But just like with configs it's part of the local tool chain and not a wire format. Open source projects have been able to work with them and use them without involving IETF. I'm just not sure this is the right place for the document. You've done the work and documentation anyway already, and you're interoperable. What do you really gain by having this in IETF? It's also a fringe topic; With that I mean in this case that it's debug specific to a few projects related to TLS and while this is the TLS WG it's still a tooling issue in my estimate. I'm really not sure what the big upside is of having it published here. A lot of chrome, openssl and other tool chain specifics are likewise only documented in the relevant project documents and it works fine for everyone involved; Is there any precedent that showed we need this in IETF - ie. where interop and debugging didn't work out because you couldn't already agree on a format and document it? Because it seems to me the community has already achieved all of this due to your and other people's contribution without adding it as an IETF doc. Thanks, Aaron This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
> Even with Recommended=N, I can imagine many managers reacting to a > presentation on "YOU NEED TO USE PQC LIKE ML-KEM BECAUSE ELSE..." by googling > "deploy ML-KEM now" and being recommended this rather than a safer hybrid[1]. > I am not convinced that such a person, if given more knowledge, "doesn't want > to do that". > [1] After all, the manager was told to deploy MLKEM, not this suspicious > X25519MLKEM, whatever scam that must surely be. Really? I asked ChatGPT "Should I use MLKEM alone or a hybrid ECC + PQC combination?" and received the following balanced reply: The decision between using ML-KEM (Kyber) alone or a hybrid ECC + PQC combination depends on your specific security and performance requirements. Considerations for Each Approach: ML-KEM (Kyber) Alone ✅ Pros: Post-quantum security: ML-KEM (Kyber) is designed to resist quantum attacks, unlike ECC. Simpler implementation: Using just one algorithm reduces complexity. More future-proof: ECC could become obsolete when quantum computers become practical. ❌ Cons: Less tested in the real world: Though NIST has standardized Kyber, it's still relatively new compared to ECC. Potential hidden vulnerabilities: Post-quantum cryptography (PQC) is evolving, and new attacks might emerge. Hybrid ECC + PQC Combination ✅ Pros: Strongest security option: If ML-KEM is broken, ECC still provides security (and vice versa). Defense in depth: Combining a well-established (ECC) and a new (PQC) algorithm increases resilience. Better interoperability: Many current systems still rely on ECC. ❌ Cons: More computationally expensive: Hybrid approaches increase handshake size and latency. Complexity in implementation: Managing two key exchanges means additional attack vectors if not handled properly. Which Should You Choose? If you need maximum security and don’t mind extra computational costs, go for hybrid ECC + ML-KEM. If you prefer a simpler, efficient, and future-proof approach, ML-KEM alone is a strong choice. If your system needs to work with existing ECC-based infrastructures while transitioning to PQC, hybrid makes sense. 💡 Current Best Practice: Many organizations (e.g., Cloudflare, AWS) are using hybrid modes during the transition to fully post-quantum cryptography. If you’re designing a system today, hybrid is the safer option for now. Y(J)S This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3
I support adoption of pure PQC KEMs drafts with Intended status: Informational (meaning that the IETF is not recommending using). Any IPR that can be asserted against Kyber can be asserted against already adopted hybrid methods incorporating Kyber. If anything, one may attempt to argue that hybrids do not implement NIST's MLKEM scheme and are thus not covered by the NIST licenses. Y(J)S -Original Message- From: Sean Turner Sent: Tuesday, April 1, 2025 8:58 AM To: TLS List Subject: [TLS] WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3 We are continuing with our pre-announced tranche of WG adoption calls; see [0] for more information. This time we are issuing a WG adoption call for the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close at 2359 UTC on 15 April 2025. In response to other WG adoption calls, Dan Bernstein pointed out some potential IPR (see [2]), but no IPR disclosure has been made in accordance with BCP 79. Additional information is provided here; see [3]. BCP 79 makes this important point: (b) The IETF, following normal processes, can decide to use technology for which IPR disclosures have been made if it decides that such a use is warranted. WG members can take this information into account during this adoption call to determine if we should adopt these drafts. Reminder: This call for adoption has nothing to do with picking the mandatory-to-implement cipher suites in TLS. Cheers, Joe and Sean [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/ [1] https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/ [2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/ [3] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/ ___ 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 This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Just to be clear, I didn't say that ECH is a kind of phishing. What I said was that DGA and ECH share a common goal of hiding malicious traffic. As to RFC8744, I don't see any consensus on desirability there. What I see is an informational RFC explaining the history of SNI, the fact that it has been used for reasons other than its original intent, explanations for rejecting many ill-advised SNI encryption proposals (omitting the current one that was not yet on the table), and ending with the correct statement "Replacing cleartext SNI transmission by an encrypted variant will break or reduce the efficacy of the operational practices and techniques implemented in middleboxes". In fact, other than the vague statements that SNI is PROBABLY included in metadata collection by pervasive surveillance actors, and that encrypted SNI helps thwart unanticipated (but not necessarily negative) usages I don't see any explanation, let alone consensus. Y(J)S -Original Message- From: Stephen Farrell Sent: Thursday, July 3, 2025 4:57 PM To: Yaakov Stein ; Subject: Re: [TLS] FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt On 03/07/2025 14:51, Yaakov Stein wrote: > Stephen, > > ECH is not yet another confidentiality feature. We disagree. > TLS already provides perfectly good user content confidentiality. The IETF reached consensus on the desirability of this back in 2020 via RFC8744. > ECH is more akin to DNS tunneling or phishing based on domain names that look > correct. Phishing? That's quite the stretch - so much so I think it quite breaks your argument;-) > It is yet another method of hiding malicious traffic. ECH and TLS has nothing to say about whether traffic is good or bad. As I said, I think this is just regurgitating old arguments, so I don't plan to continue arguing, unless/until I see something new, which (other than a claim that ECH==phishing;-), I've not. Cheers, S. > > Y(J)S > > -Original Message----- > From: Stephen Farrell > Sent: Thursday, July 3, 2025 4:24 PM > To: Yaakov Stein ; > Subject: Re: [TLS] FW: New Version Notification for > draft-stein-tls-ech-considered-harmful-00.txt > > > Hiya, > > On 02/07/2025 15:43, Yaakov Stein wrote: >> Just in case anyone missed this ... > > I see nothing new or noteworthy in the text. It's the same set of arguments > emitted whenever there's the prospect that some new protocol confidentiality > feature looks like it may get to be widely deployed. > > It mostly reminds me of a meeting I was at where (mobile) telcos > (loudly:-) predicted the sky would fall because youtube had turned on https. > The sky didn't fall. > > Cheers, > S. > > This message is intended only for the designated recipient(s). It may contain > confidential or proprietary information. If you are not the designated > recipient, you may not review, copy or distribute this message. If you have > mistakenly received this message, please notify the sender by a reply e-mail > and delete this message. Thank you. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Watson, * Your document argues that ECH isn't good because it simultaneously can be defeated by flow behavior classification and that it defeats flow based allocation required for QoS. These can't both be right. Not what I said. I said that 90% of the flows (the common and in general benign ones) can be identified. The rare applications/sites (which are more likely to be malicious) can not. So, we are OK from the QoS point of view, but at a higher (monetary and ecological) cost. We are not OK regarding security. * Furthermore, the flow based enforcement isn't actually for QoS: we have lots of technologies for sharing these streams in a good manner and bounding delay now. I am not sure what you are saying. I interpret it as no-one uses DPI for applying QoE-related policy, which is simply not true. * And if you understood the Internet architecture the network isn't supposed to provide these kinds of services. In a perfect end-to-end-principle world this would be correct and there would be n middleboxes. We do not live in such a world. And in such a world the network can’t prioritize under congestion, and malicious packets are never blocked. * The IETF cannot guarantee product categories remain useful just because forever. So, IETF WGs shouldn’t carefully consider unintended effects of protocol changes ? Y(J)S This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: I-D Action: draft-ietf-tls-wkech-08.txt
Stephen, Small nit regarding the definition : Zone factory (ZF): an entity that has write-access to the DNS and similar text in the intro. First, it leaves unclear what THE DNS means (although clear from later on that you are talking about the authoritative DNS server) and so you mean write access to the authoritative DNS server's zone files or zone database (or "binding data" if you prefer). So, something l like Zone factory (ZF): an entity that has write-access to the authoritative DNS server zone database. In addition, I am not sure that the ZF really needs real "write access". Later on you use the term "publish" as in ZF publishes new HTTPS RR which implies a separate ZF entity with a pub/sub interface in which case the ZF has no "write access" to the DNS internals, it merely publishes information that the DNS server can decide to consume. Y(J)S -Original Message- From: Stephen Farrell Sent: Monday, July 7, 2025 7:04 PM To: tls@ietf.org Subject: [EXTERNAL] [TLS] Re: I-D Action: draft-ietf-tls-wkech-08.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe Hiya, I figure this one's about ready for WGLC so if given the chance to present it in Madrid, asking for that'd be the last slide:-) As the chairs prefer, that could be started before, during or after Madrid. Cheers, S. PS: Not sure if a pressie in Madrid is needed, as the changes since -07 are modest, though not entirely trivial, so happy to do a pressie, or to just ask for WGLC and see if that causes any upset:-) On 07/07/2025 16:44, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-tls-wkech-08.txt is now available. It is a > work item of the Transport Layer Security (TLS) WG of the IETF. > > Title: A well-known URI for publishing service parameters > Authors: Stephen Farrell > Rich Salz > Benjamin Schwartz > Name:draft-ietf-tls-wkech-08.txt > Pages: 18 > Dates: 2025-07-07 > > Abstract: > > We define a well-known URI at which an HTTP origin can inform an > authoritative DNS server, or other interested parties, about its > Service Bindings. The data can include Encrypted ClientHello (ECH) > configurations, allowing the origin, in collaboration with DNS > infrastructure elements, to publish and rotate its own ECH keys. > > Note > > This note is to be removed before publishing as an RFC. > > The source for this draft is in https://github.com/sftcd/wkesni/ > Issues and PRs are welcome there too. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-08 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-wkech-08 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Raghu, I certainly am not advocating believing in only SNI by itself, an advanced DPI system will use dozens of metadata features, SNI being only one. Indeed, in those cases where there is a single service behind an IP address, there is no reason for SNI to be present (although it often is anyway) and can certainly be faked. As I said in my ID you can't rely on client-side software. 99% of clients don't know what they are doing, and won't keep their protections up-to-date. And MiTM of any type is an abomination - we don't want to replace one attack with a worse one. In any case I am talking about a large ISP network, not a small or campus-size one where admins can set up proxies for individual users. Y(J)S -Original Message- From: Raghu Saxena Sent: Thursday, July 10, 2025 11:50 AM To: tls@ietf.org Subject: [EXTERNAL] [TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe Dear Yaakov, I would be careful about relying on plaintext SNI for detecting malicious flows. The SNI parameter is controlled by the client, and can even be ignored by the server. One would think that any decent malware author would either not set the SNI, or just "spoof" it - in which case if threat analysis software is relying on this field, it'd think the flow is legitimate and let is pass, which is probably even worse. In fact, recently when traveling on British Airways, I was able to (ab)use SNI, to use their "Free Messaging WiFi" for arbitrary traffic [0]. In environments where it is essential that network administrators inspect users' traffic to detect malicious flows, I think the better solution is to install MiTM CAs on client, which then allow the network admin to decrypt TLS and inspect the traffic. If this is then considered as an invasion of privacy in that setting, I'd argue inspecting SNI is the same; the client would rather hide it if they can. In fact, personally, I think browser's behavior to set SNI by default is actually harmful to privacy, since there are very popular websites (Top25) that function fine without the SNI extension, yet ISPs (such as "Jio" in India - from my experience) use this leakage to block them. If you want to argue that the users' are "OK" with monitoring of the domains, but not of their entire TLS traffic, then the network admin can setup an HTTP(S) proxy (without MiTM), which would be able to log the domains via the `CONNECT` header, while blocking all other traffic. Once again, if this level of control over client's traffic is not possible, one should rethink if the "admins" should be able to peek into the SNI at all. Regards, Raghu Saxena [0] https://www.saxrag.com/tech/reversing/2025/06/01/BAWiFi.html On 7/2/25 10:43 PM, Yaakov Stein wrote: > Just in case anyone missed this ... > > Y(J)S > > -----Original Message- > From: internet-dra...@ietf.org > Sent: Tuesday, July 1, 2025 4:52 PM > To: Yaakov Stein ; Yaakov Stein > Subject: New Version Notification for > draft-stein-tls-ech-considered-harmful-00.txt > > A new version of Internet-Draft > draft-stein-tls-ech-considered-harmful-00.txt > has been successfully submitted by Yaakov (J) Stein and posted to the IETF > repository. > > Name: draft-stein-tls-ech-considered-harmful > Revision: 00 > Title:ECH Considered Harmful > Date: 2025-07-01 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.txt > Status: > https://datatracker.ietf.org/doc/draft-stein-tls-ech-considered-harmful/ > HTML: > https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-stein-tls-ech-considered-h > armful > > > Abstract: > > Encrypted Client Hello is designed to enhance personal privacy, in > particular obstructing the ability of communications service > providers (but not Over The Top service providers) to map packet > flows to applications. While mostly ineffective in attaining this > goal, it does severely hamper network-based detection of malicious > flows, thus exposing end-users to various security risks that were > previously avoidable. > > > > The IETF Secretariat > > > This message is intended only for the designated recipient(s). It may contain > confidential or proprietary information. If you are not the designated > recipient, you may not review, copy or distribute this message. If you have > mistakenly received this message, please notify the sender by a reply e-mail > and de
[TLS] Re: [EXTERNAL] Re: Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
There are many references that state that the vast majority of people don’t understand and can’t configure security features, and complementing these many references that claim that the vast majority of breaches are human related. For example: https://purplesec.us/resources/cybersecurity-statistics/ “It’s estimated that 99% of cloud security failures through 2025 will be the customers’ fault.” See also https://arxiv.org/pdf/2212.10382, https://www.computerworld.com/article/1361241/90-of-security-incidents-trace-back-to-pebkac-and-id10t-errors.html https://www.csoonline.com/article/544717/security-awareness-studies-prove-once-again-that-users-are-the-weakest-link-in-the-security-chain.html Y(J)S From: Rob Sayre Sent: Saturday, July 12, 2025 4:24 AM To: TLS@ietf.org; Yaakov Stein Subject: [EXTERNAL] Re: [TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe Yaakov Stein mailto:yst...@allot.com>> wrote: > 99% of clients don't know what they are doing, Interesting. What's the citation there? thanks, Rob This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Rich, I never said that TLS without ECH provides sufficient privacy. I said it provides sufficient security, and I fully admit that SNI raises privacy concerns. The difference between us is that I believe that this privacy concern is minor (and almost negligible in the most common case where flows are classified without associating them with particular subscribers) as compared to the much more invasive privacy intrusions of the OTTs. Unlike you I believe that we need to consider the privacy vs. security tradeoff - comparing an almost insignificant privacy intrusion vs. major security threats. I don't recall saying that ECH is itself an attack, but if I did, I humbly rescind that statement. In a perfect world with no malicious sites, ECH is completely innocuous. In a perfect world where antivirus and IDS work perfectly, are always up-to-date, and zero-days don't exist, ECH is completely innocuous. ECH is merely a highly efficient method of hiding the actual attacks from network-based security mechanisms. Y(J)S From: Salz, Rich Sent: Thursday, July 3, 2025 6:39 PM To: Yaakov Stein ; Subject: Re: [EXTERNAL] Re: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe Well, I didn't write this to merely get things off my chest. Well, it sure reads that way. For example, calling it an "attack" is needlessly provocative. Saying that TLS provides sufficient privacy, when the ECH document itself points out that having the SNI in the clear is a privacy concern, shows a poor understanding. You seem to disagree with that concern, which is fine, but your argument in the document is not persuasive. Take this feedback however you want; it's worth what you paid for it. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Stephen, ECH is not yet another confidentiality feature. TLS already provides perfectly good user content confidentiality. ECH is more akin to DNS tunneling or phishing based on domain names that look correct. It is yet another method of hiding malicious traffic. Y(J)S -Original Message- From: Stephen Farrell Sent: Thursday, July 3, 2025 4:24 PM To: Yaakov Stein ; Subject: Re: [TLS] FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt Hiya, On 02/07/2025 15:43, Yaakov Stein wrote: > Just in case anyone missed this ... I see nothing new or noteworthy in the text. It's the same set of arguments emitted whenever there's the prospect that some new protocol confidentiality feature looks like it may get to be widely deployed. It mostly reminds me of a meeting I was at where (mobile) telcos (loudly:-) predicted the sky would fall because youtube had turned on https. The sky didn't fall. Cheers, S. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Rich, Well, I didn't write this to merely get things off my chest. I have been active in the IETF for over 25 years, and this is the first time I have seen an attack pass IETF LC. Regarding using 5-tuples, random dynamic + 443 port numbers are mostly useless, and server IP address does not provide granular application classification. I don't really care if the server belongs to Google since the same IP address can be used for about 20 different applications with wildly diverging forwarding policy requirements. Gmail can be delayed for seconds, search has intermediate delay but low data-rate, Youtube DASH has critical delay issues at startup and then none afterwards, but high bandwidth, etc. And a large percentage of the traffic may be on an operator CDN, so that different OTTs share IP addresses. And that covers only the traffic management issue I raised. Regarding the more serious malware detection issue, I assume that you expect me to rely on the RFC 3514 marking in the IP header? Y(J)S From: Salz, Rich Sent: Wednesday, July 2, 2025 6:28 PM To: Yaakov Stein ; Subject: [EXTERNAL] Re: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe I appreciate that sometimes it's just good to get something off your chest. Why doesn't TCP-level filtering and control work? Nobody's hiding the five-tuple. This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt
Just in case anyone missed this ... Y(J)S -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, July 1, 2025 4:52 PM To: Yaakov Stein ; Yaakov Stein Subject: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt A new version of Internet-Draft draft-stein-tls-ech-considered-harmful-00.txt has been successfully submitted by Yaakov (J) Stein and posted to the IETF repository. Name: draft-stein-tls-ech-considered-harmful Revision: 00 Title:ECH Considered Harmful Date: 2025-07-01 Group:Individual Submission Pages:7 URL: https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.txt Status: https://datatracker.ietf.org/doc/draft-stein-tls-ech-considered-harmful/ HTML: https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-stein-tls-ech-considered-harmful Abstract: Encrypted Client Hello is designed to enhance personal privacy, in particular obstructing the ability of communications service providers (but not Over The Top service providers) to map packet flows to applications. While mostly ineffective in attaining this goal, it does severely hamper network-based detection of malicious flows, thus exposing end-users to various security risks that were previously avoidable. The IETF Secretariat This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
