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 <stephen.farrell@xxxxxxxxx> 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
>