Re: [dns-privacy] ADoT signalling

[Manu Bretelle]

FYI, I tried to cover some alternatives with their pros/cons during IETF104
DPRIVE meeting:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01.pdf

Seems there is a fair intersection with the one available in this draft.

Manu

On Mon, Nov 4, 2019 at 11:55 AM John R Levine  wrote:

> On Sun, 3 Nov 2019, John Levine wrote:
> > I thought it might be useful to make a list of possible ways to signal
> > that a server offers ADoT:
> >
> > https://datatracker.ietf.org/doc/draft-levine-dprive-signal/
>
> Did another version with more possibilities.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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] [Ext] Threat Model

[John Levine]

In article  you write:
>> That's per-zone, though, whereas DoT support is per-server.
>
>Maybe that's ideal, but one would expect that a zone only rolls this
>out once all their nameservers support it.

Most of my zones have a secondary run by somebody else, whose software
is never in sync with mine.  It's also fairly common for large operators
to mitigate their DNS risk by spreading DNS across multiple providers.
If you have to wait until every server can do ADoT rather than until
some of them can, that will make deployment a lot slower.

> Otherwise, whether or not
>resolvers do DoT to authoritative servers would be an odd game of
>russian roulette depending on which NS record was followed, something
>that could even be tweaked by an attacker, like by stripping glue from
>the ones that did support it.

There are plenty of signal schemes that don't fail that way.  See my
recent draft.

>> DS records that somehow encode NS target names in their rdata might
>> work...
>
>That still leaves too much control at the parent to change it against
>the child's wishes. A DNSKEY flag commits the child zone using publication
>at its parent without giving the parent a veto.

The parent zone always has a veto.  It can remove the NS or DS records if it
doesn't like what the child is doing.

R's,
John

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

Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson]

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters  wrote:

> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>

IMNSHO, that is something the domain owner needs to consider, much more so
than the resolver operator.

Specifically, this is something that should probably go into a BCP about
DoT:

If you plan on doing DoT and using TLSA records, it is RECOMMENDED that the
same level of redundancy for DoT servers is deployed as would be the
general case for DNS (i.e. two minimum).

(Along with an explanation of why not having TLSA records for at least two
distinct server names would create an availability/security weakness.)

Other than the question of just one TLSA, I think the recommendation on
what to do if only a subset of NS RRSET members have TLSA records, is to
try to use all the ones that have TLSA records, repeatedly, before doing
anything else.
The "anything else" could be any of several things, from some variation of
"serve stale" to SERVFAIL to using Do53.

Brian


>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>
> Paul
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Ext] Threat Model

[Eric Rescorla]

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters  wrote:

> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>

This is a good point, and seems like an argument against all of the
opportunistic versions as well, even those with HSTS-style mechanisms.

Suppose I look up a.example.com and get ns1.nameservers.example and
ns2.nameservers.example, and I have talked to ns1 and know it does Dot but
I don't know about ns2. What then? Or say I can't connect to ns1

-Ekr

Paul
>
> ___
> 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] [Ext] Threat Model

[Brian Dickson]

On Mon, Nov 4, 2019 at 12:37 PM Tony Finch  wrote:

> Paul Wouters  wrote:
> >
> > The right way to do this is a DNSKEY flag, which is protected by the
> > signed DS at the parent. Similar to draft-powerbind for the
> > delegation-only domain.
>
> That's per-zone, though, whereas DoT support is per-server.
>

Well, it kind of depends, i.e. yes and no.

E.g. a DNS hosting provider might (or might not) apply the DoT support to
all the zones hosted on a given server, which has the effect of being
per-server, while still being implemented at a per-zone level.

Per-zone also is much friendlier to multi-provider (primary/secondary), in
those cases, i.e. prevents targeted downgrades on such zones (presuming the
secondary actually serves on the DoT port).

The names of the servers (and certificate management) would be orthogonal
to the signaling of DoT support. I would expect the TLSA records would be
per-server and orthogonal to the per-zone signaling of DoT support.

(The analogy would be routing registries and routing announcements. You
have to have the registration done first before the announcement, but the
registration and the announcement are distinct elements. Similar also to DS
and DNSKEY records.)

Brian


>
> DS records that somehow encode NS target names in their rdata might
> work...
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> partnership and community in all areas of life
>
> ___
> 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] [Ext] Threat Model

[Paul Wouters]

On Mon, 4 Nov 2019, Tony Finch wrote:


Subject: Re: [dns-privacy] [Ext] Threat Model

Paul Wouters  wrote:


The right way to do this is a DNSKEY flag, which is protected by the
signed DS at the parent. Similar to draft-powerbind for the
delegation-only domain.


That's per-zone, though, whereas DoT support is per-server.


Maybe that's ideal, but one would expect that a zone only rolls this
out once all their nameservers support it. Otherwise, whether or not
resolvers do DoT to authoritative servers would be an odd game of
russian roulette depending on which NS record was followed, something
that could even be tweaked by an attacker, like by stripping glue from
the ones that did support it.


DS records that somehow encode NS target names in their rdata might
work...


That still leaves too much control at the parent to change it against
the child's wishes. A DNSKEY flag commits the child zone using publication
at its parent without giving the parent a veto.

Paul

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

Re: [dns-privacy] [Ext] Threat Model

[Tony Finch]

Paul Wouters  wrote:
>
> The right way to do this is a DNSKEY flag, which is protected by the
> signed DS at the parent. Similar to draft-powerbind for the
> delegation-only domain.

That's per-zone, though, whereas DoT support is per-server.

DS records that somehow encode NS target names in their rdata might
work...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
partnership and community in all areas of life

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

Re: [dns-privacy] ADoT signalling

[John R Levine]

On Sun, 3 Nov 2019, John Levine wrote:

I thought it might be useful to make a list of possible ways to signal
that a server offers ADoT:

https://datatracker.ietf.org/doc/draft-levine-dprive-signal/


Did another version with more possibilities.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dns-privacy] ADoT signalling

[Christian Huitema]

On 11/4/2019 7:12 AM, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer  > wrote:
>
> On Sun, Nov 03, 2019 at 05:33:34PM -0500,
>  John Levine mailto:jo...@taugh.com>> wrote
>  a message of 14 lines which said:
>
> > I thought it might be useful to make a list of possible ways to
> signal
> > that a server offers ADoT:
>
> I would like also a discussion on whether signaling is 1) good 2)
> necessary.
>
> Even if you get a signal, the reality may be out-of-sync with the
> signal, for instance because of a problem on the server side (remember
> s published without checking IPv6 connectivity works) or on the
> client side (port 853 blocked).
>
>
> I'm less worried about the latter because I would expect recursive
> resolvers to generally be operated by people who are able to establish
> their port 853 status.


Note that port 853 is a convention. Servers could trivially run multiple
services over port 443, and demux based on the ALPN. I suppose that if
we see a lot blockage of port 853, servers will just do that -- run on
port 443, demux based on ALPN="DoT"...

-- Christian Huitema

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

Re: [dns-privacy] Threat Model

[Livingood, Jason]

In the -01 I added a parenthetical to address this suggestion and later WG 
discussion. Not sure if we’re there yet so open to specific wording suggestions.
//from GH repo//
# Threat Model and Problem Statement

Currently, potentially privacy-protective protocols such as DoT provide 
encryption between the user's stub resolver and a recursive resolver. This 
provides (1) protection from observation of end user DNS queries and responses 
as well as (2) protection from on-the-wire modification DNS queries or 
responses (including potentially forcing a downgrade to an unencrypted 
communication). Of course, observation and modification are still possible when 
performed by the recursive resolver, which decrypts queries, serves a response 
from cache or performs recursion to obtain a response (or synthesizes a 
response), and then encrypts the response and sends it back to the user's stub 
resolver.

But observation and modification threats still exist when a recursive resolver 
must perform DNS recursion, from the root to TLD to authoritative servers. This 
document specifies requirements for filling those gaps.

From: dns-privacy  on behalf of Eric Rescorla 

Date: Friday, November 1, 2019 at 2:11 PM
To: "dns-privacy@ietf.org" 
Subject: [dns-privacy] Threat Model

It seemed like it might be a good idea to take a step back and talk
about threat model to see if we're all on the same page.

The set of threats I am concerned with is primarily about an on-path
active attacker who learns the query stream (i.e., the domains being
queried) coming out of the recursive resolver. It's of course mostly
inevitable that the attacker learns which authoritative servers are
being queried, but I think we can all agree there's still plenty of
information to leak here [0].


In the current DNS, such an attacker can of course just perform a
passive attack by listening to the DNS query traffic. It's possible to
straightforwardly exclude this attack by opportunistically attempting
DoT [1] to the authoritative. However, an active attacker can mount a
downgrade attack on the negotiation, forcing you back to
cleartext. So, unless you have a secure way of:

(1) knowing the expected name of the authoritative for a given query
and that it supports DoT
(2) verifying that the server you are connecting to actually has
that name

Then the attacker can just mount a MITM attack on your connections and
collect this data by proxying the traffic to the true authoritative.

Do people agree with this assessment of the situation? Is this form
of attack something they agree should be in scope?

-Ekr

[0] There are of course also integrity issues here, but (1) those
are addressed by DNSSEC and (2) if you solved the active attack
problem, that would provide some measure of integrity for the data.

[1] Or any secure transport such as DoH, DoQ, tcpcrypt, etc.
but given the focus of this group, I'll just say DoT.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

[Tommy Pauly]

> On Nov 2, 2019, at 4:57 AM, Stephane Bortzmeyer  wrote:
> 
> On Fri, Nov 01, 2019 at 03:40:51PM -0700,
> Tommy Pauly  wrote 
> a message of 393 lines which said:
> 
>> We've posted new versions of our drafts on discovering designated DoH 
>> servers, and Oblivious DoH:
> 
> If you want to separate the knowledge of the source IP address and the
> knowledge of the QNAME, I still don't understand what is the point of
> Oblivious DoH when we can simply connect to the DoH resolver over
> Tor. This really deserves an explanation in the draft.

You're correct that using DoH over Tor would achieve some of the goals, at 
least as far as separating client IP addresses and
query contents! However, there are a couple reasons we're interested in having 
DoH servers directly support receiving Oblivious queries:

- Coming from the perspective of an operating system, we're trying to define a 
solution that can be a relatively lightweight extension
to standard protocols that can be enabled as a default mode for users when we 
need to improve privacy. Distributing public keys
through DNS, and adding a proxy + encryption step to DoH is more practical for 
this kind of deployment than using Tor. Tor is also
meant as a generic connection-level anonymity system, and thus seems overly 
complex for the purpose of proxying a request/response
protocol such as DNS.

- If you do DoH over Tor, the client is still doing an end-to-end TLS 
connection with the server (thus allowing for more fingerprinting
surface), and the DoH server can still track the patterns of resolution that a 
single client does within their TLS connection. In order
to mitigate the correlation of resolutions, a client could open a new 
connection for each query, but that gets expensive as well.
Encrypting at the DNS message level, per-query, within longer-lived connections 
between clients and proxies, and proxies and target
servers, decreases the ability to correlate more effectively with fewer 
round-trips.

Thanks,
Tommy

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

Re: [dns-privacy] ADoT signalling

[Eric Rescorla]

On Mon, Nov 4, 2019 at 7:32 AM Stephane Bortzmeyer 
wrote:

> On Mon, Nov 04, 2019 at 07:12:46AM -0800,
>  Eric Rescorla  wrote
>  a message of 96 lines which said:
>
> > I'm less worried about the latter because I would expect recursive
> > resolvers to generally be operated by people who are able to
> > establish their port 853 status.
>
> Not all resolvers are big boxes in the central datacenter. I may want
> to run a resolver on a small box at home even if my ISP blocks port
> 853.
>

Yes, I didn't say "control" it, but "establish" it. My point is that you
will generally know which state you are in and not need to do an automatic
fallback.


-Ekr


> > Well, this is why I asked about the threat model. If we care about
> > active attack, then this kind of approach does not work well.
>
> I tend to agree with Stephen Farrell here. If we insist on perfect
> resistance to active attackers, we may never deploy anything. I would
> suggest something more like "probe 853, remember what it was last time
> (to warn the sysadmin about a sudden block), may be allow to whitelist
> auth servers that must have DoT".
>
> For signaling, my personal preference goes to DANE, anyway.
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] ADoT signalling

[John R Levine]

On Mon, 4 Nov 2019, Stephane Bortzmeyer wrote:

Not all resolvers are big boxes in the central datacenter. I may want
to run a resolver on a small box at home even if my ISP blocks port
853.


I don't think anyone expects port 53 to go away.


I tend to agree with Stephen Farrell here. If we insist on perfect
resistance to active attackers, we may never deploy anything.


Same answer, port 853 is additional to port 53.


For signaling, my personal preference goes to DANE, anyway.


I'll add it to the list.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

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

Re: [dns-privacy] ADoT signalling

[Eric Rescorla]

On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer 
wrote:

> On Sun, Nov 03, 2019 at 05:33:34PM -0500,
>  John Levine  wrote
>  a message of 14 lines which said:
>
> > I thought it might be useful to make a list of possible ways to signal
> > that a server offers ADoT:
>
> I would like also a discussion on whether signaling is 1) good 2)
> necessary.
>
> Even if you get a signal, the reality may be out-of-sync with the
> signal, for instance because of a problem on the server side (remember
> s published without checking IPv6 connectivity works) or on the
> client side (port 853 blocked).


I'm less worried about the latter because I would expect recursive
resolvers to generally be operated by people who are able to establish
their port 853 status.

So, in any case, the client has to be
> ready to encounter a problem and to try a fallback.
>
> So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
> more or less in parallel and keep DoT if it works.
>

Well, this is why I asked about the threat model. If we care about active
attack, then this kind of approach does not work well.

-Ekr


> ___
> 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] ADoT signalling

[Stephane Bortzmeyer]

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine  wrote 
 a message of 14 lines which said:

> I thought it might be useful to make a list of possible ways to signal
> that a server offers ADoT:

I would like also a discussion on whether signaling is 1) good 2)
necessary.

Even if you get a signal, the reality may be out-of-sync with the
signal, for instance because of a problem on the server side (remember
s published without checking IPv6 connectivity works) or on the
client side (port 853 blocked). So, in any case, the client has to be
ready to encounter a problem and to try a fallback.

So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
more or less in parallel and keep DoT if it works.


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

Re: [dns-privacy] ADoT signalling

[Stephane Bortzmeyer]

On Sun, Nov 03, 2019 at 05:33:34PM -0500,
 John Levine  wrote 
 a message of 14 lines which said:

> I thought it might be useful to make a list of possible ways to signal
> that a server offers ADoT:
> 
> https://datatracker.ietf.org/doc/draft-levine-dprive-signal/
> 
> I'm sure there are others, feel free to send suggestions.

Well, some more were mentioned in draft-bortzmeyer-dprive-step-2 some years ago:

1) DANE (used as a signaling tool)

2) "reverse" DNS
3.5.0.0.1.0.0.0.0.0.0.0.0.0.0.0.e.f.a.c.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN TXT 
"I do DoT"

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