[dns-privacy] Updated draft-pp-recursive-authoritative-opportunistic to cover recent discussions here

Greetings again. It is good to see much more discussion here about how we might to recursive-to-authoritative encryption. Based on this, I have updated . - There may be interest in using authenticated results in

Re: [dns-privacy] Logistics for IETF 109

Brian, I will be glad to take minutes in CodiMD - https://codimd.ietf.org/notes-ietf-109-dprive?both I would welcome anyone else helping, too. Dan On Nov 19, 2020, at 2:44 PM, Brian Haberman mailto:br...@innovationslab.net>> wrote: All, The material for the upcoming session are in the

Re: [dns-privacy] Logistics for IETF 109

All, The material for the upcoming session are in the materials page. Do I have anyone willing to take minutes for our session?? Regards, Brian On 11/11/20 4:47 PM, Brian Haberman wrote: > The chairs have posted the initial agenda for IETF 109... > >

[dns-privacy] DOTPIN, TLSA, and DiS

Please bear with me while I take you on a rollercoaster :-) We introduce our three actors: DOTPIN: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ - pin TLS key material in a DS record. Scales badly if one NSset hosts 100k domains, basically preventing you from

Re: [dns-privacy] how can we ADoT?

On Wed, 2020-11-18 at 23:09 +, Tony Finch wrote: > > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip] > > > > For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending > > a server name at all (which matches what I said earlier - name servers > > have IPs,