Hi Ben, thank you for your answer but this is confirming I have a lot of difficulties to agree. In fact I disagree and after thorough internal discussions this confirms the solidity of our support to Paul Vixie’s position.
Re-read Paul V. answers and consider the MUST NOT clauses in his emails Inline Arnaud Taddei Global Security Strategist | Enterprise Security Group mobile: +41 79 506 1129 Geneva, Switzerland arnaud.tad...@broadcom.com <mailto:arnaud.tad...@broadcom.com> | broadcom.com > On 2 Oct 2024, at 16:50, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > wrote: > > Hi Arnaud, > > I believe your assessment that many network administrators think they need to > block access to certain domains and/or disable the usage of ECH via network > service configuration. Ok > I also believe that they are generally incorrect, since ECH does not conceal > any information that a firewall should believe. Ok I am not going to redo that loop because we had it with Chris Wood and others and we showed that this is a gross misunderstanding of our enterprise environments are: 1) In practice the SNI is reliable 2) Proxies are not stupid and they check and improve the evaluation ticket in the proxy process before it actually takes action 3) when the SNI is not reliable this is a very good source of attackers information and we like this entropy as security practitioners Again our Internet Draft on ECH deployment considerations is explicit about that: 2, 2.3, 2.4 and 2.5, Appendix B.3 with production data > However, that is not the topic at hand. I partially agree and disagree. Re-reading the whole thread my answer is slightly orthogonal but it provides context to Paul Vixie crucial point > We are discussing the Security Considerations of draft-ietf-tls-svcb-ech, and > two points in particular: > > 1. A reminder that Section 3.1 of RFC 9460 applies here. This section > considers an active attacker who does not control the DNS resolver, but > attempts to interfere with it by forcing SERVFAIL responses, or no response > at all. It does not impair the effectiveness of a filtering DNS resolver, > which can simply respond REFUSED to any objectionable query. This clause seems correct to me. > The resolver could also rewrite the SVCB record to delete the "ech" SvcParam, > but this would add complexity without any benefit and would break stub DNSSEC > validation (hence my comment that you quoted). Again this is EXACTLY what enterprises want to do and probably already on other fields and DNS software vendors too. The assumption that DNSSEC is important is simply irrealistic in enterprise context. That is not how the real world works > 2. A proposed addition to this section > (https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files > <https://www.google.com/url?q=https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files&source=gmail-imap&ust=1728485455000000&usg=AOvVaw02-Ac_smH6thuLHC98fUyE>): > > > To achieve the security goals from Section 10.1 of [ECH], clients for this > > specification SHOULD use an authenticated and encrypted connection to a DNS > > resolver that they trust to preserve the confidentiality of their queries > > and return authentic answers. I completely disagree for the same arguments that Paul Vixie explains very precisely. Let me extract from Paul’s reference: "How does it work? ... The resolver usually checks both the domain name queries and the returned IP addresses against threat intelligence, and then prevents connections to known or suspected malicious sites. PDNS can also protect a user by redirecting the requesting application to a nonmalicious site or returning a response that indicates no IP address was found for the domain queried. In addition, many enterprise DNS resolvers still do not validate DNSSEC or support DoH/DoT, but many PDNS providers add these DNS security enhancements as well [4]. …” You have to consider the world of security operations which was obviously heavily ignored so far here. Going the authentic path will have exactly the contrary effect. > The referenced section states a design goal that "An attacker cannot > downgrade a connection that attempts to use ECH to one that does not use > ECH.". It is really hard for me to answer that position. It is good to have a goal, but when in design only the end target is considered with no ‘migration’ path, usually (32 years of observations) it leads to the situation that doesn’t mean you can reach this goal in practice > This text notes some resulting implied requirements: > > 1. The client's connection to the DNS server is not vulnerable. > 2. The DNS server is not an attacker. > 3. The DNS server is not itself vulnerable. Unfortunately these requirements are in practice irrealistic. In general terms you cannot trust the DNS resolver > These requirements are entirely compatible with "protective DNS". I'm happy > to adjust the proposed text as needed to make that clear. No, these requirements are entirely incompatible with what would be the requirements that lead to PDNS. The bottom line is if I understand the situation correctly, unless Paul Vixie’s point are reconsidered here, we are going to set a catastrophic requirement here if we continue this path and I don’t want to think about the implications for poor mortal security operation people when they are going to have to explain to their boss what they are forced to do. Probably a pop-corn time. I don’t know which way forward to offer and which compromise to offer but the clause is clearly problematic "ECH ensures that TLS does not disclose the SNI, but the same information is also revealed in the DNS queries used to resolve the server's hostname. To achieve the security goals from {{Section 10.1 of !ECH}}, clients for this specification SHOULD use an authenticated and encrypted connection to a DNS resolver that they trust to preserve the confidentiality of their queries and return authentic answers." Maybe we could use the so-called “Australian method” and start to drop the two segments in bold and leave this to security operational people to do their job. My 0.02 Swiss Francs > > --Ben > From: Arnaud Taddei <arnaud.taddei=40broadcom....@dmarc.ietf.org > <mailto:arnaud.taddei=40broadcom....@dmarc.ietf.org>> > Sent: Wednesday, October 2, 2024 9:54 AM > To: Paul Vixie <p...@redbarn.org <mailto:p...@redbarn.org>> > Cc: Deirdre Connolly <durumcrustu...@gmail.com > <mailto:durumcrustu...@gmail.com>>; Ben Schwartz <bem...@meta.com > <mailto:bem...@meta.com>>; Paul Wouters <paul.wout...@aiven.io > <mailto:paul.wout...@aiven.io>>; draft-ietf-tls-svcb-ech.auth...@ietf.org > <mailto:draft-ietf-tls-svcb-ech.auth...@ietf.org><draft-ietf-tls-svcb-ech.auth...@ietf.org > <mailto:draft-ietf-tls-svcb-ech.auth...@ietf.org>>; TLS@ietf.org > <mailto:TLS@ietf.org> <tls@ietf.org <mailto:tls@ietf.org>>; dn...@ietf.org > <mailto:dn...@ietf.org> WG <dn...@ietf.org <mailto:dn...@ietf.org>> > Subject: Re: [TLS] [DNSOP] Re: Re: AD review draft-ietf-tls-svcb-ech > > I am taking this thread on the fly and I do have a number of concerns with > what I read and I align with Paul Vixie here. > > First I disagree with Ben on “I don’t see any reason why an enterprise, etc.” > … > I DO see reasons here confirmed in a campaign of discussions about ECH with > no less than 70 organisations in the Fortune 150 in the past 18 months > I learnt tons of things and in particular the pressure for them to control > their Resolver to be able to strip the ECH RR > Secondly this was not even our idea, this was Eric’s idea in the difficult > side meeting of IETF 115 in London I believe > Third we started to document all of this in an internet draft on ECH > deployment considerations > <https://www.google.com/url?q=https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/__;!!Bt8RZUm9aw!5pqKx-25Heqn-A4fiF_78q2RJK0ajK1JkmH-QQ03RbI1usTedZRgFhSD6lO7GB1_a03GpDMYAEWbKP1JClVwoGxK9uU$&source=gmail-imap&ust=1728485455000000&usg=AOvVaw0MQaW6CDlhI3eXPStLu0oo> > which is in development > 4 use cases are covered > and for example for enterprise use cases you can look at 5.3.2. > I left an editor note to properly describe how to do it properly as there are > some intricacies in practical terms > Here is the extract with 5 main issues that represent a risk for Enterprises > > "As some Browser makers made the use of ECH optional, this gives a > first approach for enterprises to disable ECH for their employees. > > However this doesn't provide an holistic solution. Indeed > enterprises will need to consider a number of issues: > > * Browsers which do not offer an option to disable ECH > > * Browsers that will make ECH non optional in the future > > * Non-browsers applications which are designed to use libraries > enforcing ECH, without any option to disable it > > * All the range of BYOD use cases where enterprises do not control > the endpoint > > * Adversaries leveraging ECH e.g. to hide their command and control > communications, e.g. in Ransomware cases. > > Whilst, disabling ECH wherever possible provides one approach to > mitigate ECH deployment issues, as per above, other mitigations > approaches need to be offered to enterprises. > > (Editor's note: we need to describe how to strip the RRs to force a > global disabling of ECH, yet mindful it might not be sufficient if an > adversary finds a way to not use the enterprise DNS resolver)" > >> On 2 Oct 2024, at 06:10, Paul Vixie <paul=40redbarn....@dmarc.ietf.org> >> wrote: >> >> >> >> Deirdre Connolly wrote on 2024-09-30 10:59: >>> > We could add a recommendation like "Clients using ECH SHOULD select a DNS >>> > resolver that they trust to preserve the confidentiality of their queries >>> > and return authentic answers, and communicate using an authenticated and >>> > confidential transport", but this draft seems like an odd place for that >>> > text. >>> I support this more than the DNSSEC recommendation >> >> i would not. much of the world now relies upon inauthentic dns responses for >> defense against bad actors. here's how US NCCIS puts it: >> >> https://www.google.com/url?q=https://www.cisa.gov/news-events/alerts/2021/03/04/joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through&source=gmail-imap&ust=1728447124000000&usg=AOvVaw3xnckupAXvxa8aiLvQayh4 >> >> <https://www.google.com/url?q=https://urldefense.com/v3/__https://www.google.com/url?q%3Dhttps:**Awww.cisa.gov*news-events*alerts*2021*03*04*joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through%26source%3Dgmail-imap%26ust%3D1728447124000000%26usg%3DAOvVaw3xnckupAXvxa8aiLvQayh4__;Ly8vLy8vLy8!!Bt8RZUm9aw!5pqKx-25Heqn-A4fiF_78q2RJK0ajK1JkmH-QQ03RbI1usTedZRgFhSD6lO7GB1_a03GpDMYAEWbKP1JClVw_TUulak$&source=gmail-imap&ust=1728485455000000&usg=AOvVaw3Qf2EpmlA7X6KsgEA_dsDP> >> >> it is precisely to prevent protective dns from being bypasses that many of >> us block all off-net DNS including off-net HTTPS to known DoH services. >> malicious insiders, intruders, malware, and poisoned supply chains do not >> want their DNS lookups to be monitored or blocked. >> >> we can argue about where the advice should and shouldn't appear, but we >> mustn't appeal to "response authenticity" when recommending a recursive DNS >> service. response authenticity is what our attackers need. >> >> -- >> P Vixie >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org > > > This electronic communication and the information and any files transmitted > with it, or attached to it, are confidential and are intended solely for the > use of the individual or entity to whom it is addressed and may contain > information that is confidential, legally privileged, protected by privacy > laws, or otherwise restricted from disclosure to anyone else. If you are not > the intended recipient or the person responsible for delivering the e-mail to > the intended recipient, you are hereby notified that any use, copying, > distributing, dissemination, forwarding, printing, or copying of this e-mail > is strictly prohibited. If you received this e-mail in error, please return > the e-mail to the sender, delete it from your computer, and destroy any > printed copy of it. -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
