Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

Emily Stark <estark@google.com> Thu, 24 November 2016 16:12 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3683129554 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 08:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.997
X-Spam-Level:
X-Spam-Status: No, score=-7.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhBwo04L6BdB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 08:12:48 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A879B12989C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Nov 2016 08:12:48 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c9waG-00007q-Ri for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Nov 2016 16:09:12 +0000
Resent-Date: Thu, 24 Nov 2016 16:09:12 +0000
Resent-Message-Id: <E1c9waG-00007q-Ri@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <estark@google.com>) id 1c9wa9-00006s-Nk for ietf-http-wg@listhub.w3.org; Thu, 24 Nov 2016 16:09:05 +0000
Received: from mail-io0-f182.google.com ([209.85.223.182]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <estark@google.com>) id 1c9wa3-0001HW-CE for ietf-http-wg@w3.org; Thu, 24 Nov 2016 16:09:00 +0000
Received: by mail-io0-f182.google.com with SMTP id x94so85892683ioi.3 for <ietf-http-wg@w3.org>; Thu, 24 Nov 2016 08:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TpiR2MAU7g2WDi6z1w0MJXkNOmF562rFDVHJre/r3vU=; b=JjdHD0yhzlrSwqdXR7mmnbmcKovidOR0Kwt2ZA+V/wHtP/AxqdmotE30R1UqrGp37U ll78YTk8AEHBI85+nsZwCR7tz0H5pMQG2CG86knYsRUu1cDq+5s9ixylfffMIL0uwlBC GDi5k3by4plGanwNRdctmvIgYSTHXlP46rnjAOJYveiT+I2wzIL8QATZjvWiuMgU0Hqx +5W2zd+yT0W7LhB9R1EeVrlkC1X8h7p0wecIIC3vCxVlgkTHGrYbO4JTWUU26hyTvRKH rPbpSCEcM3Uc7PkFThDXB8yJLkvgfpEAe63qab6IugtsBioaoU203yWV/KXS1/9+p1Gr XT3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TpiR2MAU7g2WDi6z1w0MJXkNOmF562rFDVHJre/r3vU=; b=YNxOrNxPcuIXR8FFzm8B7UK0cMFULHWXizABs3/Vj2cRTrPXk8y0SAY2bDQ6H3RJOb W7cPHcI1aoaKubbGiHyGObmWRwl6jozXEO+L08xk8cLlwt2KDRVux9imyjqe+Ns68wD8 iTXBDKWIEfT6s2B8cKa1+Ftpy3NGehsFlgkXltDe1edMoZtA69W8KnHciPv0X20jK1AJ NRpqIvlpfZS9TF+wPIG/hKzmjOIzBSoSJIQVkZayRbhPKdShNMVxUKRQxMWk+QIR371C 01Y4gstPKI+iETiCvsDER1MGB+dZGgENz25EcUZsKOIQqN6WaZgw7t42kejEyUNbIeJW rIaw==
X-Gm-Message-State: AKaTC02mi/2XdgS5Hfv5es5U90u1gedrIXTgftP4gy9+vhjKgI8vkk8ho9zRQjQ79rFxehhdupmne3IIoZcp2h4O
X-Received: by 10.36.50.214 with SMTP id j205mr2812920ita.33.1480003713263; Thu, 24 Nov 2016 08:08:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.136.84 with HTTP; Thu, 24 Nov 2016 08:08:12 -0800 (PST)
In-Reply-To: <A030350C-F73A-402D-A3B6-28244F855015@mnot.net>
References: <147995400666.32746.15867339667353417986.idtracker@ietfa.amsl.com> <FCDFC352-5D68-456F-AFF4-39E9E1697AF2@mnot.net> <CAKXHy=d18Zy-khibw78iC5i=8iOu2v_M2VS_aKV2jOexp8=gBg@mail.gmail.com> <A030350C-F73A-402D-A3B6-28244F855015@mnot.net>
From: Emily Stark <estark@google.com>
Date: Thu, 24 Nov 2016 08:08:12 -0800
Message-ID: <CAPP_2SYJu2o7W8zWVd62-c9ekCfCUB6UQ=avNnM8R2NqhFhv2Q@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Mike West <mkwst@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a114aab8c98b19c05420e37a7
Received-SPF: pass client-ip=209.85.223.182; envelope-from=estark@google.com; helo=mail-io0-f182.google.com
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=1.473, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c9wa3-0001HW-CE 51a28891f0dd10f3c564ffee0c1040f1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt
Archived-At: <http://www.w3.org/mid/CAPP_2SYJu2o7W8zWVd62-c9ekCfCUB6UQ=avNnM8R2NqhFhv2Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32996
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Thu, Nov 24, 2016 at 2:10 AM, Mark Nottingham <mnot@mnot.net> wrote:

> One other thing --
>
> If we take an approach that doesn't allow fallback to headers for new
> features, it's going to be important to get broad buy-in from implementers.
> Otherwise, it'll raise the friction for those new features.
>
> For example, if Expect-CT were to adopt it, and browsers were now required
> to make an extra fetch to implement the spec, some might not like that, and
> resist implementing it.
>

A feature could always define its own fallback to headers, couldn't it?


>
> This has been the case when we've discussed similar approaches in the
> past; the extra fetch -- even when not on the critical path -- adds
> friction. If that's changed, it's great news -- but we should verify that.
>
> Cheers,
>
>
> > On 24 Nov. 2016, at 8:33 pm, Mike West <mkwst@google.com> wrote:
> >
> > On Thu, Nov 24, 2016 at 3:28 AM, Mark Nottingham <mnot@mnot.net> wrote:
> > FYI, updated draft.
> >
> > Prettier (and latest) version available at:
> >   https://mnot.github.io/I-D/site-wide-headers/
> >
> > Thanks for the update, Mark! It seems like we agree on broad strokes: a
> well-known resource defines a set of things for an origin. Clients can
> preemptively grab that resource, or a server can push it down. I'm
> confident in that model, and I expect we'll be able to work out the
> details. :)
> >
> > I talked to a number of folks about this in Seoul, and it seems like
> some potential implementers have a preference for a header-based approach,
> rather than creating a JSON data structure with semantics that diverge from
> headers.
> >
> > This is my gut feeling too, but it could be that they were agreeing with
> me because I was there. Another approach is suggested by Mike West here:
> >   https://wicg.github.io/origin-policy/
> >
> > The differences between our proposals seems to boil down to how we wish
> to model the "things" that are defined for an origin. The "site-wide
> headers" proposal runs with the status quo, HTTP-based approach of response
> headers that have origin-wide impact, and standardizes a mechanism of
> distinguishing those headers in the future. The "origin policy" proposal
> seems like a superset of that approach, allowing legacy headers to be
> pinned origin-wide, while also making room for policy definition in a
> non-resource-specific way. That seems like a better long-term model to me.
> >
> > Historically, response headers have been the most convenient way of
> establishing origin-wide policy, because they exist and developers can
> easily poke at them. It's easier to alter application code to send a new
> `Strict-Transport-Security` header rather than, for instance, altering an
> HTTP server to send new data as part of a TLS handshake. The mental model,
> however, is muddled at best, elevating any arbitrary resource to govern the
> entire origin.
> >
> > The site-wide headers proposal extends this pattern, envisioning a
> future where we have a few legacy site-wide headers with strange names, and
> more modern site-wide headers with a `site-` prefix. Any arbitrary response
> may still exercise control over the site, and each new feature must be
> modeled as a response header. I'd prefer to avoid both of these
> implications.
> >
> > In fact, I'd suggest that both of our proposals implicitly recognize
> this as folly, and choose instead to endow _only_ a particular resource
> with origin-wide authority. Neither proposal uses that resource's response
> headers to set the policy, but instead the resource's content. I think
> we're only talking about headers at all because of historical precedent,
> and I'd be pretty happy limiting origin-policy's header-based mechanism to
> something like the list in https://mnot.github.io/I-D/
> site-wide-headers/#rfc.section.1.1 (probably with some additions for
> headers whose ship has sailed, like Emily's `Referrer-Policy`).
> >
> > I'm happy with that legacy behavior for things like CSP, because
> `Content-Security-Policy` is quite explicitly a resource-specific header
> with resource-specific implications. Modeling it as part of a particular
> response (even if it's set on an origin-wide basis) seems reasonable: the
> developer is claiming "Each of the resources on this origin will have a
> policy something like this, but they might differ a bit." `Referrer-Policy`
> and `Access-Control-Allow-Origin` are similarly resource-specific. The
> origin policy proposal tries to recognize this by giving explicit
> "baseline" or "fallback" options for overrides (https://wicg.github.io/
> origin-policy/#dom-httpheader-type (regardless of the approach we take to
> headers, this bit seems critical to me)).
> >
> > I'd contrast that legacy behavior with something like the
> `cors-preflight` controls sketched out in https://wicg.github.io/origin-
> policy/#cors-preflight-member. Things like this don't make much sense to
> me as an HTTP response header for any particular resource, nor could they
> reasonably differ between resources. The origin's owner is making
> declarations about the way Fetch ought to work for the origin at large,
> independent of any particular response. I'd very much prefer not being
> forced to model it as a `site-cors-preflight: whatever` header. Likewise,
> I'd much prefer to suggest to Future Emily that she define a new
> `certificate-transparency` member in an origin's policy manifest rather
> than a new `Site-CT` header.
> >
> > -mike
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>