Subject: Re: [Add] A proposed charter for ABCD

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jan 2020 17:23:36 -0800

On Tue, Dec 24, 2019 at 12:10 PM Christian Huitema <[email-masked]>
wrote:

>
> > On Dec 24, 2019, at 9:39 AM, Michael Richardson <[email-masked]>
> wrote:
> >
> >
> > Vittorio Bertola <vittorio.bertola=[email-masked]>
> wrote:
> >> I think that one actual problem that many here would like to solve is:
> >> for decades we have been discovering and using the local
> >> network-provided resolver as a default, we would like to continue doing
> >> that but with an encrypted local resolver, how do we do that?
> >
> > While I'm with you, I'm not sure that this is what others want.
>
> You are assuming that people obviously want to continue doing what they
> are doing but only with an encrypted access to a local server. Rather than
> assuming that, it might be better to unpack the tradeoff behind that
> particular solution, and explain in which circumstances they make sense.
>

I would also like to push on this, but for different reasons. As usual,
it's important to start with the threat model.

If we start from the RFC 3552 threat model in which the attacker has
complete control of the network, then learning that the local network has
an encrypted resolver is not that useful as a mechanism to switch you from
unencrypted to encrypted mode, because the attacker will just downgrade you
or point you at their own resolver (this is just the usual point about
encryption without authentication not being that useful).

It seems like there are a few situations in which this kind of discovery is
still useful:

- You have a limited threat model in which you trust the local network but
not the Internet
- You have some sort of trust relationship with the discovery mechanism,
e.g., the record is signed by a key you know (this is arguably a special
case of the previous point)
- You have multiple resolvers you trust via some other mechanism and the
local network steers you to one.

However, aside from these and others like them, an unauthenticated
discovery function seems not that useful
-Ekr

> Personally I believe there is a difference between retrieving  an A or
> AAAA record and retrieving an ESNI record. Resolving the first one locally
> may well be convenient. Resolving the ESNI locally leads to a very clear
> privacy exposure.
>
> -- Christian Huitema
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jan 2020 22:46:37 -0500

Eric Rescorla <[email-masked]> wrote:
    > However, aside from these and others like them, an unauthenticated discovery
    > function seems not that useful

I agree with you.
I think the question is whether we should:

1) find a way to authenticated existing discovery mechanisms.
   (There are many ways we could go about this)

2) build a new discovery mechanism for DNS servers that includes
   authentication.

Christian has done lots of work in DNS-SD to create new a service discovery
mechanism that does not leak the question.  I'm not entirely sure that
discovering the DNS server is a question we need to avoid leaking, but
it might be that it is important to avoid leaking which DNS servers the
device would trust.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2020 00:28:23 -0500

There’s no point in authenticating the configuration data.   The only way you can trust the resolver is if you are able to configure a trust relationship to it, and validate that it is the resolver with which you have a trust relationship.  If you can do that, it doesn’t matter if the configuration protocol is authenticated.   And, importantly, authenticating the configuration protocol is quite a bit harder.   We know this because we’ve tried.   So I would not suggest wasting time revisiting that rathole.

Sent from my iPad

> On Jan 1, 2020, at 10:46 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 02 Jan 2020 11:00:32 +0100

Moin!

On 2 Jan 2020, at 6:28, Ted Lemon wrote:

> There’s no point in authenticating the configuration data.   The 
> only way you can trust the resolver is if you are able to configure a 
> trust relationship to it, and validate that it is the resolver with 
> which you have a trust relationship.  If you can do that, it doesn’t 
> matter if the configuration protocol is authenticated.   And, 
> importantly, authenticating the configuration protocol is quite a bit 
> harder.   We know this because we’ve tried.   So I would not suggest 
> wasting time revisiting that rathole.
Can you define trust relationship / authenticating configuration data. 
Depending on how you define that the solution is either obvious or 
impossible. As an ops guy and non native english speaker I often 
struggle with abstractions, so let me give you an concrete example you 
can hopefully give an answer on:

- A router sends a client an PvD RA as defined in 
(draft-bruneau-intarea-provisioning-domains - 
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ 
) with FQDN content of pvd.myisp.net.
- My system retrieves https://pvd.myisp.net/.well-known/pvd and can 
DNSSEC validate the domain and the HTTP certificate
- In the JSON blob retrieved contains the following keys (see 
draft-pauly-dprive-adaptive-dns-privacy - 
https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/?include_text=1 
):
	dohuri: https://doh.myisp.net/dns-query
	requireDNSFiltering: True
	dnsFilteredZones: “.”
I can again DNSSEC validate the domain and the HTTP certificate using 
they key stores available with my system.

Is that authenticated? Is there a trust relationship?

So long
-Ralf
—--
Ralf Weber

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Jan 2020 05:12:14 -0800

> Is that authenticated? Is there a trust relationship?

No, because the first step wasn't authenticated. An attacker could have
forged the RA.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2020 09:10:48 -0500

On Jan 2, 2020, at 5:00 AM, Ralf Weber <[email-masked]> wrote:
> Can you define trust relationship / authenticating configuration data. Depending on how you define that the solution is either obvious or impossible. As an ops guy and non native english speaker I often struggle with abstractions, so let me give you an concrete example you can hopefully give an answer on:

Good questions, thanks.

> - A router sends a client an PvD RA as defined in (draft-bruneau-intarea-provisioning-domains - https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ ) with FQDN content of pvd.myisp.net.
> - My system retrieves https://pvd.myisp.net/.well-known/pvd and can DNSSEC validate the domain and the HTTP certificate
> - In the JSON blob retrieved contains the following keys (see draft-pauly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/?include_text=1 ):
> I can again DNSSEC validate the domain and the HTTP certificate using they key stores available with my system.
> 

No.   You have no more reason to trust that than you do any other random HTTPS-authenticated web site that you might try to access.   When you go to https://www.badguy.com, you know that it’s really www.badguy.com because the TLS cert validates, and maybe the DNSSEC validated, but you /don’t/ have any reason to trust answers you get from that site.

That’s why I say there’s no reason to go through any extra bother.   In order to have a trust relationship, I need to have configured a list of sites I trust as DNS resolvers.  This is independent of the RA I receive, or the DHCP message I receive.

Then when I get an RA or a DHCP message asserting the availability of a DNS resolver, if I have a trust relationship with that resolver, and I can validate the cert upon connecting, then it’s a “trusted resolver.”   Otherwise, it’s an “untrusted resolver.”   It’s the pre-established trust relationship that makes it trusted, not some assertion I get from the network about it being trustworthy.

E.g., suppose I trust the SLA from my ISP.   I believe that my ISP will not snoop on my DNS data, and I want to use their resolver.   If their resolver is using DoH or DoT, then I can list the domain name(s) of their resolver in my list of trusted resolvers.   When I am offered one of these resolvers, I can validate that I’m actually communicating with it, by validating the TLS cert, and then I can trust it, because of that pre-established trust relationship, not because of any assertion the network made about its trustworthiness.

Absent some kind of out-of-band trust establishment process like this, there can’t be a trust relationship with a resolver.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 02 Jan 2020 15:21:24 +0100

Moin!

On 2 Jan 2020, at 15:10, Ted Lemon wrote:
> No.   You have no more reason to trust that than you do any other 
> random HTTPS-authenticated web site that you might try to access.   
> When you go to https://www.badguy.com, you know that it’s really 
> www.badguy.com because the TLS cert validates, and maybe the DNSSEC 
> validated, but you /don’t/ have any reason to trust answers you get 
> from that site.
Well that is sort of true. So let me reword the rest of your text to be 
more accurate ;-) :

That’s why I say there’s no reason to go through any extra bother.   
In order to have a trust relationship, I need to have configured a list 
of sites I trust as web sites  This is independent of the link I 
receive, or the URL I receive.

Then when I get a link or URL asserting the availability of a web site, 
if I have a trust relationship with that web stie, and I can validate 
the cert upon connecting, then it’s a “trusted web site.”   
Otherwise, it’s an “untrusted web site.”   It’s the 
pre-established trust relationship that makes it trusted, not some 
assertion I get from the some linke or URL about it being trustworthy.

E.g., suppose I trust the SLA from my web site operator.   I believe 
that my web site will not sell my private data, and I want to use their 
content.   If they are using DNSSEC and have a valid certificat,  then I 
can list the domain name(s) of that website in my list of trusted 
websites.   When I am offered one of these websites, I can validate that 
I’m actually communicating with it, by validating the TLS cert, and 
then I can trust it, because of that pre-established trust relationship, 
not because of any assertion from an link .

Absent some kind of out-of-band trust establishment process like this, 
there can’t be a trust relationship with a web site.

I’ll leave it as this and have a good night of sleep before my next 
response.

So long
-Ralf
—--
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Jan 2020 10:56:23 -0500 (EST)

On Thu, 2 Jan 2020, Eric Rescorla wrote:

> No, because the first step wasn't authenticated. An attacker could have forged the RA.

That does not matter if you have a preloaded DNSSEC root trust anchor,
and the received configuration doesn't include any domain overrides,
which would be what you would expect for a hotel or coffee shop wifi?
(really, all non-enterprise, non-home networks you join)

However, that only relates to the authenticated part. An attacker could
still have rerouted your encrypted DNS queries through their server,
where they relay and monitor. And so yes, the privacy would still be
lost. But then again, if you are concerned about that, why ever accept
a remote config for an encrypted DNS server?

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Jan 2020 10:26:34 -0800

> a remote config for an encrypted DNS server?

I think in general you wouldn't, but as I noted in a previous message,
there are a few special cases this might make sense

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Thu, 2 Jan 2020 13:17:12 -0800

On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon <[email-masked]> wrote:

> impossible. As an ops guy and non native english speaker I often struggle
> with abstractions, so let me give you an concrete example you can hopefully
> give an answer on:
>
> Good questions, thanks.
>
> No.   You have no more reason to trust that than you do any other random
> HTTPS-authenticated web site that you might try to access.   When you go to
> https://www.badguy.com, you know that it’s really www.badguy.com because
> the TLS cert validates, and maybe the DNSSEC validated, but you /don’t/
> have any reason to trust answers you get from that site.
>
> That’s why I say there’s no reason to go through any extra bother.   In
> order to have a trust relationship, I need to have configured a list of
> sites I trust as DNS resolvers.  This is independent of the RA I receive,
> or the DHCP message I receive.
>
> Then when I get an RA or a DHCP message asserting the availability of a
> DNS resolver, if I have a trust relationship with that resolver, and I can
> validate the cert upon connecting, then it’s a “trusted resolver.”
>  Otherwise, it’s an “untrusted resolver.”   It’s the pre-established trust
> relationship that makes it trusted, not some assertion I get from the
> network about it being trustworthy.
>
> E.g., suppose I trust the SLA from my ISP.   I believe that my ISP will
> not snoop on my DNS data, and I want to use their resolver.   If their
> resolver is using DoH or DoT, then I can list the domain name(s) of their
> resolver in my list of trusted resolvers.   When I am offered one of these
> resolvers, I can validate that I’m actually communicating with it, by
> validating the TLS cert, and then I can trust it, because of that
> pre-established trust relationship, not because of any assertion the
> network made about its trustworthiness.
>
> there can’t be a trust relationship with a resolver.
>

"If there were any sense to the English language, trust would be a
four-letter word." - Risky Business quote.

One of the problems we are having in this thread, is the terminology, which
I'd like to suggest a couple of substitutes for clarity.
"Trust" can have several meanings, which is unfortunate in that the
inherent ambiguity causes unclear meaning.

Perhaps two distinct terms or phrases would be appropriate - one for what
DNSSEC provides (data integrity protection), and one for privacy.
Maybe we could just use DNSSEC and privacy?

I'd like to start with Ted's last statement, and break it into two related
components, which are actually both relevant using both meanings of "trust".
- Absent some kind of out-of-band DNSSEC establishment process, there can't
be a DNSSEC relationship with a resolver
   (I'd actually prefer to use "server" here, since a client is UNABLE to
distinguish a resolver from a forwarder.)
- Absent some kind of out-of-band privacy establishment process, there
can't be be a privacy relationship with a resolver. (Same concerns on
server rather than resolver.)

The assumption that may be being made is that the only way to have a DNSSEC
relationship with a resolver, is when two conditions are true:
- The resolver has a globally unique, resolvable name with a chain of
(DNSSEC) trust from the DNS Root Trust Anchor
- The name of the resolver is known (or discoverable), and the URI for the
service in question is also well-known
These generally require some OOB method of discovery/publication/usage.
The relevance of the following statement is unclear, but it should be
noted: there is basically no way to validate the claim of a given network,
of the network's association with the resolver (e.g. whether they are part
of the same ISP, etc.)

There is another way by which a DNSSEC relationship to a resolver can be
established, which is very much non-obvious: the OOB publication of a
specific DNSSEC Trust Anchor, for a zone which publishes some
server-related information.
For example, a DNSKEY associates a name with a public key for a named zone.
The contents of that zone can be signed with DNSSEC, and those signatures
validated with the DNSKEY.
The degree of trust in the DNSSEC status is dependent on the manner of the
OOB publication. However, revocation of such trust is trivial (unpublish
the zone or roll the key) and provides POP (proof of possession of the
private key).

The information in a signed zone can be used for bootstrapping any number
of related DNS mechanisms (e.g. TLSA records), or even unrelated mechanisms
for bootstrapping other associations (lots of possibilities, such as URIs
for network support, URIs for web pages that have QR codes for whatever
other stuff you want to publish).

The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and the
real value is being able to use names which have only local significance
(e.g. under the local-use ISO namespaces such as "zz").

The bootstrap method for upgrading from DHCP-provided resolver IP could be
as simple as connecting on port 53 and asking for a global well-known name,
which returns the FQDN of the server (even if that FQDN is locally scoped
under "zz"). If a match is found in the set of Trust Anchors, look things
up in that zone and validate with the corresponding TA (or the Root TA if
the FQDN is global.) Bootstrap to having a DNSSEC trust relationship is
then complete.

What data is published in a signed zone of this sort is entirely open to
standardization, for any number of use cases.

Examples could include:
- Methods of providing ways of authenticating Access Points (since the SSID
is not trustworthy in general, and the normal authentication of public
SSIDs is "none" or "client to SSID" rather than the other way around).
- URIs for HTTPS connections for arbitrary uses, e.g. including obtaining
short-term guest credentials to use on WiFi
- URIs for SSL VPNs (much better than just encrypting DNS)
- any well-known prefix-based services (_SOMETHING._TCP)
- CNAMEs, DNAMEs to FQDN-based services
- Anything anyone wants to standardize for bootstrapping from locally
scoped network connections

Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2020 18:11:10 -0500

Actually, the meaning of the term “trust” in computer security is not at all ambiguous, and your descriptions make things less clear, not more. 

Most of what you say here is just missing the point I made earlier. Trust is a decision: in order to do what I want, I must trust some thing. How do I enforce this?  With cryptographic authentication. 

DNSSEC is a cryptographic authentication mechanism. It does not establish trust. It allows me to authenticate your identity, which I may or may not trust. TLS provides a similar capability. 

Privacy is a thing that I might or might not trust you to provide for me. One of many things.

Your identity is how I mark you as trusted. Cryptographic authentication is how I validate that you actually are who you claim to be: that your identity is the identity I have marked as trusted.

The way you have attempted to explain this is much more complicated, and does not make things clearer.  See if you can talk about this in terms of trusted services, trusted identity and authentication of identity. It will be a lot easier to understand. 

> On Jan 2, 2020, at 16:17, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
> "If there were any sense to the English language, trust would be a four-letter word." - Risky Business quote.
> 
> One of the problems we are having in this thread, is the terminology, which I'd like to suggest a couple of substitutes for clarity.
> "Trust" can have several meanings, which is unfortunate in that the inherent ambiguity causes unclear meaning.
> 
> Perhaps two distinct terms or phrases would be appropriate - one for what DNSSEC provides (data integrity protection), and one for privacy. 
> I'd like to start with Ted's last statement, and break it into two related components, which are actually both relevant using both meanings of "trust".
> - Absent some kind of out-of-band DNSSEC establishment process, there can't be a DNSSEC relationship with a resolver 
>    (I'd actually prefer to use "server" here, since a client is UNABLE to distinguish a resolver from a forwarder.)
> - Absent some kind of out-of-band privacy establishment process, there can't be be a privacy relationship with a resolver. (Same concerns on server rather than resolver.)
> 
> The assumption that may be being made is that the only way to have a DNSSEC relationship with a resolver, is when two conditions are true:
> - The resolver has a globally unique, resolvable name with a chain of (DNSSEC) trust from the DNS Root Trust Anchor
> - The name of the resolver is known (or discoverable), and the URI for the service in question is also well-known
> The relevance of the following statement is unclear, but it should be noted: there is basically no way to validate the claim of a given network, of the network's association with the resolver (e.g. whether they are part of the same ISP, etc.)
> 
> There is another way by which a DNSSEC relationship to a resolver can be established, which is very much non-obvious: the OOB publication of a specific DNSSEC Trust Anchor, for a zone which publishes some server-related information.
> For example, a DNSKEY associates a name with a public key for a named zone. The contents of that zone can be signed with DNSSEC, and those signatures validated with the DNSKEY. 
> The degree of trust in the DNSSEC status is dependent on the manner of the OOB publication. However, revocation of such trust is trivial (unpublish the zone or roll the key) and provides POP (proof of possession of the private key).
> 
> The information in a signed zone can be used for bootstrapping any number of related DNS mechanisms (e.g. TLSA records), or even unrelated mechanisms for bootstrapping other associations (lots of possibilities, such as URIs for network support, URIs for web pages that have QR codes for whatever other stuff you want to publish).
> 
> The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and the real value is being able to use names which have only local significance (e.g. under the local-use ISO namespaces such as "zz").
> 
> The bootstrap method for upgrading from DHCP-provided resolver IP could be as simple as connecting on port 53 and asking for a global well-known name, which returns the FQDN of the server (even if that FQDN is locally scoped under "zz"). If a match is found in the set of Trust Anchors, look things up in that zone and validate with the corresponding TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC trust relationship is then complete.
> 
> What data is published in a signed zone of this sort is entirely open to standardization, for any number of use cases.
> 
> Examples could include:
> - Methods of providing ways of authenticating Access Points (since the SSID is not trustworthy in general, and the normal authentication of public SSIDs is "none" or "client to SSID" rather than the other way around).
> - URIs for HTTPS connections for arbitrary uses, e.g. including obtaining short-term guest credentials to use on WiFi
> - Anything anyone wants to standardize for bootstrapping from locally scoped network connections
> 
> Brian
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 2 Jan 2020 15:30:18 -0800

On Thu, Jan 2, 2020 at 3:11 PM Ted Lemon <[email-masked]> wrote:

> Actually, the meaning of the term “trust” in computer security is not at
> all ambiguous, and your descriptions make things less clear, not more.
>
> Most of what you say here is just missing the point I made earlier. Trust
> is a decision: in order to do what I want, I must trust some thing. How do
> I enforce this?  With cryptographic authentication.
>
> DNSSEC is a cryptographic authentication mechanism. It does not establish
> trust. It allows me to authenticate your identity, which I may or may not
> trust. TLS provides a similar capability.
>

Okay, so what I'm referring to is the cryptographic authentication of the
data served, not the identity of the server, which is (for the purposes of
data integrity of the served data) irrelevant.

(Yes, it is also possible to cryptographically authenticate information
about a server if that is itself in a signed zone.)

What I'm talking about, in this context, is not *what* the server is, but
what it *provides*.

It does not require TLS, and TLS adds nothing of substance to the the data
integrity, with respect to changes to data between the authority server
publishing the data, and the client receiving the data.

This does, however, largely hinge on whether or not the client does DNSSEC
validation.

Both aspects (identity and data validation) depend on client DNSSEC
validation, unless there is a particular reason for the client to not
validate its data. (IMNSHO, that is unwise to do, presuming a reasonably
modern general purpose device like laptop, desktop, mobile phone, or
tablet. Low-power devices are a different kettle of fish, e.g. IoT devices,
and those should really have their own gateways that do validation on their
behalf, if the architectural model supports it.)

> Your identity is how I mark you as trusted. Cryptographic authentication
> is how I validate that you actually are who you claim to be: that your
> identity is the identity I have marked as trusted.
>
>
The way you have attempted to explain this is much more complicated, and
> does not make things clearer.  See if you can talk about this in terms of
> trusted services, trusted identity and authentication of identity. It will
> be a lot easier to understand.
>

You left out "validated DNS data", which is technically distinct from
trusted services, or at least is what I am attempting to distinguish from
"trusted privacy on services offered".

The client doesn't have to trust the services, if the data can be
validated.
That's the whole point of DNSSEC, it does not require that the client trust
the resolver.
If the goal of making DNS secure involved trusting resolvers, that could
have been done by having resolvers AXFR the zones, and could have been done
like 20 years ago.
That wasn't the model, and the design of DNSSEC specifically excludes that
trust, precisely because of the underlying trust issues that show up when
considering the privacy issues.

Trying to solve privacy issues by discarding the entire design and mode of
operation of DNSSEC is a major step backwards, IMHO.

(Even if particular resolver operators are trustworthy, removing the
validation on the client increases the attack surface on signed zones from
~0 to >> ~0, simply by facilitating data modification on the resolver,
notwithstanding the theoretical likelihood of that as an attack. Risk =
cost * probability, and cost is not zero for what is functionally the
equivalent to a cache poisoning attack. If validation is done, data
modification anywhere other than on the publishing side of DNS is
detectable and results only in denial of service, rather than other kinds
of results to modified DNS data.)

Brian

> One of the problems we are having in this thread, is the terminology,
> which I'd like to suggest a couple of substitutes for clarity.
> - Absent some kind of out-of-band DNSSEC establishment process, there
> can't be a DNSSEC relationship with a resolver
> The assumption that may be being made is that the only way to have a
> DNSSEC relationship with a resolver, is when two conditions are true:
> For example, a DNSKEY associates a name with a public key for a named
> zone. The contents of that zone can be signed with DNSSEC, and those
> signatures validated with the DNSKEY.
> The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and
> the real value is being able to use names which have only local
> significance (e.g. under the local-use ISO namespaces such as "zz").
>
> - Methods of providing ways of authenticating Access Points (since the
> SSID is not trustworthy in general, and the normal authentication of public

---

From: Jim Reid <[email-masked]>
Date: Thu, 2 Jan 2020 23:38:16 +0000

The debate about trust terminology/definitions is fascinating. It's very likely to be a topic that the new WG-to-be could eventually discuss. But it doesn't belong on this thread. Could we please branch this off somewhere else so this thread can focus on the charter proposals? Thanks.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 2 Jan 2020 15:46:46 -0800

On Thu, Jan 2, 2020 at 3:38 PM Jim Reid <[email-masked]> wrote:

> The debate about trust terminology/definitions is fascinating. It's very
> likely to be a topic that the new WG-to-be could eventually discuss. But it
> doesn't belong on this thread. Could we please branch this off somewhere
> else so this thread can focus on the charter proposals? Thanks.
>

Certainly.

But, I really want to emphasize, that terminology was a preface to the the
meat of my original message, which was that the issues EKR raised, can be
addressed, and should be in-scope for the charter proposals.

It's the portion of text that begins with "I'd like to start with Ted's
last statement"...

I'd encourage anyone interested in the charter discussion to take a look at
that.

This is about having real work to do, which solves the underlying problems
related to bootstrapping resolver discovery and the ability to securely
obtain metadata in-band (e.g. whatever is relevant to clients) is both
useful and relevant, IMHO.

Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2020 17:56:07 -0600

[as an individual]

> The debate about trust terminology/definitions is fascinating. It's very likely to be a topic that the new WG-to-be could eventually discuss. But it doesn't belong on this thread. Could we please b…

Having read through this thread, I think there is a useful 
charter-related distinction to be made here, and I think conflating 
these two things may be one reason people are talking past each other:

 1. Do I trust the question I ask to be confidential? [1]
 2. Do I trust the answer I get to be accurate?

Given that the only context apparently under discussion is web browsers, 
and given that the vast majority of HTTP connections are performed over 
TLS [2] [3], I suspect that #1 is the far more interesting question, and 
the only one that really makes sense to focus on in the charter.

/a

____
[1] Yes, I recognize that "confidential" raises the question "from 
whom," and that the answer to that is the real underlying tension in 
this discussion. I'm not trying to give that part of the question short 
shrift; I'm eliding any such discussion because it is aggressively 
unrelated to my point. To be clear, my point is that the *other* 
question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are 
detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Jan 2020 19:54:14 -0500

On Jan 2, 2020, at 18:56, Adam Roach <[email-masked]> wrote:
> Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:
> 
> 
> Do I trust the question I ask to be confidential? [1]
> Do I trust the answer I get to be accurate?
> 
> Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.
> 

Indeed, since #2 is solved by DNSSEC. :)

---

From: Alec Muffett <[email-masked]>
Date: Fri, 3 Jan 2020 01:10:27 +0000

On Thu, 2 Jan 2020 at 23:56, Adam Roach <[email-masked]> wrote:

> 3. Do I trust the answer will not be blocked?

4. Do I have a relationship with a specific answer provider, and can I be
certain that the response I have received has been provided by them [and
not surveilled, tampered with, or blocked by any third party, per nos. 1,
2, & 3]?

Funny, people keep forgetting that "security" - privacy, integrity - policy
extends past the 7-layer model and into "layer 8" aka "administration".

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 3 Jan 2020 12:58:02 +0100 (CET)

Il 03/01/2020 00:30 Brian Dickson <
[email-masked]> ha scritto:

The client doesn't have to trust the services, if the data can be validated.

That's the whole point of DNSSEC, it does not require that the client trust the resolver.

If the goal of making DNS secure involved trusting resolvers, that could have been done by having resolvers AXFR the zones, and could have been done like 20 years ago.

That wasn't the model, and the design of DNSSEC specifically excludes that trust, precisely because of the underlying trust issues that show up when considering the privacy issues.

Trying to solve privacy issues by discarding the entire design and mode of operation of DNSSEC is a major step backwards, IMHO.

As I have been trying to explain confusedly with my lightning talk at the last OARC, I am afraid that the ship of interchangeable resolvers has sailed about ten years ago. Many modern DNS-based services, from CDNs to malware filtering, rely on the fact that you are using a specific resolver; same for other increasingly important features of a DNS resolution service, like speed and privacy. There is even a business pressure in this direction, as these are ways for the DNS operator to compete and draw customers, either to a paid DNS service (e.g. NextDNS, Mozilla's second TRR), or to a paid Internet access service (e.g. the ISP resolvers), or to a no-one-understands-the-business-model-yet public resolver (e.g. the "Quads").

I don't see that ship sailing back home - I rather see more competition coming. This is why the ability to discover and authenticate resolvers is so important for the entire industry (and also why we are seeing lots of antitrust arguments in legal and political venues).

So, on Adam's point:

Il 03/01/2020 00:56 Adam Roach <
[email-masked]> ha scritto:

The problem is that you cannot deal with resolver selection only from the viewpoint of privacy. You might devise a discovery mechanism that ensures total privacy, but if it also reduces choice and competition, or if it leads to slower performance, it will still harm the Internet.

The point is rather to empower users to choose their resolver in a reliable way, with as much choice as possible, and with their own personal tradeoff among all the possible features of a resolver; the new group's work should aim at that objective.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jan 2020 10:58:18 -0600

On 1/3/20 5:58 AM, Vittorio Bertola wrote:
> So, on Adam's point:
>> Il 03/01/2020 00:56 Adam Roach < [email-masked] 
>> <mailto:[email-masked]>> ha scritto:
>>
>> Given that the only context apparently under discussion is web 
>> browsers, and given that the vast majority of HTTP connections are 
>> performed over TLS [2] [3], I suspect that #1 is the far more 
>> interesting question, and the only one that really makes sense to 
>> focus on in the charter.
> The problem is that you cannot deal with resolver selection only from 
> the viewpoint of privacy. You might devise a discovery mechanism that 
> ensures total privacy, but if it also reduces choice and competition, 
> or if it leads to slower performance, it will still harm the Internet.
>
> The point is rather to empower users to choose their resolver in a 
> reliable way, with as much choice as possible, and with their own 
> personal tradeoff among all the possible features of a resolver; the 
> new group's work should aim at that objective.

Without agreeing or disagreeing with what you say above, I want to 
clarify that you missed my point. I tried to be clear -- especially in 
footnote [1] of my message -- that there is a lot of additional nuance 
behind question 1, and you're definitely getting at some of it. But the 
sole thesis of the message you quote above is that people are using 
"trust" to mean two different, mostly unrelated things, and that only 
one of them is interesting in the context under discussion.

/a

---

From: Tommy Jensen <[email-masked]>
Date: Sat, 4 Jan 2020 00:28:32 +0000

adam>> But the sole thesis of the message you quote above is that people are using "trust" to mean two different, mostly unrelated things, and that only one of them is interesting in the context under discussion.

+1. The accuracy of the answer (your #2) is a problem that exists whether the DNS delivery mechanism is encrypted or not, as has been hinted at already on this thread. It also has existing solutions. I agree that your #1 (confidentiality) should be our primary focus so we can nail down a charter before we go even longer without an IETF WG on the matter.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Adam Roach <[email-masked]>
Sent: Friday, January 3, 2020 8:58 AM
To: Vittorio Bertola <vittorio.bertola=[email-masked]>; Brian Dickson <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] A proposed charter for ABCD

On 1/3/20 5:58 AM, Vittorio Bertola wrote:
So, on Adam's point:
Il 03/01/2020 00:56 Adam Roach < [email-masked]<mailto:[email-masked]>> ha scritto:

Without agreeing or disagreeing with what you say above, I want to clarify that you missed my point. I tried to be clear -- especially in footnote [1] of my message -- that there is a lot of additional nuance behind question 1, and you're definitely getting at some of it. But the sole thesis of the message you quote above is that people are using "trust" to mean two different, mostly unrelated things, and that only one of them is interesting in the context under discussion.

/a

---

From: Brian Dickson <[email-masked]>
Date: Fri, 3 Jan 2020 18:00:06 -0800

On Thu, Jan 2, 2020 at 3:56 PM Adam Roach <[email-masked]> wrote:

> Having read through this thread, I think there is a useful charter-related
> distinction to be made here, and I think conflating these two things may be
> one reason people are talking past each other:
>
>
> and given that the vast majority of HTTP connections are performed over TLS
> [2] [3], I suspect that #1 is the far more interesting question, and the
> only one that really makes sense to focus on in the charter.
>
>
>
Respectfully, I disagree with this summary.

Briefly: I am discussing bootstrapping into the state of having a trusted
resolver (that would then be used for your HTTP stuff).

It is not necessarily the case that every possible bootstrapping process
can proceed without using DNSSEC.

In particular, the issue generally categorized as "discovery" (but which
very likely also encompasses related issues like resolver identity (name),
reachability, forwarders and their topologies, and related network issues
(NAT)).

This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver" as a
policy for encrypted DNS (which would put Mozilla at odds with Google), I
think it is premature to exclude DNSSEC validation on the client, as part
of that bootstrap process.

I'm reasonably confident at this point in making the following assertion:

   - The above dependencies are intractable.
   - The root problem is that private addressing and private namespaces are
   incompatible with CA-issued certificates,
   - This effectively makes TLSA records the only feasible solution for
   establishing TLS connections to any resolver which does not have a
   published public name and public (non-RFC1918) address.
   - TLSA (DANE) requires DNSSEC validation.

Once the bootstrapping has been done, the TLS connections can be
established  using the trusted resolver, and depending on the browser's
implementation choices, may exclude the use of DNSSEC validation.

However, it is not possible to bootstrap to any resolver except those on a
hardcoded list and using certificates issued by CAs from browser-specific
CA sets, unless client DNSSEC validation is available.

This needs to be explicitly discussed as part of the WG charter scope
discussion.

Brian

> /a
>
> ____
> [1] Yes, I recognize that "confidential" raises the question "from whom,"
> and that the answer to that is the real underlying tension in this
> discussion. I'm not trying to give that part of the question short shrift;
> I'm eliding any such discussion because it is aggressively unrelated to my
> point. To be clear, my point is that the *other* question is basically
> uninteresting in this context.
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jan 2020 22:22:12 -0600

On 1/3/20 8:00 PM, Brian Dickson wrote:
> I think it is premature to exclude DNSSEC validation on the client, as 
> part of that bootstrap process.

Thanks for the clarification. With your added explanation, this makes sense.

To be clear, I don't agree with some of your other assertions, but you 
did make it clear that you're talking about DNSSEC in a very narrow, 
bootstrap-related capacity, and I agree that there is likely a set of 
solutions that lie down that path. I think we can come up with better 
solutions than the one you sketched out, but I agree with you that the 
charter should not rule it out of scope.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jan 2020 13:27:46 -0800

On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson <[email-masked]>
wrote:

>> charter-related distinction to be made here, and I think conflating these
>> two things may be one reason people are talking past each other:
>>
>>

It might be helpful if you laid out what role you think cryptographic
authentication is playing here.

Cryptographic authentication, whether via WebPKI or DNSSEC/TLSA, ties
the server to a given identity. So, the first step is to ask where
that identity comes from and why you trust *that*. So perhaps you
could start by laying out the setting you have in mind.

-Ekr

>    - The root problem is that private addressing and private namespaces
>    are incompatible with CA-issued certificates,

---

From: Brian Dickson <[email-masked]>
Date: Sat, 4 Jan 2020 15:37:36 -0800

On Sat, Jan 4, 2020 at 1:28 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
>> Unless the WG wants to expressly reject the notion of "same resolver" as
>> a policy for encrypted DNS (which would put Mozilla at odds with Google), I

The specifics are part of the stuff I'm working on currently (doing a proof
of concept), but at a 50,000 foot level:

   - The identity is generated by the server itself, and has a
   corresponding DNS zone which is locally scoped (won't work outside the
   local environment, for some value of "local), but globally unique. Making
   the name a zone allows all the data to be DNSSEC signed and relies only on
   a single trust anchor specific to the server (the DNSKEY with SEP bit set
   for the zone itself).
   - The trust for that requires some mechanism for distributing the
   corresponding trust anchor.

   - Maybe technically out of scope for the WG but definitely a requirement
   to bootstrap securely. Potential methods might include:
      - DHCP
      - dot1x, or something similar
      - unique-per-client name (but perhaps sharing a public key?)
      - some demonstration that DHCP spoofing or RA spoofing is not
      possible in the local environment (e.g. dot1x for port access, and using
      DHCP for obtaining the DNSKEY)
      - Publication via other non-networked mechanisms, e.g. with QR codes
      (under physical control of the operator), for example
         - coffee shop paper slips with a QR code rather than just an SSID,
         username, password (which don't prevent SSID spoofing)
         - CCTV channels (hotels, conference display panels, etc) with QR
         codes, or menus with QR codes.
         - QR code published on a TLS-protected web site (e.g. conference
         web site), available before traveling or on-site
         - QR code on badges
         - QR code on T-Shirts etc
      - The QR code would need to encode the public key and name, and would
      prevent spoofing since only the actual server would have the necessary
      private key with which to sign the data.
      - The trust of such a QR code and corresponding server is possibly
      subjective, but at least under the control of whoever controls the local
      "meat-space"
      - Advanced ideas could include things like rotating names and keys,
      sync'd via a seed, on a physical (hardened) token with a display for a QR
      code.

The identity, being local in scope, can be changed as frequently as
necessary, potentially extremely frequently (every 15 minutes?).
Having a naming scheme with enough entropy is sufficient to prevent
collision and prevent guessing, thus making it more secure and/or more
trustworthy (I think).

Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or thereabouts.
Want more entropy? Add more characters. The base-36 exponential curve gets
very big, very fast. Making it machine-readable or published electronically
removes the UI/UX element from consideration.

The locally significant aspect would be to place it in an unused and
un-assignable namespace, e.g. the ISO reserved 2-letter codes that were
discussed in DPRIVE or DNSOP (such as zz pseudo-TLD).

The TLS aspect would generally require self-signed certs with TLSA type
3-1-1 records published (EE public key fingerprint) for validation, and
would be in a 1:1 lock-step with the identity (and zone name).

Assuming the POC works, I think most of the above aspects can be reduced to
bike-shedding.

Brian

>> However, it is not possible to bootstrap to any resolver except those on
>> a hardcoded list and using certificates issued by CAs from browser-specific
>>> whom," and that the answer to that is the real underlying tension in this

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Jan 2020 16:01:09 -0800

On Sat, Jan 4, 2020 at 3:37 PM Brian Dickson <[email-masked]>
wrote:

>>>> performed over TLS [2] [3], I suspect that #1 is the far more interesting
>>>> question, and the only one that really makes sense to focus on in the
>>>> charter.
>>>>
>>>>
>>>>
>>> Briefly: I am discussing bootstrapping into the state of having a
>>> trusted resolver (that would then be used for your HTTP stuff).
>>>
> The specifics are part of the stuff I'm working on currently (doing a
> proof of concept), but at a 50,000 foot level:
>
>    - Maybe technically out of scope for the WG but definitely a
>    requirement to bootstrap securely. Potential methods might include:
>       - DHCP
>       - Publication via other non-networked mechanisms, e.g. with QR
>       codes (under physical control of the operator), for example
>          - coffee shop paper slips with a QR code rather than just an
>          SSID, username, password (which don't prevent SSID spoofing)
>       - The QR code would need to encode the public key and name, and
>       would prevent spoofing since only the actual server would have the
>       necessary private key with which to sign the data.
> Thanks.

That said, this seems like it reduces back to the unsolved problem of
secure bootstrapping, and none of the alternatives you propose here seem
very plausible. And if we assume that they *do* work, then there's no
particular reason to mess around with special-use names and TLSA records:
just distribute the IP address and the public key (or a hash of the key)
directly.

-Ekr

> Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or
> thereabouts. Want more entropy? Add more characters. The base-36
> exponential curve gets very big, very fast. Making it machine-readable or
> published electronically removes the UI/UX element from consideration.
>
> Assuming the POC works, I think most of the above aspects can be reduced
> to bike-shedding.
>
> Brian
>
>
>>
>> -Ekr
>>
>>
>>>

---

From: Brian Dickson <[email-masked]>
Date: Sat, 4 Jan 2020 18:58:15 -0800

On Sat, Jan 4, 2020 at 4:01 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Sat, Jan 4, 2020 at 3:37 PM Brian Dickson <
>>>> It is not necessarily the case that every possible bootstrapping
>>>> process can proceed without using DNSSEC.
>>>>
>>>> In particular, the issue generally categorized as "discovery" (but
>>>> which very likely also encompasses related issues like resolver identity
>>>> (name), reachability, forwarders and their topologies, and related network
>>>> issues (NAT)).
>>>>
>>>> Unless the WG wants to expressly reject the notion of "same resolver"
>>>> as a policy for encrypted DNS (which would put Mozilla at odds with
>>>> Google), I think it is premature to exclude DNSSEC validation on the
>>>> client, as part of that bootstrap process.
>>>>
>>>
>>          - CCTV channels (hotels, conference display panels, etc) with
>>          QR codes, or menus with QR codes.
>>          - QR code published on a TLS-protected web site (e.g.
>>          conference web site), available before traveling or on-site
>>          - QR code on badges
>>       - Advanced ideas could include things like rotating names and
>>       keys, sync'd via a seed, on a physical (hardened) token with a display for
>>       a QR code.
>>
>> Thanks.
>

The latter would only work if the only kind of server were resolver, and if
no forwarders existed.

The discovery stuff is all about actually determining (among non-malicious
servers which are already "trusted" by virtue of being used via existing
mechanisms) what servers are actually doing resolving (versus only being
forwarders).

It is not possible via in-band query to determine from the perspective of a
client (stub) whether a server is a forwarder or resolver. It is equally
impossible from the server side to determine if the client is a forwarder
or an actual client.

I agree, that if it not for this issue, the IP and pubkey would be
sufficient.

The problem is that establishing a TLS connection to a forwarder (which
forwards the query to another server) is not in the same class of privacy
protection as having a TLS connection to the eventual upstream resolver
(relative to the first forwarder).

Using the actual resolver would maximize the privacy benefit, without
changing where resolution is being done per se.

That's the goal of the stuff I'm working on -- allow the client to figure
out who the resolver(s) available are, and whether the resolver(s) do DoT
or DoH, and respect whatever the client's preferred  policy is (i.e. using
DoT and/or DoH, if the client requests such), by only sending the queries
over the appropriate connection type, to one of the existing resolvers that
could be providing resolution.

(The forwarder could have a "tree" of upstream forwarders, and a number of
"leaf" resolvers, only some of which do TLS. The objective is, bypass the
forwarders and talk TLS to one or more resolvers, using whatever other
underlying resolver selection logic exists to pick the best among those.)

The plausibility depends (as is the case for pretty much everything in the
IETF) on implementation and deployment.
However, the reverse is also true; if you don't buy a ticket (write a
spec), you can't win (have interoperable deployment at all).

It's premature at this point to try to evaluate anything from 50,000 feet,
so let's leave it (plausibility) as an open question, thanks.

Brian

>>>>    - The root problem is that private addressing and private
>>>>    namespaces are incompatible with CA-issued certificates,
>>>>    - This effectively makes TLSA records the only feasible solution
>>>>    for establishing TLS connections to any resolver which does not have a
>>>> However, it is not possible to bootstrap to any resolver except those
>>>> on a hardcoded list and using certificates issued by CAs from
>>>> browser-specific CA sets, unless client DNSSEC validation is available.
>>>>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Jan 2020 07:43:10 -0500

On Jan 4, 2020, at 9:58 PM, Brian Dickson <[email-masked]> wrote:
> (The forwarder could have a "tree" of upstream forwarders, and a number of "leaf" resolvers, only some of which do TLS. The objective is, bypass the forwarders and talk TLS to one or more resolvers, using whatever other underlying resolver selection logic exists to pick the best among those.)

This sounds really complicated.  What is the problem you are trying to solve that requires so much complexity?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Jan 2020 06:38:38 -0800

> solve that requires so much complexity?

I agree with Ted. This seems insufficiently developed to be a in a charter
we are writing now.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Sun, 5 Jan 2020 12:29:48 -0800

> solve that requires so much complexity?

Resolver discovery.

Specifically, resolver discovery to upgrade the resolution to TLS (DoT or
DoH), without changing the selection of resolver(s).

If discovery is done in-band using DNS (e.g. with a well-known name), this
automatically means that only the closest server in the forwarder "tree"
will be discovered.
The goal of discovery shouldn't be to discovery the closest TLS speaker.
The goal should be to discover the resolver(s) being used, and whether TLS
is supported.
The purpose of the discovery is to enable privacy protection using TLS to a
resolver.

Doing TLS upgrade to a forwarder does not accomplish the privacy goal of
ADD, if the forwarder itself is not doing TLS to its upstream(s), even if
the forwarder is trusted. (I trust I don't need to explain why.)

Similarly, if the forwarder does not support TLS, but the resolver it is
using does support TLS, making a direct connection to the resolver via TLS
is both necessary and sufficient to achieve the privacy goal of ADD.

I agree, what I described sounds complicated. However, what it is doing is
using a very well-known and familiar algorithm,
https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm.

If a forwarder is using the same mechanism as a resolver (to allow
discovery), that has the side effect of preventing the client from directly
reaching the resolver to do discovery.
If the spec for discovery is to handle this situation, the forwarder needs
to do discovery towards its upstream, and publish that information for the
client's consumption.
Each of those elements of discovery (client-forwarder, forwarder-upstream)
is what amounts to a "link state". ("Link" meaning forwarder-upstream
discovery information, "state" referring to TLS-or-not, including DoT vs
DoH.)
The client obtains all the link state information, runs it through
Dijkstra, and finds one or more TLS resolvers it can use, and if more than
one is available, selects the best (for some value of best).

NB: One possible outcome for the algorithm is that the client decides that
the full path of forwarders is all-TLS, and that it trusts the TLS state of
the forwarders, and connects to the first forwarder using TLS. That choice
is for the client to make. (Here client refers to application, not
necessarily something exposed to the user of the application.)

Dijkstra is very simple, it's undergrad level computer science stuff, and
widely used on the Internet in the OSFP and ISIS routing protocols. It only
sounds complicated.

The forwarder issue exists but is only a problem if a forwarder gets
"upgraded" to do the resolver discovery support. At that point, the analogy
would be all of the fine IETF stuff that got broke by NAT. Rather than
doing work that gets broken by not taking it into consideration, the goal
here is to handle the problem in a way that is baked into the discovery
mechanism.

The problem being solved is simple to describe: resolver discovery. Putting
that into the charter as something to try to solve makes sense.

The upstream discovery part is very simple. The only time any complexity
arises is if (a) there are forwarders, and (b) the forwarders implement the
same discovery support as resolvers.
The complexity is not itself part of the discovery mechanism, which remains
very simple (the "link state" component that gets encoded in the discovery
mechanism),
The complexity is on the client where Dijkstra is used to select a
resolver.
And the Dijkstra only needs to be run if the topology learned is not
simple.
If forwarders exist, but are not implementing discovery, the regular
mechanism for discovering the resolver itself "just works", and no Dijkstra
is necessary.
The complex parts, if necessary, are only invoked once, during the TLS
bootstrap.
That bootstrap may need to be re-run whenever the client moves between
networks. This is just the upgrade being re-run, if the resolver choice is
dynamic such as DHCP or via RA.

All of this is only required if the resolver has not been hard-coded, so it
does not affect any other parts of the client, only the part handling "same
resolver" policy when the resolver is not on a list of known resolvers.

TL;DR: it's not that complicated, I just did a poor job of describing "link
state" and Dijkstra. It's only needed to make resolver discovery reliable.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Jan 2020 15:34:33 -0500

> Resolver discovery.

Okay, but what specific problem are you trying to solve?   You can already do resolver discovery with DHCP or RA.  You continued this with a really long answer, but it was more of a description of your solution to your unstated problem.   Start with the basics.   Describe a configuration that you think makes sense.   Describe why it makes sense.   Explain why just using DHCP or RA doesn’t work in that configuration.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 5 Jan 2020 13:18:27 -0800

Sent from my iPhone

> On Jan 5, 2020, at 12:34 PM, Ted Lemon <[email-masked]> wrote:
> 

Discovery of non-forwarder resolver that does DoT/DoH.

DoT/DoH to a forwarder is not privacy preserving if the upstream is non-local and not using DoT/DoH.

DHCP or RA will only return the servers they are configured to advertise, which may be (and frequently is) a forwarder.

The most prevalent example would be home routers doing DHCP, implementing forwarder functionality, and advertising themselves as the resolver. Many of those use one of the public quad-N resolvers as forwarder target.

Discovery of the quad-N resolver allows upgrade to DoT/DoH without forced substitution of resolver. Use of quad-N would occur IFF said quad-N were the actual forwarder target of the DHCP/RA server learned, and would not require the upgrade of the forwarder at all.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Jan 2020 14:38:26 -0800

On Sun, Jan 5, 2020 at 1:18 PM Brian Dickson <[email-masked]>
wrote:

> Okay, but what *specific* problem are you trying to solve?   You can
> already do resolver discovery with DHCP or RA.  You continued this with a
> really long answer, but it was more of a description of your solution to
> your unstated problem.   Start with the basics.   Describe a configuration
> that you think makes sense.   Describe why it makes sense.   Explain why
> just using DHCP or RA doesn’t work in that configuration.
>
>
> DHCP or RA will only return the servers they are configured to advertise,
> which may be (and frequently is) a forwarder.
>
> The most prevalent example would be home routers doing DHCP, implementing
> forwarder functionality, and advertising themselves as the resolver. Many
> of those use one of the public quad-N resolvers as forwarder target.
>
> Discovery of the quad-N resolver allows upgrade to DoT/DoH without forced
> substitution of resolver. Use of quad-N would occur IFF said quad-N were
> the actual forwarder target of the DHCP/RA server learned, and would not
> require the upgrade of the forwarder at all.
>

This seems like a potentially reasonable problem statement, though as noted
previously, it's not secure against many forms of active attack.

However, given that the initial discovery procedure is insecure, I'm
puzzled why you think that DNSSEC (or anything like it) is required.
Rather, what's required is that the discovery be via DNS (so that the
upstream can inject its response) but if you're interested in using the
Quad-N resolvers, then the operators can quite easily acquire WebPKI certs.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Sun, 5 Jan 2020 16:32:23 -0800

On Sun, Jan 5, 2020 at 2:39 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Sun, Jan 5, 2020 at 1:18 PM Brian Dickson <
> This seems like a potentially reasonable problem statement, though as
> noted previously, it's not secure against many forms of active attack.
>
It's only required if the intermediate system (forwarder doing its own
discovery and serving DoH/DoT) supports DNSSEC but not the full set of CAs
(or the set needed for the cert for Resolver Foo, for arbitrary value of
"Foo").

The bootstrap I'm working on has two phases (very closely coupled).
Learning and remembering names and trust anchors, minimizes the weakness
caused by the insecurity of the first step (using a well-known name).
For the case where the forwarder itself is "upgraded" (for lack of a better
term), it should be possible for the forwarder to publish trust anchors
both for its own name (random unique .zz name) and for the well-known
name's zone.
(i.e. Place the well-known name in its own zone, with a way to link from
that well-known name to the unique forwarder name, and to sign that linkage
by the locally instantiated well-known name's trust anchor.)
Local context and local significance opens up techniques that are
inappropriate and unworkable in the global namespace.

I'm interested in supporting Quad-N, but not exclusively. The idea is to
support same-resolver upgrades, for the largest possible set of resolvers
(full resolvers rather than forwarders). There are at least hundreds of
thousands of those, and possibly as many as several million (3 million is
the number reported by a researcher in DNS-OARC based on an extensive
multi-year study.)

Certainly, I'd position it as "implementors are strongly recommended to
support DNSSEC so that fallback to DNSSEC can be used if WebPKI validation
cannot succeed due to lack of CA certificate matching the certificate
offered, but where there is a corresponding TLSA record."

I don't think exclusively depending on DNSSEC is required, but I also don't
think exclusively depending on WebPKI is the best course of action for the
potential WG charter.

Brian