On Fri, Oct 4, 2024 at 11:32 AM Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org> wrote: > > > On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz <bem...@meta.com> wrote: >> >> I've updated PR#16 to reframe this paragraph as a statement of fact: >> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16/files > > > Speaking as individual, > >> >> >> It seems strange to me to describe a vulnerability without explaining how to >> mitigate it, but I'm willing to move forward if this is all we have >> consensus for. > > > I also find it a bit odd that we don't warn people the entire purpose of the > draft would be in vain, if one did not use a properly secured DNS transport > to a DNS server with a compatible privacy policy. > > Perhaps a short Operational Considerations section could be added explaining > the use of ECH at the Enterprise network and networks deploying DNS filter > security services could be blocked for security reasons at the cost of > privacy loss to the network? And that the enduser might not have a choice > based on the DNS constrains within those networks. > > Of course I myself am now thinking I want a DNS module that pulls these DNS > records based on previous queries and stashes these in my own DNS resolver so > that I can move onto these kind of networks and use ECH without requiring to > do further DNS lookups :P > > Maybe just an aggressive prefetch of ECH related records :P > > Which makes me wonder if it makes sense to advise long TTLs on these records > so that they move along on your phone/laptop even if you enter these kind of > networks.
If deploying in DNS, ECH can be supported: the resolve has the destination name. The issue is with SNI blocking hardware doing the block instead of DNS. At least that's what I understand from this conversation. > > Paul W > >> >> >> --Ben >> ________________________________ >> From: Eric Rescorla <e...@rtfm.com> >> Sent: Friday, October 4, 2024 8:07 AM >> To: Salz, Rich <rs...@akamai.com> >> Cc: Arnaud Taddei <arnaud.tad...@broadcom.com>; Ben Schwartz >> <bem...@meta.com>; Paul Vixie <p...@redbarn.org>; 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: [DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech >> >> I don't really think it's helpful to re-litigate the broader topic of the >> merits of ECH; nothing we say in security considerations will make a >> material difference there. With that said, I don't love the last sentence as >> we know users >> I don't really think it's helpful to re-litigate the broader topic of the >> merits of ECH; nothing we say in security considerations will make a >> material difference there. >> >> With that said, I don't love the last sentence as we know users don't really >> choose their resolvers. How about simply stating the facts: >> >> "This specification does not effectively conceal the target domain name from >> an untrusted resolver." >> >> >> -Ekr >> >> >> On Thu, Oct 3, 2024 at 9:41 AM Salz, Rich >> <rsalz=40akamai....@dmarc.ietf.org> wrote: >> >> I do not think this conflict of views can be resolved. The draft is intended >> to show how it ECH should be used to preserve it’s security guarantees, and >> there are groups in the DNS community who say this prevents their normal >> course of operation, and providing the features that they provide. I >> apologize in advance if anyone finds my wording clumsy or, worse, offensive. >> I was trying to use neutral words throughout. >> >> >> >> I think we just acknowledge that in the security considerations and declare >> the issue closed. >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > TLS mailing list -- t...@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
