A nit, a question and a comment: On 26/09/17 00:03, Ted Hardie wrote: > Adam, > > Thanks for summarizing the discussion and its outcomes. Looking at the > revised charter, I noticed that it currently says "The use of HTTPS and its > existing PKI provides integrity and confidentiality, and it also allows the > transport to interoperate with common HTTPS infrastructure and policy." Nit: Not sure if it's worth nothing, but the integrity service here is different from DNSSEC, and clients need to be cognizant of that. Probably obvious though. > The choice not to specify a particular version means that there may be more > than one transport. You may wish to rephrase this or elide it to reflect > the decision taken on that point. This para: " While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The Working Group will not engage in such preventative design. " ... strikes me as weird, given that it didn't say what is the "primary" use-case. I think that needs fixing or may cause confusion later. The question is: did I miss where you said what was the primary use-case? The comment: I find this version no better than the last in terms of saying that the WG needs to consider the scope within which DNS answers are used. And that was my major issue with the last iteration, so overall, this version doesn't seem that much better to me. My suggestion is to add text along these lines: "The WG will analyse the security and privacy issues that could arise from accessing DNS in this manner. For example it'd clearly be bad if JavaScript from random web sites could poison the OS's DNS cache (though hopefully no implementation would allow that). The manner in which that analysis is documented will be decided by the WG." Cheers, S. > > regards, > > Ted > > > > On Mon, Sep 25, 2017 at 3:56 PM, Adam Roach <adam@xxxxxxxxxxx> wrote: > >> Thanks to everyone who commented on the proposed charter for >> DNS-over-HTTPS. I have noted four main categories of discussion: >> >> >> 1. Whether to rule specific versions of HTTP in or out of scope of the >> charter. While the consensus here was rough, there were more proponents of >> leaving the version out than baking it in. I further observe that leaving >> version out of the charter does not preclude the WG from reaching consensus >> that requires or precludes certain versions from being used. >> >> 2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, >> but I find slightly more people in favor of allowing discovery than those >> opposed to its inclusion. I will be adding language to the charter proposal >> that allows such work if those parties interested in specifying such >> mechanisms show up in the working group. If no such critical mass shows up, >> the WG will be allowed to close without performing such specification. >> >> 3. Scope of work: whether DNS-over-HTTPS servers are accessed normal >> stub resolver libraries or via JavaScript. The proposed charter now >> contains text clarifying that the JavaScript use case is not the primary >> motivation, but that the WG will not take steps to preclude it. >> >> 4. Regarding the question of whether to perform the work at all (or >> whether to perform the work now): the analysis for starting a working group >> generally hinges on whether a viable group of willing and capable >> participants exists to complete such work, without regard to those who wish >> the work not to take place. While exceptions to this generality may >> certainly exist, I find no reason the proposed working group is special in >> this dimension. >> >> The revised version of the proposed charter can now be found at: >> >> https://datatracker.ietf.org/doc/charter-ietf-doh/ >> >> /a >> >> _______________________________________________ >> Doh mailing list >> Doh@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/doh >> >> >
Attachment:
signature.asc
Description: OpenPGP digital signature