On Fri, Oct 4, 2024 at 11:32 AM Paul Wouters <[email protected]> wrote: > > > On Fri, Oct 4, 2024 at 10:06 AM Ben Schwartz <[email protected]> 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 <[email protected]> >> Sent: Friday, October 4, 2024 8:07 AM >> To: Salz, Rich <[email protected]> >> Cc: Arnaud Taddei <[email protected]>; Ben Schwartz >> <[email protected]>; Paul Vixie <[email protected]>; Paul Wouters >> <[email protected]>; [email protected] >> <[email protected]>; [email protected] <[email protected]>; >> [email protected] WG <[email protected]> >> 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 >> <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Astra mortemque praestare gradatim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
