Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https

[Martin Thomson <[e-mail]>]

On Wed, May 2, 2018 at 9:43 PM Sara Dickinson <[e-mail]> wrote:
> A simple statement in Section 6 to the effect that ‘DNS API clients and
servers may use EDNS(0) padding [RFC7830] in the DNS wire format
independently of whether or not HTTP padding is used.’ would suffice I
think.

That would be fine with me.  Or a more general: "Padding of requests and
responses can use padding provided at any protocol layer that supports it:
TLS 1.3, HTTP/2, and EDNS(0) padding can all be used as desired."

> > It would be lovely if Stubby could add DOH as a transport that is
parallel to DNS-over-TLS, and for that there has to be some common
understanding of privacy and trust levels. Duplicating to twisty mazes from
DNS-over-TLS usage policies is not going to help. Instead, a new document
that covers DNS-over-TLS, DOH, and the likely future DNS-over-QUIC needs to
deal with this, and more clearly.

> I’m all for that general approach but…. what I think would help here is:

> - Can this document make any clear statement about whether or not a DNS
API server is ‘trusted' if HTTPS authentication fails?

If trust is attached to a name or URI, then authenticating that identifier
is a critical precondition of authorizing a server.  Though that isn't
stated here directly, it is at implied through the use of HTTPS.  I don't
think that we need to explicitly restate requirements from RFC 2818 though.