Subject: [Doh] Reviewing Resolver-Associated DOH

From: Ben Schwartz <[email-masked]>
Date: Fri, 15 Mar 2019 09:12:56 -0400

I'd like to thank the working group participants for the extensive
discussion of our most recent drafts.  However, I would appreciate more
review of the Resolver-Associated DOH draft, which has the largest time
segment allocated for the upcoming meeting.  This draft contains several
components that have been controversial in the past:

1. IP-address certificates
2. A new .well-known endpoint
3. JSON
4. Recursive resolvers synthesizing responses as if they were authoritative
for certain names
5. Machine-readable content in a TXT record

Also, the draft does not enable the use of DoH if (1) an application relies
on POSIX-like DNS APIs to bootstrap AND (2) the resolver is only reachable
on a non-public IP address (e.g. RFC 1918).  This is a side effect of the
requirement that the DoH server provide a valid certificate for its name,
chained to a root that is already trusted by the client.  This draft does
not alter that requirement.

If any of these technical elements are of concern to you, please comment
now, so that the meeting can be as productive as possible.

--Ben

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 15 Mar 2019 13:41:34 +0000

Bad ! Especially if the less enlightened think to try to create a certificate for a private IP. Very bad idea.

  1.  A new .well-known endpoint

Maybe someone can suggest a better location that doesn’t break things.

4. Recursive resolvers synthesizing responses as if they were authoritative for certain names
5. Machine-readable content in a TXT record

Also, the draft does not enable the use of DoH if (1) an application relies on POSIX-like DNS APIs to bootstrap AND (2) the resolver is only reachable on a non-public IP address (e.g. RFC 1918).  This is a side effect of the requirement that the DoH server provide a valid certificate for its name, chained to a root that is already trusted by the client.  This draft does not alter that requirement.

If any of these technical elements are of concern to you, please comment now, so that the meeting can be as productive as possible.

--Ben
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 15 Mar 2019 13:51:20 +0000

Continuing (sigh outlook shortcuts stink).

 I hate it overloading TXT. TXT usage is already full of horrors, I know when looking for ‘quick’ solutions it’s there its easy and its likely to work. That’s not how protocol developments should be, is it the ‘right’ option ? If there isn’t a better answer then fine TXT it is.

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 15 Mar 2019 17:51:15 +0400

On Fri, Mar 15, 2019 at 5:41 PM Winfield, Alister
<Alister.Winfield=[email-masked]> wrote:
> IP-address certificates
> A new .well-known endpoint
>
>
>

Can you elaborate more ?
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 15 Mar 2019 13:55:17 +0000

> Maybe someone can suggest a better location that doesn’t break things.

   I can't decide on anywhere that’s not full of horrors... That is I'm reluctantly falling back towards the .well-known endpoint but every time I see a thing like it somehow I suspect there is a problem there waiting to be found later.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Mar 2019 16:21:55 +0000

For clarity: in draft-ietf-doh-resolver-associated-doh, IP address certificates are only used when getting the DoH servers using HTTPS. The format for that query is:
   https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/

On Mar 15, 2019, at 6:41 AM, Winfield, Alister <Alister.Winfield=[email-masked]> wrote:
> 	• IP-address certificates
>  

Can you say why they are bad? They are not common, but they are certainly available and have proven useful in some environments for a long time.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Mar 2019 16:27:23 +0000

> 5. Machine-readable content in a TXT record

This is the first I had heard that people objected to using a TXT record, but I might have missed that part of the discussion. Given that this query is for a newly-created SUDN that is only used for looking up DoH information, there is no chance that the TXT record would be in use for anything else.

Having said that, it would be quite easy for this document to create a new RRtype for this particular query. (I would not want to re-use the URI RRtype because it would take more effort to explain the priority and weight, as well as dealing with the common error of people not put the URI in quotations marks as is required for the URI RRtype.)

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 15 Mar 2019 12:52:30 -0400

To be clear, I'm not objecting to this choice.  I'm merely noting that use
of TXT has been a point of controversy in other discussions at the IETF.
Some groups have decided to proceed with TXT, some have preferred to use
different or new RRTYPEs, and some have not yet decided.  I would like the
working group to consider this question soon so it doesn't delay consensus
later.

On Fri, Mar 15, 2019 at 12:27 PM Paul Hoffman <[email-masked]>
wrote:

> On Mar 15, 2019, at 6:12 AM, Ben Schwartz <bemasc=[email-masked]..org>
> wrote:
> This is the first I had heard that people objected to using a TXT record,
> but I might have missed that part of the discussion. Given that this query
> is for a newly-created SUDN that is only used for looking up DoH
> information, there is no chance that the TXT record would be in use for
> anything else.
>
> Having said that, it would be quite easy for this document to create a new
> RRtype for this particular query. (I would not want to re-use the URI
> RRtype because it would take more effort to explain the priority and
> weight, as well as dealing with the common error of people not put the URI
> in quotations marks as is required for the URI RRtype.)
>
> --Paul Hoffman

---

From: "Hewitt, Rory" <[email-masked]>
Date: Fri, 15 Mar 2019 16:53:21 +0000

Ben,

Comments inline:

No position

As with all /.well-known/ endpoints, the issue is both standardization and publicization. AIUI, @mnot's original ideal would be to have /.well-known/ be pretty 'generic'. Therefore I'm not a fan of "/doh-servers-associated/" - I'd much rather see "/dns/doh/", which would enable other (future) DNS-related functionality to have a sub-folder within "/.well-known/dns/". If that's not a possibility, what about "/.well-known/dns-doh/"?

  1.  JSON

Not sure of the question here. Are you asking about the format JSON should take, or whether JSON is a 'good idea'? Yes to the latter.

  1.  Recursive resolvers synthesizing responses as if they were authoritative for certain names

No position

  1.  Machine-readable content in a TXT record

As with #3, good idea, but not sure of the exact question.

Finally, I think the spec should contain examples of a 'proposed' JSON response and of the format of a TXT RR. Without examples (even where marked as "unofficial proposal"), it's much harder to read by those who didn't write it.

Rory

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Friday, March 15, 2019 6:13 AM
To: DoH WG <[email-masked]>
Subject: [Doh] Reviewing Resolver-Associated DOH

I'd like to thank the working group participants for the extensive discussion of our most recent drafts.  However, I would appreciate more review of the Resolver-Associated DOH draft, which has the largest time segment allocated for the upcoming meeting.  This draft contains several components that have been controversial in the past:

--Ben

---

From: "Hewitt, Rory" <[email-masked]>
Date: Fri, 15 Mar 2019 16:57:40 +0000

Ben,

How has the use of TXT been a point of controversy in the past?

Is it a general "TXT records are bad" or "Adding new TXT records is bad" or "TXT records have never been standardized or formatted consistently among their various uses, so there's always the possibility of clashes".

Because I, for one, would agree with the last.

Rory

From: Ben Schwartz <bemasc=[email-masked]>
Sent: Friday, March 15, 2019 9:53 AM
To: Paul Hoffman <[email-masked]>
Cc: DoH WG <[email-masked]>
Subject: Re: [Doh] Use of TXT records

To be clear, I'm not objecting to this choice.  I'm merely noting that use of TXT has been a point of controversy in other discussions at the IETF.  Some groups have decided to proceed with TXT, some have preferred to use different or new RRTYPEs, and some have not yet decided.  I would like the working group to consider this question soon so it doesn't delay consensus later.

On Fri, Mar 15, 2019 at 12:27 PM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 15 Mar 2019 15:24:17 -0400

> How has the use of TXT been a point of controversy in the past?

See for example
https://mailarchive.ietf.org/arch/msg/tls/b0DQpCStJ4RSlp7uVXSobS-ssjA

> Is it a general "TXT records are bad" or "Adding new TXT records is bad"
> or "TXT records have never been standardized or formatted consistently
> among their various uses, so there's always the possibility of clashes".
>

My understanding is that some DNS experts believe that TXT records should
be reserved for human-readable comments, while others believe that it is
more expedient to store data in TXT records than to define a new RRTYPE for
each new usage.

> *From:* Ben Schwartz <bemasc=[email-masked]>
> *Sent:* Friday, March 15, 2019 9:53 AM
> *To:* Paul Hoffman <[email-masked]>
> *Cc:* DoH WG <[email-masked]>
> *Subject:* Re: [Doh] Use of TXT records
>
>
>
> On Mar 15, 2019, at 6:12 AM, Ben Schwartz <
> bemasc=[email-masked]..org> wrote:

---

From: "Hewitt, Rory" <[email-masked]>
Date: Fri, 15 Mar 2019 19:47:26 +0000

Understood.

Well presumably TXT records (given their name) were ORIGINALLY INTENDED to only store human-readable text. But what defines human-readable? I mean, it's all ASCII characters (no binary data), so it's all "human-readable" to some extent.

The problem is surely that because there is no standard that says "The first X characters in a TXT record must be one of the following IANA-registered types, and the subsequent data must follow the related IANA format", then ANYTHING which reads a TXT record must do some (possibly complex) processing to determine what sort of TXT record it is?

For instance, SPF records just start with v=spf1 followed by a blank, which REALLY bugs me, because there's nothing that defines what 'type' of TXT record it is. But the subsequent text is 'kinda' human-readable - you just need to know its format.

I'm fine with using TXT records for DoH, but I would love them to start with type=DOH followed by a blank. Whatever format beyond that is used doesn't matter, as long as it's consistent. Since it's going to be IP addresses, what's the concern - it wouldn't even need to be Base64-encoded, would it?

If you use a new RRTYPE, then every single document ever written about DNS record types will have to be updated to include the new RRTYPE.

Maybe a little hyperbolic, but only a little...

LSS; Use TXT records.

Rory

From: Ben Schwartz <[email-masked]>
Sent: Friday, March 15, 2019 12:24 PM
To: Hewitt, Rory <[email-masked]>
Cc: Paul Hoffman <[email-masked]>; DoH WG <[email-masked]>
Subject: Re: [Doh] Use of TXT records

On Fri, Mar 15, 2019 at 12:57 PM Hewitt, Rory <[email-masked]<mailto:[email-masked]>> wrote:
Ben,

See for example https://mailarchive.ietf.org/arch/msg/tls/b0DQpCStJ4RSlp7uVXSobS-ssjA

My understanding is that some DNS experts believe that TXT records should be reserved for human-readable comments, while others believe that it is more expedient to store data in TXT records than to define a new RRTYPE for each new usage.

Rory

From: Ben Schwartz <bemasc=[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 15, 2019 9:53 AM
To: Paul Hoffman <[email-masked]<mailto:[email-masked]>>
Cc: DoH WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Doh] Use of TXT records

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Mar 2019 15:51:41 -0500

On 3/15/19 8:41 AM, Winfield, Alister wrote:
> Bad ! Especially if the less enlightened think to try to create a 
> certificate for a private IP. Very bad idea
>

If you have more detailed thoughts on this to share, I'm sure the ACME 
working group would appreciate your input on 
https://tools.ietf.org/html/draft-ietf-acme-ip-05

/a

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Mar 2019 08:57:26 +0100

> On 15 Mar 2019, at 17:52, Ben Schwartz <bemasc=[email-masked]> wrote:
> 

If a slower consensus means a more easily adopted solution, take the slower consensus.  I realize this is a controversial thing to say in a room full of DNS experts, but rolling out new RRTYPEs is a royal pain.  TXT is far easier to deal with.

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 Mar 2019 15:27:34 +0000

> If a slower consensus means a more easily adopted solution, take the slower consensus.  I realize this is a controversial thing to say in a room full of DNS experts, but rolling out new RRTYPEs is…

I thoroughly disagree in this case. The only application using this will be one that can create binary messages, so the RRtype number is pretty trivial. 

The reason I chose TXT is that there is zero chance that there is any other reason for a TXT record for this special-use domain name, and people know TXT. If the WG wants a new RRtype for this, that's easy for me to change in the draft.

--Paul Hoffman

---

From: nusenu <[email-masked]>
Date: Sat, 16 Mar 2019 15:51:00 +0000

> Abstract
> 
>    Browsers and web applications may want to know if there are one or
>    more DoH servers associated with the DNS recursive resolver that the
>    operating system is already using. 
[...]
> There is a use case for browsers and web applications to want

to make it clear that this discovery mechanism can be used by any application
(or even the OS itself) and is not limited to "browsers and web applications"
maybe use something more generic like "Systems and applications may want know
if there are one or more DoH servers ..."?

> TXT vs. RRtype

For the reasons Paul outlined and since this is a special local-only domain
name I believe TXT is fine here.
I also agree with Eliot that TXT allows easier adoption than a new RRtype.

Generally speaking I would find it nice to have a similar discovery mechanism
for DoT but since that is outside the DoH WG I assume it has to go into a
separate document (even though it could copy most of the text).

https://datatracker.ietf.org/wg/doh/about/ wrote:
> This will enable the domain name system to
> function over certain paths where existing DNS methods (UDP, TLS [RFC 7857],

there is probably a typo:
RFC 7857 (Updates to NAT) vs RFC 7858 (DNS-over-TLS)

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: nusenu <[email-masked]>
Date: Sat, 16 Mar 2019 15:51:00 +0000

Hewitt, Rory wrote:
> As with all /.well-known/ endpoints, the issue is both
> standardization and publicization. AIUI, @mnot's original ideal would
> be to have /.well-known/ be pretty 'generic'. Therefore I'm not a fan
> of "/doh-servers-associated/" - I'd much rather see "/dns/doh/",
> which would enable other (future) DNS-related functionality to have a
> sub-folder within "/.well-known/dns/". If that's not a possibility,
> what about "/.well-known/dns-doh/"?

+1

I find these suggested .well-known URLs clearer than "doh-servers-associated".

Maybe it would be good to have a single matching string used here and in 
the .arpa DNS lookup.

> Not sure of the question here. Are you asking about the format JSON
> should take, or whether JSON is a 'good idea'? Yes to the latter.

+1

> Finally, I think the spec should contain examples of a 'proposed'
> JSON response and of the format of a TXT RR. Without examples (even
> where marked as "unofficial proposal"), it's much harder to read by
> those who didn't write it.

I was also looking for examples of the JSON response and the TXT RR record,
when reading the I-D, so yes to examples in the text.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 Mar 2019 16:04:49 +0000

> if there are one or more DoH servers ..."?

Good point. I'll discuss "browser can be almost any application" in the next draft.

> I find these suggested .well-known URLs clearer than "doh-servers-associated".

I'm generally against this idea for two reasons:

- No one will see this URL other than software developers and operators watching their logs. They will not be visible to users.

- Layered spaces under a .well-known/ are possible but I don't think they are well-understood.

> Maybe it would be good to have a single matching string used here and in 

I disagree with this for the same reasons as above.

> when reading the I-D, so yes to examples in the text.

Fully agree. There will be an example in the next version of the draft.

--Paul Hoffman

---

From: nusenu <[email-masked]>
Date: Sat, 16 Mar 2019 20:58:00 +0000

A general question before some more comments:

If the application supports the discovery mechanism in this
I-D _and_ has an option where the user can explicitly set
a DoH URI (like current Firefox has), in that case 
the DoH URIs discovered via this protocol MUST NOT override
the user's choice, correct?
(since some of the discovery mechanisms
in the current draft use unauthenticated data).

the text could be something like:

"If the DoH client has a DoH URI configured already, 
it MUST NOT override the DoH URI learned through the discovery
mechanisms in this document."

> 3.  DoH Servers from DNS
> 
>    To find the URI templates for DoH servers associated with a resolver,
>    a browser sends that resolver a query for "resolver-associated-
>    doh.arpa" 

I believe this specific discovery mechanism 
introduces a new attack opportunity that is not there
today.

Imagine a client having statically configured his operating system for Do53
via 8.8.8.8 (DNS options in DHCP are ignored on the client)
and imagine an attacker being in the temporary position between the user
and 8.8.8.8 (i.e. an internet cafe).

Under these circumstances "DoH Servers from DNS" allows an attacker 
to persistently set a victims DoH server URI. 
Which gives the attacker access to the victims DNS traffic and allows him
to feed the DoH client arbitrary responses even after the 
victim is out of his reach (i.e. user left the internet cafe). 
There is also no chance the victim could check
the integrity of TXT records via DNSSEC because they will never be signed.

The same attack vector also applies if the user uses Do53 via 10.0.0.1
and the attacker sits between 10.0.0.1 and 8.8.8.8 (the upstream resolver of 10.0.0.1).

Same attack vector applies to section 4 (Resolver Addresses from DNS).

>    A client MUST re-issue the queries in "DoH Servers from DNS" and
>    "Resolver Addresses from DNS" every time the configured resolver in
>    the operating system changes.

This would break the persistence of the attack but does not help if the user
statically configured his resolver (ignoring DNS options in DHCP) or the internet cafe
is using the same resolver as the victim's home network (i.e. 8.8.8.8).

To avoid introducing this new attack vector and to prevent downgrade
attacks from section 2 to less safe option 3 I would suggest
to stick to the safest option in the current I-D (DoH Servers from HTTPS)
and drop the less safe options or at least add the following 
3 parts to reduce the impact (persistence) of the attack and
to make it clear to implementer and operators that they MUST 
do/provide the option described in section 2 before doing
section 3:

1)
extend: 

> A client MUST re-issue the queries in "DoH Servers from DNS" and
> "Resolver Addresses from DNS" every time the configured resolver in
> the operating system changes 

with:

or whenever the client's IP address changes
(even if the resolver does not change). 

2)
extend:

>    If the array of URI templates returned is empty, that indicates that
>    the resolver does not have any DoH servers associated with it.

with:

>    **DoH clients MUST NOT attempt to find DoH servers via the mechanism 
>    defined in section 3 in that case.**

3)

extend section 8 with something like:
"The mechanism in section 2 is the safest and MUST be attempted first."

You could also consider some downgrade attack protections where the attacker
simply blocks 443 to force the unauthenticated mechanism in section 3.

Such a protection could be implemented via an additional field in the JSON file
by borrowing max-age from HSTS.
https://tools.ietf.org/html/rfc6797#section-6.1.1

>    The returned JSON object [RFC8259] MUST contain a member whose name
>    is "associated-resolvers" and whose value is a JSON array.  The array
>    contains zero or more JSON strings, each of which is a single URI
>    template.

It would be great if the JSON format would specify an optional description
field. The description could then be displayed in the application UI. This would allow
the operators to provide multiple profiles that can be selected by the user.
If multiple URIs are defined the DoH client must use the first one
by default if the user didn't choose one explicitly (if DoH is used by default).

such a JSON file could look like:

{
  "associated-resolvers": [
    {
      "uri": "https://doh.example.com/dns-query",
      "description": "Non-filtering and DNSSEC-validating resolver"
    },
    {
      "uri": "https://doh.example.com/dns-query-filtering",
      "description": "DNSSEC-validating resolver filtering known malware domains"
    }
  ]
}

> - No one will see this URL other than software developers and
> operators watching their logs. They will not be visible to users.

It is probably not so important how the url/file is called in the end
but having a speaking name with "dns-over-https-..." in its name
would be clearer than just doh-.. even if only operators have to place
the file on their servers and no end user will ever see that URL.

thanks for working on this!
nusenu

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 17 Mar 2019 16:45:12 -0400

On Sat, Mar 16, 2019, at 03:22, Paul Hoffman wrote:
> Can you say why they are bad? They are not common, but they are 
> certainly available and have proven useful in some environments for a 
> long time.

Didn't we already discuss this?  Sure they can be issued and relied upon, which makes them useful in some environments.  They also tend to be useless in more situations than not.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Mar 2019 20:51:12 +0000

On Mar 17, 2019, at 1:45 PM, Martin Thomson <[email-masked]> wrote:
> Didn't we already discuss this?  

Yes, but I was asking the person who brought it up for clarity.

> Sure they can be issued and relied upon, which makes them useful in some environments.  They also tend to be useless in more situations than not.

Do you feel that they are useful or useless for the protocol in  draft-ietf-doh-resolver-associated-doh that lets a resolver advertise its related servers?

--Paul Hoffman

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 17 Mar 2019 18:03:20 -0400

I've been uncomfortable about this draft for a while.  To be clear, I want some of what it sets out to accomplish, but the design gives me concerns that go beyond the short list of mildly offensive design characteristics.  It recently occurred to me that these are not so bad if they are necessary, but they might be a consequence of a deeper problem.  It's a problem that I think is entirely inappropriate for this working group to be tackling, but that didn't stop us from adopting the draft, so here goes...

The problem this attempts to address - at least in part - is talking to a resolver about the resolver itself.  In order to do that, it takes a rather circuitous route, depending on how many barriers there are.  Now I'm not deep enough into DNS to answer this question, but I wonder why we would ever design a system for talking to a resolver like the one proposed.

It barely uses the DNS protocol, meaning that it asks an HTTP server about a DNS server, even to the point of asking the DNS server to tell it which HTTP server to talk to.

It also fails to authenticate any of the information that is provided.  Arguably, none of this information can be authenticated given its origin, but the number of unauthenticated steps is typically limited, but here we have an additional exposure to attack.

It seems like the approach that has been taken with DoT is to try and see.  But we're all sufficiently scared of HTTP servers that we don't feel like that is a responsible thing to do with DoH.  And - more reasonably - we realize that having a way to find alternative endpoints for a resolver is worth having.  But why not provide a mechanism that can do for DoT what this does for DoH?  The draft provides two entirely bespoke names in the top-level .arpa space for DoH, but otherwise has no generalized characteristics whatsoever.

Maybe there is a better approach.

I don't know if there is any hope of adding a general facility to DNS where a client could talk to the server about itself, rather than the data that it can provide.  Most of what I can see in the protocol is concentrated on achieving some moving data in some way (RFC 6975 is almost there in talking about client capabilities).  Not knowing enough about the protocol, I can't say whether OpCodes, EDNS, or a reserved subtree is the right channel here, but it seems like ad hoc additions to the .arpa tree isn't as much a measured approach as simply a convenient one.

In HTTP we have started to use .well-known for providing resources that can talk about an origin as a whole.  That's a facility that this draft fixates on.  It's a convenient safety valve for those cases where the sophistication of the protocol starts to exceed the secondary channels provided in the protocol (EDNS in DNS, header fields in HTTP).

HTTP also has a convenient mechanism for doing exactly what this draft is attempting to do (almost, more later): find an alternative service endpoint for the current service, ideally one with better properties in some way.  RFC 7838 describes alternative services, which are implemented as a header field (here, an EDNS0 option seems like it might work).  In that design, a response from the resolver contains a list of alternative service endpoints, expressed as a tuple of name (and port) and endpoint type (using ALPN).  With some DNS-specific tweaks, I don't see why that would be a terrible approach here.

That design wouldn't work for all the stated use cases for resolver-associated DoH, but it would cover some of the more critical ones.  The main one that springs to mind being the web application case: as a web site, I want to make a DNS query from the perspective of my clients, so that (I can scan their network)^U I can find service endpoints more appropriate to their network location than mine.  I'd like to have a little more discussion of why we think that web sites might want to do their own DNS querying, but I don't believe that the current design helps web sites achieve this goal.

FWIW, I'm now unclear on why the draft calls "browsers" out specially.  Browsers aren't really special in this context.  You might reasonably care about three levels of things: devices (or operating systems), applications, and web sites.  The distinction between each being decreasing levels of access to information about their operating environment.  Applications might not know about their DHCP configuration and web sites generally can't directly access a DNS resolver directly.

--Martin

p.s., Happy to talk about how IP address certificates will make this difficult to deploy, but let's try to hit the high points first.

p.p.s., I really wish that DoT had decided to add some meta-information channel.  That solves a bunch of these issues.  I guess we can ALPN-up ourselves a v2 if we needed one.

On Sat, Mar 16, 2019, at 00:13, Ben Schwartz wrote:
> Also, the draft does not enable the use of DoH if (1) an application 
> relies on POSIX-like DNS APIs to bootstrap AND (2) the resolver is only 
> reachable on a non-public IP address (e.g. RFC 1918). This is a side 
> effect of the requirement that the DoH server provide a valid 
> certificate for its name, chained to a root that is already trusted by 
> the client. This draft does not alter that requirement.
> 
> If any of these technical elements are of concern to you, please 
> comment now, so that the meeting can be as productive as possible.
> 
> --Ben
> Attachments:
> * smime.p7s

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 17 Mar 2019 18:57:15 -0400

On Mon, Mar 18, 2019, at 07:51, Paul Hoffman wrote:
> Do you feel that they are useful or useless for the protocol in  
> draft-ietf-doh-resolver-associated-doh that lets a resolver advertise 
> its related servers?

It will depend on deployment context whether they can be used.  You have to have an IP address that meets the conditions set out in draft-ietf-acme-ip, which means minimally no RFC 1918 or LLA/ULA.

I don't think that I'm comfortable recommending a design that doesn't allow for names, unless we can get pretty wide agreement from networks saying that this is feasible in their deployment, even if (and perhaps especially if) they are not currently consdering DoH deployment.  Even if we had names, it's not clear that getting certificates for those names is easy.

BTW, neither IP address certificates nor names work for the device that ostensibly offers DNS resolution on the network I am in right now.  That means that the third-party service is the only option that is likely to work in most private premises and small offices.  That might reduce the pressure on this mechanism.

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 17 Mar 2019 23:25:37 +0000

> - Layered spaces under a .well-known/ are possible but I don't think they are well-understood.

I very much agree. It could make things more complicated for IANA, and 
it could make things more complicated for server administrators. Even if 
the additional level of complexity is minimal in many cases, it may not 
be in others.

I'm not against including the three-letter acronym 'dns' in the string 
somehow; that may help administrators who look at .well-known a while 
after somebody got that folder set up.

Regards,   Martin.

---

From: nusenu <[email-masked]>
Date: Sun, 17 Mar 2019 23:52:00 +0000

Martin Thomson wrote:
> It also fails to authenticate any of the information that is
> provided.  

The mechanism in chapter 2 (DoH Servers from HTTPS) is authenticated, right?
(but still vulnerable to downgrade attacks). If we ignore the fact that
the resolver IP has probably been configured over an unsafe protocol in the first place (DHCP).

> Arguably, none of this information can be authenticated
> given its origin, but the number of unauthenticated steps is
> typically limited, but here we have an additional exposure to
> attack.
> 
> It seems like the approach that has been taken with DoT is to try and
> see.  

Those that do (Android 9 for example) don't really authenticate 
the endpoint and use it opportunistically, right?

> But we're all sufficiently scared of HTTP servers that we don't
> feel like that is a responsible thing to do with DoH.  And - more
> reasonably - we realize that having a way to find alternative
> endpoints for a resolver is worth having.  But why not provide a
> mechanism that can do for DoT what this does for DoH? 

I'd like to see that happen as well but I assume that will not be on the DoH WG
since it is outside it's charter?

The idea I had in mind would be to have "DoT Servers from HTTPS"
like section 2 in this draft but without the unauthenticated options
in section 3 and 4.

> HTTP also has a convenient mechanism for doing exactly what this
> draft is attempting to do (almost, more later): find an alternative
> service endpoint for the current service, ideally one with better
> properties in some way.  RFC 7838 describes alternative services,
> which are implemented as a header field (here, an EDNS0 option seems
> like it might work).  In that design, a response from the resolver
> contains a list of alternative service endpoints, expressed as a
> tuple of name (and port) and endpoint type (using ALPN).  With some
> DNS-specific tweaks, I don't see why that would be a terrible
> approach here.

How would the DoH URI be authenticated in that case?

> I'd like to have a little more discussion of why we think that
> web sites might want to do their own DNS querying

+1

> FWIW, I'm now unclear on why the draft calls "browsers" out
> specially.  Browsers aren't really special in this context.  You
> might reasonably care about three levels of things: devices (or
> operating systems), applications, and web sites.  The distinction
> between each being decreasing levels of access to information about
> their operating environment.  Applications might not know about their
> DHCP configuration and web sites generally can't directly access a
> DNS resolver directly.

I brought this up as well and Paul mentioned he will address this in the
next version of the draft:
https://mailarchive.ietf.org/arch/msg/doh/bOL0JX0QA-y9qA2G88ngSDSzQAI

> p.s., Happy to talk about how IP address certificates will make this
> difficult to deploy, but let's try to hit the high points first.

It will require the resolver to be on a public IP but letsencrypt
might issue certificates for IP addresses in the future:

"Let’s Encrypt may offer IP address certificates in the future, but as of September 2018 we do not. "
https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082

https://datatracker.ietf.org/doc/draft-ietf-acme-ip/

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 17 Mar 2019 22:10:41 -0400

> the resolver IP has probably been configured over an unsafe protocol in 

Yeah, if we assume that the configuration is OK (a big assumption, but there are reasons we might tolerate DHCP authentication being what it is), then you are right.  The most troublesome bits are the .arpa lookups, which aren't authenticated, and can't be authenticated.  That might be considered a feature: if my home router passes the request on upstream to a resolver that supports this protocol, then that resolver gets a second chance to provide the information.  Of course, that assumes that you find unauthenticated anything a feature.  I tend to see it as a bug.

> Those that do [DoT] (Android 9 for example) don't really authenticate 

That is my understanding.

> > But why not provide a

I'd hate for our charter to cause us to disregard better solutions.

> > service endpoint for the current service, [...]
> 

This is a good question.  If you have any cause to believe that the server is providing valid responses, then you could take whatever it gives you.  That's arguably worse than what is in the draft now.  The way Firefox authenticated its configured DoH resolver was by providing both an IP address and a name against which the server is authenticated.  But most situations won't have a name configured.  One could be added to DHCP, and PvD too I guess, but that doesn't help the web application all that much and it might only help an operating system (or applications on platforms with an interface to DHCP options).

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 18 Mar 2019 11:28:04 -0400

On Sun, Mar 17, 2019 at 6:03 PM Martin Thomson <[email-masked]> wrote:

> I don't know if there is any hope of adding a general facility to DNS
> where a client could talk to the server about itself, rather than the data
> that it can provide.

As a chair, I agree with nusenu that this topic might be out of charter,
but if we decide that it is the best course of action then we can make
organizational changes as necessary.  We may also be able to find a
balance, by implementing a DoH-specific practice that seems likely to
generalize well.

> p.p.s., I really wish that DoT had decided to add some meta-information
> channel.  That solves a bunch of these issues.  I guess we can ALPN-up
> ourselves a v2 if we needed one.
>

Not as chair, here's a free, slightly unsettling idea: use the "h2" ALPN on
port 853 to negotiate a DoT-to-DoH upgrade during the TLS handshake.

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 18 Mar 2019 16:44:14 +0000

I understand that we don't necessarily want a directory structure under /.well-known/ - therefore I would suggest one of the following:

/.well-known/dns-doh/
/.well-known/dns-doh-servers/

I just don't want to end up with a situation where a single-layer structure results in the /.well-known/ folder containing hundreds of poorly-named files. We're already seeing some people using this folder to store not only things like robots.txt, but also assorted Apple and Google files and their own internal 'constant' data.

Therefore, at a minimum, 'our' files should be named consistently - meaning that (IMHO) any DNS-related file should begine with "dns-". Not sure whether we're in a position to influence IANA to implement a naming standard...

Rory

-----Original Message-----
From: Martin J. Dürst <[email-masked]> 
Sent: Sunday, March 17, 2019 4:26 PM
To: Paul Hoffman <[email-masked]>; DoH WG <[email-masked]>
Subject: Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

>>> standardization and publicization. AIUI, @mnot's original ideal 
>>> would be to have /.well-known/ be pretty 'generic'. Therefore I'm 
>>> not a fan of "/doh-servers-associated/" - I'd much rather see 
>>> "/dns/doh/", which would enable other (future) DNS-related 
>>> functionality to have a sub-folder within "/.well-known/dns/". If 
>>> that's not a possibility, what about "/.well-known/dns-doh/"?
>>
>> +1
>>

I very much agree. It could make things more complicated for IANA, and it could make things more complicated for server administrators. Even if the additional level of complexity is minimal in many cases, it may not be in others.

I'm not against including the three-letter acronym 'dns' in the string somehow; that may help administrators who look at .well-known a while after somebody got that folder set up.

Regards,   Martin.

---

From: nusenu <[email-masked]>
Date: Mon, 18 Mar 2019 21:35:00 +0000

Martin Thomson:
>>> But why not provide a mechanism that can do for DoT what this
>>> does for DoH?
>> 
>> I'd like to see that happen as well but I assume that will not be
>> on the DoH WG since it is outside it's charter?
> 

These are encouraging words. I'd support the inclusion of a DoT 
discovery mechanisms if that is asked but I assume a discovery mechanism
for DoT will be specified anyway, if not in this one it will be in a separate document.
One reason that makes me think it would be worthwhile to have a
single document for both (DoT and DoH) is that we might end up
with a better protocol.

I'm taking a step back and ask two high level questions
and answer them for myself but it would be great to hear more
opinions.

What use-cases are we aiming to cover?

I assume the primary use-case here is
"Application (or OS) wants to discover a DoH server associated with the current Do53 resolver".
(also but to a less extend "web application wants to discover ...")

What security properties are we aiming for?

I'd like to see a protocol that is not vulnerable to man-in-the-middle
and downgrade attacks, even if that means that use-cases that can't
detect the IP address of the currently used resolver can not be covered.

Alternatively we could have a 'strict' and an 'opportunistic' discovery profile
with distinct security properties to tackle all currently covered
use-cases without weakening the security properties of the entire protocol for all use-cases?
(example: "A client able to determine the resolver's IP address MUST NOT use the
"DoH Servers from DNS" discovery mechanism.")
At the very least we should prevent a temporary on-path attacker getting a persistent
feed of a victim's DoH traffic as described in my other email [1].
 
[1] https://mailarchive.ietf.org/arch/msg/doh/295yrI72xt0eSnYueiOuqVpSj4s

kind regards,
nusenu

---

From: nusenu <[email-masked]>
Date: Mon, 18 Mar 2019 21:43:00 +0000

Hewitt, Rory:
> I understand that we don't necessarily want a directory structure
> under /.well-known/ - therefore I would suggest one of the
> following:

let me throw in a 3rd option:

/.well-known/dns-over-https-servers

> I just don't want to end up with a situation where a single-layer
> structure results in the /.well-known/ folder containing hundreds of
> poorly-named files.

+1

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 18 Mar 2019 21:56:20 +0000

I'm firmly in favor of having a naming 'convention' of:

	/.well-known/dns-doh-servers

I think it's critical to have "dns-" as the name prefix, to clearly indicate that this is a DNS-related file. Then "doh-" to indicate that this is a DoH-specific file and so on... Using this convention means that the DoT folks can create their own files as

	/.well-known/dns-dot-servers

While your idea of "/.well-known/dns-over-https-servers" fulfills the first "dns-" part of my convention (and it's also very clear what it is 😊), I guess I'm always going to be antsy that there's going to be a new DNS-related 'technology' in the future called e.g. "Carrier-Pigeon DNS" and that team is going to call their file "/.well-known/carrier-pigeon-dns". So it's better (IMHO) to explicitly indicate that it's a series of Three-Letter-Acronyms...

Of course, a naming convention only works if everyone both knows about it and follows it. Even if we decide to use a 'strict' naming convention, unless it's both 'publicized' and 'enforced', it's kinda useless.

Rory

-----Original Message-----
From: nusenu <[email-masked]> 
Sent: Monday, March 18, 2019 2:43 PM
To: [email-masked]
Subject: Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

+1

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Mar 2019 08:59:44 +1100

*well-known URI expert hat on*

Without speaking to the technical merit of the proposals being discussed, I'd like to discourage folks from thinking that they can reserve prefixes within the first well-known URI path segment; it is a managed space, but if we start this practice, we're going to have a nightmare managing the competing requirements.

If you want to reserve a prefix, reserve something like /.well-known/dns-servers/ and put the specific flavour after that (or in the retrieved file, or...).

All that said, bike shedding the name at this point probably isn't a terribly productive use of time.

Thanks,

> On 19 Mar 2019, at 8:56 am, Hewitt, Rory <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 18 Mar 2019 18:00:53 -0400

> for DoT will be specified anyway, if not in this one it will be in a

DoT is currently discovered by probing port 853 on the resolver's IP
address.  Is this sufficient for your use case?

> detect the IP address of the currently used resolver can not be covered.

An active adversary "in the middle" can fully substitute itself for a Do53
resolver without alerting the user.  Do you see an achievable defense
against downgrade attacks, or is this not part of your threat model?

Alternatively we could have a 'strict' and an 'opportunistic' discovery
> profile

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 18 Mar 2019 22:09:16 +0000

@Mark Nottingham

This came up because while chatting to @Paul Hoffman offline, I made it clear that there are lots of people who are sticking assorted files into their /.well-known/ folder, either directly or within sub-folders with no apparent consistency. The last thing anyone wants is a name-clash with an existing file, unlikely though that seems. I'm not sure the extent to which folks on this mailing list are aware of the horrible, ridiculous ways in which real people operate their web servers (as opposed to the 'idealized' way they may be presumed by standards-writers).

That being said, your point about bike-shedding is well-taken.

Thanks,

Rory

Rory Hewitt
Senior Solutions Architect
Global Services & Support

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Monday, March 18, 2019 3:00 PM
To: Hewitt, Rory <[email-masked]>
Cc: nusenu <[email-masked]>; [email-masked]
Subject: Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

Thanks,

---

From: Adam Roach <[email-masked]>
Date: Mon, 18 Mar 2019 17:10:21 -0500

[no hats]

> All that said, bike shedding the name at this point probably isn't a terribly productive use of time.

<tongue-in-cheek>

I'm starting to get sad that we defined this as an arbitrary namespace 
instead of a sequence of integers assigned by IANA.

/.well-known/27/

</tongue-in-cheek>

/a

---

From: nusenu <[email-masked]>
Date: Mon, 18 Mar 2019 23:24:00 +0000

> address.  Is this sufficient for your use case?

that is the current status quo with no specification that defines
DoT discovery mechanisms (or is it?). In an I-D I'd include:

- a mechanism that does not force the operator to use the same IP for Do53 and DoT 
(other than just for the initial discovery mechanism)
- allows multiple DoT endpoints for increased redundancy
- allows the Do53 resolver operator to support DoT without running DoT
servers themselves
- running DoT on non-853 ports (i.e. 443)
 
> against downgrade attacks, or is this not part of your threat model?

Good point, lets define a threat model first:

Consider an adversary that has the following capabilities:

- can manipulate and read any network traffic from the user (including DHCP)

- the adversary's capabilities are limited to some networks
(i.e. public wifis) but he has no global capabilities

- the attacker can _not_ issue trusted certificates for arbitrary IP addresses
- the adversary has _no_ access to the client system
 
security goals:
if the victim uses DHCP for Do53 discovery:
 - prevent attacks that impact the victim's DoH server URI
beyond the visit in an adversary-controlled network (i.e. public wifis)

if the client is configured to use a static Do53 server (no DHCP for DNS server discovery used):
 - prevent the adversary from feeding the victim with his DoH URI
 - prevent a silent downgrade attack that makes the victim believe
a previously discovered DoH server does no longer speak DoH (to force the victim to plain Do53)

As outlined in [1] I believe these goals are currently not met yet and an adversary can feed a victim
his DoH server URI even beyond the victim's visit in the adversary controlled network.
It would be great if we could improve this (I think we can).

kind regards,
nusenu

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Mar 2019 02:13:21 +0000

> - running DoT on non-853 ports (i.e. 443)

If you want to update RFC 7858, that's great, but this would all be work for the DPRIVE WG, which is the one that standardized DoT. 

--Paul Hoffman

---

From: nusenu <[email-masked]>
Date: Tue, 19 Mar 2019 07:13:00 +0000

> If you want to update RFC 7858, that's great, but this would all be
> work for the DPRIVE WG, which is the one that standardized DoT.
 
Yes I'm aware, I just replied to this question in Ben's email since he asked here.

The rest of the email was related to the current