WebAppSec Teleconference, 23-Feb-2015

23 Feb 2015


See also: IRC log


+1.206.348.aaaa, bhill2, +1.206.876.aabb, mkwst, +1.418.907.aacc, francois, +1.503.712.aadd, terri, +1.831.246.aaee, dveditz, Wendy, +1.646.821.aaff, deian, +1.415.736.aagg, +1.310.597.aahh, jww, tanvi, gmaone, crispin_microsoft, drx, freddyb, +1.415.857.aaii, devd, [IPcaller]
Dan Veditz, Brad Hill
Brad Hill


rrsagent make minutes

<scribe> Scribe: Brad Hill

<scribe> scribenick: bhill2

<tanvi> mkwst: ping. can http pages set upgrade-insecure-requests? if so, then making it part of mixed makes less sense

<mkwst> tanvi: Yes, as currently specced.

<mkwst> which is why it's called `upgrade-insecure-requests`, and not `upgrade-mixed-content`.

<tanvi> mkwst: was there a resolution on whether it should be part of mixed or a separate spec?

<mkwst> tanvi: Welcome to the call on which I expect people to give their opinion about topics like that one!


<mkwst> tanvi: Because no one uses the list anymore! :)

<tanvi> mkwst: okay great

<tanvi> i'm dialing in in a minute

who's on from Microsoft?

Minutes Approval

(thanks, Dan!)

<dveditz> http://www.w3.org/2011/webappsec/draft-minutes/2015-02-09-webappsec-minutes.html

dveditz: Any objections to unanimous consent to approve minutes?
... hearing no objections, minutes adopted unanimously

Agenda Bashing

no agenda bashing

Rechartering & Mozilla's formal objection

dveditz: webappsec chairs and wendy had a call with the TAG on the Powerful Features draft regarding Mozilla's objection
... not all people from Mozilla were on the call, unfortunately
... the TAG is interested in the concept behind the document
... they have deferred to this WG to come up with a formal definition as opposed to a TAG finding
... would like to see that happen
... Powerful Features has 2 parts : defining what a sufficiently secure context is, and recommendations on how to tell if you are a powerful feature that should restrict itself to a secure context
... the algorithm on secure context determiniation is non-conteroversial
... the objection is to whether there should be a description at all of how to make the determination whether a feature should be secure-only

<mkwst> bhill2: Conclusion was the TAG was willing to take on the document as a joint deliverable

bhill2: where we came to, was TAG was willing to take this on as a joint deliverable
... with idea that description of when to apply would be non-normative

<mkwst> tanvi: the airport behind Brad. :)

<dveditz> tanvi: it's brad, I'm leading because he's in a noisy place

<tanvi> ah okay

bhill2: and that controversy about application of the algorithm to a feature would be resolved by the TAG
... as the elected body representing the W3C Membership

dveditz: other parts of the objection I think have been resolved
... async decision process
... COWL spec description
... concerns whether it is implementable, but not an objection to spec or concept
... if it can't be implemented, it won't move to Rec anyway
... EPR and compatibility with linking
... should be fine so long as final spec respects user wishes

drx: have heard this feedback, people are passionate about it
... no immediate solution but we need to take into account as we develop the spec
... and will be working on it

<JeffH> drx = ?

drx is David Ross (google)

<drx> yes

crispin: about my "privileged" name suggestion...

dveditz: powerful is a poor choice, we should think of a better word

<dveditz> bhill2: we have at least 2 people at Mozilla who object to include more than a few minor examples in the spec

<dveditz> ... and members of the TAG who want a more thorough fleshing out of why features should only be in a secure context

<dveditz> ... don't think we're going to divide the baby any further

<dveditz> ... this group needs to decide whether we have addressed Mozilla's objection as far as we want to and move forward to presenting the response to the director

<dveditz> ... or if we want to change the scope of the spec now

<dveditz> ... I'd like to resolve this now

<dveditz> mkwst: I'd like to move, unsurprisingly, that we continue.

<dveditz> ... the section strongly objected to is no longer normative

<dveditz> ... and I think we can come up with language people are happy with

<dveditz> bhill2: would love to hear from a few other people on the record. thx mike

<dveditz> ... with my hat as an individual I'd like to 2nd mike's point

bhill2: hat=individual, second mike's opinion

<dveditz> wseltzer: with my w3 team contact hat on we can go back to mozilla and ask if these changes satisfy their objection

<dveditz> ... and if they don't remove their objection we can bring it up for consideration by the director that this proceed notwithstanding their objection

+1, yes Mozilla has been helpful and reasonable, just a difference of opinion

<dveditz> ... I'd like to add publicly that Mozilla has been helpful in allowing the objection to be discussed openly, I don't think they are being obstructionist

dveditz: this is a helpful way forward, we have differing points of view whithin mozilla
... so would be good to go back to David Baron, our AC rep to get a formal response and remove any sections of the objection that have been resolved
... and get a reduced objection at least, or possibly remove it entirely

<wseltzer> ACTION: Wseltzer to ask Mozilla AC rep about the current status of their charter objections [recorded in http://www.w3.org/2015/02/23-webappsec-minutes.html#action01]

<trackbot> Created ACTION-214 - Ask mozilla ac rep about the current status of their charter objections [on Wendy Seltzer - due 2015-03-02].

dveditz: please poke David on that

wseltzer: I will do that

I'm not aware of other open charter issues

FWPD of CSP Pinning


mkwst: CSP Pinning spec is application of pinning concept to CSP
... a certain policy should apply to every page on a host + subhosts
... some people are interested, some people are not and don't think it's a good use of group's time
... no real feedback, can take that as positive. Is there consensus that this is enough?

<wseltzer> +1 I think it's useful

+1, I will also respond on list

<JeffH> you mean essentially an "includeSubDomains" directive for CSP ?

<mkwst> jeffh: https://w3c.github.io/webappsec/specs/csp-pinning/

mkwst: includeSubDomains is one part of the proposal

<JeffH> ok, I'll try to review it

<mkwst> jeffh: I'd appreciate it!

dveditz: no objections, resolved to publish FPWD

FPWD of Upgrade Insecure Resources


+1 strongly support!

mkwst: Brian Smith thinks this should be part of Mixed Content spec, which explains the problem domain
... I (mkwst) think that it is complex enough to be best served in its own document

devd: is disagreement about whether it should be its own spec?

mkwst: haven't seen any disagreement on concept

dveditz: I have elsewhere

devd: only automatically, or is there disagreement when there is explicit opt-in via header?

<JeffH> Also, i have feedback on w3c.github.io/webappsec/specs/mixedcontent/ to write up -- just editorial at this time

devd: don't think it matters where the spec should be, we should defer to the editor's preference

<mkwst> jeffh: that'd be great!

terri: in working with implementers, it is easier to give them one spec than several

<JeffH> this "multiple specs vs a single spec" is very common one in the spec-writing world.

mkwst: would be helpful to have an explainer document for all the specs this group has produced

<JeffH> "explainer doc" == "road map"

mkwst: think it would be more useful than trying to combine everything

terri: I agree this would be useful

jeffh: often referred to as a road map document

I think the most important gate for a FPWD is that people want to move ahead with the concept (for IPR sake) and we can combine later if we need

but no need to delay for now

dveditz: that amounts to consensus to publish, then

Mixed Content to CR


deveditz: any issues open if we don't merge upgrade?

mkwst: one open issue is TimBL's point, but I consider it closed as he has not responded, but may come up in transition process
... 2nd question is what to do with fetch
... see rsleevi's recent thread on a new fetch mode for media that bypasses mixed content checking
... starting with a way to lock everything down is the right way to start

dveditz: any objections to publishing CR of Mixed Content?

<mkwst> (CR, not CR)

<mkwst> (We've been through last call)

dveditz: hearing no objections, resolved to publish Mixed Content as Candidate Recommendation


<JeffH> wseltzer: have a ptr to the "new process" ?

<wseltzer> JeffH, http://www.w3.org/2014/Process-20140801/

<JeffH> thjx

Fail open or closed on unknown algorithms

dveditz: do we have right people on call?

<francois> francois is here too

bhill2: failing closed catches algorithm typos, etc.
... failing open allows new algorithms to be deployed before long tail of browsers that don't understand them go away completely

devd: SRI isn't protecting against typos, failing open is important for forward compat

<JeffH> actually, in reviewing various sources, the terms "fail open" and "fail closed" are used ambiguously and inconsistently, so need to be applied/used in a clearly-defined context

bhill2: we do support multiple algorithms?

devd: at scale, long tail is horrible...

<francois> i think the biggest issue is what do we do on an old SRI-enabled browser that encounters a "sha3-..." integrity attribute?

<JeffH> in an electrical circuit context, fail open means that current doesn't flow.

jww: need to inform developers that their hash is not good, not sure spec is right place to do it

dveditz: don't want to say that spec should never fail closed

devd: if agree it is an informing a developer issue, not a security issue, spec shouldn't say how to inform devleoper

<dveditz> Zakim: who is in the speaker queue

francois: other case is if we fail closed we could get into a situation where a browser supports SRI but is older and it encounters an integrity attrib it doesn't know about
... a really old browser that doesn't support SRI would work, but an old impl of SRI would fail

<freddyb> I lean towards agreeing with francois

sounds like everyone agrees on fail open, I'll withdraw my typo-related taking of the opposite side

<freddyb> we should encourage security imporvements (e.g. someone moving to SHA-3,4,5,.. :)), which fail-close may not.

<francois> just to be explicit, by "failing open" we mean "not blocking the load"

<freddyb> +1

<JeffH> "fail open" as being used in the context of SRI means, it seems, that the integrity check of the subresource in question is not successful ?

<freddyb> Content-type discussion was @ https://github.com/w3c/webappsec/issues/176

<JeffH> looks like francois and I have different understandings wrt "fail open" ?

<jww> We're specifically discussing "fail open" in the case that a hash algorithm is unknown/considered insecure

<jww> (not that the has value is incorrect)

<dveditz> JeffH: what jww said, we're only talking about unknown (typo'd) algorithms. the author has said "ensure this hash" and the browser doesn't know how

Support content-type indication in SRI or not?

<freddyb> github issue about the content-type discussion is at https://github.com/w3c/webappsec/issues/176

bhill2: could we pass an argument to fetch to say treat as if no-sniff, even if server doesn't send

<dveditz> not talking about cases where the browser knows how, the rest of the spec is clear on that

but say the server says "this is a gif" but doesn't set no-sniff, you should treat it only as a gif, never a jar

I'm ok with leaving this out for v1

devd: fine with allowing it to be specified, but don't want to make it mandatory

francois: currently if you specify a content-type as part of the attribute it will be enforced, if you don't include one then only the hash will be enforced and there will be a devtools warning

dveditz: thought we're not using ni:// url form

francois: correct, there is another way to specify content-type in the new syntax

<JeffH> dveditz: thx

mkwst: deciding the grammar now is important to keep option to move towards cache semantics later

devditz: anyone think we should take it out, even if not mandatory?

I don't object to making it optional

right on time!

I need to get on a plane, thanks, Dan!

wendy - can you handle the end-of-meeting zakim / rrsagent stuff?

<wseltzer> trackbot, end teleconf

Summary of Action Items

[NEW] ACTION: Wseltzer to ask Mozilla AC rep about the current status of their charter objections [recorded in http://www.w3.org/2015/02/23-webappsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2017/02/15 22:32:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Brad Hill
Found ScribeNick: bhill2

WARNING: Replacing list of attendees.
Old list: +1.503.712.aaaa
New list: +1.206.348.aaaa bhill2 +1.206.876.aabb mkwst +1.418.907.aacc francois +1.503.712.aadd terri +1.831.246.aaee dveditz Wendy +1.646.821.aaff deian +1.415.736.aagg +1.310.597.aahh jww tanvi gmaone crispin_microsoft drx freddyb +1.415.857.aaii devd [IPcaller]

Default Present: +1.206.348.aaaa, bhill2, +1.206.876.aabb, mkwst, +1.418.907.aacc, francois, +1.503.712.aadd, terri, +1.831.246.aaee, dveditz, Wendy, +1.646.821.aaff, deian, +1.415.736.aagg, +1.310.597.aahh, jww, tanvi, gmaone, crispin_microsoft, drx, freddyb, +1.415.857.aaii, devd, [IPcaller]
Present: +1.206.348.aaaa bhill2 +1.206.876.aabb mkwst +1.418.907.aacc francois +1.503.712.aadd terri +1.831.246.aaee dveditz Wendy +1.646.821.aaff deian +1.415.736.aagg +1.310.597.aahh jww tanvi gmaone crispin_microsoft drx freddyb +1.415.857.aaii devd [IPcaller]
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0403.html
Got date from IRC log name: 23 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/23-webappsec-minutes.html
People with action items: wseltzer

[End of scribe.perl diagnostic output]