[dnsoverhttp] Seoul Bar Bof Minutes

[Patrick McManus <[e-mail]>]

Thanks to everyone who attended last night - I estimated about 75 people
(and I apologize for undersizing the space). There is definitely strong
interest and last night provided a nice overview. Let's see if we can focus
it now on the list.

Thanks also especially to Kyle Rose and Shane Kerr who both took minutes at
a bar bof. That's a high bar! I am inlining them below directly as I don't
think an informal gathering warrants further editing - they are quite
useful as is.

=======


DNS-over-HTTP Minutes (DRAFT: NEEDS CORRECTIONS)
2016-11-16 18:45-19:45 GMT+9
[e-mail]

INTRO (Pat)

 * Self-declared "working group". Haha.
 * Four key areas: lookup, publish, tunnels, interaction w/ H2
 * 2 drafts already!

 MT: Need people to articulate reasons people want this
 JH: Let's just capture reasons w/o judgment

BRAINSTORMING

 JH: Want ability to publish DNS in a way that works for ACME and for me as
an application developer
 ?:
    * Suggesting that a client might want to know DNS entries, and "Hey, I
have those!"
    * Push proof of matching DNS for TLS same-connection reuse with
authentication (e.g., DNSSEC)
 ?: Privacy via HTTPS that is better than DPRIVE
 <missed a comment from Davey>
 <missed another comment>
 MNot: Hopefully get something cleaner to work with
 Tale:
    * Controversy
    * Compelxity in serving DNS in addition to web traffic from HTTP servers
 Alexander:
    * Does this replace DNS infrastructure, or just become a different
transport?
    * Why not QUIC?
 TH:
    * Interested in semantic mapping of DNS onto rich capabilities of HTTP
    * Do we need canonicalization, which is complicated and scary
 ?: Debuggability
 ?: Want ability to push authenticated data to client that server knows it
will need

DAVEY: draft-ietf-dnsop-dns-wireformat-http-00

 MT:
    * BCP 58 doesn't capture nuances
 * POST makes you invisible to cache. Not necessarily a bad thing, but a
change.
 * Some discussion of wire format

PH: generic JSON thing

 * Not a canonical defn of how to do DNS in JSON
 * E.g., carrying broken DNS response
 * JH and PH collaborated
 * DNS over HTTP for a generic query, not tunnel

 PM: What about content negotiation?
 JH: Can handle multiple formats, but semantics are the same
 PH: JSON is MTI

DISCUSSION

 MNot: Want something that gets some real value out of using HTTP
 PM: Good interaction w/ caches & proxy infrastructure
 MT: If using DNS over HTTP, could hit browser cache instead of forward
resolver when doing a DNS lookup
 TH:
    * On DNS, you get an answer based on who/where you are
    * W/HTTP, could place a cookie that influences answers
    * Possible to carry information throughout infrastructure that DNS
can't currently express
    * Core semantics re: caching & personalization need to be nailed down
 MNot: Don't have to take cookies
 TH: Like URI formulation b/c easier to make those distinctions
 Alexaner: Sounds like DNS proxy service
 JH:
    * Interesting Q's re: geographic distributions
    * Some tunneling strategies break how we do this
 Tale:
    * To me, wire format is simpler part
    * Tunneling is pretty straightforward
 MNot:
    * Mapping record types easy
    * Semantic mapping tricky
 ?:
    * Interesting uses of DNS is a kludge (e.g., mapping clients)
    * Opportunity to improve the capabilities of DNS
    * Consider fully implications rather than just say "no"
 Wendy:
    * <missed the point of her earlier comments>
    * Could we enhance security rather than destroy privacy?
 PH:
    * DNS protocol & HTTPS have specific privacy and security properties
    * As long as we're not making HTTP less secure/less private, don't make
it different
    * DNS is not special

OBJECTIONS

 ?:
    * Sounds like HTTP world wants <something?>
    * DNS has totally different semantics from HTTP
 MT: Concerned that people are avoiding scoping discussion to avoid conflict
 ?:
    * Absolutely want to do tunnel
    * Push scares me
        - Caching on anything other than TTL scary
        - TTL *is* the semantics of DNS
 ?: Don't want CNN telling me the DNS entries for Google (unless signed)
 Ekr: IETF often has people who agree on the solution but not on the problem
 MNot: Is the point to replicate DNS semantics w/HTTP, or go well beyond
that?
 Denis:
    * There are DNS semantics other than queries
    * AXFR, for instance
 ?: Concern about on-the-fly signing and management of trust anchors
 Wes:
    * IETF doesn't have a great track record for dual stack
    * Stapling stuff together creates complexity
 Brian?: <missed the point of his statement>
 ?: Should figure out what people actually want
 Ekr: Replicating system resolver is very difficult
 ?: <missed another one>

CONCLUSION

 * Clear consensus that there's enough of interest to explore further
 * No one in the room thinks this is dangerous enough that we should not
explore it further
 * Call for draft authors: a few hands (4-5)

 JH: Assuming we have a small enough problem to solve, can we have a
Chicago BoF?

 * Observation that draft volunteers were mostly DNS people

dns-over-http-minutes.txt
Displaying dns-over-http-minutes.txt.

---- From Shane Kerr ---

# Introduction
Lots of stuff going on in this space.
People? Energy?

1. Lookup semantics
2. Publish/modify semantics
3. Tunneling
4. Push DNS records inside HTTP/2 application layer protocol

Where would we do this work?

# Reasons that people want this?

* Ability to publish/modify records use as proof types in ACME for
  Lets Encrypt certificates not in public servers that works as a web
  application developer

* Pushing DNS helps for pre-resolve directive
* Claim about origin, certificate plus DNS match, speed that up

* DNS with TLS, not easy in DNS

* Type information in constrained environment without DNS server
  (COAP?)

* Better DNS server (fragmentation issues)
* API for application developers

* DNS is confusing. Something cleaner.
  Concern: Clients cache information, behind HTTP servers to get
  correct information from CDN. Added DNS is much bigger load than
  just web load.

Q: Replace DNS? (Auth+Proxy)
Q: Timeline?
Q: Why not DNS over QUIC? :)
   DNS over HTTP over QUIC? DNS over QUIC directly?

* Mapping between resources expressed in DNS and expressed in HTTP.
  Can use DNS URI scheme for this. Like PUSH promise.

* Serialization that is not raw DNS. Sort of a capture format.

* Feed data that server knows client will want.

* Middleboxes suck.

# Presentations

Davey Song presents wire-format draft
- some discussion about POST and whether it is okay

Paul Hoffman explains his JSON draft
- not canonical

Ted Hardie wants people to explore differences, for example DNS
caching versus HTTP caching. HTTP can carry a whole lot more
information than we have had a possibility in the past (with DNS).
Caching and personalization seem to be where to start.

Mark ??? mentions that cookies may or may not be required.

Someone mentions similar things in DNS and HTTP. TTL, cookies, ...

Joe Hartelman explains that for some use cases a
DNS-client-to-DNS-server over HTTP, others... not? There are a bunch
of interesting questions about geographical distributions.

Which part is the simpler part? Wire format! (From a DNS point of
view.)

Andrew Sullivan... hard things are privacy & security & so on. Maybe
we can do this in a newer protocol. Don't know if there are solutions,
but they should be fully considered.

Wendy Seltzer thinking if we brought DNS to the web we could use it
for security models. (People like this!) Could this enhance security
rather than destroy privacy?

Paul Hoffman says DNS has well-studied privacy & security. HTTP too.
Would not want the outcome to say "it is dangerous in HTTP so we won't
do it". As long as HTTP security is not made worse, DNS should be made
equal.

# Show-Stopping Concerns?

Olafur Gundmonson - it seems like HTTP people want a new DNS
transport. Question is semantics. DNS is sometimes very different from
HTTP semantics.

??? - scope is not clear.

Ray Bellis: I am happy tunneling wire format.

Warren Kumari: Where are the edges of this?

???:

Mark ???:

Stuart Cheshire: DNS has query, but also update and so on. DNS session
signaling has semantics for long-lived connections. So translations
will have to include variants without normal 12-byte headers.

Jim Reid: pushing more of DNSSEC into web browser... maybe a concern.

???: Changes pushing DNS to look more like HTTP. And HTTP pushing more
towards DNS.

Lorenzo Colitti: Going to break entire industries.

Dan York: Interest indicates we may want a BoF.

Wes Hardaker: We have a bad record with dual-stack, gluing things
together.

Olafur Gundmonson: A lot of DNS hacks are because of re-use. If we
don't need resolvers, maybe we can do interesting things.

Eckert: If you want a clean channel, don't use HTTP.

???: Very different use cases. A clean API. That seems easy. Browsers
talking directly to... something. That seems crazy. DNS version 2.

# Next Steps?

Q: Who thinks there are enough interesting things to continue to explore
   this?
A: 90%

Q: Who would be willing to narrow down the scope enough to have a BoF?
A: About 15-20 people.

Q: Who is willing to write drafts?
A: 4 or 5.

Q: Who will give feedback to drafts?
A: 30 or so.

Q: Do people think we may be ready to have a BoF in Chicago.
A: Many hands.

Q: Do DNS people in the room feel like it has been socialized highly
   in the DNS world?
A: Yes [ for parts we mentioned ]