Subject: [dnsoverhttp] New version of draft-hoffman-dns-over-http

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Oct 2016 13:23:40 +0000

Greetings again. Joe and I have submitted a new draft that we hopefully covers all of the messages from this list on the -00 draft. The diffs are here:
   https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-over-http-01

For things where there seemed to be agreement, we put them in; where there wasn't, we put in a TODO. We would love to hear proposals for specific text on any of the TODOs.

Earlier, there was discussion of having an informal bar BoF in Seoul. There is no need to wait for that to happen before submitting proposed text.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Mon, 17 Oct 2016 17:19:01 -0400

Paul, Joe, thanks for pushing this forward.

I don't have a chance this minute to propose text - but I have a few notes.
I can help with text down the line if it would help. But I didn't want to
just sit on my comments.

-Patrick

On Sat, Oct 15, 2016 at 9:23 AM, Paul Hoffman <[email-masked]>
wrote:

> Greetings again. Joe and I have submitted a new draft that we hopefully
> covers all of the messages from this list on the -00 draft. The diffs are
> here:
> For things where there seemed to be agreement, we put them in; where there
> wasn't, we put in a TODO. We would love to hear proposals for specific text
> on any of the TODOs.
>
>
   If no PREFIX is configured as above, the client MAY query a DNS
   resolver for which they have an IP address.  The query is

      https://<IPADDRESS>/.well_known/TBD1
 If the DNS server knows about API support, the returned URI will be
   the PREFIX.

I don't really know what this means for sure. Is the query an https query
or a DNS query? methods etc? What is a returned URI?

   TODO: Full discussion about using this protocol in HTTP/2 for server
   push.  This will also hopefully cover caching and DNS TTLs.

I don't think the push section will satisfy the caching considerations
language - that is independent of push

The primary thing to define here is what path and origin the pushed request
is for.

Secondarily you get to decide whether that lives in the scope of an
existing stream (e.g. an html document) or is attached to the whole session
(aka stream 0) - this relationship is defined by push. If it is stream 0
you would need to define an h2 extension and negotiate it with settings -
so I would probably avoid that.

Thirdly, as we've discussed there are security considerations around the
scope in which you want to use the response. My argument would be to
require it to be signed and not restrict its usage, while discussing the
implications of that.

> Earlier, there was discussion of having an informal bar BoF in Seoul.
> There is no need to wait for that to happen before submitting proposed text.
>
> --Paul Hoffman
> _______________________________________________
> dnsoverhttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Oct 2016 02:28:29 +0000

On Oct 17, 2016, at 2:19 PM, Patrick McManus <[email-masked]> wrote:
> I don't have a chance this minute to propose text - but I have a few notes. I can help with text down the line if it would help.

It would, for the second one.

> But I didn't want to just sit on my comments.

Thanks! 
> I don't really know what this means for sure. Is the query an https query or a DNS query? methods etc? What is a returned URI?

Good catch. It is an HTTPS query, using GET. The returned URI becomes the PREFIX in the template.

> I don't think the push section will satisfy the caching considerations language - that is independent of push

I thought that someone linked them in the earlier thread.

> The primary thing to define here is what path and origin the pushed request is for.
> 
> Secondarily you get to decide whether that lives in the scope of an existing stream (e.g. an html document) or is attached to the whole session (aka stream 0) - this relationship is defined by push. If it is stream 0 you would need to define an h2 extension and negotiate it with settings - so I would probably avoid that.
> 
> Thirdly, as we've discussed there are security considerations around the scope in which you want to use the response. My argument would be to require it to be signed and not restrict its usage, while discussing the implications of that.

Wording (from anyone on the list) would be a good start to getting conversation on this topic, which seemed of interest to many.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Tue, 18 Oct 2016 10:58:19 -0400

On Mon, Oct 17, 2016 at 10:28 PM, Paul Hoffman <[email-masked]>
wrote:

>
> > I don't really know what this means for sure. Is the query an https
> query or a DNS query? methods etc? What is a returned URI?
>
cool. to nudge it along a little further - is it a 200 reply (that would be
my position), or are redirects allowed.. I think the words you want are the
"response message body" contains the PREFIX and you probably want a defined
content-type for it. It also begs the question of how you do HTTPS with an
IP Addr. One thing you might be able to do is make this a two step process
- do it first over http:// to get an unauthenticated hint and then repeat a
similar query via https:// to the PREFIX (containing a hostname) to confirm
the service.

> They are linked in the sense that the pushed records would just use the
caching information the same way the 'pulled' ones would.. so it isn't
http/2 push specific.

> Wording (from anyone on the list) would be a good start to getting
> conversation on this topic, which seemed of interest to many.
>
> --Paul Hoffman