Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Manu Bretelle
FYI, I tried to cover some alternatives with their pros/cons during IETF104 DPRIVE meeting: https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01.pdf Seems there is a fair intersection with the one available in this draft. Manu On Mon, Nov 4, 2019

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread John Levine
In article you write: >> That's per-zone, though, whereas DoT support is per-server. > >Maybe that's ideal, but one would expect that a zone only rolls this >out once all their nameservers support it. Most of my zones have a secondary run by somebody else, whose software is never in sync with

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread Brian Dickson
On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters wrote: > On Mon, 4 Nov 2019, Brian Dickson wrote: > > > The names of the servers (and certificate management) would be > orthogonal to the signaling of DoT support. I would expect the TLSA records > would > > be per-server and orthogonal to the

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread Eric Rescorla
On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters wrote: > On Mon, 4 Nov 2019, Brian Dickson wrote: > > > The names of the servers (and certificate management) would be > orthogonal to the signaling of DoT support. I would expect the TLSA records > would > > be per-server and orthogonal to the

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread Brian Dickson
On Mon, Nov 4, 2019 at 12:37 PM Tony Finch wrote: > Paul Wouters wrote: > > > > The right way to do this is a DNSKEY flag, which is protected by the > > signed DS at the parent. Similar to draft-powerbind for the > > delegation-only domain. > > That's per-zone, though, whereas DoT support is

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread Paul Wouters
On Mon, 4 Nov 2019, Tony Finch wrote: Subject: Re: [dns-privacy] [Ext] Threat Model Paul Wouters wrote: The right way to do this is a DNSKEY flag, which is protected by the signed DS at the parent. Similar to draft-powerbind for the delegation-only domain. That's per-zone, though, whereas

Re: [dns-privacy] [Ext] Threat Model

2019-11-04 Thread Tony Finch
Paul Wouters wrote: > > The right way to do this is a DNSKEY flag, which is protected by the > signed DS at the parent. Similar to draft-powerbind for the > delegation-only domain. That's per-zone, though, whereas DoT support is per-server. DS records that somehow encode NS target names in

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread John R Levine
On Sun, 3 Nov 2019, John Levine wrote: I thought it might be useful to make a list of possible ways to signal that a server offers ADoT: https://datatracker.ietf.org/doc/draft-levine-dprive-signal/ Did another version with more possibilities. Regards, John Levine, jo...@taugh.com,

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Christian Huitema
On 11/4/2019 7:12 AM, Eric Rescorla wrote: > > > On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer > wrote: > > On Sun, Nov 03, 2019 at 05:33:34PM -0500, >  John Levine mailto:jo...@taugh.com>> wrote >  a message of 14 lines which said: > > > I thought

Re: [dns-privacy] Threat Model

2019-11-04 Thread Livingood, Jason
In the -01 I added a parenthetical to address this suggestion and later WG discussion. Not sure if we’re there yet so open to specific wording suggestions. //from GH repo// # Threat Model and Problem Statement Currently, potentially privacy-protective protocols such as DoT provide encryption

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

2019-11-04 Thread Tommy Pauly
> On Nov 2, 2019, at 4:57 AM, Stephane Bortzmeyer wrote: > > On Fri, Nov 01, 2019 at 03:40:51PM -0700, > Tommy Pauly wrote > a message of 393 lines which said: > >> We've posted new versions of our drafts on discovering designated DoH >> servers, and Oblivious DoH: > > If you want to

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Eric Rescorla
On Mon, Nov 4, 2019 at 7:32 AM Stephane Bortzmeyer wrote: > On Mon, Nov 04, 2019 at 07:12:46AM -0800, > Eric Rescorla wrote > a message of 96 lines which said: > > > I'm less worried about the latter because I would expect recursive > > resolvers to generally be operated by people who are

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread John R Levine
On Mon, 4 Nov 2019, Stephane Bortzmeyer wrote: Not all resolvers are big boxes in the central datacenter. I may want to run a resolver on a small box at home even if my ISP blocks port 853. I don't think anyone expects port 53 to go away. I tend to agree with Stephen Farrell here. If we

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Eric Rescorla
On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer wrote: > On Sun, Nov 03, 2019 at 05:33:34PM -0500, > John Levine wrote > a message of 14 lines which said: > > > I thought it might be useful to make a list of possible ways to signal > > that a server offers ADoT: > > I would like also a

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Stephane Bortzmeyer
On Sun, Nov 03, 2019 at 05:33:34PM -0500, John Levine wrote a message of 14 lines which said: > I thought it might be useful to make a list of possible ways to signal > that a server offers ADoT: I would like also a discussion on whether signaling is 1) good 2) necessary. Even if you get a

Re: [dns-privacy] ADoT signalling

2019-11-04 Thread Stephane Bortzmeyer
On Sun, Nov 03, 2019 at 05:33:34PM -0500, John Levine wrote a message of 14 lines which said: > I thought it might be useful to make a list of possible ways to signal > that a server offers ADoT: > > https://datatracker.ietf.org/doc/draft-levine-dprive-signal/ > > I'm sure there are others,