Subject: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Jun 2020 07:05:21 -0700

Hi folks,

As has been noted previously, the current Firefox DoH/TRR design
bypasses the ISP resolver even if the ISP resolver supports DoH.

I have just posted draft-rescorla-doh-cdisco-00, which describes a
CNAME-based mechanism for discovering when a local resolver supports
DoH/TRR. Firefox can then determine whether that resolver is on the
TRR list and if so can use it in preference to generic resolver. The
use of CNAME was chosen for pragmatic reasons (laid out in the draft).
We're studying other designs but thought it would be a good idea
to document this one.

See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2020 21:24:27 -0400

In article <[email-masked]> you write:
>DoH/TRR. ...

It looks like you're mixing together two questions: "I want an index
into my local DoH table" and "where's a DoH resolver?" They're both
plausible questions but I wouldn't mix them together.

For the first question, a CNAME lookup to doh-resolver.arpa (a name we
can easily ensure never exists in the public DNS) seems OK.

For the second question, I'd do a URI lookup of _doh._tcp.doh-resolver.arpa
or if you don't trust your local crudware resolver to handle URI, a TXT record.

In both cases you can't use DNSSEC but that seems inevitable for this
kind of bootstrap.

R's,
John

---

From: tirumal reddy <[email-masked]>
Date: Fri, 26 Jun 2020 13:08:13 +0530

On Thu, 25 Jun 2020 at 19:36, Eric Rescorla <[email-masked]> wrote:

> TRR list and if so can use it in preference to generic resolver.. The

    2.  Some consumer-grade middleboxes (e.g., WiFI routers) may block
        unknown RRTypes.  The data here is quite old and limited, but
        still not particularly promising.

Now-a-days several security vendors are offering security services in home
networks (co-located on the home router or on a seperate device). McAfee
security service co-located on Home routers does not block unknown RRTypes.

-Tiru

>
> -Ekr
>
>
>
>
>
>
>
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 26 Jun 2020 14:46:18 -0700

Hi Ekr,

Thanks for sharing this draft. Very exciting to see this step forward in supporting the automatic use of DoH.

Regarding the choice of using DNS + CNAME, I completely understand and sympathize with the practical deployment aspects. Going forward, I’d like to see if collectively we can use a record that gives a full DoH URI. Your draft does reference the option of using HTTPS RRs for this, as Tommy Jensen has proposed in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti>.

In my email to this list just a bit ago, I mentioned that we’re starting to request these RR types (well, the older version for HTTPSSVC, but will be updated) on the iOS and macOS betas. Hopefully we can measure based on that how much RRType interference exists in networks. I’d be curious to hear what kinds of measurements the Mozilla team is taking in this space, as you are able to share.

I’d also be interested to have a discussion here about the acceptable ranges for breakage. Certainly, if the percentage of home wifi setups that fails with a new RRType is very high, it’s a problem. However, if the percentage is lower but still significant (say, 5%?), we can consider the tradeoff of solutions. Intolerance to passing unknown RRTypes is one way that this could break; however, there are many other ways a local wifi router could potentially interfere. For example, a wifi router might not recurse to the ISP's DNS resolver, but some other resolver (which if it is 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that doesn’t). There will always be *some* tail of networks that won’t work, even with the CNAME approach; and I’d like to see a long-term solution that allows for richer information than just a hostname. Thoughts?

Best,
Tommy

> On Jun 25, 2020, at 7:05 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi folks,
> 
> See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt <https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt>
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Add mailing list
> [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2020 15:08:05 -0700

On Fri, Jun 26, 2020 at 2:46 PM Tommy Pauly <[email-masked]> wrote:

> Regarding the choice of using DNS + CNAME, I completely understand and
> sympathize with the practical deployment aspects. Going forward, I’d like
> to see if collectively we can use a record that gives a full DoH URI. Your
> draft does reference the option of using HTTPS RRs for this, as Tommy
> Jensen has proposed in
> https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti
> .
>
> In my email to this list just a bit ago, I mentioned that we’re starting
> to request these RR types (well, the older version for HTTPSSVC, but will
> be updated) on the iOS and macOS betas. Hopefully we can measure based on
> that how much RRType interference exists in networks. I’d be curious to
> hear what kinds of measurements the Mozilla team is taking in this space,
> as you are able to share.
>

We're just starting the work to collect data, but we expect to publish it
once we have it.

I’d also be interested to have a discussion here about the acceptable
> ranges for breakage. Certainly, if the percentage of home wifi setups that
> fails with a new RRType is very high, it’s a problem. However, if the
> percentage is lower but still significant (say, 5%?), we can consider the
> tradeoff of solutions. Intolerance to passing unknown RRTypes is one way
> that this could break; however, there are many other ways a local wifi
> router could potentially interfere. For example, a wifi router might not
> recurse to the ISP's DNS resolver, but some other resolver (which if it is
> 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that
> doesn’t).
>

Sure. Though note that it's proxying to a non-TRR resolver then whether it
filters CNAMEs doesn't matter because the intent here would be to use a
default TRR.

I'd be interested in hearing what tradeoffs you see here. Other than
inelegance, what's problematic about the CNAME approach?

There will always be *some* tail of networks that won’t work, even with the
> CNAME approach; and I’d like to see a long-term solution that allows for
> richer information than just a hostname. Thoughts?
>

Well, as I said when this group was first formed, we should start by
figuring out what we are trying to accomplish and the threat model.

For the TRR case, it's not actually the hostname we are interested in but
rather the identity of the network-associated TRR. The hostname is just a
convenient lookup key. If an ISP told us they wanted to use
"<isp-name>.invalid" that wouldn't be a problem for us as long as it was
unique.

The scenario you seem to be interested in is one in which the user joins
the network and then learns that the associated Do53 resolver supports DoH
and then connects to it with whatever coordinates that resolver (or DHCP or
whatever) provides. That clearly is not useful in the 3552 threat model
which assumes that the attacker entirely controls the network because the
attacker can just send their own resolver coordinates. That isn't to say
that there aren't more limited but still realistic threat models where this
would be useful, but I think you should start by describing those.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Jun 2020 23:10:44 +0000

> See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt

A particular relevant part of this draft for this WG is:

3.2.  Why a CNAME?

   Most other proposed designs (e.g., [I-D.pp-add-resinfo] and
   [I-D.pp-add-stub-upgrade], and [I-D.pauly-add-resolver-discovery])
   use new RRtypes.  While this may be the right answer eventually, it
   is less convenient for immediate deployment, for several reasons:

   1.  It is somewhat more difficult (though not impossible) to look up
       new RRTypes on the client and provision them on the ISP resolver.

   The choice to use a CNAME does have one major drawback: it does not
   let us provide the URL template but only the name of the resolver.
   This is not a problem for our system in practice because Firefox will
   only connect to resolvers on a preconfigured list and thus will use
   the CNAME as a lookup key for that list.  The Mozilla team is working
   to measure the rate of new RRType interference and may revise this
   approach depending on the results of that.

   [[OPEN ISSUE: We are working to measure the rate of new RRType
   interference and may revise this approach depending on the results of
   that.]]

Point 1 feels overstated. The clients we are talking about here are modern web browsers, which can clearly write whatever they want in their DNS queries. I cannot imagine that an ISP resolver that has to also act as an authoritative server would have any restriction on what RRtypes they can provision.

Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are looking into it. The key part of that is what is "unknown" to any such middlebox. The research should definitely look at whether CNAME is in the list of unknown RRtypes, given that stub resolvers rarely send CNAME queries.

The major drawback that is listed does indeed seem major for use cases other than Mozilla's TRR. This WG has been discussing other use cases, so it feels restrictive to consider a solution that is focused on just that one use case unless the middlebox problem is shown to be crippling to the use of new and more flexible RRtypes.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Sat, 27 Jun 2020 00:04:52 +0000

On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote:
> ... Other than inelegance, what's problematic about the CNAME approach?

inelegance is permanent, accretive, and earns compound interest. we ought not 
dismiss inelegance as the basis for reluctance. inelegance is not inevitable 
nor is it automatically acceptable.

> ...

as we describe them, we should also describe their scale, their age, and their 
likely lifespan. the 3552 threat model, while it does use the term 
'pervasive', is nowhere near as common as the SASE (secure access service 
edge) operations model, nor will it ever be. if apps who want to do their own 
DNS treat any DoH failure as an attack, and start an arms race of spy-vs-spy 
bypass along the lines of Tor, that's going to feel problematic to any of us 
whose privately owned securely operated edge networks have a local-only DNS 
policy.

RESINFO could probably get better results by using TXT, because of long tail 
problems. but ultimately we have to pick a default assumption that we can act 
on when secure resolver discovery fails. "OMG it's a 3552 attack" is not the 
only interpretation we could think of for this. it's entirely possible that 
the most engineering solution to the discovery problem is to fail hard when 
the middlebox prevents authenticated policy negotiation, to force middlebox 
upgrades. i know that "tough love" is a hard sell, but "assume 3552 attack" is 
also a form of tough love.

-- 
Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2020 17:36:02 -0700

On Fri, Jun 26, 2020 at 4:11 PM Paul Hoffman <[email-masked]> wrote:

> > See:
> https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt
>
> Point 1 feels overstated. The clients we are talking about here are modern
> web browsers, which can clearly write whatever they want in their DNS
> queries.

"clearly" is doing a lot of work here. Sure, it's just software so we could
do this. However, Firefox uses the system resolver and in particular calls
getaddrinfo(). So while yes, we could in theory write our own resolver or
plumb to the OS-specific more flexible interfaces (e.g. res_query()) up to
the part of the code that needs this information. Hence, as I said,
"somewhat more difficult (though not impossible)".

I cannot imagine that an ISP resolver that has to also act as an
> authoritative server would have any restriction on what RRtypes they can
> provision.
>

I do not operate such a resolver so I cannot speak to this point.

Point 2 is interesting, and I'm glad to hear that Mozilla and Apple are
> looking into it. The key part of that is what is "unknown" to any such
> middlebox. The research should definitely look at whether CNAME is in the
> list of unknown RRtypes, given that stub resolvers rarely send CNAME
> queries.
>
> The major drawback that is listed does indeed seem major for use cases
> other than Mozilla's TRR. This WG has been discussing other use cases, so
> it feels restrictive to consider a solution that is focused on just that
> one use case unless the middlebox problem is shown to be crippling to the
> use of new and more flexible RRtypes.
>

We haven't asked the WG to consider this draft. As I said in my message, we
thought it would be useful to document it, hence the draft.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Jun 2020 17:47:34 -0700

> also a form of tough love.

Hi Paul,

I think this response perhaps conflates two somewhat different issues,
namely CNAME versus authenticated policy propagation.

Ignoring the question of CNAME for the moment, if a device joins a
network and gets its configuration from that network (e.g., via DHCP),
then it is trusting that network to provide the configuration. So, the
question then becomes what benefit is obtained if that network
supplies a Do[TH] server rather than a Do53 server. In the 3552 model,
we assume the attacker has complete control of the network and can
therefore supply its own server, so it's not clear what the security
benefit is. Conversely, if the network is totally secure and trusted,
then it's *also* not clear what the security benefit is.

So, if we are to have unauthenticated discovery of Do[TH] servers,
then we must have some other threat model. For instance we might
think that the attacker can read all packets but for some reason
can't impersonate the DHCP server. What I'm saying is that we should
start by laying out what that threat model is and then we can define
what, if any, technical measures add security benefit in that threat
model. That would be true even if we knew that there weren't
middleboxes which tampered with new record types.

Two more points, if I may:

1. Where this interfaces with the question of CNAME versus RESINFO
is that RESINFO is much more flexible, but (as above) it's not
clear we can securely make use of this flexibility.

2. It's worth nothing that there are scenarios where the device
can get authenticated network configuration (for instance, if
the device is managed and has had some sort of authentication key
installed). The comments above do not apply to this scenario
but rather to the scenario where you have a naive device joining
a network.

-Ekr

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 27 Jun 2020 03:04:10 +0200

FWIW, there is a URI resource record, RFC 7553, that gives a URI as RDATA.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 27 Jun 2020 15:04:55 +0000

On Jun 26, 2020, at 5:36 PM, Eric Rescorla <[email-masked]> wrote:
>> Point 1 feels overstated. The clients we are talking about here are modern web browsers, which can clearly write whatever they want in their DNS queries.
>> 
> "clearly" is doing a lot of work here. Sure, it's just software so we could do this. However, Firefox uses the system resolver and in particular calls getaddrinfo(). So while yes, we could in theory write our own resolver or plumb to the OS-specific more flexible interfaces (e.g. res_query()) up to the part of the code that needs this information. Hence, as I said, "somewhat more difficult (though not impossible)".

I assumed that Firefox was using an internal mechanism for creating the DNS queries in the draft. How can Firefox send a CNAME query if it "uses the system resolver and in particular calls getaddrinfo()"? I admit weakness here, but I thought that getaddrinfo() doesn't let you specify the RRtype, just "give me an address" where "address" is defintely not "a domain name".

If Firefox has the means of sending a constructed CNAME query and process the response, shouldn't it also (ahem) clearly have the means of sending a constructed TBD1 query and process the response?

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jun 2020 08:49:38 -0700

On Sat, Jun 27, 2020 at 8:04 AM Paul Hoffman <[email-masked]> wrote:

> >> Point 1 feels overstated. The clients we are talking about here are
> modern web browsers, which can clearly write whatever they want in their
> DNS queries.
> >>
> > "clearly" is doing a lot of work here. Sure, it's just software so we
> could do this. However, Firefox uses the system resolver and in particular
> calls getaddrinfo(). So while yes, we could in theory write our own
> resolver or plumb to the OS-specific more flexible interfaces (e.g.
> res_query()) up to the part of the code that needs this information. Hence,
> as I said, "somewhat more difficult (though not impossible)".
>
> I assumed that Firefox was using an internal mechanism for creating the
> DNS queries in the draft.

No.

How can Firefox send a CNAME query if it "uses the system resolver and in
> particular calls getaddrinfo()"? I admit weakness here, but I thought that
> getaddrinfo() doesn't let you specify the RRtype, just "give me an address"
> where "address" is defintely not "a domain name".
>

https://linux.die.net/man/3/getaddrinfo

"If *hints.ai_flags* includes the *AI_CANONNAME* flag, then the
*ai_canonname* field of the first of the *addrinfo* structures in the
returned list is set to point to the official name of the host."

> If Firefox has the means of sending a constructed CNAME query and process
> the response, shouldn't it also (ahem) clearly have the means of sending a
> constructed TBD1 query and process the response?'''
>

We do not send a raw query.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2020 18:58:59 -0000

In article <CABcZeBNKHHO=n68tj2DMGQkRaZQzbZE=[email-masked]>,
>We do not send a raw query.

Beyond that I gather there is still concern about SOHO routers with
poorly implemented DNS forwarders that only handle some kinds of
queries.

R's,
John

PS: It sure would be nice to have more up to date info about how common
they are. Maybe I can use some of my 64 million RIPE Atlas credits.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jun 2020 12:21:42 -0700

> they are. Maybe I can use some of my 64 million RIPE Atlas credits.

I agree it would be nice. We are working on taking some measurements and I
believe Apple is as well.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 14:06:34 -0400

> poorly implemented DNS forwarders that only handle some kinds of

I believe that the majority of devices on the market are now based upon
versions of openwrt which, even if 10 years out of date, now have only 15
year old DNS forwarding code.  And that's new enough.

    > they are. Maybe I can use some of my 64 million RIPE Atlas credits.

It would be good to have some real data, and this would be a great thing to
do.

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

---

From: "John R Levine" <[email-masked]>
Date: 28 Jun 2020 14:29:22 -0400

> year old DNS forwarding code.  And that's new enough.

It's not what's on sale now, it's what's installed.  People tend to keep 
what they have unless it breaks in ways that are obvious to them.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Jun 2020 19:20:24 +0000

> what they have unless it breaks in ways that are obvious to them.

as we learned with EDNS, we should have broken more stuff sooner. being 
liberal in what we accept and conservative in what we generate has not scaled 
and won't.

-- 
Paul

---

From: Daniel Migault <[email-masked]>
Date: Mon, 29 Jun 2020 17:40:16 -0400

Hi,

I believe the proposal presents some
similarities to draft-mglt-drdp [1] that is
using the DNS to proceed to the
discovery. I see drdp as more generic,
and would be happy to improve it.

I would be happy to understand why HTTP
is a better stack to perform the
discover as opposed to DNS. I think that
DNS is better as it is the common
protocol to DoT DoH and DNS, but I might
be missing something.

Here are my comments regarding your
proposal:

I believe that CNAME is to restrictive
and would not make possible for example
to have multiple resolvers. I believe
the ISP should be able to provide
multiple resolvers. Some resolver may
implement DoH, DoT in combination with
multiple additional services. So in
short CNAME would limit the discover of
one or no resolvers.  The limitation
seems for both the application and the
ISP as it does not provide the ability
for an application to chose the service
and force the ISP to make that choice.
On the other hand, the ISP can hardly to
made a choice that fits any application
or the end user. The ISP cannot propose
different services for different
applications.

CNAME does not provide useful necessary
parameters that may also be useful for a
DoH resolver DRDP lists among others:
alpn, ensiconfig, uri template, user
display, auth_domain, filtering,
ip_subnet, dnssec, ....

My understanding is that BCP 17 saw SRV
as a long term solution for CNAME which
is now superseded by HTTPSVC/SVCB. I see
SRV as very common in home networks with
service discovery.

I believe that using a generic is
problematic as is prevents its resoltion
to be secured with DNSSEC.

In DRDP [1], the list of resolvers is
associated to a resolving domain. In the
case of an ISP the resolving domain is
derive with a reverse resolution from
the IP address announced by the ISP .
Note that other means may be provided.
With the resolving domain - in your case
resolver.example, the application will
retrieve the resolvers associated to the
resolving domain.  In your case you are
exclusively focused on DoH server, so
your application will them perform
_443_dns.example.com. SVCB.

Note that an early version of DRDP was
using SRV/TXT instead of SVCB.

Yours,
Daniel

[1]
https://github.com/mglt/draft-mglt-abcd-dofoo-discovery/blob/master/draft-mglt-add-rdp.mkd

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 16:15:21 -0700

> protocol to DoT DoH and DNS, but I might

I don't quite follow this, as we do not use HTTP.

> to have multiple resolvers
>

This goes back to use case. In our use case, the multiple resolvers would
be supplied by manual configuration of the client. the CNAME is just a
lookup key.

> to be secured with DNSSEC.

As I said earlier, this goes back to threat model. Please describe the
thrat model where you think DNSSEC helps.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Mon, 29 Jun 2020 20:43:08 -0400

> I don't quite follow this, as we do not use HTTP.
I thought you were saying using HTTPSSVC was architecturally better - that
was section 5 not 4.

> be supplied by manual configuration of the client. the CNAME is just a

Unless I am missing something, I do not see how the ISP could respond
saying and provide the application a resolver that implements DoH, a
resolver that implement DoTs, a resolver that implements DoH and DNSSEC
validation and let the application pick the one it prefers.

> thrat model where you think DNSSEC helps.

The threat model seems for Comcast and the end user having the traffic of
its end users being redirected to Cloudflare instead of the local resolver.
Both resolvers are trusted according to Firefox but the end user and the
ISP may have a different view. It also means that any information that is
not preconfigured cannot be trusted.

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 18:15:07 -0700

> I thought you were saying using HTTPSSVC was architecturally better - that

Well, S 5 is an empty IANA Considerations section.

In any case, I don't really have a position on whether HTTPSVC is better.
The text says it "may be" the right answer eventually.

> validation and let the application pick the one it prefers.

That's correct. As I said, that's not part of our use case, because we're
only trying to determine which network you are on and then look up the
resolvers in our TRR list. If we expected ISPs to have >1 kind of resolver
we'd probably just have them register them all with us and then incorporate
the list into the binary. I appreciate that this won't work well for many,
but as I said, this mechanism is targeted at quite a narrow use case.

> not preconfigured cannot be trusted.

Well, I agree that this attack is possible (and is described in S 4) but I
don't see how DNSSEC prevents it. It's true that if the user is on a
network operated by "example.com" DNSSEC could be used to secure the
information that "example.com" wants you to use a given resolver, but the
problem is that the user has no secure way of discovering that they are on "
example.com", and therefore the attacker can just substitute in their own
domain there.

I could of course be wrong about this. If you believe I am, I would
encourage you to describe the entire discovery chain and where you believe
DNSSEC acts to prevent attack.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Mon, 29 Jun 2020 23:05:11 -0400

On Mon, Jun 29, 2020 at 9:15 PM Eric Rescorla <[email-masked]> wrote:

>> I thought you were saying using HTTPSSVC was architecturally better
>> - that was section 5 not 4.
>>
>
that was section 5 of adns

>>> This goes back to use case. In our use case, the multiple resolvers
>>> would be supplied by manual configuration of the client. the CNAME is just
>>> a lookup key.
>>>
>>
If the lookup takes as input the IP addresses or something provided by the
ISP (like the local resolver IP address), the resulting chain is likely to
be from the ISP. DNSSEC is needed to assert it. Another way would be to be
able to display example.com. The user should be able to see how the domain
is associated to the ISP it has subscribed to or if it is being redirected
to a cloud provider.  DNSSEC would make sur the corresponding IP address -
as well as other information - are bound to the displayed domain.

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 20:08:02 -0700

On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <[email-masked]> wrote:

> be from the ISP. DNSSEC is needed to assert it.
>

Why do you assume that the IP is delivered securely?

Another way would be to be able to display example.com. The user should be
> able to see how the domain is associated to the ISP it has subscribed to or
> if it is being redirected to a cloud provider.  DNSSEC would make sur
> the corresponding IP address - as well as other information - are bound to
> the displayed domain.
>

At this point, why would I need DNSSEC? I could just use the WebPKI.

-Ekr

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Jun 2020 00:51:40 -0700

i wasn't speaking, but i was addressed, so i will attempt an answer.

Eric Rescorla wrote on 2020-06-29 20:08:
> 
> 
> On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     If the lookup takes as input the IP addresses or something provided
>     by the ISP (like the local resolver IP address), the resulting chain
>     is likely to be from the ISP. DNSSEC is needed to assert it. 
> 

because dnssec allows me to verify end-to-end authenticity of 
name/address bindings (and other dns content.) while tls and ssh and 
gssapi add a useful second layer of end-to-end identify verification, 
those are not the only protocols i use.

>     Another way would be to be able to display example.com
>     <http://example.com>. The user should be able to see how the domain
>     is associated to the ISP it has subscribed to or if it is being
>     redirected to a cloud provider.  DNSSEC would make sur
>     the corresponding IP address - as well as other information - are
>     bound to the displayed domain.
> 

dns has always been used by protocols outside the web, and will always 
be used by protocols outside the web. but even in your web use case, 
there will always be uri schemes which lack end-to-end identity 
verification. some current examples can be found here:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

the web is a fish. the internet is a pond.

-- 
P Vixie

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 30 Jun 2020 19:07:43 +1000

Hi Paul,

On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
> name/address bindings (and other dns content.) 

DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, but in this case the IP address didn't come from DNSSEC.  It's not DNS content.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Jun 2020 09:19:18 +0000

On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote:
> DNSSEC allows you to be sure of the veracity of what comes from DNSSEC, but
> in this case the IP address didn't come from DNSSEC.  It's not DNS content.

i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered securely 
today is because off-net DHCP forgery is hard, or because their technician 
programmed it into my edge gateway, or their customer service department 
printed it on my welcome letter.

but i didn't want to interpret the question in that way because my answer 
would sound silly, even to me. i apologize for my confusion.

---

moving on, what i'd love to have is SDNCP rather than DHCP. S=secure, 
N=network. because i want to know i'm getting what the operator of the network 
wants me to get, and because there are other parameters besides RDNS that i 
care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i will 
have to talk to. because, IoT. if DHCP isn't useful because it's not secure, 
we should stop using it. but before we could do that, we'd have to meet its 
functionality in another way.

i realize that i've identified an unmarketable general case which has got to 
sound like i want to boil the ocean, or boil frogs, or something. but i figure 
if i don't say something, then after we've consensed around a secure RDNS 
discovery protocol, and somebody says what about all these other parameters 
that also have to be set by the network operator and have to be authenticated, 
we won't know how we got there.

i'd like setting up an IoT device to be like bluetooth pairing, only, secure. 
like, enter a four-digit PIN or something. getting secure RDNS configuration 
should be like that. right now it's a welcome letter printed by my ISP, and 
that seems outdated.

-- 
Paul

---

From: Daniel Migault <[email-masked]>
Date: Tue, 30 Jun 2020 08:49:27 -0400

Hi,

My responses would have been inline with those of Paul.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2020 05:58:01 -0700

On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <[email-masked]> wrote:

> today is because off-net DHCP forgery is hard,

Let's start here:
I agree that off-net DHCP forgery is hard. However, once you assume that
you are off-path, then Do53 interception is *also* hard. So for this to be
useful you need an environment in which the attacker is able to attack Do53
but *not* to attack DHCP. What I'm asking for is for someone to define that
threat model precisely so that we can design protocols that match it.

> should be like that. right now it's a welcome letter printed by my ISP,

This all sounds great. And when it was available, we could also use it to
indicate which Do[HT] server you ought to use.

The question I am addressing is what we ought to do in the interim.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jun 2020 09:17:32 -0400

> functionality in another way.

We tried that. Unfortunately, what we found is that it just moves the problem. Suppose you send out an SDNCP discovery request and get back one or more signed responses. Which one do you choose?

The answer is presumably that you choose the one you trust, but maybe you don’t trust any of them.  If you don’t trust any of them, is it because you are on a foreign network, or because the legitimate one(s) are being blocked?  If you do trust one, why do you trust it?  How do you establish trust in something you haven’t communicated with before? If you are able to set up a trust relationship, why not just use that to authenticate 802.1x?

Consider it from the other angle: suppose you just take what the network gives you, but you want to know if it’s legitimate or spoofed. How do you do _that_?

Well, it turns out we know how. You validate with DNSSEC; if that doesn’t work, you know your DNS server is lying to you. You validate with PKI. If that doesn’t work, you know that your TLS server is lying to you. 

If you want to trust the network, use 802.1x. Use the fact that 802.1x securely validated as an indication that you are on a trusted network, and can trust what the infrastructure says to you at least enough to bootstrap. If not, don’t trust anything the network tells you—validate it, or don’t use it. And by the way, even if 802.1x validates, that’s not at all a reason not to use DNSSEC and TLS and PKI. Use them too. So all 802.1x really buys you is that it’s harder for an on-link attacker to trick you into wasting time validating stuff that won’t validate, which is probably why it’s not more widely used.

So the question is, what problem are you solving with SDNCP that isn’t already solved with DNSSEC, TLS and PKI?

The only answer we came up with is that it might be nice to be able to know that we are speaking to the same operator we were last time. But we didn’t actually identify a compelling use case for that, and consequently the work was abandoned.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 30 Jun 2020 19:13:53 +0530

> threat model precisely so that we can design protocols that match it.

The various possible attacks in a home network are discussed in
https://tools.ietf.org/html/draft-btw-add-home-06#section-9

-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2020 09:00:11 -0700

> https://tools.ietf.org/html/draft-btw-add-home-06#section-9

As far as I can tell, what this text says is that authenticating the server
based on information received in DHCP is not useful.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Jun 2020 17:19:09 +0000

> The question I am addressing is what we ought to do in the interim.

Given that this discussion is happening on an IETF WG mailing list, the sub-question is who you mean by "we". Earlier, you indicated that you were not necessarily proposing this for IETF standardization, and your draft is indeed informational, nor have you asked the WG to consider the proposal.

If all that Firefox needs is a simple way for a resolver to reply with a key that Firefox can use to look up in its TRR list, the CNAME proposal is fine. For that matter, so would an A record where Mozilla assigns each TRR an arbitrary IPv4 address that is used as a key; this would avoid any problems with middleboxes that blocked CNAME queries. There doesn't seem to be any value to standardize such a proposal.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2020 10:28:44 -0700

On Tue, Jun 30, 2020 at 10:19 AM Paul Hoffman <[email-masked]>
wrote:

> Given that this discussion is happening on an IETF WG mailing list, the
> sub-question is who you mean by "we".

I'm talking about what this WG ought to do.

Earlier, you indicated that you were not necessarily proposing this for
> IETF standardization, and your draft is indeed informational, nor have you
> asked the WG to consider the proposal.
>
> If all that Firefox needs is a simple way for a resolver to reply with a
> key that Firefox can use to look up in its TRR list, the CNAME proposal is
> fine. For that matter, so would an A record where Mozilla assigns each TRR
> an arbitrary IPv4 address that is used as a key; this would avoid any
> problems with middleboxes that blocked CNAME queries. There doesn't seem to
> be any value to standardize such a proposal.
>

As I said before, I'm not asking for standardization of this proposal. I
posted it to document what it is that we do.

With that said, a number of the comments on this proposal have taken the
form of "this is inflexible because we want to carry information of type
X". I agree that that's technically correct, but the point that I am making
(and in fact one that I made when ADD was first chartered) is that
proposals that intend to carry other data (such as the URI template of the
resolver, for instance) need to document the threat model that they are
assuming and demonstrate that they provide some value in that threat model.
That would be true even if we had never submitted this document. What I
have seen so far seems insufficient.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 30 Jun 2020 17:47:05 +0000

On Jun 30, 2020, at 10:28 AM, Eric Rescorla <[email-masked]> wrote:
> With that said, a number of the comments on this proposal have taken the form of "this is inflexible because we want to carry information of type X". I agree that that's technically correct, but the point that I am making (and in fact one that I made when ADD was first chartered) is that proposals that intend to carry other data (such as the URI template of the resolver, for instance) need to document the threat model that they are assuming and demonstrate that they provide some value in that threat model.. That would be true even if we had never submitted this document. What I have seen so far seems insufficient.

Fully agree about "insufficient", including in the drafts I'm co-author on. I don't think each draft should be doing its own threat model because doing so has not led to any agreeemnt in the past, but it might be good if the WG wanted to have that in general.

--Paul Hoffman

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 30 Jun 2020 23:23:47 +0200 (CEST)

>     Il 30/06/2020 14:58 Eric Rescorla <[email-masked]> ha scritto:
> 
>     On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <[email-masked] mailto:[email-masked] > wrote:
> 
>     I agree that off-net DHCP forgery is hard. However, once you assume that you are off-path, then Do53 interception is *also* hard. So for this to be useful you need an environment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someone to define that threat model precisely so that we can design protocols that match it.
> 
I have written and deleted two or three longer replies to this, so I will just quote what Daniel Migault wrote a few messages ago: "The threat model seems for Comcast and the end user having the traffic redirected to Cloudflare instead of the local resolver." But of course the basic issue is that we seem to disagree on what a threat is.

--

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

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Jun 2020 15:05:13 -0700

On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> I have written and deleted two or three longer replies to this, so I will
> just quote what Daniel Migault wrote a few messages ago: "The threat model
> seems for Comcast and the end user having the traffic redirected to
> Cloudflare instead of the local resolver." But of course the basic issue is
> that we seem to disagree on what a threat is.
>

Agree that there is disagreement here.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2020 15:05:55 -0700

> that we seem to disagree on what a threat is.

No, I don't in fact that's the issue at all. To recap, this is a solution
for a very specific problem. I'm not suggesting that it's a generic
solution.

However, there have been a number of proposals for nominally generic
solutions none of which seem to come with a fully defined threat model. I'm
trying to get to what that model is. Specifically, I agree that it would be
a useful to allow endpoint devices to securely learn the identity of the
Do[HT] server associated with their local network [0]. This would then
allow you to get private resolution even if there were attackers on the
network (as in classical Ethernet or unencrypted WiFi). However, even with
that objective, we still need to define a realistic set of attacker
capabilities and then a design which is secure given those capabilities.
That is what I am asking for.

-Ekr

[0] Under the assumption that you are connecting to the right network, of
course, which is sometimes a very thin assumption.

> [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 01 Jul 2020 05:34:17 +0000

On Tuesday, 30 June 2020 13:17:32 UTC Ted Lemon wrote:
> > N=network. because i want to know i'm getting what the operator of the
> > network wants me to get, and because there are other parameters besides
> > RDNS that i care about, such as whether there's a mandatory HTTPS or
> > HTTP/3 proxy i will have to talk to. because, IoT. if DHCP isn't useful
> > because it's not secure, we should stop using it. but before we could do
> > that, we'd have to meet its functionality in another way.
> 
> We tried that. Unfortunately, what we found is that it just moves the
> problem. Suppose you send out an SDNCP discovery request and get back one
> or more signed responses. Which one do you choose?

as i wrote, i'd expect it to be like bluetooth pairing, which has the same 
problem, and which solves it with a six-digit PIN code for verification. maybe 
we can use something more modern, like thumbprint scans.

> already solved with DNSSEC, TLS and PKI?

as i wrote, there are other network configuration parameters which are also 
valuable targets, such as outbound proxy settings.

as i've written elsewhere, not all DNSSEC-validating servers are equal. as the 
owner and operator of private networks, i require all my users, apps, and 
nodes to use a DNSSEC-validating server that also has a policy layer, and 
transaction logging. so, using DNSSEC as a measure of correctness does not and 
will never cover the requirements of the Secure Access Service Edge. this is 
more important than ever now that so many workers are working from home. see:

https://techspective.net/2020/06/23/the-four-horsemen-of-sase-secure-access-service-edge/

> The only answer we came up with is that it might be nice to be able to know
> that we are speaking to the same operator we were last time. But we didn’t
> actually identify a compelling use case for that, and consequently the work
> was abandoned.

i think i should have paid more attention at that time, and i apologize. DHCP 
was always the wrong thing to build, like BOOTP before it, and IPv6 address 
assignment after it. secure hosting networks have to use /30 and later /31 
netmasks (one customer per vlan) in order to trust any of this.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Jul 2020 01:59:51 -0400

> we can use something more modern, like thumbprint scans.

Yes, we thought of all that. But we couldn’t come up with a use case for it.

> valuable targets, such as outbound proxy settings.

Who configures those with DHCP? That would be insane.

> more important than ever now that so many workers are working from home. see:

It sounds like a validating stub resolver will fail to work with your product. 

> netmasks (one customer per vlan) in order to trust any of this.

I don’t know what a “secure hosting network” is. Is that an IETF thing?

---

From: tirumal reddy <[email-masked]>
Date: Wed, 1 Jul 2020 12:04:31 +0530

On Tue, 30 Jun 2020 at 21:30, Eric Rescorla <[email-masked]> wrote:

> As far as I can tell, what this text says is that authenticating the
> server based on information received in DHCP is not useful.
>

No, the draft discusses new DHCP/RA options to convey the DoH/DoT server
domain name. Section 9 discusses several attacks and mitigations the
endpoint can use to defend from an on-path attacker modifying the DHCP
response.

(1) Attacker modifying the DHCP response to point to the DoH/DoT server
hosted by the attacker.
(2) Attacker modifying the DHCP response to point to a public DoH server
not capable of filtering malware when the local resolver provides malware
filtering capability.

-Tiru