Re: [Doh] New version: draft-ietf-doh-resolver-associated-doh-03.txt

[nusenu <[e-mail]>]

Paul Hoffman wrote:
> The diffs here are what I think have general agreement from the
> discussion about this draft so far, but I may have missed things.
> Comments are still quite welcome.

Thanks for the update, I had a look at the diff:

draft-ietf-doh-resolver-associated-doh-03.txt:
>  	   If DNS queries sent from stub resolvers to recursive resolvers are	
> 		 	   not sent over transports that assure data integrity and server	
> 		 	   authentication, the "DoH servers from DNS" and "Resolver addresses	
> 		 	   from DNS" protocols are susceptible to on-path attackers directing a	
> 		 	   user to a DoH server that is not actually associated with their	
> 		 	   resolver.  Do53 is not a secure transport, and neither is DoT using	
> 		 	   the opportunistic profile.	
> 		 		
> 		 	   The DNS responses used in "DoH servers from DNS" and "Resolver	
> 		 	   addresses from DNS" cannot be validated with DNSSEC [RFC4033], and	
> 		 	   thus even a validating stub resolver would treat them the same as any	
> 		 	   other DNS responses in unsigned zones.

Thanks for adding this to the security section. 
Maybe also add a sentence about the downgrade attack weakness of the protocol?

I'm wondering about the reasoning for not adding additional safeguards 
to reduce the window of opportunity for attackers exploiting the weaknesses
in the DoH server discovery mechanism as suggested in [1]?

> "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."

[...]

> 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). 

[...]

> "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



kind regards,
nusenu


[1] https://mailarchive.ietf.org/arch/msg/doh/295yrI72xt0eSnYueiOuqVpSj4s




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