Subject: [dnsoverhttp] Fwd: New Version Notification for draft-hoffman-dns-over-https-00.txt

From: Patrick McManus <[email-masked]>
Date: Wed, 3 May 2017 23:15:34 -0400

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, May 3, 2017 at 11:09 PM
Subject: New Version Notification for draft-hoffman-dns-over-https-00.txt
To: Patrick McManus <[email-masked]>, Paul Hoffman <
[email-masked]>

A new version of I-D, draft-hoffman-dns-over-https-00.txt
has been successfully submitted by Patrick McManus and posted to the
IETF repository.

Name:           draft-hoffman-dns-over-https
Revision:       00
Title:          DNS Queries over HTTPS
Document date:  2017-05-03
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-hoffman-dns-over-
https-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-over-
https/
Htmlized:       https://tools.ietf.org/html/draft-hoffman-dns-over-https-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hoffman-dns-
over-https-00

Abstract:
   DNS queries sometimes experience problems with end to end
   connectivity at times and places where HTTPS flows freely.

   HTTPS provides the most practical mechanism for reliable end to end
   communication.  Its use of TLS provides integrity and confidentiality
   guarantees and its use of HTTP allows it to interoperate with
   proxies, firewalls, and authentication systems where required for
   transit.

   This document describes how to run DNS service over HTTP using
   https:// URIs.

   [ This paragraph is to be removed when this document is published as
   an RFC ] Comments on this draft can be sent to the DNS over HTTP
   mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp .

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 13:52:35 +1000

> A new version of I-D, draft-hoffman-dns-over-https-00.txt

A few nits only; I need to think more about how this fits into the
ecosystem.  I am warming to the notion that you have flexibility in
representation format, that's a key advantage of using HTTP.  You have
neatly punted on the hard parts of that by choosing the dumb option to
document, which means that you can bootstrap effectively.

The query string uses one of the worst encodings known to man.  Did
you do any analysis here?  Is base64url bad for some reason.  For
instance, I would believe that it increases the length of the string
in the aggregate if you told me.

You should use a parameter name for the query string so that you at
least have the chance to automatically discover a service and make
requests in other forms using the query string without sniffing or
other such horrors (conneg works fine for the POST variant, but you
are pushing those uses to a method that isn't a great fit).  What you
have consumes the entire usable space in the query string, so it would
be hard to get in edgewise with an alternative query form.

Do you really need to encode the ID?  I realize that might be
construed as opening the floodgates, but it is going to make caching
that much more fragmented.  Can you not just trim it off?

Section 7 seems a little repetitive.  I don't think that you have much
of a case on security grounds to require h2, but the last paragraph
seems quite convincing.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 4 May 2017 11:17:42 -0400

Thanks Martin.

> document, which means that you can bootstrap effectively.

ack - and I believe Paul has a JSON media-type document going on a separate
path that should dovetail nicely,  but not be a blocker. I certainly would
hope to see some JSON in the wild.

> in the aggregate if you told me.

will open an issue for more analysis.. did one example by hand and it was a
~wash size wise.. and the hex made a clearer example :) more study would be
good, but its a micro opt given the existing bounds on the sizes involved.

> be hard to get in edgewise with an alternative query form.

so this is interesting. I started down that road, but couldn't really
figure out how to do any form of negotiation beyond the MTI with it so just
stuck with the simpler variant you see in -00. 415 seems to apply
specifically to content-type and bodies so wouldn't work as a signal. Or am
I being too pessimistic?

Strictly speaking we don't need the uglier GET variant at all - the POST is
absolutely cacheable. But realistically speaking that will not work with a
lot of existing caches.

> that much more fragmented.  Can you not just trim it off?
low friction of using an existing (albeit encoded) format traded off vs a
couple bytes... that is why the normalization of ID SHOULD is in there tho.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 4 May 2017 11:30:39 -0400

On Thu, May 4, 2017 at 11:17 AM, Patrick McManus <[email-masked]>
wrote:

> ack - and I believe Paul has a JSON media-type document going on a
> separate path that should dovetail nicely,  but not be a blocker. I
> certainly would hope to see some JSON in the wild.
>
>
>>
> will open an issue for more analysis.. did one example by hand and it was
> a ~wash size wise.. and the hex made a clearer example :) more study would
> be good, but its a micro opt given the existing bounds on the sizes
> involved.
>
>
>>
> Strictly speaking we don't need the uglier GET variant at all - the POST
> is absolutely cacheable. But realistically speaking that will not work with
> a lot of existing caches.
>
>
>

The text is

   In order to maximize cache friendliness, DNS API Clients SHOULD use
   the same ID (the first two bytes of the header) for every DNS
   request.

That's enough to ensure that the same client making the same request hits
the cache, but it's not enough to make sure that _different_ clients can
hit a shared cache.  Even different tabs in the same browser won't share
the browser cache unless they select matching IDs.

Personally, I would just skip these two bytes.  Instead of being "part of
the DNS format", I think of the ID as being a generic miniature RPC
protocol, which we are replacing with HTTP.  Failing that, I would say the
ID MUST be zero.

>
>
>
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 May 2017 15:46:07 +0000

On May 4, 2017, at 8:30 AM, Ben Schwartz <[email-masked]> wrote:
> That's enough to ensure that the same client making the same request hits the cache, but it's not enough to make sure that _different_ clients can hit a shared cache.  Even different tabs in the same browser won't share the browser cache unless they select matching IDs.
> 
> Personally, I would just skip these two bytes.  Instead of being "part of the DNS format", I think of the ID as being a generic miniature RPC protocol, which we are replacing with HTTP.  Failing that, I would say the ID MUST be zero.

If we're going to use the wire protocol (which I think is good, particularly for extensions), then it should actually be the wire protocol. Therefore, I would strongly prefer "MUST be zero" to "be close to, but not exactly, the wire protocol but not exactly in order to help caching".

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 May 2017 10:16:53 +1000

> If we're going to use the wire protocol (which I think is good, particularly for extensions), then it should actually be the wire protocol. Therefore, I would strongly prefer "MUST be zero" to "be…

This suggests a potential solution to Patrick's parameter negotiation
dilemma.  Use those two bytes to switch query format...

Also, zero encodes terribly in hashes.  Pick something nice.

(I'll get back in my box now, the bad ideas should abate momentarily.)

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 8 May 2017 14:15:58 -0400

I spent a few minutes playing with Martin's old bhpack code and got the
following results for HPACK Huffman-code queries.

HPACK(base64(random bytes)): 1.19 bytes per byte
HPACK(url-encode(random bytes)): 1.82 bytes per byte

HPACK(base64(random lower-case letters)): 1.15 bytes per letter
HPACK(lower-case letters): 0.82 bytes per letter

I compute that percent-encoding is about 50% larger than base64 for random
bytes in HTTP/2.  (I think it was 86% larger in HTTP/1.1).  For a mix of
random bytes and lower-case letters, percent-encoding beats base64 in
HTTP/2 when the input is 66% letters or more.  DNS queries have about 20
bytes in binary, so that would be about 40 name characters.

So base64 still wins, but I'm OK with percent encoding.

On Thu, May 4, 2017 at 8:16 PM, Martin Thomson <[email-masked]>
wrote:

> > If we're going to use the wire protocol (which I think is good,
> particularly for extensions), then it should actually be the wire protocol.
> Therefore, I would strongly prefer "MUST be zero" to "be close to, but not
> exactly, the wire protocol but not exactly in order to help caching".
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 May 2017 18:57:40 +0000

> So base64 still wins, but I'm OK with percent encoding.

I have a weak operational preference for base64. We'll switch to it in the -01 draft and see if there are strong objections.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 May 2017 02:03:44 +0000

On May 3, 2017, at 8:52 PM, Martin Thomson <[email-masked]> wrote:
> The query string uses one of the worst encodings known to man.

Did you forget that UTF-7 was a thing?

Proposal to change to base64url:
   https://github.com/paulehoffman/draft-hoffman-dns-over-https/pull/9
Any objections?

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 May 2017 12:17:17 +1000

>    https://github.com/paulehoffman/draft-hoffman-dns-over-https/pull/9

None from me.

(And you are right, UTF-7 is worse.)