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.
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.
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.
/a