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. I also believe that they are generally incorrect, since ECH does not conceal any information that a firewall should believe. However, that is not the topic at hand.
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. 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). 2. A proposed addition to this section (https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files): > 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. 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.". 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. These requirements are entirely compatible with "protective DNS". I'm happy to adjust the proposed text as needed to make that clear. --Ben ________________________________ From: Arnaud Taddei <arnaud.taddei=40broadcom....@dmarc.ietf.org> Sent: Wednesday, October 2, 2024 9:54 AM To: Paul Vixie <p...@redbarn.org> Cc: Deirdre Connolly <durumcrustu...@gmail.com>; Ben Schwartz <bem...@meta.com>; Paul Wouters <paul.wout...@aiven.io>; draft-ietf-tls-svcb-ech.auth...@ietf.org <draft-ietf-tls-svcb-ech.auth...@ietf.org>; t...@ietf.org <t...@ietf.org>; dnsop@ietf.org WG <dnsop@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 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/__;!!Bt8RZUm9aw!5pqKx-25Heqn-A4fiF_78q2RJK0ajK1JkmH-QQ03RbI1usTedZRgFhSD6lO7GB1_a03GpDMYAEWbKP1JClVwoGxK9uU$> 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://urldefense.com/v3/__https://www.google.com/url?q=https:**Awww.cisa.gov*news-events*alerts*2021*03*04*joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through&source=gmail-imap&ust=1728447124000000&usg=AOvVaw3xnckupAXvxa8aiLvQayh4__;Ly8vLy8vLy8!!Bt8RZUm9aw!5pqKx-25Heqn-A4fiF_78q2RJK0ajK1JkmH-QQ03RbI1usTedZRgFhSD6lO7GB1_a03GpDMYAEWbKP1JClVw_TUulak$> 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 -- t...@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.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
