[dnsoverhttp] Seoul Bar Bof Minutes

Patrick McManus <pmcmanus@mozilla.com> Wed, 16 November 2016 00:50 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 49CA712941C for <dnsoverhttp@ietfa.amsl.com>; Tue, 15 Nov 2016 16:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.735
X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9U0CfXM2NKJV for <dnsoverhttp@ietfa.amsl.com>; Tue, 15 Nov 2016 16:50:23 -0800 (PST)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 332151293F9 for <dnsoverhttp@ietf.org>; Tue, 15 Nov 2016 16:50:23 -0800 (PST)
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com []) by linode64.ducksong.com (Postfix) with ESMTPSA id A73053A015 for <dnsoverhttp@ietf.org>; Tue, 15 Nov 2016 19:50:22 -0500 (EST)
Received: by mail-it0-f51.google.com with SMTP id c20so183388850itb.0 for <dnsoverhttp@ietf.org>; Tue, 15 Nov 2016 16:50:22 -0800 (PST)
X-Gm-Message-State: ABUngvf6U/vrm85SzvhPGtWm6hs431LwkmoMvlphUnCGqmKv1oAs6NAJe1nHsYD5Z1jnLftiilxxyUr+flUIkA==
X-Received: by with SMTP id u2mr5951163itd.47.1479257422025; Tue, 15 Nov 2016 16:50:22 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 15 Nov 2016 16:50:21 -0800 (PST)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 16 Nov 2016 09:50:21 +0900
X-Gmail-Original-Message-ID: <CAOdDvNo3LAKzgBhDRALULXBZ98DQ+F9E03N8MKhZUHkwmgn0Ug@mail.gmail.com>
Message-ID: <CAOdDvNo3LAKzgBhDRALULXBZ98DQ+F9E03N8MKhZUHkwmgn0Ug@mail.gmail.com>
To: dnsoverhttp@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c088fa82be58405416075ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/8WktowaQUOmWjZH7JU4c7KrGj-w>
Subject: [dnsoverhttp] Seoul Bar Bof Minutes
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 00:50:26 -0000

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.


2016-11-16 18:45-19:45 GMT+9


 * 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


 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
    * Controversy
    * Compelxity in serving DNS in addition to web traffic from HTTP servers
    * Does this replace DNS infrastructure, or just become a different
    * Why not QUIC?
    * 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

    * BCP 58 doesn't capture nuances
 * POST makes you invisible to cache. Not necessarily a bad thing, but a
 * 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


 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
    * 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
    * Interesting Q's re: geographic distributions
    * Some tunneling strategies break how we do this
    * To me, wire format is simpler part
    * Tunneling is pretty straightforward
    * 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"
    * <missed the point of her earlier comments>
    * Could we enhance security rather than destroy privacy?
    * 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


    * 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
    * There are DNS semantics other than queries
    * AXFR, for instance
 ?: Concern about on-the-fly signing and management of trust anchors
    * 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>


 * 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

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

* 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

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

# 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

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
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 ]