Subject: [Doh] Ignore AD (Authentic Data) bit

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Wed, 27 Jun 2018 14:45:31 +0200

Hi,

the AD-bit is just a flag forwarded by the DoH-server to the DoH-client. 
Nobody knows where or by whom DNSSEC-'validation' was done or if someone 
tampered with the AD bit on the DoH-server or any upstream 
server/connection. A security chain is only as strong as the weakeast 
link. To make matters worse router vendors lull users in a false sense 
of security by advertising DNSSEC support while only passing along the 
AD-bit instead of doing DNSSEC validation on the router. This undermines 
the reputation of DNSSEC. In my opinion the AD-bit should never ever 
have made it into the DNSSEC-RFCs.

I suggest to replace the text

'It is the choice of a client to either perform full DNSSEC validation 
of answers or to trust the DoH server to do DNSSEC validation and 
inspect the AD (Authentic Data) bit in the returned message to determine 
whether an answer was authentic or not.'

in section '9. Security Considerations' with

'The DNSSEC AD (Authentic Data) bit MUST be ignored by DoH clients to 
avoid AD bits manipulated on the DoH server, upstream servers or 
upstream connections.'

Regards,

Renne

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Jun 2018 09:11:02 -0400

Hi,

On Wed, Jun 27, 2018 at 02:45:31PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> server/connection.

While this is true, it is entirely possible to have an environment
where you trust your upstream resolver to do the validation for you.
For instance, in an enterprise environment where you control both the
clients and the validating resolver, and you know what the policy is
for that resolver, the AD bit can be useful.

> To make matters worse router vendors lull users in a false sense of security
> by advertising DNSSEC support while only passing along the AD-bit instead of
> doing DNSSEC validation on the router.

That would not be a case where you should trust the validator, because
you did not control the configuration or verify that proper validation
was being done.

> In my opinion the AD-bit should never ever have made it into the
> DNSSEC-RFCs.

But it did, for the reasons above.  In cases such as you describe, it
is open to the client to do its own validation anyway, so I don't see
why there is a problem.

> 'The DNSSEC AD (Authentic Data) bit MUST be ignored by DoH clients to avoid
> AD bits manipulated on the DoH server, upstream servers or upstream
> connections.'

I am very strongly opposed to this.  It would be entirely wrong for
DoH to change DNSSEC handling in this way.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Wed, 27 Jun 2018 15:48:20 +0100

> DoH to change DNSSEC handling in this way.

+lots.

Ray

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 27 Jun 2018 16:33:06 +0100

> On 27 Jun 2018, at 15:48, Ray Bellis <[email-masked]> wrote:
> 

+lots again

Plus, I don’t believe this is within the charter of the WG. 

Sara.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 27 Jun 2018 10:44:43 -0500

> >> DoH to change DNSSEC handling in this way.

<aol>
Me too!
</aol>

> Plus, I don’t believe this is within the charter of the WG.

Agreed.

W

>
>
> Sara.
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jun 2018 11:02:32 -0500

Hrr.   I get that it feels wrong for DoH to change the resolver trust
model, but I agree that the trust model is wrong.   The only reason to ever
trust the AD bit is that your communication with the resolver is
authenticated such that you know that you are talking to the resolver and
not an attacker.   This is difficult to do with TSIG—it requires that every
client have its own key, and that TSIG be configured on the client, which
is never the case.   So the set of situations where the AD bit can actually
be trusted is actually very limited.

Saying that "you should not trust the resolver in this case" represents an
incorrect mental model of how this can work.  There is no person who is
making trust decisions here.   Either the software trusts the resolver on
some basis, or else it does not.

Interestingly, DoH in principle provides a basis for trusting the resolver:
you can validate the resolver's TLS cert, and that cert can be marked
"trust" or "don't trust" and then the software can automatically implement
the trust decision configured in the user interface.

So a better approach than saying "don't trust the AD bit" would be to say
"here is what is required in order to trust the AD bit" and then state that
explicitly, and by default say that the AD bit should not be set, and
should be ignored if set, when such a trust relationship has not been
validated.

I really don't see any reason why the document should not do this.   If you
are strongly opposed to this as well, it would be good if you could give
some reason other than "this is the way we've always done it" or "the user
knows."

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 27 Jun 2018 12:15:18 -0400

On Wed, Jun 27, 2018 at 12:03 PM Ted Lemon <[email-masked]> wrote:

> Interestingly, DoH in principle provides a basis for trusting the
> resolver: you can validate the resolver's TLS cert, and that cert can be
> marked "trust" or "don't trust" and then the software can automatically
> implement the trust decision configured in the user interface.
>

I think that this is an interesting line of reasoning, but I believe that
it is outside the scope of this working group.

I really don't see any reason why the document should not do this.

DNS over HTTPS will be, to the best of my knowledge, the third standardized
transport for DNS with TLS certificate validation, after DNS over TLS (RFC
7858) and DNS over DTLS (RFC 8094).  There may well be yet more
authenticated transports defined in the future.  Your proposal here applies
to all authenticated transports, not just DOH, so it is not suitable for
this document or this working group.

I would be interested in seeing your proposal in DNSOP, where there is more
expertise on the likely impact of a change to the specified usage of the AD
bit.

>   If you are strongly opposed to this as well, it would be good if you
> could give some reason other than "this is the way we've always done it" or
> "the user knows."
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Jun 2018 12:18:39 -0400

On Wed, Jun 27, 2018 at 11:02:32AM -0500, Ted Lemon wrote:
> Hrr.   I get that it feels wrong for DoH to change the resolver trust model,
> but I agree that the trust model is wrong.

If you are using a random resolver that you got from DHCP, I agree
that the trust model is entirely wrong.  But there are other ways to
get configured.  And note that you are _supposed_ to configure your
DoH resolver, which is a debate we already had.  If you did, and you
have validated the certificate and all that, then the trust model with
AD is not wrong.

> that TSIG be configured on the client, which is never the case.   So the set of
> situations where the AD bit can actually be trusted is actually very limited.

One that I know Microsoft was proposing at one point was an enterprise
environment where IPSec is in use and secure communications are
established to a domain controller that provides the necessary
configuration.  

> incorrect mental model of how this can work.  There is no person who is making
> trust decisions here.   Either the software trusts the resolver on some basis,
> or else it does not.

Yes, and there are ways that you _could_ be configured in which the
software can trust the resolver.  (I was speaking colloquially when I
said "you".)
 
> Interestingly, DoH in principle provides a basis for trusting the resolver: you
> can validate the resolver's TLS cert, and that cert can be marked "trust" or
> "don't trust" and then the software can automatically implement the trust
> decision configured in the user interface.

Yes.

> So a better approach than saying "don't trust the AD bit" would be to say "here
> is what is required in order to trust the AD bit" and then state that
> explicitly, and by default say that the AD bit should not be set, and should be
> ignored if set, when such a trust relationship has not been validated.

I am not the document editor, but I can see how such text could be
useful in the Security Considerations section if someone were to
prepare it & submit it for consideration.  I don't especially think it
is needed, however: I don't think DoH adds anything special to the AD
bit handling.  You should only trust the AD bit when you can trust the
resolver and trust that your hop to that resolver is properly
secured.  That was always true, and remains true now.  RFC 4035 has
this to say about it:

    In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel.

I don't see what's new here.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Wed, 27 Jun 2018 18:34:47 +0200

Am 27.06.2018 um 18:18 schrieb Andrew Sullivan:
> RFC 4035 has this to say about it:
> 
The fact that e.g. home router vendors define the DSL line and the 
network path to the resolver of the ISP as trusted to print 'DNSSEC' on 
the retail package without having to develop a full DNSSEC 
implementation for the router.

Best regards,

Renne

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Jun 2018 12:46:00 -0400

On Wed, Jun 27, 2018 at 06:34:47PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:

> The fact that e.g. home router vendors define the DSL line and the network
> path to the resolver of the ISP as trusted to print 'DNSSEC' on the retail
> package without having to develop a full DNSSEC implementation for the
> router.

What's new about that?  Why do you trust such a resolver?  People have
always been able to lie about what they're doing -- that's the whole
point of the text in RFC 4035, and why you are in a position to do
validation yourself anyway.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Thu, 28 Jun 2018 12:24:20 +0200

> validation yourself anyway.

+1

I fully agree that DoH does not bring anything new with respect to AD bit.

-- 
Petr Špaček  @  CZ.NIC