Re: [dns-privacy] DoT at the DNS root

On 30 Oct 2019, at 03:48, Jim Reid wrote: > > > NB Offlist Sigh. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] DoT at the DNS root

On 30 Oct 2019, at 01:32, Eric Rescorla wrote:: > Do we have estimates of the load level here as compared to (say) Quad9 or > 1.1.1.1? NB Offlist Take a look at how long it took for the root server operators (RSOs) to make their infrastructure DNSSEC-capable. Each of them understandably took

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

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 compared to (say) Quad9 > or 1.1.1.1? The root server

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

In article you write: >> 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 compared to (say) Quad9 >or 1.1.1.1? The load has nothing to do with it. Surely

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

On 10/29/2019 5:01 PM, Eric Rescorla wrote: > Ben, > > Is what you're saying here that .com provides the NS record for > example.com and that may not itself be > example.com , but instead ns.server.invalid, and > therefore if you can't trust .com then it

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

On Tue, Oct 29, 2019 at 6:27 PM Ben Schwartz wrote: > > > On Tue, Oct 29, 2019 at 8:53 PM Eric Rescorla wrote: > >> >> >> On Tue, Oct 29, 2019 at 5:44 PM Ben Schwartz wrote: >> >>> >>> >>> On Tue, Oct 29, 2019 at 8:02 PM Eric Rescorla wrote: >>> On Tue, Oct 29, 2019 at 3:55 PM

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

On Tue, Oct 29, 2019 at 5:02 PM Eric Rescorla wrote: > > > On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie wrote: > >> Clipping away a bit where we appear to agree. >> >> On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz wrote: >>> >> >> This resembles the ongoing experiment >>

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

On Tue, Oct 29, 2019 at 5:44 PM Ben Schwartz wrote: > > > On Tue, Oct 29, 2019 at 8:02 PM Eric Rescorla wrote: > >> >> >> On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie wrote: >> >>> Clipping away a bit where we appear to agree. >>> >>> On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz wrote: >>>

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

On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie wrote: > Clipping away a bit where we appear to agree. > > On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz wrote: >> > > This resembles the ongoing experiment > between Facebook and > Cloudflare, where

Re: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

On Tue, Oct 29, 2019 at 4:23 PM Rob Sayre wrote: > On Tue, Oct 29, 2019 at 4:02 PM Eric Rescorla wrote: > >> Document: draft-lmo-dprive-phase2-requirements-00.txt >> >> After reviewing this draft, it is not clear to me what architectural >> model people have in mind. At a high level, say that I

Re: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

On Tue, Oct 29, 2019 at 4:02 PM Eric Rescorla wrote: > Document: draft-lmo-dprive-phase2-requirements-00.txt > > After reviewing this draft, it is not clear to me what architectural > model people have in mind. At a high level, say that I attempt to > dereference example.com and I have a cached

[dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

Document: draft-lmo-dprive-phase2-requirements-00.txt After reviewing this draft, it is not clear to me what architectural model people have in mind. At a high level, say that I attempt to dereference example.com and I have a cached NS record for .com. So, I query example.com and get back: - An

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

Clipping away a bit where we appear to agree. On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz wrote: > This resembles the ongoing experiment between Facebook and Cloudflare, where both parties have agreed to speak DoT by hardcoding the relevant

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

Dear Colleagues, On 29/10/2019 17.41, IETF Secretariat wrote: The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ I think that this

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

On Tue, Oct 29, 2019 at 12:07 PM Ted Hardie wrote: > On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz wrote: > >> FWIW, my expectation has been that ADoT would use TLSA-like >> authentication, with no trust anchors other than DNSSEC (and nothing >> resembling the WebPKI). >> >> Which certificate

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

On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz wrote: > FWIW, my expectation has been that ADoT would use TLSA-like > authentication, with no trust anchors other than DNSSEC (and nothing > resembling the WebPKI). > > Which certificate usage are you thinking of, in RFC 6698 terms? Generally, I

Re: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

In article you write: > >I appreciate the authors kicking off the effort with this draft that >proposes phase 2 requirements. As do I, but it still needs a lot of work. One thing that would help me a lot is matching up the features with what problem they're supposed to solve. * Keeping

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Does anyone who was on the call, have the URI of the github doc, please? Off-list response is fine. Brian Dickson On Fri, Oct 25, 2019 at 8:04 AM Brian Haberman wrote: > Hi Paul, > > On 10/25/19 10:27 AM, Paul Hoffman wrote: > > On 10/25/19 6:25 AM, Brian Haberman wrote: > >> >

Re: [dns-privacy] fingerprinting in draft-ietf-dprive-bcp-op-04

> On 29 Oct 2019, at 18:05, Dan Wing wrote: > > Yes, thanks -- that covers what I wrote. Thanks! > Thanks! > > I have also noticed concern with HTTP headers disclosing client-identifying > information so might want to also mention > > "HTTP headers (e.g., User-Agent, Accept,

Re: [dns-privacy] fingerprinting in draft-ietf-dprive-bcp-op-04

Yes, thanks -- that covers what I wrote. Thanks! I have also noticed concern with HTTP headers disclosing client-identifying information so might want to also mention "HTTP headers (e.g., User-Agent, Accept, Accept-Encoding)" or similar. -d On Oct 29, 2019, at 5:47 AM, Sara Dickinson

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

On Tue, 29 Oct 2019, Stephen Farrell wrote: I had a quick read and support adoption. There's work to be done but doing it in the WG seems correct to me. I'm not sure I would agree. In a way, dnsop seems more appropriate to me. Sure it is about encryption, but to me dprive feels more to be for

[dns-privacy] Call for Adoption: draft-hzpa-dprive-xfr-over-tls

This starts a Call for Adoption for draft-hzpa-dprive-xfr-over-tls The draft is available here: https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ Please review this draft to see if you think it is suitable for adoption by DPRIVE, and comments to the list, clearly stating your

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

On Tue, Oct 29, 2019 at 8:41 PM IETF Secretariat wrote: > > > The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ > I support

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

I had a quick read and support adoption. There's work to be done but doing it in the WG seems correct to me. Cheers, S. On 29/10/2019 16:45, Border, John wrote: > > Adopt it > > > -Original Message- > From: dns-privacy On Behalf Of IETF Secretariat > Sent: Tuesday, October 29, 2019

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

Top-reply, which I think can potentially address all the underlying issues: Make DANE support a SHOULD, along with publishing corresponding TLSA records at the FQDN of the DNS server a SHOULD. Make the recommendation that the certificate served include the full chain including CA cert. This would

Re: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

+1 From: dns-privacy on behalf of Patrick McManus Sent: Tuesday, October 29, 2019 12:19 PM To: DNS Privacy Working Group Subject: [dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804 I appreciate the authors kicking off

Re: [dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

Adopt it -Original Message- From: dns-privacy On Behalf Of IETF Secretariat Sent: Tuesday, October 29, 2019 12:41 PM To: dns-privacy@ietf.org; draft-hzpa-dprive-xfr-over-...@ietf.org; dprive-cha...@ietf.org Subject: [dns-privacy] The DPRIVE WG has placed

[dns-privacy] The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state "Candidate for WG Adoption"

The DPRIVE WG has placed draft-hzpa-dprive-xfr-over-tls in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-hzpa-dprive-xfr-over-tls/ ___ dns-privacy mailing list

Re: [dns-privacy] wglc feedback draft-ietf-dprive-bcp-op

Sara, I sincerely appreciate the consideration.. > I think one of the concerns here was to ensure equity of service for > clients that choose not to use these mechanism even if they impose a > performance hit on the server. In principle a server could give lower > priority to (or timeout)

[dns-privacy] draft-lmo-dprive-phase2-requirements-00.txt, wiretapping, and RFC 2804

I appreciate the authors kicking off the effort with this draft that proposes phase 2 requirements. On a couple of occasions the draft makes creates requirements wrt law enforcement compliance. e.g. "comply with locally relevant law enforcement [..] (high priority)". While RFC 2804 says "The

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

Hi Paul, On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman wrote: > On 10/29/19 8:02 AM, Ted Hardie wrote: > > To be sure I understand you correctly, in the second case, the > connection would be made to some IP address (e.g. NASA's 198.116.4.181). > The recursive resolver logs the details of the

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

On 10/29/19 8:02 AM, Ted Hardie wrote: > To be sure I understand you correctly, in the second case, the connection > would be made to some IP address (e.g. NASA's 198.116.4.181).  The recursive > resolver logs the details of the certificate, but it continues with the > connection even if the CA

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

Hi Paul, On Tue, Oct 29, 2019 at 7:50 AM Paul Hoffman wrote: > Greetings again. I was surprised, but happy, to not see a requirement in > the list for authentication of servers in the list. However, I suspect that > this might have been an oversight, and the endless debate on authentication >

[dns-privacy] ADoT requirements for authentication?

Greetings again. I was surprised, but happy, to not see a requirement in the list for authentication of servers in the list. However, I suspect that this might have been an oversight, and the endless debate on authentication requirements will start as soon as there is a proposed protocol

Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Here are a few responses to the initial draft. I will try to be on the call unless we lose power again. There are many parts of the "core requirements" that seem out of place. - Resolvers have never had to understand the different between the root zone and TLDs and SLDs and "other", so