Hi Erik, Agree it is out of the scope of this draft, but we have another vehicle that would be ideal to capture what you write
We didn’t push it too much in the past 9+ months as per agreement with ADs and Working Group chairs, Eric and others to wait for ECH to be ratified first and on our side we stick to our agreement Yet you can consult: https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/ And if you feel to make a PR with your below content or raise an issue in our GitHub it will certainly appreciated Indeed I left an editor note as a placeholder to precisely describe how enterprises can do this at the end of 5.3.2 Any feedback welcome but if so, let’s start another email thread to not mix things 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 4 Oct 2024, at 21:06, Erik Nygren <erik+i...@nygren.org> wrote: > > The suggested text seems inoffensive to me as well, but we may also want to > expand it to cover the recursive-to-authoritative path for resolvers > associated with the client. (ie, just using DoH to your home router isn't > going to help when it uses Do53 to the authorities.). > > On the topic of DNSSEC, it's worth noting that rfc9460 (for SVCB) has some > text there as well which provides some recommendations. > Some of those were general and were intended to provide some degree of > coverage for the ECH use-case (before this was > split out to its own draft). > > > I do share the concerns that Enterprise environments are going to need to be > able to disable ECH. > That seems out of the scope of this draft, and it seems like they could do > this in a few ways: > * Stripping SVCB/HTTPS RRs entirely > * Removing (or replacing) ech entries from the SVCB/HTTPS RRs, especially if > used along with devices that do terminating TLS MitM. > * Managed device client-side policy configured as part of the OS/client > environment. > None of these are in the remit of the IETF or things we want to be > standardizing, so seem out of scope here, > and also none of them truly defend against hostile/compromised clients that > ignore the enterprise policies > and are trying to establish covert channels. It seems like leaving things on > this front out of the draft is preferable. > > Erik > > > > On Fri, Oct 4, 2024 at 11:37 AM Stephen Farrell <stephen.farr...@cs.tcd.ie > <mailto:stephen.farr...@cs.tcd.ie>> wrote: >> >> >> On 10/4/24 16:09, Salz, Rich wrote: >> > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 >> > <https://www.google.com/url?q=https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16&source=gmail-imap&ust=1728673740000000&usg=AOvVaw2NP4qMjAJX_KyonlxZ1foF> >> > "Discuss >> > the impact of resolver selection on security" >> >> That suggested text seems inoffensive to me fwiw. >> >> S. >> _______________________________________________ >> TLS mailing list -- t...@ietf.org <mailto:t...@ietf.org> >> To unsubscribe send an email to tls-le...@ietf.org >> <mailto:tls-le...@ietf.org> > _______________________________________________ > 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
