Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

we're not talking about significant delays. I suspect the broader application space of O-HTTP makes it a bit messier, and it could take a while to hammer out all the details. I for one want to use O-HTTP for POST requests. As for this draft I support adoption targeting experimental. Sincerely,

Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

On Tue, Oct 29, 2019 at 8:30 PM Jim Reid wrote: > > On 30 Oct 2019, at 01:32, Eric Rescorla wrote: > > > >> Yes, it's hard, but I think it's worthwhile, because the prospect of getting the root to offer ADoT seems very distant to me. > >> > > Why? Do we have estimates of the load level here as

Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

On Fri, Apr 5, 2019 at 9:45 AM william manning wrote: > > Every now and then, Paul Vixie and I are in complete harmony. In my current > slot, we are one of thousands of entities that are being held accountable to > a series of regulatory requirements that have significant fiscal impacts on >

Re: [dns-privacy] Some additional signalling ideas

On Sun, Mar 31, 2019 at 7:15 AM Ralf Weber wrote: > > Moin! > > > On 31. Mar 2019, at 14:48, Watson Ladd wrote: > > > > Dear all, > > Please rip these ideas to shreds: > I assume with this sentence you mean that the following ideas are bad ideas. >

[dns-privacy] Some additional signalling ideas

Dear all, Please rip these ideas to shreds: 1) An extra bit in a response for "you could have asked over TLS" 2) An extra field when looking up the nameserver for "you can ask that server over TLS" 3) An extra field/bit/convention for "this nameserver supports tls" (like tls-ns vs ns) Sincerely,

[dns-privacy] Correction to my mike statement about the provisioning draft

Despite citations to SRP-6 the rfc 5054 implements 6a which doesn't have a 2 for 1 attack. It does however use SHA1 hardcoded. Probably not a good idea. We seem to have thought there were other draft issues as well though. Sincerely, Watson Ladd

[dns-privacy] draft-ietf-dprive-bcp-op-2 and tls

Dear all, TLS 1.3 resumption doesnt have the cookie problem TLS 1.2 does. Resumption is a big gain for performance and is likely to be more so in the future so I propose 5.1.3.1 be edited accordingly. Also I wonder why we aren't talking about all resolvers. Sincerely, Watson

Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On Mon, Nov 16, 2015 at 10:28 AM, Olafur Gudmundsson wrote: > >> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson wrote: >> >> Shane Kerr wrote: >>> Andreas Gustafsson wrote: I'm also wondering if there might be scenarios where the

Re: [dns-privacy] DPRIVE over UDP or TCP

On Sun, Apr 26, 2015 at 8:33 PM, Dan Wing dw...@cisco.com wrote: On 26-Apr-2015 08:27 pm, Watson Ladd watsonbl...@gmail.com wrote: On Fri, Apr 24, 2015 at 9:21 AM, Dan Wing dw...@cisco.com wrote: On 23-Apr-2015 06:37 pm, Phillip Hallam-Baker i...@hallambaker.com wrote: On Thu, Apr 23

Re: [dns-privacy] Call for Adoptions on the 3 documents.

On Thu, Apr 23, 2015 at 6:46 AM, Warren Kumari war...@kumari.net wrote: On Wed, Apr 22, 2015 at 8:43 PM, Watson Ladd watsonbl...@gmail.com wrote: I agree that DNSCurve is the best solution. ... which a: was not one of the options, b: is recursive to auth and c: has not been written up

Re: [dns-privacy] DPRIVE over UDP or TCP

with TLS, unless you do fancy stateful failover tricks. The easiest solution is to encrypt packets with a public key that the servers have, or force every packet to contain something equivalent to resumption data. But that requires not using TLS/DTLS. Sincerely, Watson Ladd

Re: [dns-privacy] Call for Adoptions on the 3 documents.

. When people say it's easy to implement DNS-over-TCP/TLS, and haven't, I think that's a warning sign. Sincerely, Watson Ladd On Wed, Apr 22, 2015 at 7:19 AM, Simon Josefsson si...@josefsson.org wrote: I support adopting 3) draft-hzhwm-dprive-start-tls-for-dns. It may not be in shipping shape

Re: [dns-privacy] draft-wijngaards-dnsop-confidentialdns and DDoS

people asked where the docs are: https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES. The writeup isn't the best, but it should be possible to see what is going on from this, and it seems very similar to the Wijngaards draft. Sincerely, Watson Ladd S. Best Regards, Zhiwei Yan 在

Re: [dns-privacy] A pool is not an onion

On Oct 26, 2014 8:09 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 25, 2014, at 7:35 PM, Watson Ladd watsonbl...@gmail.com wrote: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why

[dns-privacy] Solving the problem

algorithm is. The cost is that caches may have to do slightly more work, and communication costs will probably increase significantly. How to load data in from the DNS into the caches when it isn't found is a problem I'm still thinking about. Sincerely, Watson Ladd