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

added an item wrt webauthn to..
some comments on selected 'day 2' items...


> Day 1: 16-May-2016 / 9:00 AM - 5:00 PM
[...]
>
> Day 2: 17-May-2016 / 9:00 AM - 5:00 PM / Mozilla HQ, Mountain View, CA
>
[...]
>
> 09:00 - 10:30

[ held open for suggestions ? ]


> 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)

[ Add Wendy Seltzer along w/myself :)  ]


WebAuthn had a F2F last Fri 13-May in Berlin. Minutes are here..

[minutes] 13 May F2F (Wendy Seltzer)
https://lists.w3.org/Archives/Public/public-webauthn/2016May/0213.html

see also: Call for Consensus: Publish FPWD
https://lists.w3.org/Archives/Public/public-webauthn/2016May/0212.html


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


WRT the above "Restrict Accept, Content-Language..." item -- Julian Reschke
<julian.reschke@gmx.de> definitely needs to be involved, and the approp
working group may well be the IETF HTTPbis WG..

https://datatracker.ietf.org/wg/httpbis/documents/


also, all the refs above are to RFC2616, which has been superseded by RFCs
[7230..7237], where 7230 and 7231 are particularly relevant to the above..

  https://tools.ietf.org/html/rfc7230
  https://tools.ietf.org/html/rfc7231


>        * 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.

https://datatracker.ietf.org/wg/dbound/documents/
https://www.ietf.org/mailman/listinfo/dbound

dbound problem statement
https://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/

note that the above "associated domains" scenario from John W is arguably
noted in the latter dbound prob stmt doc thusly..

   Linking domains together for merging
   operations
      It is frequently the case that domain names are aliases for one
      another.  Sometimes this is because of an ongoing merger (as when
      one company takes over another and merges operations).  A client
      encountering such a site needs to answer the question, "Is domain
      X just another name for domain Y?"

that said, technical solution work is progressing slowly for various reasons
which we can discuss...






>
[...]
>
> end

Received on Monday, 16 May 2016 16:27:00 UTC