Re: [Doh] WG Review: DNS Over HTTPS (doh)

[Patrick McManus <[e-mail]>]

Hi All. I'll respond to most of the key points in one message. Forgive the
consolidation.

* This is meant to be over "https" full stop. Whether that means we require
a particular minimum level of version (which the input draft defines as >=
h2 not == h2 btw) to satisfy the uses at hand is a controversy suitable for
the wg to resolve.

On one hand we should consider that semantic http has no versioning, so
using the semantics from something like javascript becomes impossible to
enforce the versioning requirement (though the server could do so). otoh
you could argue that the mechanisms of <=h1 are not technically up to the
task (hol blocking, lack of priority, etc..) of providing a reasonable
implementation for a recursive resolver like use case.. or even argue that
the IETF would have been better off historically across the board using new
functionality as a forcing function for migrating to newer specifications
rather than putting such a premium on backwards compatibility (or arguing
against that based on bootstrapping costs, etc..). As I said - that's a
controversy for the wg. The charter should be over https, and the wg can
decide exactly what that means there is no need to litigate it in a charter
discussion.

* I believe adam and mnot are right on the questions of same origin, js,
https:// uris..

* I think its fine for the charter to say the group must document the
security considerations of the source of a name resolution.

-P


On Fri, Sep 15, 2017 at 3:33 PM, Stephen Farrell <[e-mail]>
wrote:

>
>
> On 15/09/17 23:04, Paul Hoffman wrote:
> > On 15 Sep 2017, at 14:44, Stephen Farrell wrote:
> >
> >> On 15/09/17 20:25, Ted Hardie wrote:
> >>>
> >>> This set of questions is pretty different from the ones you get
> >>> with "function over different paths", because the locus of
> >>> control moves from the mostly-trusted browser to the mostly not
> >>> trusted downloaded application.
> >>
> >> FWIW, I share Ted's concerns about origins. Regardless of what
> >> approaches are taken, the effects of this need to be well
> >> understood I think. I don't object to the WG being chartered though
> >> but would suggest that there be a mention in the charter that the
> >> WG needs to document the consequences, including the dangers, of
> >> caching and re-use of DNS answers for likely implementations.
> >
> > The charter already points to the document that the work will be
> > based on, which has that topic in it, because *you* pointed it out in
> > the earlier discussion of the document. As co-author on the document,
> > I assure you we will not remove it, if for no other reason than I
> > wouldn't want to face your wrath again in IETF Last Call. :-)
>
> "Wrath" has to count a pretty speedy escalation in terms,
> and especially when I'm so shy and retiring about saying
> what I think:-)
>
> I'm also confident that that security considerations will
> cover this topic in some sense. I'm not confident that I
> understand the relevant consequences at this point in
> time, so ISTM useful to mention it in the charter as that
> might help later.
>
> >
> >> I'd be even happier if the resulting spec had a bunch of MUST NOT
> >> statements about that, if such statements were likely to be
> >> effective.
> >
> > All MUST NOTs are only partially effective, but we use them anyway
> > to help good implementers.
>
> Agreed. And sometimes we use them to describe damaging
> things bad implementers might otherwise be likely to do
> without realising the downsides.
>
> > If you have some proposed MUST NOTs on
> > the current document, by all means send them in.
>
> Probably better in a different thread, but I think there
> is scope for a MUST NOT (re-)use answers outside the same
> origin, but I've no doubt there are subtleties there that
> the WG would need to figure out and that'd make this
> sentence a bad idea to include on it's own.
>
> S.
>
> >
> > --Paul Hoffman
> >
>
>