Subject: [Doh] draft-ietf-doh-resolver-associated-doh-02 comments

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Mar 2019 20:53:04 +0000

Hiya,

I had a read of this.

I think I share Martin's general concerns, but don't have a
concrete high-level suggestion other than to talk more about
it and be open to possibly big changes being needed as we
work it out.

Points that might be worth clarifying as we go:

- Section 2: what about OCSP? are we assuming that the OCSP
responder is resolved by the precursor system resolver or
the DoH resolver or both? I don't think it makes a security
difference (OCSP works or doesn't as usual), but it may be
a gotcha in terms of establishing the TLS session. Or, are
we assuming there's no point in OCSP for an IP-address
cert? (I forget;-)

- Section 2: "the normal rules for HTTP" - does that mean
all re-directs MUST be HTTPS too? And can those URLs use
DNS names or must they be IP address certs too?

- Sections 3 & 4: the use of special-use domain names here
seems ickky to me. ("ickky" being a technical terms for "I
don't like that but can't justify my opinion" :-) I think
it'd be a pity to see more crap DNS queries emitted from
browsers though and would love to see something better. I
also wonder what'd happen with these queries in a home n/w
with a never-updated router or with a brand-new flashy
home router that e.g. has a public DNS name. (In that
latter case, I can easily get a cert for the name of my
home router, but not for it's IP address.)

- Section 7, para 1: that's way too one-sided. DoH could
be less privacy-friendly (than say DoT) due to cookies and
whatnot.

- Section 8: Why diss. DoT? It's not a competition:-)

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 19 Mar 2019 19:42:59 -0400

> we assuming there's no point in OCSP for an IP-address

In capport we've made some recommendations about what can be done when you have limited network access.  The situation isn't identical, but the guidance is the same: staple OCSP responses and provide all intermediates (i.e., don't send people chasing after AIA URLs that they can't resolve).
 
> DNS names or must they be IP address certs too?

There are no "normal rules" for HTTP and redirects.  You have to explicitly say that redirects to unauthenticated resources are not permitted.

> be less privacy-friendly (than say DoT) due to cookies and

I think that it might pay to spend some time on this particular meme on a separate thread.  My view is that while the opportunities exist, a lot of the concern here comes more from this being different and new and less from real provable problems.  For instance, both parties have to work pretty hard to get cookies.  Even in the contexts where you think that you might not have to (like a browser).
 
> - Section 8: Why diss. DoT? It's not a competition:-)

I agree.  It is, but it's our responsibility to rise above that.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Mar 2019 23:59:30 +0000

Hiya,

On 19/03/2019 23:42, Martin Thomson wrote:
>> - Section 7, para 1: that's way too one-sided. DoH could be less
>> privacy-friendly (than say DoT) due to cookies and whatnot.
>
> I think that it might pay to spend some time on this particular meme
> on a separate thread.  

Yeah, that's reasonable.

> My view is that while the opportunities exist,
> a lot of the concern here comes more from this being different and
> new and less from real provable problems.  For instance, both parties
> have to work pretty hard to get cookies.  Even in the contexts where
> you think that you might not have to (like a browser).

That's also fair. OTOH, the heritage of the web here is somewhat,
to gigantically, depressing, and given the capability exists...

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Mar 2019 01:03:18 +0000

> we assuming there's no point in OCSP for an IP-address

This is an interesting question. It assumes that the application has no DNS resolver when the HTTPS query is sent, and that getting the associated DoH server is a prerequisite to sending DNS (in this case, to locate the OCSP server).

That was certainly not the intention, given that the application can send DNS queries for the other protocols described. I'll add a note to that effect in the next draft.

> DNS names or must they be IP address certs too?

The term "normal HTTP" was used in the DoH spec (RFC 8484), and here "normal rules for HTTP" were assumed to be the same.

> browsers though and would love to see something better.

Better suggestions are still heartily welcomed. These are the result of many comments on earlier drafts, but you are not alone in disliking the use of special-use domain names.

> I
> home router that e.g. has a public DNS name.

Nothing special. If a resolver doesn't understand the SUDN, it will pass it upstream and get an NXDOMAIN answer back.

> (In that

Certificates are not useful for the protocols in these sections.

> be less privacy-friendly (than say DoT) due to cookies and

The sentence explicitly says "communication privacy", not overall privacy, for the very reason you give. I guess that wasn't clear enough. I'll add "However, using a DoH server can also reduce overall privacy because both TLS and HTTPS allow for user identification in ways that plain Do53 does not."

> - Section 8: Why diss. DoT? It's not a competition:-)

For many people, it is. That is, people constantly ask why should DoH even exist if DoT already exists. This helps explain that.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Mar 2019 01:24:03 +0000

Hiya,

Other bits will resolve themselves in time (which is to say,
I may agree or not but we can do that later:-), but on these
two...

On 20/03/2019 01:03, Paul Hoffman wrote:
> The sentence explicitly says "communication privacy", not overall
> privacy, for the very reason you give. I guess that wasn't clear
> enough. 

I don't know that there is actually a discrete and useful
concept of "communication privacy" TBH. Regardless of that,
it'd seem wiser to steer away from such debates if possible,
and it should be easy enough in this case to recognise the
dangers inherent in HTTPs vs DoT. (That being said, I'd be
happy if the kind of "why it's in practice hard to be that
privacy-unfriendly using DoH" text that Martin earlier
implied could be useful were included as well.)

I'll add "However, using a DoH server can also reduce overall
> privacy because both TLS and HTTPS allow for user identification in
> ways that plain Do53 does not."
> 
> For many people, it is. 

They are incorrect. Better to not pander to that error.

> That is, people constantly ask why should DoH
> even exist if DoT already exists. This helps explain that.

The current text did not help me at all and I can't see how it
helps anyone really, unless one is willing to accept that:
  "DoT==bad && DoH==good"
(or some such absolutist nonsense), is a sensible proposition.

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 00:35:07 -0400

On Wed, Mar 20, 2019, at 12:03, Paul Hoffman wrote:
> This is an interesting question. It assumes that the application has no 
> DNS resolver when the HTTPS query is sent, and that getting the 
> associated DoH server is a prerequisite to sending DNS (in this case, 
> to locate the OCSP server).
> 
> That was certainly not the intention, given that the application can 
> send DNS queries for the other protocols described. I'll add a note to 
> that effect in the next draft.

I would be unhappy with that. Our implementation can currently operate without another source of name resolution. Given that the mechanisms we are talking about are just best practice, why not just recommend that resolvers follow them? I would not mandate anything, but explaining the consequences of diverging from best practice has its own normative impetus.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 24 Mar 2019 13:21:24 +0100

On Wed, Mar 20, 2019 at 2:03 AM Paul Hoffman <[email-masked]> wrote:

> The term "normal HTTP" was used in the DoH spec (RFC 8484), and here
> "normal rules for HTTP" were assumed to be the same.
>
>
There is a (emerging) definition that I believe is being referred to as
normal http (or version independent http) - but it doesn't govern this
question of the scheme of the target redirect. This draft would need to
limit cross scheme redirects explicitly if that was what was wanted. (which
makes sense to me).

The definition I am referring to is the http-core work in the 3 active
drafts here: https://github.com/httpwg/http-core

-Patrick