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://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/> 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 > > 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.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
