On Fri, Oct 4, 2024 at 11:30 AM Paul Wouters <paul.wout...@aiven.io> 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. > I think the text I proposed makes this clear. > > 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. > I would not be in favor of this. This is been intensely controversial and I want the document done. -Ekr > 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>; TLS@ietf.org <tls@ietf.org>; >> dn...@ietf.org WG <dn...@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 -- dn...@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org >> >>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
