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. 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 > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
