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

[Paul Hoffman]

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 order for caches to 
promote parent-side NS records to a higher standing than they currently have in 
the caches, or something like that. If so, that should be part of the 
opportunistic draft because opportunistic means "try to authenticate if there 
is any value at all".

- It now seems more likely that someone will write a "always authenticate" 
draft; if so, the discussion of the transport cache would be useful to both, so 
it could be split out as a separate document.

See y'all later for the WG meeting!

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Logistics for IETF 109

[Dan York]

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 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...

https://datatracker.ietf.org/meeting/109/materials/agenda-109-dprive-00

Regards,
Brian

On 10/26/20 7:55 AM, Brian Haberman wrote:
Hi all,
As you may have seen, we have a 2-hour session allocated to us for
IETF 109. The chairs are going to split the session into two primary
pieces. The first part (30-40 minutes) will be dedicated to updates on
DPRIVE drafts. We are working with the authors of the DoQ and
xfr-over-tls drafts for this part. The second part (75+ minutes) will be
a working session for the phase 2 requirements draft. The goal will be
to identify and discuss edits to the draft in order to make it
representative of the requirements for encrypting exchanges between
recursive resolvers and authoritative servers.

We will push out an agenda as we get more details worked out. If
you have any questions, please let the chairs know.

Regards,
Brian


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Logistics for IETF 109

[Brian Haberman]

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...
> 
> https://datatracker.ietf.org/meeting/109/materials/agenda-109-dprive-00
> 
> Regards,
> Brian
> 
> On 10/26/20 7:55 AM, Brian Haberman wrote:
>> Hi all,
>>  As you may have seen, we have a 2-hour session allocated to us for
>> IETF 109. The chairs are going to split the session into two primary
>> pieces. The first part (30-40 minutes) will be dedicated to updates on
>> DPRIVE drafts. We are working with the authors of the DoQ and
>> xfr-over-tls drafts for this part. The second part (75+ minutes) will be
>> a working session for the phase 2 requirements draft. The goal will be
>> to identify and discuss edits to the draft in order to make it
>> representative of the requirements for encrypting exchanges between
>> recursive resolvers and authoritative servers.
>>
>>  We will push out an agenda as we get more details worked out. If
>> you have any questions, please let the chairs know.
>>
>> Regards,
>> Brian
>>



signature.asc
Description: OpenPGP digital signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] DOTPIN, TLSA, and DiS

[Peter van Dijk]

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 ever rolling keys. Written in the 
assumption that software changes at registries are hard, so it only asks them 
to allow one more DNSKEY Algorithm number. Has great latency properties.

TLSA: frequently touted as an ADoT signal/pin mechanism that would not have all 
the problems DOTPIN has. Makes sense, but requires some inventive thinking 
because delegation NSsets are not signed.

DiS: 
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/
 - a parent side signature over delegation data (NS records and glue), 
published as another DS record. Written in the assumption that we can actually 
change registry software (in this case, specifically, the DNSSEC signer).


We give our actors roles in a The Shining/MacGyver fanfic crossover:

DiS assumes registry processes can be changed a little. If we trust that they 
can change more than just a little, the following combination of factors can be 
proposed:
1. auth operators publish TLSA records for their NSes
2. the registry, while generating zone files, queries for those TLSA records
3. from the found TLSA records, the registry generates DOTPIN DSes
4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and 
perhaps the DiS

This offers us:
1. TLSA-based keyrolls from a single 'source of truth' (the auth operator), at 
low delay (however often the registry re-lookups the TLSA and pushes a zonefile 
update)
2. a secure shortcut straight through the problematic unsigned nature of 
delegation NSsets
3. zero additional latency delivery of signal/pinning information to resolvers

However:
1. the complex moving parts are now in the registry, instead of in 10-20 pieces 
of (mostly open source) DNS software
2. as a whole, it's not pretty
3. an operator hosting 100k domains can make the TLD zone file grow by 100k 
records by publishing one additional (TLSA) record for one of their NSes

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

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

[Peter van Dijk]

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, not really names).
> 
> Do you mean not sending in TLS SNI? Yes, that would make sense if we're
> not doing name-based auth.

Yes.

> > >   * Ignore certificate name mismatches, and authenticate just the public
> > > key. [snip]
> > 
> > As above. (Not saying that it is the only way, but 'a name server has
> > no name' has a lot of convenient properties.)
> 
> There's another downside to this case: with IP-based or name-based auth,
> you can put the CA's public key in the TLSA rather than the server key, so
> there's less rollover churn, but that doesn't make sense for key-based
> auth.

Ah, of course. Then you have the downsides of TLSA with the downsides
of DOTPIN.

> I think there are significant (albeit woolly) advantages to staying as
> close as possible to normal webPKI for DoT: much lower congnitive load for
> operators who can reuse their https knowledge; deveopers don't have to
> write code that's too weirdly different from https; very straightforward
> parallel deployment for DoT, DoH, DoQ (if we ever want to support more
> transports).

That makes sense.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy