Subject: [Doh] draft-ietf-doh-dns-over-https-04 feedback

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 10:01:25 +0000

I've just done a quick read of yesterday's -04 update.

I think §5.0 could benefit from a reference to RFC 2308 to clarify that
it's talking about negative answer caching.

It also says:

> A DNS API server SHOULD respond with HTTP status code 415 
> (Unsupported Media Type) upon receiving a media type it is unable to 
> process.

why not "MUST" ?

In §7.1, the wire format description which only refers to RFC 1035 could
be read as too prescriptive w.r.t. the packet length since it's limited
to 512 bytes in RFC 1035.

There's no need for that limitation, but consideration should be given
to how a DNS API Server that is actually a proxy between DOH and real
wire format should behave in the presence of a longer packet that isn't
accompanied by an EDNS OPT RR.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 10:07:41 +0000

I forgot one:

Why require base64url instead of plain base64?  The latter is natively
supported in web applications via the `window.btoa` and `.atob` functions.

Ray

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 22 Mar 2018 10:19:53 +0000

The alternative to base64url encoding is URI encoding a base64 payload, a two
step operation. A naïve parser in Javascript without needing anotherlibrary
could be done in as little as[1]:

    atob(data.replace(/_/g, '/').replace(/-/g, '+'))

Regards

[1] https://stackoverflow.com/a/44528376

On Thu, Mar 22, 2018 at 10:07:41AM +0000, Ray Bellis wrote:
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 22 Mar 2018 06:32:48 -0400

> > (Unsupported Media Type) upon receiving a media type it is unable to 

Because it might have good reasons for replying with some other code,
if multiple issues exist with the request?

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 10:47:57 +0000

> if multiple issues exist with the request?

OK, so you need to allow for HTTP protocol layer errors such as 401, etc
which happen earlier in the stream's processing.

But if it gets that far, is there any other possible response than 415?

I'm not sure how to phrase it, but I think it MUST be 415 *unless* some
other error was *already* detected (at which point I'd expect request
processing to have been aborted anyway).

Ray

---

From: Patrick McManus <[email-masked]>
Date: Thu, 22 Mar 2018 11:08:21 +0000

Thanks Ray,

imo pretty much this is what SHOULD already signals - I would phrase it as:
that's the expected behavior unless you have a really good reason you
cannot (Dave points out one really good reason - conflicting non-successful
states). Its also plausible an HTTP gateway would not have enough
information to determine more than "failure" and would want to fallback on
400 which would be less than optimal but ok. This is sort of a general
problem and I don't think the draft is overall advantaged by doing this
case by case.

on the other hand we did add some similar text around success/non-success
and how dns and http interact. That's also not strictly necessary but I
think it has a broad enough impact that it is worth doing. I would hope to
avoid doing that with a laundry list of codes (my approach is consistent
with BCP56bis )