Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
Hi Paul, On 12/5/18 12:23 PM, Paul Wouters wrote: > On Wed, 5 Dec 2018, Brian Haberman wrote: > >> While MLS is still in its infancy, it is designed for many-to-many >> communications. That may be beneficial when we are talking about >> authoritative servers using anycast. > > MLS is about authenticated (group) chat. In this case, the is a big > need for the querier to remain anonymous and not to present any > identity. MLS would be an extremely poor fit and bring in a number > of other concerns, such as depencies on registration services, > authentication services, etc. etc. That's a good point that I hadn't considered. > > It's the wrong hammer for DNs privacy Thanks for the quick response on MLS. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
On Wed, Dec 05, 2018 at 10:22:49PM +0530, Mukund Sivaraman wrote: > Nod, HTTPS has demonstrated that TLS can be scalable (even more so in > recent years) and DNS is not different in this aspect. This is one > aspect for protocol selection. I also worry about roundtrips in > recursive resolution. If a message security scheme can somehow work as a > stateless request-response protocol where prior state establishment is > not necessary, it can reduce time to respond to queries comparable to > traditional DNS. This was not a problem for stub->resolver transport > where processing a client request is limited to talking to one peer, and > RTT to a resolver is usually low. resolver->auth is different where the > transport can be used many times for a single client query. Unexpected latency here can not only badly impact user experience, but cause timeouts. FWIW, a stub resolver such as glibc would typically timeout a query in 5 seconds and make a second attempt (possibly to a different nameserver) if the first one fails. This may or may not totally take 5 seconds in all. dig will timeout each fetch at 5 seconds by default, and try up to 3 times in all before it gives up. The need to answer within such time is why the serve-stale draft has a "client response timer". These circumstances can also occur with regular DNS with a lot of indirection (several NS lookups in servicing a single client query) and high RTT to nameservers. E.g. BIND can wait from 10 upto 30 seconds for a resolution to timeout based on configuration, but its client usually won't wait that long, but named can at least insert the resolution result into cache for future queries. Stub timeout behavior is something to consider when switching transports. Mukund ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
On Dec 5, 2018, at 6:25 AM, Paul Wouters wrote: > > On Fri, 30 Nov 2018, Paul Hoffman wrote: > >>> I am not sure I see a need for a different TLS/DTLS profile compared to >>> regular (web) based (D)TLS connections. What do you or Karl think would >>> be different? >> >> (D)TLS is not the only option. Using message security instead of connection >> security would eliminate the need for keeping TCP and crypto state on the >> server, and could maybe reduce the amount of CPU usage as well. > > Is there a draft that describes this message security? Or is that part > of the work to be started? The latter. > It seems that before dprive publishes a (D)TLS profile, that this path > should be considered first? Maybe, or maybe they can be done in parallel. There are already plenty of message security standards to start from (COSE, CMS, OpenPGP), and "encrypt a simple DNS message body" is trivial. What is less trivial is weighing the costs and benefits to resolvers and authoritative servers, which is the work that is going to start happening soon. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
