On Mar 18, 2021, at 9:03 AM, Tommy Pauly <[email protected]> wrote: > > > >> On Mar 18, 2021, at 8:41 AM, Paul Hoffman <[email protected]> wrote: >> >> On Mar 17, 2021, at 7:37 PM, Tommy Pauly <[email protected]> >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
