Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

2019-03-24 Thread manu tman
Thanks Ilari, > This proposal actually reminds me a lot of idea I had that actually > used DS records instead of new record type. > > AFAIK: > - DNSsec ignores any such record (unknown algorithm) > -> No interference with DNSsec. > - CDS does not ignore such records. > -> Automated

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

2019-03-23 Thread manu tman
to leave for the airport, but I’d be happy to discuss > this further in a side-meeting or ad-hoc. > > > > Thanks, > > > > Jon > > > > > > -- > > Jon Reed > > Senior Performance Engineer > > Nameservers Service Performance > > > &

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

2019-03-15 Thread manu tman
> > >> 6. IANA Considerations > > " TODO: This document requires IANA actions (new RR type)." > > What new RR type is needed? Looks to me like all standard RR's. > > Thanks Bob! My mistake, this is a left over from copy/pasta. I removed it from master. Manu -- > Bob Harold > >

Re: [dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

2019-03-11 Thread manu tman
Mon, Mar 11, 2019 at 12:12 PM A. Schulze wrote: > > > Am 11.03.19 um 17:20 schrieb manu tman: > > I have captured in a draft the mechanism I used during IETF 103 > hackathon and which is available aan experimental module in > knot-resolver[0]. > > I was taken short with

[dns-privacy] New Version Notification for draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

2019-03-11 Thread manu tman
During earlier discussion (post virtual meeting), there were a mixture of feeling as to where SPKI may be published, here is one proposal bump (through the rush of time) to publish it in the parent zone. Manu ——— A new version of I-D, draft-bretelle-dprive-dot-for-insecure-delegations-01.txt

[dns-privacy] New Version Notification for draft-bretelle-dprive-dot-spki-in-ns-name-00.txt

2019-03-11 Thread manu tman
Hi all, I have captured in a draft the mechanism I used during IETF 103 hackathon and which is available aan experimental module in knot-resolver[0]. I was taken short with time before cit-off date, but I hope this will better explain how it works. Manu [0]

Re: [dns-privacy] Is there a draft for Knot "Experimental DNS-over-TLS Auto-discovery"

2019-03-11 Thread manu tman
Right in time before the cut-off date I captured it in a draft: https://www.ietf.org/id/draft-bretelle-dprive-dot-spki-in-ns-name-00.txt Manu On Thu, Dec 27, 2018 at 9:05 AM manu tman wrote: > > > On Thu, Dec 27, 2018 at 8:28 AM Stephane Bortzmeyer > wrote: > >&

Re: [dns-privacy] DoT between recursive and authoritative pilot

2018-12-27 Thread manu tman
> > >> >> I do not find how the Cloudflare resolver discovers that Facebook >> authoritative name servers use DNS-over-TLS, and what are their >> keys. Hardwired in the resolver for the experiment? > > >> > The subject for the cert is not especially illuminating, though. I tried > sending the

[dns-privacy] DoT between recursive and authoritative pilot

2018-12-21 Thread manu tman
Hi list, As some you already know, Cloudflare and Facebook have been running a pilot on using DoT between Cloudflare DNS and Facebook authoritative name servers. You can read more about it at https://code.fb.com/security/dns-over-tls/ Thanks Manu ___

Re: [dns-privacy] It's DNS Jim....

2018-12-20 Thread manu tman
On Thu, Dec 20, 2018 at 1:20 AM Ralf Weber wrote: > > > > Now onto delegation, we have a clear way of delegating information down > the tree to a different entity. All the information needed is handed > down from the parent (NS and Glue for DNS plus DS for DNSSEC). This > seems to be the natural

Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

2018-12-13 Thread manu tman
> > On Fri 2018-12-14 02:22:12 +0530, Mukund Sivaraman wrote: > > The trailing '='s are part of the base32 encoding. > > > > [muks@naina ~]$ echo -n > "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA" | base32 -d > > abcdefghijklmnopqrstuvwxyz789012[muks@naina ~]$ echo -n >

Re: [dns-privacy] Implementer Perspective

2018-10-15 Thread manu tman
On Mon, Oct 15, 2018 at 5:20 AM Brian Haberman wrote: > All, > This week (10/15 - 10/21) let's focus on the implementer's > perspective on DNS privacy between recursive resolvers and authoritative > servers. >From authoritative server perspective, but really the question can be flipped

Re: [dns-privacy] Authenticating DoT nameservers for insecure delegations

2018-09-28 Thread manu tman
On Fri, Sep 28, 2018 at 9:09 AM Paul Hoffman wrote: > On 28 Sep 2018, at 8:32, manu tman wrote: > > > I have been thinking of a way to authenticate DoT servers for delegations > > that cannot be validated using DANE as describe in Stephane’s draft > > https://tools.ietf.o

[dns-privacy] Authenticating DoT nameservers for insecure delegations

2018-09-28 Thread manu tman
Hi all, I have been thinking of a way to authenticate DoT servers for delegations that cannot be validated using DANE as describe in Stephane’s draft https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01 The idea is to leverage both DNSSEC and SPKI to authenticate a zone but by

Re: [dns-privacy] User Perspective

2018-07-28 Thread manu tman
1) User may be willing to send PII (such as ECS) to authority if the transaction is encrypted. 2) user may be willing to be signaled that the response is “validated” if the authoritative answer was obtained over an authenticated link for unsigned zones ( similar to 4. from Paul) Manu >