[dns-privacy] Amortization techniques for less popular name server names

[Brian Dickson]

One issue that is likely to arise regardless of the specific technique used for 
signaling availability of ADoT is the cost differential between popular and 
less popular name servers (referring to number of zones and/or aggregate zone 
popularity).

It is clear that the costs to revolvers will be amortized significantly if 
those costs depend on that popularity.

I would like to offer some suggestions for techniques that may be able to 
improve the costs towards less popular name servers.

These are not the only viable methods, nor is it the case that such methods are 
for certain necessary. However, if there arises a need for such a solution, I 
think it could be useful to have a possible solution in advance to address that 
hypothetical need. I don’t mind spending this effort, and am not married to the 
idea. If it isn’t needed, or if other solutions work better, that’s great.

These suggestions are in part to generally improve performance of DNS generally 
and to support privacy as much as possible. It is also partly to mitigate any 
possible  perception that there is any intent to leverage market position to 
influence the ADoT standardization process. Any ADoT solution should be 
evaluated neutrally, on the basis of meeting requirements, especially on a 
scalability perspective. Choosing a solution that scales badly but does so 
equally, would be a bad outcome IMHO.

So, what possible techniques could improve scaling for less popular name 
servers?
That depends on what those costs are and what scaling attributes they have.
I believe that the main costs would be computational costs and latency.
Latency can potentially be addressed by considering when any queries that are 
required occur. Early cache population  (rather than “just in time”) can reduce 
or eliminate such latency. (This is the classic space vs time trade-off.) Also 
worth considering are methods that replace queries and caches with use of 
secondary server functionality (on resolvers in particular) and notifies zone 
transfers. These have the additional potential benefit of being TTL-agnostic: 
they are as “live” as low TTL records, but as stable and performant as long TTL 
records.

Attempting to do XFR for many name servers which are infrequently used would 
have scalability issues from any resolver, if the server names are in a large 
number of zones. One approach to reducing this issue is aggregating server 
names inside many fewer zones. Doing this aggregation creates trust issues, 
however. This trust issue can possibly be addressed by using multiple (but 
still many fewer) zones containing aggregated sets of name server names, 
operated by different parties, and possibly registered in different TLDs and 
served in different jurisdictions. The presumption is independent operation 
reduces the risks of collusion, the impacts of operator error, and the risk of 
legal issues causing operational problems.

This is not without operation complexity. For instance, if secondary service 
was used, the operators of the aggregating zones would likely need to find a 
way of managing the client base of resolvers, or of publishing information to 
allow clients to validate transferred zones themselves.

There would still be operational cost, particularly if signed zones meant 
individual records required validation. One possible method of reducing the 
need for validation of signed records retrieved by XFR is the use of ZONEMD. It 
might allow for deferred validation or no validation of individual records, 
depending on what the resolver operator considered acceptable. (The zone digest 
would still need to be calculated and verified, but that is likely much less 
expensive.)

The example set up would be something like:

DNS operator:
snowflake.example.org NS small-ns-operator.dns-cooperative-one.example.net

Aggregate operator:
dns-cooperative-one.example.net ZONEMD value
dns-cooperative-one.example.net DNSKEY value
small-ns-operator.dns-cooperative-one.example.net  v6addr
privacy-thing.small-ns-operator.dns-cooperative-one.example.net TYPE value // 
eg TLSA record

ResolverX:
zone “ dns-cooperative-one.example.net” {
 type secondary;
 primary v6addr-of-primary;
 use-zonemd;
};

The end result in this example would be that ResolverX could have pre-populated 
ADoT info for rarely used nameservers, and be able to perform 
privacy-preserving queries to them with minimal incremental latency. 
(Establishing TLS session keys in advance would be one feasible way of speeding 
it up. Another would be maintaining open TLS sessions to every authority 
server, which might not be an available option depending on the policies of the 
authority server operators.)

Further scalability might be possible by using similar techniques such as 
catalog zones for publishing aggregator zones.

DNS software developers might ship example configs containing real aggregator 
zones to facilitate use of them.

The mutual benefit between small DNS authority operators and 

Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Brian Dickson]

On Sun, Nov 15, 2020 at 6:08 AM Peter van Dijk 
wrote:

> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> > The most unambiguous signal possible, is the presence of a TLSA record
> on _853._tcp..
>
> That's quite a far reaching statement, and I believe it likely to be
> wrong.
>
>
I think we can move this part of the discussion to the larger
thread/document started by Tony Finch.


> > Using NS names in a separate zone or zones (for each DNS operator) is
> scalable, and facilitates DNSSEC signing, at little to no incremental cost
> and little to no operational complexity
>
> The incremental cost for a resolver (doing a full resolution process
> for the TLSA records of one or more NS names) is not small, and neither
> are the latency costs. For 'popular' name servers, this cost can mostly
> be amortised, leaving the penalty with any domain hosted on a NSset
> that only has a few domains.
>

Okay, so my statement implied "to the operator of the name server(s)", not
the resolvers.

Resolver operators need to make their own decisions on whether to offer
privacy services, including whether there are any limits on which authority
servers they implement those privacy services towards.

I don't believe anyone has stated that there would not be any latency cost
or other cost (e.g. compute) for privacy services.

So, IMHO, any discussion on those costs needs to be done in relation to the
other attributes, such as "correctness" of the proposal.
Correctness would involve things like:

   - accommodating multiple server operators with different privacy
   settings (yes/no)
   - anycast dns server addresses where specific anycast instances may have
   different privacy settings (yes/no)
   - ability to differentiate privacy settings at a zone level via some
   mechanism
   - correct source of truth for privacy settings (i.e. must be the dns
   server operator, not the zone owner, to be the actual source of truth)
  - A clear example of the reason this source of truth is required, can
  be seen in the problem with NS records configured by the zone
owner rather
  than the DNS server operator: lame delegations.
   - cost to authoritative server operators (and scalability)

Again, this discussion should proceed in the other thread (Tony Finch's).


>
> > Using TLSA records at _853._tcp. in a signed zone provides an
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.
>
> Not downgrade-resistant, until NS names in delegations become signed.
>

That's a moot point.
TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
based on the

   DNSSEC validation state (as defined in [RFC4033
]).


So, downgrade-resistant, period. (Use of TLSA presupposes signed, in
other words.)



> (I proposed some solutions for that in other threads; Fujiwara has
> [independently, I think] now written a draft resembling one of those
> solutions
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
> )
>
> 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
>
___
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-11 at 19:07 +, Tony Finch wrote:
> 
>   * Encryption would apply to the server as a whole, whereas the
> working group consensus is that it should be possible for
> different zones on the same server to use encrypted and
> unencrypted transports.

(plus, in another email, Tony wrote: "A nice thing about TLSA records
is they also tell the client what name to look for in the server's
cert.")

This looks like a mistake to me, or at least, a choice that would have
to be made very deliberately.

Today, the name through which I reach an NS does not matter - it is not
part of the protocol exchange like the HTTP Host header is. This
simplifies a lot of things, and allows some leeway for mismatches in
names between parents, childs, etc., as long as they reach the same IP.
 
It also seems that any 'split' between which zones on a certain IP
support encryption and which zones do not, would make any opportunistic
proposal obsolete immediately.

I'd like to assume that all transports offered by an NS host the ~same
data (ignoring, for a moment, that we might one day imagine data that
should only be seen over transports with certain security properties,
but I'm imagining that such data would not cover whole zones).

In fact, it would be good if I don't assume. Instead, we should
actively decide whether any such splits are allowed, or forbidden.

I note that the phase2 doc has this text:

9.   A given name server may be authoritative for multiple zones.  As
such, a name server MAY support use of a secure transport
protocol for one zone, but not for another.

So in fact, right now we have written down that this is allowed. But I
think it is a mistake.

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] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Peter van Dijk]

On Sun, 2020-11-15 at 16:52 +, Paul Hoffman wrote:
> Thanks for the response! I hope that there is more list discussion before the 
> WG meeting this week.
> 
> On Nov 15, 2020, at 5:52 AM, Peter van Dijk  
> wrote:
> > The cost of port checking is not low.
> 
> We disagree in the general case, because I'm assuming a transport cache that 
> is filled before an actual query is sent. Transport caches would be useful 
> for both opportunistic and authenticated encryption.

That makes sense, but there's a risk of penalizing the 'small domain
owner' here.

> We agree in the specific case of "determine the transport at the time the 
> resolver's user is waiting for an answer".

+1

> > Variant 1: try 853 and 53 in parallel. High code complexity and a high 
> > likelihood that the first query to a 'new' auth (where 'new' might be 
> > measured in minutes) will be plain text anyway.
> 
> There is no code complexity if you are probing the fill a transport cache. 
> There is definitely the large, classical complexity of asyncy-with-abort for 
> determining when needed.
> 
> > Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms 
> > is a long time.
> 
> For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate 
> need, there is no way to sanely balance "additional privacy" against 
> "addition latency" in a way that everyone (or even most people) would agree 
> to.

Agreed. It's a big spectrum from DOTPIN (~no additional latency, lots
of privacy, but some serious deployment impediments) to some
interpretation of 'just do TLSA' (lots of additional latency) and any
other proposal is likely to fall somewhere on that spectrum, with some
room to be even worse than TLSA. Anything involving potential timeouts
does look bad from the start, to me.

> > This is not happy eyeballs where both transports (v4 and v6) tend to have 
> > identical security properties. 
> 
> Exactly right.
> 
> > DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing 
> > and guessing in the resolver process. I'd love for us to not add probing 
> > and guessing in other parts of that process.
> 
> I would love for that as well, if we make the solution barely harder to 
> implement than port-checking. I am skeptical that we as a group can make a 
> simple solution because everything we as a group do ends up much more 
> complicated than we expected when we started. 

We are terrible people :-)

> This is why I think we should compare the result to port-checking.

It is a useful baseline for comparison, indeed.

> The interesting wrinkle here is that if the solution is DNS-based, it will 
> very likely be faster than port-checking because in most cases the result 
> will come back much faster than any timeout that someone would pick for 
> port-checking. The answer will likely also have much more value than a port 
> check. That gives us (at least) two axes to compare and argue about, so I 
> think it is worth pursuing. Tony's draft has a lot of good comparison 
> thinking in it already.

Yes.

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] [Ext] Revised opportunistic encryption draft

[Paul Hoffman]

On Nov 15, 2020, at 6:08 AM, Peter van Dijk  wrote:
> 
> On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>> The most unambiguous signal possible, is the presence of a TLSA record on 
>> _853._tcp..
> 
> That's quite a far reaching statement, and I believe it likely to be
> wrong.

+1. The analysis in Tony's draft shows that simple assumptions are probably 
simplistic.

--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] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Paul Hoffman]

Thanks for the response! I hope that there is more list discussion before the 
WG meeting this week.

On Nov 15, 2020, at 5:52 AM, Peter van Dijk  wrote:
> 
> On Wed, 2020-11-04 at 15:04 +, Paul Hoffman wrote:
>> It would be useful if a resolver could tell in advance, and at a cost less 
>> than port-checking. There could be a new protocols developed to do that. I 
>> don't see this as a requirement, though, given the low cost of port-checking.
> 
> The cost of port checking is not low.

We disagree in the general case, because I'm assuming a transport cache that is 
filled before an actual query is sent. Transport caches would be useful for 
both opportunistic and authenticated encryption.

We agree in the specific case of "determine the transport at the time the 
resolver's user is waiting for an answer".

> Variant 1: try 853 and 53 in parallel. High code complexity and a high 
> likelihood that the first query to a 'new' auth (where 'new' might be 
> measured in minutes) will be plain text anyway.

There is no code complexity if you are probing the fill a transport cache. 
There is definitely the large, classical complexity of asyncy-with-abort for 
determining when needed.

> Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is 
> a long time.

For cache-filling, a 500 or 1000 ms timeout seems reasonable. For immediate 
need, there is no way to sanely balance "additional privacy" against "addition 
latency" in a way that everyone (or even most people) would agree to.

> This is not happy eyeballs where both transports (v4 and v6) tend to have 
> identical security properties. 

Exactly right.

> DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and 
> guessing in the resolver process. I'd love for us to not add probing and 
> guessing in other parts of that process.

I would love for that as well, if we make the solution barely harder to 
implement than port-checking. I am skeptical that we as a group can make a 
simple solution because everything we as a group do ends up much more 
complicated than we expected when we started. This is why I think we should 
compare the result to port-checking.

The interesting wrinkle here is that if the solution is DNS-based, it will very 
likely be faster than port-checking because in most cases the result will come 
back much faster than any timeout that someone would pick for port-checking. 
The answer will likely also have much more value than a port check. That gives 
us (at least) two axes to compare and argue about, so I think it is worth 
pursuing. Tony's draft has a lot of good comparison thinking in it already.

--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] [Ext] Revised opportunistic encryption draft

[Peter van Dijk]

On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
> The most unambiguous signal possible, is the presence of a TLSA record on 
> _853._tcp..

That's quite a far reaching statement, and I believe it likely to be
wrong.

> Using NS names in a separate zone or zones (for each DNS operator) is 
> scalable, and facilitates DNSSEC signing, at little to no incremental cost 
> and little to no operational complexity

The incremental cost for a resolver (doing a full resolution process
for the TLSA records of one or more NS names) is not small, and neither
are the latency costs. For 'popular' name servers, this cost can mostly
be amortised, leaving the penalty with any domain hosted on a NSset
that only has a few domains.

> Using TLSA records at _853._tcp. in a signed zone provides an 
> unambiguous signal to use optionally TLSA, in a downgrade-resistant manner.

Not downgrade-resistant, until NS names in delegations become signed.
(I proposed some solutions for that in other threads; Fujiwara has
[independently, I think] now written a draft resembling one of those
solutions 
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1
)

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] [Ext] I-D Action: draft-ietf-dprive-phase2-requirements-02.txt

[Peter van Dijk]

On Wed, 2020-11-04 at 15:04 +, Paul Hoffman wrote:
> It would be useful if a resolver could tell in advance, and at a cost less 
> than port-checking. There could be a new protocols developed to do that. I 
> don't see this as a requirement, though, given the low cost of port-checking.

The cost of port checking is not low.

Variant 1: try 853 and 53 in parallel. High code complexity and a high 
likelihood that the first query to a 'new' auth (where 'new' might be measured 
in minutes) will be plain text anyway.

Variant 2: try 853 first. How long do we wait for a timeout? In DNS, 500ms is a 
long time.

This is not happy eyeballs where both transports (v4 and v6) tend to have 
identical security properties. 

DNS Flag Day 2019 (no more EDNS fallbacks) was designed to reduce probing and 
guessing in the resolver process. I'd love for us to not add probing and 
guessing in other parts of that process.

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] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

[Peter van Dijk]

On Wed, 2020-08-12 at 12:51 +0200, Peter van Dijk wrote:
> Delegation NS records are not signed, so do we stick -those- (or a hash
> of the NSset perhaps?) into DS?

https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/?include_text=1

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