Subject: [Doh] AD Review: draft-ietf-doh-dns-over-https-12

From: Adam Roach <[email-masked]>
Date: Tue, 24 Jul 2018 18:24:19 -0500

This is my AD review for draft-ietf-doh-dns-over-https-12.  I have a handful
of comments below that I'd like to see addressed prior to asking the IESG to
consider the document, but they do not preclude it from entering IETF last
call. Please treat them as you would any other last-call comments.

Thanks to everyone who worked on this document, and to the early 
implementors
whose work informed its development.

---------------------------------------------------------------------------

Abstract:

 >  This document describes how to make DNS queries over HTTPS.

This seems overly minimal for an abstract. I would propose a condensed 
version
of the first paragraph of the Introduction; e.g.:

    This document defines a specific protocol for sending DNS queries and
    getting DNS responses over TLS-secured HTTP. Each DNS query-response 
pair is
    mapped into an HTTP exchange.

---------------------------------------------------------------------------

§5.1.1 and 5.2.2:

Please consider adding or replacing the existing examples with a request 
for a
AAAA record. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for
guidance on the use of IPv6 examples in IETF specifications.

===========================================================================

All of my remaining comments are minor editorial issues.

§1:

 >  Each DNS query-response pair is mapped into a HTTP
 >  exchange.

Nit: "...an HTTP..."

---------------------------------------------------------------------------

§4:

 >  DoH
 >  Servers MAY support more than one URI.

Nit: "...URI Template."

---------------------------------------------------------------------------

§5.1:

 >  The DoH client SHOULD include an HTTP "Accept" request header to

Nit: "...request header field..."

 >  Irrespective of the value of the Accept request header, the client

Nit: "...request header field..."

---------------------------------------------------------------------------

§6.1:

 >  A DoH exchange can pass through a hierarchy of caches that include
 >  both HTTP and DNS specific caches.

Nit: "...both HTTP- and DNS-specific caches."

---------------------------------------------------------------------------

§6.1:

 >  The stale-while-revalidate and stale-if-error Cache-Control
 >  directives ([RFC5861]) could be well suited to a DoH implementation

Nit: "...well-suited..."

---------------------------------------------------------------------------

§6.1:

 >  DoH clients MUST account for the Age response header's value

Nit: "...header field's value..."

 >   if a RRset is received with a DNS TTL of 600, but the Age header

Nit: "...header field..."

---------------------------------------------------------------------------

§6.2:

 >  The messages in classic UDP based DNS [RFC1035] are inherently

Nit: "...UDP-based..."

---------------------------------------------------------------------------

§6.3:

 >  For HTTP requests initiated by the DoH client this is implicit in the

Nit: "...DoH client, this is..."

---------------------------------------------------------------------------

§9.2:

 >  The DNS wire format [RFC1035] contains no client identifiers, however
 >  various transports of DNS queries and responses do provide data that

Nit: "...client identifiers; however, various..."

 >  for correlation such as explicit HTTP cookies and implicit

Nit: "...for correlation, such as..."

---------------------------------------------------------------------------

§9.2:

 >  requests directly group those requests.  Long lived connections have
 >  better performance behaviors than short lived connections, but group

Nit: "...long-lived..."

Nit: "...short-lived..."

---------------------------------------------------------------------------

§9.2:

 >  TLS based implementations often achieve better handshake performance

Nit: "TLS-based..."

---------------------------------------------------------------------------

§9.2:

 >  are designed as an explicit state tracking mechanism between the

Nit: "...state-tracking..."

---------------------------------------------------------------------------

§10:

 >  Session level encryption has well known weaknesses with respect to

Nit: "Session-level..."

Nit: "...well-known..."

---------------------------------------------------------------------------

§11:

 >  It logically follows that the
 >  server which is queried can influence the end result.

Nit: "...server that is queried..."

---------------------------------------------------------------------------

§11:

 >  The HTTPS channel used by this specification establishes secure two
 >  party communication between the DoH client and the DoH server.

Nit: "...two-party..."

---------------------------------------------------------------------------

§11:

 >  Some HTTPS client implementations perform real time third party
 >  checks of the revocation status of the certificates being used by

Nit: "...third-party..."

 >  possibility of deadlock, DoH servers SHOULD NOT rely on DNS based
 >  references to external resources in the TLS handshake.  For OCSP the

Nit: "...DNS-based..."

---------------------------------------------------------------------------

§11:

 >  Alternative strategies a client might employ include making the
 >  initial resolution part of the configuration, IP based URIs and
 >  corresponding IP based certificates for HTTPS, or resolving the DNS

Nit: "...IP-based..." (twice)

---------------------------------------------------------------------------

§11:

 >  HTTP [RFC7230] is a stateless application level protocol and

Nit: "...application-level..."

/a

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 Jul 2018 20:23:53 -0400

Thanks Adam!

>    mapped into an HTTP exchange.

can I convince you of (the subtly different) "This document defines a
protocol for sending DNS queries and getting DNS responses over HTTPS. Each
DNS query-response pair is mapped into an HTTP exchange."

> Nit: "...request header field..."
I understand header field is traditional; but honestly I'd like to stop
doing it as I don't think it clarifies anything in this context and just
sounds stilted. I'll accept pushback, but I want to try :)

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Jul 2018 20:14:06 -0500

On 7/24/18 7:23 PM, Patrick McManus wrote:
> Thanks Adam!
>
> On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Abstract:
>
>     This seems overly minimal for an abstract. I would propose a
>     condensed version
>        getting DNS responses over TLS-secured HTTP. Each DNS
>     query-response pair is
> protocol for sending DNS queries and getting DNS responses over HTTPS. 
> Each DNS query-response pair is mapped into an HTTP exchange."

That's fine as well.

> I understand header field is traditional; but honestly I'd like to 
> stop doing it as I don't think it clarifies anything in this context 
> and just sounds stilted. I'll accept pushback, but I want to try :)
>

You're getting pushback. "Header" means something, and this ain't it.

The issue is that we use "header" *colloquially* to mean "header field," 
but in a formal context, that's not just sloppy -- it's inside baseball. 
An implementor who is not part of the existing HTTP culture -- 
especially one who is just coming up to speed by reading the base HTTP 
documents, and who has the distinction between "header" and "header 
field" fresh in his mind -- may rightly be confused by this short-hand. 
Our documents are for a broader audience than ourselves, and we need to 
remain mindful of the level of experience some of that audience might have.

/a

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jul 2018 17:16:49 +1000

On Wed, Jul 25, 2018 at 11:14 AM Adam Roach <[email-masked]> wrote:

> The issue is that we use "header" *colloquially* to mean "header field," but in a formal context, that's not just sloppy -- it's inside baseball. An implementor who is not part of the existing HTTP culture -- especially one who is just coming up to speed by reading the base HTTP documents, and who has the distinction between "header" and "header field" fresh in his mind -- may rightly be confused by this short-hand. Our documents are for a broader audience than ourselves, and we need to remain mindful of the level of experience some of that audience might have.

For the benefit of those watching, the distinction is fairly
rigorously maintained in HTTP documents, but it's unclear if it is
valuable.  That distinction is: the header is the thing at the front
of a message, before the body.  The header contains a status line and
a number of header fields.  We often see people refer to (for example)
header fields as "headers" without any risk of confusion, but it's a
just a recognized and widespread shorthand.

This is not a closed subject (see
https://github.com/httpwg/http-core/issues/111#issuecomment-403666777),
and I don't believe that there is much risk of confusion, but using
the correct form doesn't cost us a lot.

(I am reminded of the big "I" internet question that we had decided
for us by the AP...)

---

From: "Hewitt, Rory" <[email-masked]>
Date: Wed, 25 Jul 2018 15:24:23 +0000

All due respect to you, Adam, but I honestly cannot conceive of a potential implementor of DoH who would get confused by the "header" / "header field" distinction. I appreciate your point that a) we should use standard terminology and b) we should be aware of the broader audience (and I'm aware that it doesn't 'cost' anything to use one rather than the other) but TBH, I've been writing code for almost 25 years, most of that in the last 15 years being web-related, and I honestly never even KNEW that the official term was "header field" - I've only used "header", even when writing product documentation. I've apparently been using it wrong all along 😊

To be blunt, if someone honestly gets confused about this sentence

then they have bigger problems to worry about than implementing DoH...

But since it's no biggie to change it to "header field", I guess we should use standard terminology.

From: Adam Roach <[email-masked]> 
Sent: Tuesday, July 24, 2018 6:14 PM
To: Patrick McManus <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12

Thanks Adam!

On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach <[email-masked] <mailto:[email-masked]> > wrote:

>  This document describes how to make DNS queries over HTTPS.

This seems overly minimal for an abstract. I would propose a condensed version
of the first paragraph of the Introduction; e.g.:

   This document defines a specific protocol for sending DNS queries and
   getting DNS responses over TLS-secured HTTP. Each DNS query-response pair is
   mapped into an HTTP exchange.

can I convince you of (the subtly different) "This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange."

That's fine as well.

I understand header field is traditional; but honestly I'd like to stop doing it as I don't think it clarifies anything in this context and just sounds stilted. I'll accept pushback, but I want to try :)

/a

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Jul 2018 12:01:21 -0400

Rory, the reason to say "Header Field" rather than "Header" is not that the
particular text you quoted would be misunderstood—I agree that it would
not.   It's that it keeps the terminology clear.   When I was reviewing the
(awesome!) HTTP 2 documents, it was really helpful to me as a new reader
that the distinction was kept clear, not because I would have
misunderstood, but simply because it reduced the intellectual workload of
parsing the document.   This is worth doing. :)

On Wed, Jul 25, 2018 at 11:24 AM, Hewitt, Rory <
rhewitt=[email-masked]> wrote:

> All due respect to you, Adam, but I honestly cannot conceive of a
> potential implementor of DoH who would get confused by the "header" /
> "header field" distinction. I appreciate your point that a) we should use
> standard terminology and b) we should be aware of the broader audience (and
> I'm aware that it doesn't 'cost' anything to use one rather than the other)
> but TBH, I've been writing code for almost 25 years, most of that in the
> last 15 years being web-related, and I honestly never even KNEW that the
> official term was "header field" - I've only used "header", even when
> writing product documentation. I've apparently been using it wrong all
> along 😊
>
>
>
> *From:* Adam Roach <[email-masked]>
> *Sent:* Tuesday, July 24, 2018 6:14 PM
> *To:* Patrick McManus <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12
>
>
>
> but in a formal context, that's not just sloppy -- it's inside baseball. An
> implementor who is not part of the existing HTTP culture -- especially one
> who is just coming up to speed by reading the base HTTP documents, and who
> has the distinction between "header" and "header field" fresh in his mind
> -- may rightly be confused by this short-hand. Our documents are for a
> broader audience than ourselves, and we need to remain mindful of the level
> of experience some of that audience might have.
>
> /a
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 25 Jul 2018 12:29:57 -0400

> (I am reminded of the big "I" internet question that we had decided

Piffle, the AP doesn't decide anything for us.  Onward, Internet!

---

From: "Hewitt, Rory" <[email-masked]>
Date: Wed, 25 Jul 2018 16:56:16 +0000

"Onward, internet!"

FTFY 😊

Rory

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Jul 2018 12:32:37 -0500

On 7/25/18 10:24 AM, Hewitt, Rory wrote:
> TBH, I've been writing code for almost 25 years, most of that in the 
> last 15 years being web-related, and I honestly never even KNEW that 
> the official term was "header field"

I'm not as much worried about you and people with similar backgrounds as 
I am people with approximately zero HTTP background but lots of DNS 
experience.

/a