IETF
websec@jabber.ietf.org
Thursday, 8 November 2012< ^ >
stpeter has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf84streaming.dnsalias.net/ietf/ietf842.m3u
Room Configuration

GMT+0
[22:22:33] hillbrad joins the room
[22:26:00] cyrusdaboo joins the room
[22:33:00] =JeffH joins the room
[22:33:45] joseph.yee joins the room
[22:34:04] xiaohong.deng joins the room
[22:34:09] <cyrusdaboo> Cyrus (me) scribing
[22:34:17] <cyrusdaboo> Just starting the meeting.
[22:34:52] <cyrusdaboo> Note Well....
[22:35:17] yoav.nir joins the room
[22:35:53] Ken Murchison joins the room
[22:36:01] <cyrusdaboo> Slide 3: Agenda
[22:36:35] <cyrusdaboo> Slide 4: Doc Status
[22:37:25] Barry Leiba joins the room
[22:38:11] <cyrusdaboo> MIME-Sniffing: no objections from the room to drop the draft in favor of WHAT-WG doing the work.
[22:38:33] Barry Leiba has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf85streaming.dnsalias.net/ietf/ietf852.m3u
[22:40:02] <cyrusdaboo> MIME-Sniffing: W3C had a reference to it, but now points to WHAT-WG so no issue with WG dropping it.
[22:40:34] <cyrusdaboo> Next: Jeff's presentation: security framework
[22:41:22] <cyrusdaboo> Slide 2: Status
[22:42:08] <cyrusdaboo> Slide 3: Relevance example
[22:42:55] <cyrusdaboo> Slide 4: Questions...
[22:44:18] <cyrusdaboo> Slide 5: Further impetus
[22:44:58] <cyrusdaboo> Slide 6: Requirements for....
[22:45:53] EKR joins the room
[22:45:58] <cyrusdaboo> Slide 7: Underway...
[22:46:24] <cyrusdaboo> Jeff will get new draft out soon. Wants review and feedback from the WG.
[22:46:31] EKR leaves the room
[22:47:18] <cyrusdaboo> Q: should this be WG document or independent?
[22:47:30] <cyrusdaboo> Jeff: thinks WG would be good.
[22:47:50] <cyrusdaboo> Paul: how will we know when it is done?
[22:48:07] <cyrusdaboo> Reviews will tell us.
[22:48:30] <cyrusdaboo> Jeff: does not need perfection.
[22:49:05] <cyrusdaboo> Brian: policy conveyance needs to be decided before other specs can complete. Can it be split out?
[22:50:10] <cyrusdaboo> Jeff: other docs are pretty much a done deal. Want to document possible alternatives.
[22:50:46] <cyrusdaboo> Q: read the draft frameworks? 5 hands
[22:50:54] <cyrusdaboo> Q: Who will review? 4 hands
[22:51:36] <cyrusdaboo> Ryan's presentation: Pub Key Pinning
[22:52:14] <cyrusdaboo> Slide: changes...
[22:52:37] <cyrusdaboo> Slide: open issues: #53
[22:54:28] <cyrusdaboo> Chrome has opted to disable pinning for a number of reasons.
[22:55:56] <cyrusdaboo> Various security tradeoffs impact this - discussion on the list - WG please review.
[22:56:27] <cyrusdaboo> Paul: do another draft please with proposed text.
[22:56:51] <cyrusdaboo> Ryan: expect a new draft...
[22:57:31] <cyrusdaboo> Brad: pinning used to defend against the CA compromise case. Need to make it clear when it applies to a particular threat model.
[22:58:11] <cyrusdaboo> Yoav: should there be a no-override option on the server?
[22:58:45] <cyrusdaboo> Slide: issue #54
[22:59:48] <cyrusdaboo> Want opinions on reporting now - or wait for next draft with proposed solutions.
[22:59:53] <cyrusdaboo> Slide issue #55
[23:00:29] <cyrusdaboo> Slide: future...
[23:00:45] m&m joins the room
[23:01:19] <cyrusdaboo> Interaction with DANE, TLS proposals?
[23:02:11] <cyrusdaboo> Also issue #56: reintroduce with directive for pinning.
[23:02:26] <cyrusdaboo> Q: when will next version be ready?
[23:02:34] <cyrusdaboo> A: within the next few weeks or sooner.
[23:03:48] <cyrusdaboo> Paul: request - don't address future consideration points in the next draft but leave a hole for it so people can think about it in the meantime.
[23:04:00] <=JeffH> thx for scribing Cyrus :)
[23:04:06] <cyrusdaboo> Might affect certtrans...
[23:04:28] <cyrusdaboo> Bryan: what about overlapping interaction between this and HSTS?
[23:05:19] <cyrusdaboo> Wants uniformity in how this is addressed.
[23:05:28] <cyrusdaboo> Paul: is that documented?
[23:06:01] <cyrusdaboo> Bryan: accumulating notes and will pass on info.
[23:06:23] <cyrusdaboo> Yoav: should go in security considerations of this doc.
[23:06:38] <cyrusdaboo> Paul: not in security considerations - should be in protocol.
[23:08:39] <cyrusdaboo> Frame options futures...
[23:14:09] <cyrusdaboo> Tobias' slides:
[23:14:27] <cyrusdaboo> Slide: 2 intro
[23:14:49] <cyrusdaboo> Slide 3: Frame-options
[23:15:05] <cyrusdaboo> Slide 4: Reasons....
[23:15:39] <cyrusdaboo> Slide 5: But...
[23:17:12] <cyrusdaboo> Slide 6: Why keep it in websec?
[23:17:36] xiaohong.deng leaves the room
[23:17:49] <cyrusdaboo> Slide 7: Options....
[23:18:01] Ryan Sleevi joins the room
[23:18:26] m&m leaves the room: Disconnected: connection closed
[23:18:38] <cyrusdaboo> 3 options listed.
[23:18:46] <cyrusdaboo> Discussions:
[23:19:45] <cyrusdaboo> Brad: design decision of one origin not settled. Needs to be discussed in both forums.
[23:20:08] <cyrusdaboo> Only very little use of Allow-From right now.
[23:21:11] <cyrusdaboo> Caching a non-issue for CSP.
[23:21:28] <cyrusdaboo> Barry: if it moves, will people here pay attention to what happens in W3C?
[23:22:24] <cyrusdaboo> Brad: invitations have been sent to editors to participate, also email sent to this WG when docs go to final review. Many people on both lists.
[23:22:53] <cyrusdaboo> Barry: will we go there?
[23:23:21] <cyrusdaboo> Tobias: yes and may participate as editor (... apparently already approved ...)
[23:24:37] <cyrusdaboo> Paul: problem with base argument that they will do the wrong thing so we don't want to send it over there?
[23:25:41] <cyrusdaboo> Tobias: not the basis. Is there benefit and synergy in making the move?
[23:26:29] <cyrusdaboo> Paul: still think moving it is trivial on either side. W3C has a strong desire - they would do adequate job.
[23:26:35] Barry Leiba leaves the room
[23:26:57] <cyrusdaboo> ekr: wants the logic in one place which webappsec is doing.
[23:27:37] im joins the room
[23:27:46] <cyrusdaboo> Brad: lion share of the work is happening and it must be kept simple with one mechanism.
[23:28:31] <cyrusdaboo> Bryan: agree with ekr and Brad - fits better with group doing CSP. Concern about dynamic generation of Allow-From - what would Vary header look like?
[23:29:01] <cyrusdaboo> (cyrus: not sure that was "vary")
[23:29:34] <cyrusdaboo> Need some sort of request header to Vary on.
[23:30:20] <cyrusdaboo> Tobias: dynamic generation just for this bit is not worth it if it forces other to go the same way.
[23:31:24] <cyrusdaboo> Brad: possible to combine these - no barriers in CSP to this.
[23:31:49] <cyrusdaboo> Chair poll: should the document stay in WG or move to W3C?
[23:32:31] <yoav.nir> Leave in IETF: 1
[23:32:40] <cyrusdaboo> Do in IETF? 1 hand
[23:32:46] <yoav.nir> Move to W3C: ~10
[23:32:48] <cyrusdaboo> In W3C? At least 10
[23:33:23] <cyrusdaboo> Barry: Any objections to moving it to W3C?
[23:33:26] <yoav.nir> Objections to moving: zero
[23:33:28] <cyrusdaboo> A: None
[23:33:39] <cyrusdaboo> Will verify on mailing list
[23:33:42] joseph.yee leaves the room
[23:34:14] <cyrusdaboo> Jeff: Mark, Thomas want a message from WG chairs about this.
[23:34:26] <cyrusdaboo> Alexey will be stepping down as co-chair.
[23:34:34] =JeffH leaves the room: Logged out
[23:34:45] <cyrusdaboo> Barry: chairs send me updated milestones!!!
[23:34:52] <cyrusdaboo> Meeting over....
[23:34:56] Ken Murchison leaves the room
[23:34:57] Ryan Sleevi leaves the room
[23:37:51] yoav.nir leaves the room
[23:39:11] joseph.yee joins the room
[23:39:53] hillbrad leaves the room
[23:49:39] cyrusdaboo leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!