Re: [dns-privacy] TLSA for secure resolver-auth transport

2020-08-12 Thread Paul Wouters
On Aug 12, 2020, at 19:50, Vladimír Čunát wrote: > >  >> On 8/12/20 9:50 PM, Paul Wouters wrote: >>> Delegation NS records are not signed, so do we stick -those- (or a hash >>> of the NSset perhaps?) into DS? >> >> I don't think so. The DS is signed, and following that path, it hardly >>

Re: [dns-privacy] TLSA for secure resolver-auth transport

2020-08-12 Thread Vladimír Čunát
On 8/12/20 9:50 PM, Paul Wouters wrote: >> Delegation NS records are not signed, so do we stick -those- (or a hash >> of the NSset perhaps?) into DS? > > I don't think so. The DS is signed, and following that path, it hardly > matters where the NS records point to. Do you fear that you will

Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

2020-08-12 Thread Vladimír Čunát
On 8/12/20 8:39 PM, John Levine wrote: >> I am against adoption for two reasons. The draft as it currently is, >> requires that domain name owners and nameserver hosting administrators >> synchronise their nameserver TLS keys. > Why wouldn't you publish multiple DS records for multiple nameserver

Re: [dns-privacy] [Ext] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

2020-08-12 Thread Paul Hoffman
On Aug 12, 2020, at 12:50 PM, Paul Wouters wrote: > The "obvious" part only referred to "use DNS records to authenticate > DNS authoritative servers". That phrase over-simplified. A more accurate phrasing would be "use a chain of DNS records to authenticate DNS authoritative servers". There are

Re: [dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

2020-08-12 Thread Paul Wouters
On Wed, 12 Aug 2020, Peter van Dijk wrote: On Mon, 10 Aug 2020, Peter van Dijk wrote: On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote: In the case of encrypted DNS to authoritative servers, those servers obviously can have an cryptographic ID based on FQDN. This is not obvious. It

Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

2020-08-12 Thread John Levine
In article you write: >I am against adoption for two reasons. The draft as it currently is, >requires that domain name owners and nameserver hosting administrators >synchronise their nameserver TLS keys. Why wouldn't you publish multiple DS records for multiple nameserver keys, like the draft

Re: [dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

2020-08-12 Thread Ilari Liusvaara
On Wed, Aug 12, 2020 at 12:51:34PM +0200, Peter van Dijk wrote: > (I changed the subject because this has turned into a solution > conversation, instead of a use case conversation) > > On Tue, 2020-08-11 at 21:49 -0400, Paul Wouters wrote: > > On Mon, 10 Aug 2020, Peter van Dijk wrote: > > > > >

Re: [dns-privacy] [Ext] Possible use case: Opportunistic encryption for recursive to authoritative

2020-08-12 Thread Paul Hoffman
On Aug 12, 2020, at 5:44 AM, Vladimír Čunát wrote: > > On 8/6/20 4:59 PM, Paul Hoffman wrote: >> In this use case, a resolver operator says “I’m happy to use encryption with >> the authoritative servers if it doesn’t slow down getting answers by much”, >> and an authoritative server says “I’m

[dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

2020-08-12 Thread Peter van Dijk
(I changed the subject because this has turned into a solution conversation, instead of a use case conversation) On Tue, 2020-08-11 at 21:49 -0400, Paul Wouters wrote: > On Mon, 10 Aug 2020, Peter van Dijk wrote: > > > On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote: > > > In the case of