Hiya, On 26/09/17 00:38, Adam Roach wrote: > On 9/25/17 6:16 PM, Stephen Farrell wrote: >> 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. > > It's not different; it's in addition to. The mechanism being described > would pass DNSSEC information through unscathed. Again, it's a nit, but I've not clue what "not different" in the above means. (Since DNSSEC is different:-) > >> >>> 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? > > It's pretty similar to DPRIVE (or, really, DNS in general). I see that > DPRIVE does have some text that seems to serve the purpose, so I'll copy > it over with minor tweaks like so: > >> The primary focus of this Working Group is to develop a mechanism that >> provides confidentiality and connectivity between DNS Clients and >> Iterative >> Resolvers. 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. > > I'm fine with that. I'll be interested to see if others are also. > > >> 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." > > What I'm seeing here is that the IETF isn't going to propose any changes > to the web security model. In most cases, I think this goes without > saying; but since you and Ted have both raised the issue, I suppose it > bears mention in the charter. I've tweaked your phrasing a bit: > >> The Working Group will analyze the security and privacy issues that could >> arise from accessing DNS over HTTPS. In particular, the Working Group >> will >> ensure that access to DNS information from a JavaScript context will >> not have >> adverse impact on the host operating system's DNS cache. The manner in >> which >> such analysis is performed will be decided by the working group. > I'd be just about ok with that. My problems with your rephrasing are: - I'm not sure the WG can "ensure" a lack of adverse impact, so why make it a requirement, if it's not possible? - Pollution of the OS's cache may not be the only bad thing that can happen, so that needs to be an example. - I'm fine that a WG decide how to document stuff, but saying they can decide the manner in which such analysis is performed seems to me like you could drive a giant cart and horses- galore through that loophole, and that phrasing seems to nearly invite that, and I've seen WGs do just that kind of thing. I'd like that you or some other AD could ask to be pointed at the analysis results and for those to at minimum need a WG-list thread, so saying "do the work, document it however you like" seems like a better plan to me. Cheers, S. > /a > >
Attachment:
signature.asc
Description: OpenPGP digital signature