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

[Paul Hoffman <[e-mail]>]

On Mar 18, 2021, at 9:03 AM, Tommy Pauly <[e-mail]> wrote:
> 
> 
> 
>> On Mar 18, 2021, at 8:41 AM, Paul Hoffman <[e-mail]> wrote:
>> 
>> On Mar 17, 2021, at 7:37 PM, Tommy Pauly <tpauly=[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> Great, but:
>> 
>>> 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.
>> 
>> 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. 
> 
> 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.

"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 way of formatting all the HTTP messages.

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, yes, if OHTTP becomes ubiquitous and deployment models are worked out, but that will take time even if OHTTP formatting is defined soon.

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