Subject: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

From: Brian Haberman <[email-masked]>
Date: Wed, 17 Mar 2021 09:00:28 -0400

All,
     This starts a DPRIVE WG call for adoption for
draft-pauly-dprive-oblivious-doh
(https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/).
Please reply to the mailing list with your views (positive or negative)
on the WG adopting the document and your supporting arguments.

     This call will end on March 31, 2021 at 11:59pm UTC.

Regards,
Brian & Tim

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Mar 2021 06:45:23 -0700

I believe this document should be adopted with a target status of
Experimental

On Wed, Mar 17, 2021 at 6:00 AM Brian Haberman <[email-masked]>
wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Mar 2021 14:58:05 +0000

> on the WG adopting the document and your supporting arguments.

During the WG meeting last week, I expressed strong negative views about adoption. The ensuing discussion helped change my opinion. I was looking at this as "there are almost no users who would want to turn this on", but then came around to "there are browsers who would want to turn this on for the benefit of their users". If the browser takes responsibility for the additional delay in responses, and takes responsibility for watching for the new failure modes and remediating them, then this protocol might be worthwhile even though it adds delay and complexity.

The deciding factor for me was that the authors turned over protocol control to the WG. The "we've already implemented this" tone in the various presentations in the past few months caused me to assume the opposite.

Thus, I mildly support adoption.

--Paul Hoffman

---

From: Eric Orth <[email-masked]>
Date: Wed, 17 Mar 2021 11:06:37 -0400

I support adoption.  I think there's strong potential for browsers and
other clients to find ways to make use of this without necessarily finding
users that understand it to explicitly enable/configure it.

On Wed, Mar 17, 2021 at 10:58 AM Paul Hoffman <[email-masked]>
wrote:

> During the WG meeting last week, I expressed strong negative views about
> adoption. The ensuing discussion helped change my opinion. I was looking at
> this as "there are almost no users who would want to turn this on", but
> then came around to "there are browsers who would want to turn this on for
> the benefit of their users". If the browser takes responsibility for the
> additional delay in responses, and takes responsibility for watching for
> the new failure modes and remediating them, then this protocol might be
> worthwhile even though it adds delay and complexity.
>
> The deciding factor for me was that the authors turned over protocol
> control to the WG. The "we've already implemented this" tone in the various
> presentations in the past few months caused me to assume the opposite.
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 18 Mar 2021 10:47:51 +1100

> on the WG adopting the document and your supporting arguments.

Adopt.  I will then encourage the working group to adopt oblivious HTTP (which we're in the process of chartering) rather than build a parallel design.

Unlike ekr, I think that aiming for Proposed Standard is better than Experimental.  There is nothing wrong with a narrow scope of applicability, though in this case that narrow scope might still provide benefit for a great many people.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Mar 2021 17:04:21 -0700

On Wed, Mar 17, 2021 at 4:48 PM Martin Thomson <[email-masked]> wrote:

> Adopt.  I will then encourage the working group to adopt oblivious HTTP
> (which we're in the process of chartering) rather than build a parallel
> design.
>
> Unlike ekr, I think that aiming for Proposed Standard is better than
> Experimental.  There is nothing wrong with a narrow scope of applicability,
> though in this case that narrow scope might still provide benefit for a
> great many people.
>

To clarify my position: i would favor a proposed standard based on O-HTTP.
I just think it's unfortunate to have something that is approximately
O-HTTP but not precisely as PS at the same time as we are also
standardizing O-HTTP

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Wed, 17 Mar 2021 17:17:36 -0700

> I believe this document should be adopted with a target status of

Fully agree.

thanks,
Rob

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 18 Mar 2021 12:14:59 +1100

On Thu, Mar 18, 2021, at 11:04, Eric Rescorla wrote:
> To clarify my position: i would favor a proposed standard based on 
> O-HTTP.  I just think it's unfortunate to have something that is 
> approximately O-HTTP but not precisely as PS at the same time as we are 
> also standardizing O-HTTP

Makes sense.  I would question the value of publishing the experimental approximately-but-not-quite-O-HTTP version then.  Unless we fail majestically in chartering and executing there, we're not talking about significant delays.

Regarding O-HTTP, we have in-principle agreement to charter a working group and I've drafted a charter (preview: https://github.com/unicorn-wg/ohttp-charter).  That will be discussed on the secdispatch@ list as soon as I send that email.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 17 Mar 2021 19:37:13 -0700

As an author, I support adoption as experimental. To Paul’s email, I also am quite happy to have change control governed by the WG.

To the OHTTP discussion, I’m fine with having the direction be to use OHTTP for ODoH, but I personally believe that even in the best case, the timelines and deployment considerations make it more practical to have an experimental ODoH ship prior to a version that uses OHTTP.

Best,
Tommy

> On Mar 17, 2021, at 6:45 AM, Eric Rescorla <[email-masked]> wrote:
> 
> I believe this document should be adopted with a target status of Experimental
> 
> On Wed, Mar 17, 2021 at 6:00 AM Brian Haberman <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> (https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/ <https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh/>).
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Mar 2021 20:06:24 -0700

> Makes sense.  I would question the value of publishing the experimental approximately-but-not-quite-O-HTTP version then.  Unless we fail majestically in chartering and executing there, we're not ta…

I  suspect the broader application space of O-HTTP makes it a bit
messier, and it could take a while to hammer out all the details. I
for one want to use O-HTTP for POST requests.

As for this draft I support adoption targeting experimental.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim

---

From: Petr Špaček <[email-masked]>
Date: Thu, 18 Mar 2021 12:18:20 +0100

>       This call will end on March 31, 2021 at 11:59pm UTC.

I oppose adoption.

In my opinion value of publishing DoH-specific version of 
approximately-but-not-quite-Oblivious-HTTP is questionable and borders 
with waste of WGs time and engineering resources (after the document is 
published).

DoH RFC 8484 already says how to map DNS to HTTP, so I think we should 
reuse generic Oblivious HTTP and build on top of that, _not_ invent the 
wheel again just for DoH.

-- 
Petr Špaček

---

From: Tomas Krizek <[email-masked]>
Date: Thu, 18 Mar 2021 13:02:19 +0100

I oppose adoption.

The draft introduces huge amount of additional complexity, both for
implementors and operators of DoH. This raises the bar for both smaller
vendors and operators, thus leading to more centralization.

Additionally, the problem it attempts to solve is not DoH-specific, or
even DNS-specific, yet it only provides a solution for DoH.

-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 18 Mar 2021 13:29:17 +0100

>      This call will end on March 31, 2021 at 11:59pm UTC.

I also oppose adoption because of what Petr Špaček and Tomáš Křížek said.

Ondrej
--
Ondřej Surý (He/Him)
[email-masked]

> On 18. 3. 2021, at 12:18, Petr Špaček <[email-masked]> wrote:
> 
> I oppose adoption.
> 
> In my opinion value of publishing DoH-specific version of approximately-but-not-quite-Oblivious-HTTP is questionable and borders with waste of WGs time and engineering resources (after the document is published).
> 
> DoH RFC 8484 already says how to map DNS to HTTP, so I think we should reuse generic Oblivious HTTP and build on top of that, _not_ invent the wheel again just for DoH.

> On 18. 3. 2021, at 13:02, Tomas Krizek <[email-masked]> wrote:
> 
> I oppose adoption.
>

---

From: Neil Cook <[email-masked]>
Date: Thu, 18 Mar 2021 13:58:10 +0000

I oppose adoption. For precisely the same reasons that Tomas lays out below,

Neil

> On 18 Mar 2021, at 12:02, Tomas Krizek <[email-masked]> wrote:
> 
> I oppose adoption.
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Mar 2021 10:49:45 -0400 (EDT)

> I oppose adoption. For precisely the same reasons that Tomas lays out below,

I am also opposing adoption.

The issue is not that we need another transport protocol. We need a
better way to decouple the stub/client data from the resolver/auth
data. How the client reaches their resolver should not be relevant
to this problem. What is relevant is how resolver pooling can decouple
the stub from the auth server.

I would rather see a new method where caching resolvers can feed each
other in a pool in such a way as to give endusers their query privacy.

Additionally, those why require this can already use TOR, which is such
a transport mechanism that is not just specified as a DNS transport.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Mar 2021 08:32:59 -0700

> vendors and operators, thus leading to more centralization.

This seems like an odd argument. We shouldn't do something that's
a manifest increase in privacy (even as experimental!) because it's
work to implement?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Mar 2021 15:41:28 +0000

> To the OHTTP discussion, I’m fine with having the direction be to use OHTTP for ODoH, but I personally believe that even in the best case, the timelines and deployment considerations make it more p…

This makes no sense. If you have a non-standard experimental spec that you are already implementing, but a forthcoming different spec whose base is being developed in another WG, you asking people to work on the will-be-obsoleted protocol wastes many people's time. 

If you want to just document what you are doing now, take your draft to the Independent Submission Editor as informational. The ISE will ask if you got external reviews, and it is quite reasonable for you to ask for those reviews.

Now that I understand the authors' intentions better, I withdraw my support for adoption.

--Paul Hoffman

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Mar 2021 08:42:17 -0700

> On Mar 18, 2021, at 8:32 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Mar 18, 2021 at 5:02 AM Tomas Krizek <[email-masked] <mailto:[email-masked]>> wrote:
> I oppose adoption.
> 

I would also point out that no one is asking that generic recursive resolvers implement this strategy, not only because it would be experimental. Certainly there would be no expectation that all DoH servers support this. Instead, cases where clients are particularly concerned about revealing client IP and identity to very large public resolvers benefit more from this. The intent of having an experimental RFC is to have a common way to achieve that goal.

Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Mar 2021 09:03:00 -0700

> On Mar 18, 2021, at 8:41 AM, Paul Hoffman <[email-masked]> wrote:
> 

I am personally not sure that deployments that want to support ODoH would necessarily want to use a generic OHTTP solution, for two reasons:
- A proxy for ODoH can know that it is proxying a message of a very specific media type that is specific to DNS. An OHTTP proxy may have no way to know what the content is, and can become a completely open proxy.
- A DoH server that wants to support ODoH can add support for the HPKE transformation to the bodies of the messages it transmits, without having to implement a new HTTP stack that has a separate way of formatting all the HTTP messages.

This is what I was referring to as the deployment considerations, and I think that they make the simple ODoH approach not a waste of time or something that would be obsoleted anytime soon—some day, yes, if OHTTP becomes ubiquitous and deployment models are worked out, but that will take time even if OHTTP formatting is defined soon.

Tommy

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2021 16:10:29 +0000

> On 18 Mar 2021, at 15:42, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Instead, cases where clients are particularly concerned about revealing client IP and identity to very large public resolvers benefit more from this.

There’s a much easier and far quicker solution for that problem. Clients who have those concerns can (and should be able to) point their queries elsewhere.

How about an RFC that says “don't use Quad-X if you’re concerned about revealing your IP address or identity to those services”?

I’m sceptical about Oblivious DNS because the use case and problem statement isn’t compelling enough, at least to me.

---

From: Tomas Krizek <[email-masked]>
Date: Thu, 18 Mar 2021 17:19:51 +0100

> I would also point out that no one is asking that generic recursive resolvers implement this strategy, not only because it would be experimental. Certainly there would be no expectation that all Do…

I'm just pointing out that due to the complexity of both supporting and
operating such setup, only very few implementations and very large
providers could use it.

Since the draft doesn't address the underlying issue for DoT or DoQ and
might be subject to be obsoleted in the future by OHTTP, I think work to
improve privacy is better spent elsewhere.
-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

---

From: Eric Orth <[email-masked]>
Date: Thu, 18 Mar 2021 12:21:48 -0400

On Thu, Mar 18, 2021 at 12:10 PM Jim Reid <[email-masked]> wrote:

> > Instead, cases where clients are particularly concerned about revealing
> client IP and identity to very large public resolvers benefit more from
> this.
>
> There’s a much easier and far quicker solution for that problem. Clients
> who have those concerns can (and should be able to) point their queries
> elsewhere.
>
> How about an RFC that says “don't use Quad-X if you’re concerned about
> revealing your IP address or identity to those services”?
>
I disagree with your assumption that clients/users are only concerned about
particular resolvers.  I think many of the users/clients involved here are
concerned about privacy exposure to any and all resolvers, and thus
changing resolvers is not a solution.

>
> I’m sceptical about Oblivious DNS because the use case and problem
> statement isn’t compelling enough, at least to me.
>

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Mar 2021 16:33:31 +0000

> On 18 Mar 2021, at 16:21, Eric Orth <ericorth=[email-masked]> wrote:
> 
> I disagree with your assumption that clients/users are only concerned about particular resolvers. 

Eric, I didn’t make any assumptions about that at all. It was Tommy who said ODNS would benefit those who were concerned about leakage to very large public resolvers. All I did was suggest a simpler alternative that wouldn’t need an RFC or the introduction of more complexity and lots more moving parts.

If the aim of ODNS is to prevent leakage to resolvers *in general*, then that’s a different story. But as I said the use case and problem statement isn’t (yet) compelling enough. The cost/benefit analysis is unclear too. YMMV.

---

From: Eric Orth <[email-masked]>
Date: Thu, 18 Mar 2021 12:40:33 -0400

On Thu, Mar 18, 2021 at 12:33 PM Jim Reid <[email-masked]> wrote:

> Eric, I didn’t make any assumptions about that at all. It was Tommy who
> said ODNS would benefit those who were concerned about leakage to very
> large public resolvers. All I did was suggest a simpler alternative that
> wouldn’t need an RFC or the introduction of more complexity and lots more
> moving parts.
>
Ah, thanks for the explanation.  Maybe Tommy can further explain his point?

>
> If the aim of ODNS is to prevent leakage to resolvers *in general*, then
> that’s a different story. But as I said the use case and problem statement
> isn’t (yet) compelling enough. The cost/benefit analysis is unclear too.
> YMMV.
>
Preventing leakage to resolvers *in general* would be exactly my interest
in ODoH.  This goes along with my previous statement that I think clients
could find good use in automatically using ODoH (for either
particularly-sensitive or all queries) as an autoupgrade to
known-supporting providers rather than just being something users
explicitly select when they have particular concerns.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Mar 2021 10:13:23 -0700

> On Mar 18, 2021, at 9:40 AM, Eric Orth <ericorth=[email-masked]> wrote:
> 
> 
> 
> On Thu, Mar 18, 2021 at 12:33 PM Jim Reid <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 18 Mar 2021, at 16:21, Eric Orth <ericorth=[email-masked] <mailto:[email-masked]>> wrote:
> > 
> Preventing leakage to resolvers *in general* would be exactly my interest in ODoH.  This goes along with my previous statement that I think clients could find good use in automatically using ODoH (for either particularly-sensitive or all queries) as an autoupgrade to known-supporting providers rather than just being something users explicitly select when they have particular concerns.

To clarify my point earlier, I was mainly replying to the concern that supporting ODoH would be a burden for resolvers to implement. Although I don’t think it’s actually that much complexity to add, given our experience, I don’t see a deployment scenario where all recursive resolvers would offer oblivious resolution.

Mainly, this is relevant for resolvers that directly receive client-generated queries, are not directly on the local network (and thus already know a lot about the user), and are in a position where a client can use a proxy to access them. Large public resolvers do fall into this category, but it isn’t limited. It could also be the resolvers used for ISPs, carriers, etc.

Thanks,
Tommy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Mar 2021 17:16:06 +0000

> - A proxy for ODoH can know that it is proxying a message of a very specific media type that is specific to DNS. An OHTTP proxy may have no way to know what the content is, and can become a complet…

"may have" carries a lot of weight in that sentence. It seems likely that OHTTP could have a service type indicator for this exact use case. Further, the proxy might have a limited number of targets that have specific properties.

> - A DoH server that wants to support ODoH can add support for the HPKE transformation to the bodies of the messages it transmits, without having to implement a new HTTP stack that has a separate wa…

This, too, could be part of OHTTP.

> This is what I was referring to as the deployment considerations, and I think that they make the simple ODoH approach not a waste of time or something that would be obsoleted anytime soon—some day,…

This sentence would make sense if you had no design and needed a WG to help make that design. But that's not the case at all. You already have a design, and deployment, and even presented research that shows how well the design works compared to non-O DoH. I'm not arguing that you should stop using the ODoH that you are already experimenting with, just that you should not expect a WG full of people to help you with it if it seems likely to be supplanted by a more general use case.

--Paul Hoffman

---

From: Neil Cook <[email-masked]>
Date: Thu, 18 Mar 2021 17:34:39 +0000

Hi Tommy,

> On 18 Mar 2021, at 17:13, Tommy Pauly <tpauly=[email-masked]> wrote:
> 

Can you explain how you think this could also be the resolvers used for ISPs, carriers etc.? 

To my understanding this draft explicitly excludes the vast majority of them. They are typically *not* public resolvers, and for a proxy not to be colluding with the resolver operator, the proxy would have to be located outside the administrative domain of the ISP/carrier, i.e. outside their network. Perhaps there is some scenario you envisage where third-parties would host and operate proxies within the ISP/Carrier network? 

Neil

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 18 Mar 2021 10:45:11 -0700

As an author, I support adoption of this draft as experimental, with the understanding that the WG will control ownership. (Indeed, we *want* input from the folks in this WG to improve the protocol!)

Best,
Chris

---

From: David Schinazi <[email-masked]>
Date: Thu, 18 Mar 2021 11:06:47 -0700

I support adoption. I think that this work is useful, and I would like to
see it happen in DPRIVE.

David

On Thu, Mar 18, 2021 at 10:45 AM Christopher Wood <[email-masked]>
wrote:

> As an author, I support adoption of this draft as experimental, with the
> understanding that the WG will control ownership. (Indeed, we *want* input
> from the folks in this WG to improve the protocol!)
>
> Best,
> Chris
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Mar 2021 01:03:39 +0000

Hiya,

I had a pretty quick read of this. I haven't followed this
discussion in detail though, so am not claiming to be that
well informed.

I'm not that convinced by it tbh - it seems that running
DNS/Tor is quite doable for at least some clients so it
may well be that it'd be as or more valuable to explore how
to make that work better, and/or to compare this design
vs. DNS/Tor or other designs in various scenarios before
adopting something like this. (In full-disclosure mode: I
think it'd be great if we managed to figure a way to
include Tor in our standards, if we can do that without
distracting the Tor people too much, and maybe DNS/Tor
could be a tractable option there, so I have a bit of
a bias towards exploring that design, but without being
willing to devote the effort required myself, so that's
both a bias and me being a hurler-on-the-ditch [1]:-)

The apparently impending work on oblivious HTTP is also
a negative here, for me, due to the danger of duplication
of scarce effort. There's also lots of scope for (O)DoX
confusion if we do this now.

Publishing this via the ISE and running experiments, then
bringing those results to the WG may be a good way to
proceed, should the proponents want to do that. Or maybe
experimenting on this in PEARG could be a better route.

I do like the idea of improving DNS privacy by making it
harder to track a single client's queries though, so I'm
not totally against this by any means.

On the draft itself:

- I'm not clear as to the overall efficacy of the approach,
given deployment realities - it may make more sense to
first adopt a work item to explore the design space of
proxied DNS (or some form of gossip as another commenter
noted) before adopting a specific solution as a WG draft.
The draft itself quite reasonably points out that it's
early days for this work, so I'm not sure if we'd be
better to adopt a design now or to wait some, but I
suspect "wait some" is the better conclusion for now.

- The danger of things like XFF/Forwarded seems real,
should this get widely deployed. I wondered if a scheme where
the entire proxy->target HTTP request (or similar octets)
are embedded into the target's encryption could allow a
client to detect that a proxy is not sending only the
expected HTTP headers etc. That'd likely require some
form of "test query" be sent to multiple targets via the
same proxy, with perhaps one of the targets being the
client itself. The idea would be to try detect cheating
proxies. I'm sure that's naive in various ways, but again
for me that argues for adopting a work-item to explore a
bigger design space than just this draft may be right.
(And apologies in advance if my quick scan of the draft
missed a discussion of such ideas.)

Lastly, typing all the above has nearly convinced me that
the right outcome here is probably: GOTO PEARG.

Cheers,
S.

[1] https://idioms.thefreedictionary.com/hurler+on+the+ditch

---

From: Rob Sayre <[email-masked]>
Date: Thu, 18 Mar 2021 18:30:47 -0700

On Thu, Mar 18, 2021 at 6:04 PM Stephen Farrell <[email-masked]>
wrote:

> proceed

This approach sounds good as well, but I don't think it will make a
practical difference. It looks like this feature will ship one way or
another.

thanks,
Rob

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 19 Mar 2021 15:11:26 +0100

> I also oppose adoption because of what Petr Špaček and Tomáš Křížek said.

I also oppose adoption, for these reasons and many other reasons
already given in the thread by others.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 19 Mar 2021 06:52:52 -0700

"Martin Thomson" <[email-masked]> writes:

TL;DR: don't adopt

> I would question the value of publishing the experimental
> approximately-but-not-quite-O-HTTP version then.  Unless we fail
> majestically in chartering and executing there, we're not talking
> about significant delays.

It seems silly to me to write up a document that is decoupled from the
parallel O-HTTP work when it would be better off depending on the
results of that work.  Otherwise we'll have potentially two different
protocols that are subtly different enough to increase code complexity
in stacks trying to offer support for both.  I'm not sure where that
intersection will exist (browsers?), but I doubt it's zero
implementations.

IMHO, ODoH is a useful goal and protocol but should be a small document
describing the additions needed beyond the eventual O-HTTP.

If the current proposal does get adopted, I'd argue for experimental
being a much better track.  I strongly doubt, without evidence, that
this will be the final solution to this newly targeted problem.

------

(as proof that I'm not opposed to the technology proposed in general:
https://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/ from
2014)

-- 
Wes Hardaker                                     
USC/ISI

---

From: Rob Sayre <[email-masked]>
Date: Fri, 19 Mar 2021 16:59:16 -0700

On Fri, Mar 19, 2021 at 12:32 PM Wes Hardaker <[email-masked]> wrote:

> results of that work.

It seems like the authors of ODoH and O-HTTP could resolve this
discrepancy, but I do agree it is a little unclear. One author is on both
documents, after all.

If someone is going to ship ODoH before O-HTTP is done, and they should be
coalesced, then an Informational RFC seems good.

thanks,
Rob

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 30 Mar 2021 18:01:07 +0200

Not for Standards Track, in the current situation.

I think O-HTTP will be a better fit for the author's intentions, as I 
can't see significant DNS-specific stuff in the proposal. Moreover, if a 
similar DNS-specific protocol was being made, I'd question why it needs 
an HTTP layer (which is basically the familiar DoH vs. DoT argument).

--Vladimir @ knot-resolver.cz