Subject: Re: [Add] data integrity and DNSSEC or DoH/DoT

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Sep 2019 06:46:52 -0700

On Tue, Sep 3, 2019 at 6:15 AM Neil Cook <[email-masked]> wrote:

>
>
> On 23 Aug 2019, at 06:39, Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Thu, Aug 22, 2019 at 1:41 PM Jim Reid <[email-masked]> wrote:
>
>>
>>
>> > On 22 Aug 2019, at 08:00, Eric Rescorla <[email-masked] <ekr@rtfm..com>>
>> wrote:
>> >
>> > Suppose that I receive a bogus response to my A record query, how am I
>> to usefully distinguish "this is malware blocking" from "this resolver is
>> malicious”?
>>
>
> ...
>
> To be slightly less glib, the dnsop WG has an I-D on extended error codes.
>> [And FWIW lack of a discrete error code(s) for validation failure is one of
>> the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error
>> already goes some way to answering your question:
>>
>> 4.16.  Extended DNS Error Code 15 - Blocked
>>
>>    The resolver attempted to perfom a DNS query but the domain is
>>    blacklisted due to a security policy implemented on the server being
>>    directly talked to.
>>
>> 4.17.  Extended DNS Error Code 16 - Censored
>>
>>    The resolver attempted to perfom a DNS query but the domain was
>>    blacklisted by a security policy imposed upon the server being talked
>>    to.  Note that how the imposed policy is applied is irrelevant (in-
>>    band DNS somehow, court order, etc).
>>
>> 4.18.  Extended DNS Error Code 17 - Prohibited
>>
>>    An authoritative or recursive resolver that receives a query from an
>>    "unauthorized" client can annotate its REFUSED message with this
>>    code.  Examples of "unauthorized" clients are recursive queries from
>>    IP addresses outside the network, blacklisted IP addresses, local
>>    policy, etc.
>>
>> I suppose draft-ietf-dnsop-extended-error could add another error code
>> for the specific case of a malicious resolver. Whatever that might mean.
>> Though I doubt the operators of such servers will choose to set that evil
>> bit on their responses.
>>
>> PS A potential problem with this I-D is these extended error codes won’t
>> be signed. So they can be spoofed by bad actors.
>
>
>
> I don’t see why malicious resolvers would tell clients they are returning
> bogus results.
>
> Yes, and for this reason I don't see how this solves the problem. It's
> just "resolver blocked it and claims reason X".
>
>
> It’s not entirely  useless. The problem it does solve is giving the user a
> better experience when a site is blocked for resolvers that support this
> extended Error Code. Currently for HTTPS the user will end up with a TLS
> connection error of some kind (or a blank page in some browsers). If a
> resolver returns a “blocked/censored/prohibited” response, then the browser
> can tell the user that the web page was blocked with an informative
> message. Assuming this becomes the default behaviour for non-malicious
> resolvers then I think it will a good signal for distinguishing  "this is
> malware blocking" from "this resolver is malicious”.
>

I'm not following. Suppose that we add an error code that says "this site
has malware". Now, I operate a resolver which is malicious in the sense
that it wishes to block a certain form of content (say, access to the IETF)
but don't want the people whose content I am blocking is being blocked for
that reason. So, instead I return "this site has malware".

My point here is that a code of this type only tells you what the resolver
*asserts* the reason it blocked it is, it doesn't necessarily tell you what
the actual reason that the content was blocked.

-Ekr

>
> Neil Cook
> [email-masked]
>
>
> -------------------------------------------------------------------------------------
> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court
> Nuremberg HRB 24738
> Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael
> Knapstein, Stephan Martin
> Chairman of the Board: Richard Seibt
>
> European Office:
> Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District
> Court Siegen, HRB 8718
> Managing Director: Frank Hoberg
>
> US Office:
> Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
>
> -------------------------------------------------------------------------------------
>
>

---

From: Neil Cook <[email-masked]>
Date: Tue, 3 Sep 2019 15:15:38 +0200

> On Thu, Aug 22, 2019 at 1:41 PM Jim Reid <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 22 Aug 2019, at 08:00, Eric Rescorla <[email-masked] <mailto:ekr@rtfm..com>> wrote:
> > 
> > Suppose that I receive a bogus response to my A record query, how am I to usefully distinguish "this is malware blocking" from "this resolver is malicious”?

...

> To be slightly less glib, the dnsop WG has an I-D on extended error codes. [And FWIW lack of a discrete error code(s) for validation failure is one of the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error already goes some way to answering your question:
> 
> I suppose draft-ietf-dnsop-extended-error could add another error code for the specific case of a malicious resolver. Whatever that might mean. Though I doubt the operators of such servers will choose to set that evil bit on their responses.
> 
> PS A potential problem with this I-D is these extended error codes won’t be signed. So they can be spoofed by bad actors.
> 

I don’t see why malicious resolvers would tell clients they are returning bogus results. 

> Yes, and for this reason I don't see how this solves the problem. It's just "resolver blocked it and claims reason X".
> 

It’s not entirely  useless. The problem it does solve is giving the user a better experience when a site is blocked for resolvers that support this extended Error Code. Currently for HTTPS the user will end up with a TLS connection error of some kind (or a blank page in some browsers). If a resolver returns a “blocked/censored/prohibited” response, then the browser can tell the user that the web page was blocked with an informative message. Assuming this becomes the default behaviour for non-malicious resolvers then I think it will a good signal for distinguishing  "this is malware blocking" from "this resolver is malicious”.

Neil Cook

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office:

---

From: Neil Cook <[email-masked]>
Date: Tue, 3 Sep 2019 16:34:49 +0200

> On 3 Sep 2019, at 15:46, Eric Rescorla <[email-masked]> wrote:
> 
> I'm not following. Suppose that we add an error code that says "this site has malware". Now, I operate a resolver which is malicious in the sense that it wishes to block a certain form of content (say, access to the IETF) but don't want the people whose content I am blocking is being blocked for that reason. So, instead I return "this site has malware".
> 
> My point here is that a code of this type only tells you what the resolver *asserts* the reason it blocked it is, it doesn't necessarily tell you what the actual reason that the content was blocked.
> 

Ok yes I understand. The blocking reason wouldn’t be that useful in the general case of not knowing whether a resolver was malicious. However I think the fact that the resolver is telling you that the content is blocked is still useful, no matter what the reason for the blocking is, for the reason described above. For example in your use-case, the user would see “this site is blocked by the DNS resolver” (or whatever) rather than “TLS connection error” which would be the case today.

Also assuming the resolver is “trusted” in some way (e.g. Mozilla TRR program) then the reason for blocking may then become useful I’d have thought.

Neil

> -Ekr
> 
> 
> 
> Neil Cook
> [email-masked] <mailto:[email-masked]>
> 

Neil Cook

European Office: 

US Office:

---

From: Neil Cook <[email-masked]>
Date: Tue, 3 Sep 2019 18:35:11 +0200

> On 3 Sep 2019, at 18:16, Christian Huitema <[email-masked]> wrote:
> 
>  
> 
> On Sep 3, 2019, at 7:34 AM, Neil Cook <neil.cook=[email-masked] <mailto:neil.cook=[email-masked]>> wrote:
> 
>> 
>> 
>>> On 3 Sep 2019, at 15:46, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Is there a way to explain how the message is blocked? Such as, "this domain is listed as malware in RBZ malware.example.net <http://malware.example.net/>." Information like that would allow the client to make an informed decision.
> 

The proposal as it’s currently specified doesn’t allow further granularity. Also Eric’s point is that you can’t trust the reason the resolver gives you, so this wouldn’t be useful. Assuming the client did trust the resolver however it may be useful;  although I’m not sure how the client would make an “informed decision” - I mean, what can the client do except try a different resolver perhaps? 

Neil Cook

European Office: 

US Office:

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Sep 2019 13:04:01 -0400

That’s why you move the censored Answer Section: data to the Authoritative Section.

Paul

Sent from mobile device

> On Sep 3, 2019, at 09:15, Neil Cook <neil.cook=[email-masked]> wrote:
> 
> 
> 
>>> > On 22 Aug 2019, at 08:00, Eric Rescorla <[email-masked]> wrote:
>>> > 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Christian Huitema <[email-masked]>
Date: Tue, 3 Sep 2019 09:16:54 -0700

> On Sep 3, 2019, at 7:34 AM, Neil Cook <neil.cook=[email-masked]> wrote:
> 
> 
> 

Is there a way to explain how the message is blocked? Such as, "this domain is listed as malware in RBZ malware.example.net." Information like that would allow the client to make an informed decision.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 3 Sep 2019 11:32:49 -0700

On 9/3/2019 9:35 AM, Neil Cook wrote:
>
>
>> On 3 Sep 2019, at 18:16, Christian Huitema <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>  
>>
>> On Sep 3, 2019, at 7:34 AM, Neil Cook
>> <neil.cook=[email-masked]
>> <mailto:neil.cook=[email-masked]>> wrote:
>>
>>>
>>>
>>>>     It’s not entirely  useless. The problem it does solve is giving
>>>>     the user a better experience when a site is blocked for
>>>>     resolvers that support this extended Error Code. Currently for
>>>>     HTTPS the user will end up with a TLS connection error of some
>>>>     kind (or a blank page in some browsers). If a resolver returns
>>>>     a “blocked/censored/prohibited” response, then the browser can
>>>>     tell the user that the web page was blocked with an informative
>>>>     message. Assuming this becomes the default behaviour for
>>>>     non-malicious resolvers then I think it will a good signal for
>>>>     distinguishing  "this is malware blocking" from "this resolver
>>>>     is malicious”.
>>>>
>>>>
>>>> I'm not following. Suppose that we add an error code that says
>>>> "this site has malware". Now, I operate a resolver which is
>>>> malicious in the sense that it wishes to block a certain form of
>>>> content (say, access to the IETF) but don't want the people whose
>>>> content I am blocking is being blocked for that reason. So, instead
>>>> I return "this site has malware".
>>>>
>>>> My point here is that a code of this type only tells you what the
>>>> resolver *asserts* the reason it blocked it is, it doesn't
>>>> necessarily tell you what the actual reason that the content was
>>>> blocked.
>>>>
>>>
>>> Ok yes I understand. The blocking reason wouldn’t be that useful in
>>> the general case of not knowing whether a resolver was malicious.
>>> However I think the fact that the resolver is telling you that the
>>> content is blocked is still useful, no matter what the reason for
>>> the blocking is, for the reason described above. For example in your
>>> use-case, the user would see “this site is blocked by the DNS
>>> resolver” (or whatever) rather than “TLS connection error” which
>>> would be the case today.
>>
>> Is there a way to explain how the message is blocked? Such as, "this
>> domain is listed as malware in RBZ malware.example.net
>> <http://malware.example.net/>." Information like that would allow the
>> client to make an informed decision.
>>
>
> The proposal as it’s currently specified doesn’t allow further
> granularity. Also Eric’s point is that you can’t trust the reason the
> resolver gives you, so this wouldn’t be useful. Assuming the client
> did trust the resolver however it may be useful;  although I’m not
> sure how the client would make an “informed decision” - I mean, what
> can the client do except try a different resolver perhaps?

If the client knows why the query was rejected, then it can look a bit
further. Take my example, in which the server would announce that the
domain is marked as blocked in a specific RBZ, "malware.example.net".
The client may decides whether it trusts that specific RBZ. Does it have
a good reputation, or is it known for a trigger-happy behavior leading
to all kinds of false positive? And then, the client may want to check
whether the domain is in fact listed in that specific RBZ, or whether
the resolver is making that up. It can indeed do that by contacting
another resolver. It may or may not do that all the time, it may or may
not expose that as some kind of option. My point is that more
transparency always helps.

-- Christian Huitema

---

From: Brian Dickson <[email-masked]>
Date: Tue, 3 Sep 2019 10:39:17 -0700

On Tue, Sep 3, 2019 at 8:42 AM Eric Rescorla <[email-masked]> wrote:

>> It’s not entirely  useless. The problem it does solve is giving the user
>> a better experience when a site is blocked for resolvers that support this

The high-level issue is that at very least some of the blocking services or
resolvers doing blocking, are set up based on some specific trust
relationship, and that trust is essential in order to have a reason to use
the service or resolver.
Those are typically either internal (enterprise) scenarios where that trust
is basically "same company" and mandated, or a service offered with some
specific terms of service, whether it is a fee-based service or free.

Trying to overlay a different model of third-party resolver where the
client doesn't have a pre-defined trust relationship with that third party,
is where things start to go sideways.

While it might be possible to re-engineer both sides of that equation so
they are not incompatible, the basic issue is that you can't easily tell
whether a resolver currently being used is strictly giving unmodified
results or not. There is no clear signal or flag.

Going beyond assertion might be possible with re-engineering, such as
providing some fourth-party attestation (e.g. the source of the feed that
gets used by the DNS resolver also provides its own signature on individual
entries that would permit human inspection).

>From a mathematical perspective, the problem is one of classical logic
versus modern logic: saying "Every X is a Y" also require an assertion of
existence "There is one member of X", in order to guarantee that Y is not
vacuously true.
In this case, the underlying truth problem is asking a user to pick one of
N different resolvers to trust, without the user having any way to know
independently if any of those resolvers are trustworthy.
If none of the resolvers is trustworthy, then the only solution is to not
trust the resolvers. This can be done by forcing DNSSEC validation to be
done and to discard any failures.
If and only if the user is able to legitimately trust their selected
resolver, can that assertion be relied upon, and at that point the
assertion has value.

There are at least two things that I see as being problems that need to be
worked on to achieve this possibility: discovery of trustworthiness and/or
trust relationship with the existing configured resolver; and the "who
watches the watchmen" problem of persistent monitoring of allegedly
trustworthy resolver operators to determine whether a given response from a
particular resolver (including any assertion about blocking and reason) can
be trusted.

IMHO, deploying any TRR without this devolves to the "can't trust the
resolver", which means no blocking, which is a terrible result (given that
we live in a malware-infested world as well as other subjectively- and
objectively-bad stuff like child pornography).

I would prefer to actually work on these problems.

I also think it would be better for all parties if implementers not deploy
things like TRRs until the bare minimum of mechanisms is available, which
may require work not only on the applications (doing dns) but also on the
resolvers themselves.

Brian

---

From: Andrew Campling <[email-masked]>
Date: Wed, 4 Sep 2019 08:54:03 +0000

On 3 Sep 2019, at 15:35, Neil Cook <[email-masked]> wrote:
Ok yes I understand. The blocking reason wouldn’t be that useful in the general case of not knowing whether a resolver was malicious. However I think the fact that the resolver is telling you that the content is blocked is still useful, no matter what the reason for the blocking is, for the reason described above. For example in your use-case, the user would see “this site is blocked by the DNS resolver” (or whatever) rather than “TLS connection error” which would be the case today.

This would seem to be a useful addition to a trusted resolver programme, would begin to offer additional, meaningful value to users.

Andrew

Regards

Andrew Campling  MBA  MSc  DipM  FRSA  MCIM  MIoD  Liveryman
Director | 419 Consulting Ltd | Tel: +44 (0) 7710 303010 | E: [email-masked]<mailto:[email-masked]>| t: @Andrew_Campling

This email contains information from 419 Consulting Ltd that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.

We monitor our email systems and may record all our emails.
419 Consulting Ltd
Registered in England: No 11944258

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 5 Sep 2019 11:57:11 +0200 (CEST)

Il 3 settembre 2019 19:39 Brian Dickson <[email-masked]> ha scritto:

In this case, the underlying truth problem is asking a user to pick one of N different resolvers to trust, without the user having any way to know independently if any of those resolvers are trustworthy.

If none of the resolvers is trustworthy, then the only solution is to not trust the resolvers. This can be done by forcing DNSSEC validation to be done and to discard any failures.

This would require clients to do DNSSEC validation on the device, rather than trust the assertion of DNSSEC validation that comes from the resolver. This would be easier to implement in the "traditional" model of a stub resolver, but with DoH, each application making DNS queries would need to take care of DNSSEC validation on its own - and I don't see that happening reliably and uniformly.

Moreover, this model would break the cases in which the user does not trust the resolver, but the resolver still has to apply filters because they are legally mandated, or applies filters that are beneficial anyway (e.g. against malware), which however cannot be validated via DNSSEC.

In the end, I think we are at a point where we need to give some thought at the general architecture of DNS resolution over the Internet, and think: where and how should it be done? For example, would it be better if full resolution happened on each individual device? I think that this would have more drawbacks than advantages. So the only alternative is to facilitate the establishment of trust in at least one resolver.

If and only if the user is able to legitimately trust their selected resolver, can that assertion be relied upon, and at that point the assertion has value.

Agreed.

There are at least two things that I see as being problems that need to be worked on to achieve this possibility: discovery of trustworthiness and/or trust relationship with the existing configured resolver; and the "who watches the watchmen" problem of persistent monitoring of allegedly trustworthy resolver operators to determine whether a given response from a particular resolver (including any assertion about blocking and reason) can be trusted.

In the end, I think that a general "resolver accreditation service" on a global scale - which Mozilla has the ambition to create with their TRR list - will never work due to scaling problems, unless you centralize resolution into a handful of global platforms, which IMHO would be a much bigger problem for the Internet. What could instead work is a way for the user to express and change an assertion of trust in one or more resolvers, devolving the problem to the edges of the network and letting each user define implicitly their own requirements for trust.

Still, if Mozilla wants to try to make that model work, they should add into it as much value as possible for users and operators - and being able to exchange trusted communications would be good value for both.

IMHO, deploying any TRR without this devolves to the "can't trust the resolver", which means no blocking, which is a terrible result (given that we live in a malware-infested world as well as other subjectively- and objectively-bad stuff like child pornography).

I also think it would be better for all parties if implementers not deploy things like TRRs until the bare minimum of mechanisms is available, which may require work not only on the applications (doing dns) but also on the resolvers themselves.

I also agree on all these points!

--

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Sep 2019 23:27:26 -0400 (EDT)

On Thu, 5 Sep 2019, Vittorio Bertola wrote:

[ quoting might have errors as the original messages seems to have odd quoting mechanisms ]

> Moreover, this model would break the cases in which the user does not trust the resolver, but the resolver still has to apply filters
> because they are legally mandated, or applies filters that are beneficial anyway (e.g. against malware), which however cannot be
> validated via DNSSEC.

If filtered properly (eg RPZ 2.0) the censored Answer section is moved
to the Authoritatve section so that DNSSEC validation can succeed while
the answer is suppressed for the client (and those not supported this
will also see a failure, even if a DNSSEC failure, instead of an
extended error opcode DNS failure with DNSSEC proof)

> In the end, I think we are at a point where we need to give some thought at the general architecture of DNS resolution over the
> Internet, and think: where and how should it be done? For example, would it be better if full resolution happened on each individual
> device?

This has been the case for a while now. This is why I wrote RFC 7901.
This is why we wrote draft-tls-dnssec-chain.

You can still use a forwarder, and you can still get all information in
one round trip.

Trusting unsigned data from the internet from random parties is not done
for any other protocol, why allow it for DNS?

> I think that this would have more drawbacks than advantages.

Can you elaborate on why you think that is?

>  So the only alternative is to facilitate the establishment of trust
> in at least one resolver.

No because transport security provided by a resolver is not data origin
security offered by DNSSEC.

> In the end, I think that a general "resolver accreditation service" on a global scale - which Mozilla has the ambition to create with
> their TRR list - will never work due to scaling problems, unless you centralize resolution into a handful of global platforms, which
> IMHO would be a much bigger problem for the Internet. What could instead work is a way for the user to express and change an assertion
> of trust in one or more resolvers, devolving the problem to the edges of the network and letting each user define implicitly their own
> requirements for trust.

Sounds very similar to the browsers having a store of root CA's. It
didn't really work from a trust point of view, and it was patched up
with first CRLs, then OCSP and then CT. Why make the same mistake
with DNs resolvers?

> I also think it would be better for all parties if implementers not deploy things like TRRs until the bare minimum of mechanisms
> is available, which may require work not only on the applications (doing dns) but also on the resolvers themselves.

Some believe TRR's are better than random ISP DNS resolvers they happen
to be (forced to) using, such as hotel or coffee shops. For example,
I've stayed at hotels whose wifi blocked Priceline and Booking.com
using DNS. So I don't see why TRR's should not be deployed until
some mysterious future time.

Paul

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 6 Sep 2019 16:32:18 +0200 (CEST)

> Il 6 settembre 2019 05:27 Paul Wouters <[email-masked]> ha scritto:
> 

I see your point, but one could reply: is the *content* of any web page you load signed or independently verified for integrity in any way? No, you just authenticate the source and secure the channel, and then trust any content you receive that way. So why should it be different when the content (via DoH) is a DNS response? I'm not saying that this argument is 100% right, but it's how lots of things work now.

[on-device recursor]
> Can you elaborate on why you think that is?

Every time the idea comes up, the operations people complain that performance would be bad due to reduced caching, and the privacy people complain that it would become much easier to associate DNS queries to a specific individual/household. Moreover, having billions of active resolvers, rather than hundreds of thousands, would possibly make things like the root key rollover much harder, and exacerbate the problem of obsolete recursors.

However, these are not impossible problems, so it still makes sense to have the discussion.

> security offered by DNSSEC.

This is a problem only if you trust ICANN and the zone owner more than you trust your resolver. If it's the opposite, you might just conclude that the resolver must have altered the response for a good reason, and trust the resolver anyway.

> with first CRLs, then OCSP and then CT. Why make the same mistake

Mozilla's TRR model is similar to a chain of trust with them at the root. However, the user can bless a resolver (i.e., tell the device "I trust a.b.c.d as a resolver") locally, without having to involve any central authority. (And yes, the current CA system is awful.)

> some mysterious future time.

At the current state of the technology, browsers cannot start a blanket adoption of the TRR model without breaking substantial parts of the Internet, so they shouldn't. They could do it in specific cases where they have determined that this won't create technical, service, policy and legal issues, which AFAIK is what Mozilla is trying to do. The above could be one of those cases, as long as they don't bypass local laws together with the local resolver, and don't clash with the captive portal mechanism. Still, if you care about that problem, I'd advise you to get a proper VPN now, rather than wait for TRRs in the browser.

--

---

From: Alec Muffett <[email-masked]>
Date: Fri, 6 Sep 2019 16:50:32 +0100

On Fri, 6 Sep 2019, 16:26 Vittorio Bertola, <vittorio.bertola=
[email-masked]> wrote:

> I see your point, but one could reply: is the *content* of any web page
> you load signed or independently verified for integrity in any way? No, you
> just authenticate the source and secure the channel, and then trust any
> content you receive that way.

One could also say that what you outline as the trust model for web pages
is precisely what one would expect from a typical HTTPS URL: because a URL
literally represents "go to <source> and retreive <content> and that is
defacto what you wanted."

A URL is a Uniform Resource Locator; there's that word, "location".

Others have layered signatures and the like atop of this mechanism, but if
you are talking about content-based-addressing (which you essentially are)
then you want non-HTTP URIs, for instance "Magnet" URIs.

Whereas: DNS is a distributed database, and the goal of that is more like a
service discovery protocol (who here remembers Jini?) - where you ask the
aether "What is the address X which corresponds to site Y?" - and there is
(currently, regrettable) little/no chain of trust, nor source-integrity nor
content-integrity, in the response.

So why should it be different when the content (via DoH) is a DNS response?

Because HTTPS has a security-model of "the URL is the Key, and a chain of
trust should permit an authoritative response of the content - which need
not be fixed! - whereas DNS is essentially a search query amongst untrusted
search engines, some of which are lying for their own reasons/benefit.

That's why.

- alec

---

From: Alec Muffett <[email-masked]>
Date: Fri, 6 Sep 2019 16:57:07 +0100

> search engines, some of which are lying for their own reasons/benefit.

ps: in case I did not make my point obvious enough: the whole point of DoH
is literally to remedy *some* of the risks inherent in the latter, by
layering requests on top of the former.

- a