W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2016

RE: WebAppSec WG Mid-Year F2F 05/16-17 Agenda (plain text)

From: <jeff.hodges@kingsmountain.com>
Date: Mon, 16 May 2016 08:27:48 -0600
Message-ID: <96482705d65bd2f4726dd59f24ae2a14.squirrel@box514.bluehost.com>
To: "W3C WebAppSec WG" <public-webappsec@w3.org>
In case other(s) might find this useful..

WebAppSec WG
Mid-Year F2F 05/16-17


Day 1: 16-May-2016 / 9:00 AM - 5:00 PM
Mozilla HQ, 331 E. Evelyn Ave Mountain View, CA

ATTENDEES
Dan Veditz, Mike West, Brad Hill, Francois Marier, Deian Stefan, Richard
Barnes, Emily Stark, Joel Weinberger, Devdatta Akhawe, Tanvi Vyas, Wendy
Seltzer, John Wilander, Frederik Braun, Arthur Janc, Jeff Hodges, Daniel
Bates, Chris Palmer, Raymes Khoury

Regrets


09:00 - 09:30 Welcome, introductions
09:30 - 10:30 CSP2 Feedback from Apple (Daniel Bates)
10:30 - 11:15 Secure Contexts and related

      * Spec status update (Mike West)

      * Synchronized Security State Between Tabs (John Wilander)

         * Currently, failed security checks (cert validity, mixed
content …) in one tab/window do not affect other tabs under the same
origin. However, a compromise of one tab can harm other tabs since
stateful mechanisms such as cookies and local storage are shared per
origin. We would like to discuss synchronized security state, for
instance removing padlocks for all open tabs under an origin if any tab
under that origin loses its padlock. This of course raises the question
"Has this origin ever lost its padlock?" and whether that should affect
security status and stateful mechanisms.

    * Disallow Mixed Trust for Extended Validation (John Wilander)

       * The rules for being granted the Extended Validation (EV) “green
bar” are fairly lax. You pay a CA, they check your identity, and then
browsers signal to users that this is trusted content. We would like to
discuss the issue of mixed trust where content is loaded from servers
with a variety of identities and certificates. EV rules could for
instance be restricted in three steps:

          * Start with console warnings of mixed trust and evangelize
the upcoming change in policy.
          * Deny EV treatment for mixed EV+non-EV content.
          * Deny EV treatment for mixed EV content. I.e. only display
the green bar if all content is EV and from the same organization.
          * This discussion needs to be synched with the CAB Forum down
the road.


11:15 - 12:00 CORS and private IP address ranges
(from Mike West, Crispin Cowan)
https://mikewest.github.io/cors-rfc1918/

Modifications to Fetch which are intended to mitigate the risks
associated with unintentional exposure of devices and servers on a
client’s internal network to the web at large.

12:00 - 13:00 Lunch

13:00 - 14:00 Guest speaker: Zach Tollman from Wired: Implementer report
on adopting HTTPS



14:00 - 15:45 Permissions in Context (3 major related topics)

    Permission Delegation to Iframes + CSP embedded enforcement (from
Chris Palmer and Raymes Khoury)

    * https://noncombatant.github.io/permission-delegation-api/
    *
https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit
    *
https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0041.html
    *
https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/thread.html#msg34
    * https://w3c.github.io/webappsec-csp/embedded/


Secure Context Components (from John Wilander)

    The Secure Contexts spec could become an effective way to allow
privileged execution in the browser. We’d like to discuss whether Secure
Contexts could have “components" so that privileged APIs could require
(named?) subsets of them. Specifically, we’d like to discuss the
following concepts as such components, in no particular order:

    * No mixed trust (across EV/non-EV/insecure context “same-origin”
frames/tabs)
    * Only subresources from associated domains as discussed above.
    * Signed web app as discussed above.
    * CSP in place without unsafe options.
    * Subresource Integrity for all applicable subresources.
    * Token binding in place
(https://tools.ietf.org/html/draft-ietf-tokbind-protocol-05).


Feature Policy
https://igrigorik.github.io/feature-policy/



15:45 - 17:00 Survey of current WebAppSec Portfolio (from Mike West and
Brad Hill)
    * What are the priorities of in-flight work?
    * What things have highest interest by user agent implementers? Are
there things unlikely to see interoperable implementations?
    * Do we have room for new areas of work?
    * What threat models are we targeting?
    * Signed Web Apps proposed work area by Apple
    * HSTS priming




AGENDA - Definite topics
    * Suborigins
    * Subresource Integrity
    * COWL


AGENDA - Potential topics
    * Report from Web Authentication WG
    * Referrer Policy
    * UI Security / VisibilityObserver




Day 2: 17-May-2016 / 9:00 AM - 5:00 PM / Mozilla HQ, Mountain View, CA

ATTENDEES
Dan Veditz, Mike West, Brad Hill, Francois Marier, Deian Stefan, Richard
Barnes, Emily Stark, Joel Weinberger, Devdatta Akhawe, Tanvi Vyas, Wendy
Seltzer, Frederik Braun, Jeff Hodges, John Wilander

Regrets


09:00 - 10:30


10:30 - 11:00 CSP 3 ‘unsafe-dynamic’ and ‘unsafe-hash-attributes’
proposals (Mike West)


11:00 - 12:00 Credential Management (Mike West) and report on the work
of the Web Authentication WG / FIDO (Jeff Hodges)


12:00 - 13:00 Lunch


13:30 - 14:30 WebAppSec and the IETF

    * Report on work in-flight at IETF today.  (Cookie policy by Mike West)

    * Proposals which are on the border between these organizations:

       * Restrict Accept, Content-Language, and Accept-Language (from
John Wilander)
          * Some standard request headers are currently not very
restricted in what characters they can contain, for instance Accept,
Content-Language, and Accept-Language. It varies between browsers but
those three have few restrictions. Looking at RFC 2616 (HTTP 1.1) and
the Header Field Definitions
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1) one
gets the impression that the named headers are validated by the browser
according to the grammar but they’re not.

          *    Supposedly, browser vendors settled years ago on the more
relaxed Ajax spec which refers to field-value production, specified in
RFC 2616, Section 4.2:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2. A general
web client that wants to be standards compliant will use the headers
spec to restrict its values and a defensive server will use the spec for
input validation. But browsers are not restricting these headers very
much (at least not the last time I checked).

          *    Since they are standard headers they can be set in
non-preflight CORS requests and potentially trigger bad behavior
server-side, including payloads for vulnerabilities like Shellshock.

          *    Some other working group might be the right place but we
wanted to start this discussion in WebAppSec.


       * Associated Domains (from John Wilander)  (Jeff Hodges can
discuss DBOUND work at IETF which is related)

          * The technical notion of cross-origin differs significantly
from the notion of ownership and control of domain names. A few examples
are {apple.com, icloud.com, filemaker.com}, {google.com, google.ru,
youtube.com, gmail.com}, {facebook.com, instagram.com, facebook.net},
{microsoft.com, xbox.com, microsoftstore.com} and {mozilla.com,
firefox.com}. Single sign-on, subresource integration, and user agent
tracking is arguably very different within one of these sets than across
them. If we could come up with a standardized way to state and validate
associated domains we could enforce better cross-origin policies.


14:30-17:00 Spec updates on SRI, Suborigins and COWL, AOB

    * SRI
       * Require-sri-for
       * Integrity for downloads
       * Cross-origin caching
       * Other v2 features?
       * Of note: https://martinthomson.github.io/http-mice/ (Merkle
Integrity Content Encoding)

    * Suborigins
       * Cookies

    * COWL
       * Welcome new editor Niklas Andréasson
       * ServiceWorkers and Push






end
Received on Monday, 16 May 2016 14:28:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC