Web Security Interest Group -- 31 Mar 2014

<wseltzer> trackbot, prepare teleconf

<trackbot> Sorry, but no Tracker is associated with this channel.

<terri> aaaa is me

<christine> Hi. Would someone please send me the passcode for the conference bridge. I tried the code that Virigine provided but the bridge is telling me it is not valid.

<wseltzer> Date: March 31, 2014

<christine> Thanks

agenda to begin at 10 past the hour (3 minutes)

<virginie> note : while we wait the last participants, you can make sure you are aware of the Web Security IG wiki here : http://www.w3.org/Security/wiki/IG

<scribe> scribenick: npdoty

virginie: welcome; we don’t always meet regularly, but good to get together and share news

any other agenda items?

- Debrief of STRINT workshop

hannes, can you help us with the workshop debrief?

<virginie> strint : https://www.w3.org/2014/strint/

HannesTschofenig: just before the IETF London meeting

… talked about the communications security tools at our disposable, and why they don’t work that well

… in some cases, have fairly good standards, but problems during implementation/deployment

… talked about policy: the boundary between legal regime and the technology, a difficult discussion because of a complicated topic

… potential policy problems ahead, should be aware of them

… discussed “opportunistic encryption” (correct terminology tbd)

… Steven Kent wrote up an I-D afterwards

… discussion on metadata and deployment aspects

… don’t have a good sense of fingerprinting and what is possible or mitigations possible

… reach out to researchers, who may volunteer to look at some of our protocols

<virginie> note : a post on opportunistic encryption by Mark Nothingham http://www.mnot.net/blog/2014/03/17/trying_out_tls_for_http_urls

… debate about middleboxes, vendors see advantages in their services

… issues of intercepting communications, in order to prevent exfiltration, for example

… XMPP community is doing experiments with e2e security concepts

… breakout sessions for research questions (slides to be shared)

… currently working on the workshop report, to be released in the next week or so

… have to figure out what we can realistically accomplish in each area

virginie: minutes available, but look forward to the report/action plan

… may have some actions that end up in the W3C scope

… any questions for hannes?

<HannesTschofenig> Here is the link to the STRINT website that contains informatoin about the sessions: https://www.w3.org/2014/strint/agenda.html

Security review and guideline

<jeffh> oh, ok thx brad

virginie: no current progress, no volunteers for reviewing

<jeffh> btw, if one joins the irc chat after calling in, doesn't see the metadata wrt their dialing in

virginie: if anyone would like to look over the WebCrypto spec, which is at Last Call, good time to make comments

<virginie> web crypto API is in last call here : https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

<HannesTschofenig> Btw, here is the document I mentioned about the threat taxonomy: http://tools.ietf.org/html/draft-barnes-pervasive-problem-00

virginie: also has been discussion about security review of the EME specification

HannesTschofenig: IETF security directorate reviews all the documents before published, and encourages earlier reviews
... a lot of reviews because there are so many documents
... the most critical part is that there is a governance model: someone makes sure that reviews happen
... specification authors have incentive to actually address the comments, because of documents that require a certain level of security
... based on pervasive monitoring, working on another document
... IESG enforces these requirements

virginie: farrell explained the IETF Security Area during our last meeting; would like W3C to be in a similar situation
... at the moment, it's true that there's no requirement

<HannesTschofenig> Here is the link to the document from Steven Kent: http://tools.ietf.org/html/draft-kent-pervasive-encryption-00

npdoty: better if we have resources/expertise already when we introduce such a requirement
... like the empty security considerations sections when that req was first introduced

HannesTschofenig: more about the lack of knowledge and guidance
... a chicken-and-egg problem, people may not dedicate the resources if they're not sure the output of their work

[npdoty, not scribe]: absolutely; I'm hoping we can do better on providing the knowledge and guidance

virginie: Privacy Interest Group have been working on providing guidance on privacy
... have been thinking about simple guidelines, list of basic things, when designing an API, that can be given to chairs and editors
... think about the bad scenarios
... indicate a note in your API where permissions may be necessary, etc.
... very simple rules that will eventually be elaborated

<jeffh> see also: http://wiki.tools.ietf.org/html/rfc6973 Privacy Considerations for Internet Protocols

virginie: share the basic reflex of someone who works in security
... something we could conduct with the Privacy Interest Group, in contact with the chairs
... start a wiki page with a simple list; security guidelines for chairs and editors

HannesTschofenig: makes sense. have we written this down yet?

virginie: can start with pointers to the IETF documents; haven't shared anything written yet
... start a wiki page after this call, send link
... see how collectively we can advise chairs / editors
... one idea: try to identify one Security Champion in every Working Group
... someone with an interest and skills in security, already in the Working Group, feels responsibility but without obligation

christine: very common for there to be a Security Considerations section in W3C specs; some groups have done a very good job in documentation and mitigation

<virginie> +1

christine: as part of this exercise, good to look at what's already out there

<jeffh> https://tools.ietf.org/html/rfc3552 Guidelines for Writing RFC Text on Security Considerations

Understanding security technology : focus on FIDO

<hillbrad> http://fidoalliance.org/

<jeffh> npdoty: see also RFC6973 (pointed to above)

hillbrad: FIDO Alliance, a group of companies working on specifications, so we can have stronger alternatives to passwords to log in to websites
... up to 100 companies now; there is a fee and IPR requirement, similar to W3C
... goal is to create unencumbered specifications, to be turned over to standards organizations for long-term maintainance (like W3C, OASIS, IETF, etc.)
... password breaches are so common
... take advantage of the momentum against passwords simultaneously with proliferation of devices with good cryptographic technologies, key management
... and a scenario for unlocking your local device
... connect those together to build a replacement for username and password
... less about durable identity, just authentication
... stayed away with traditional identity assertions, want to target for the broadest possible Web use cases
... and so want to have privacy guarantees about trackability

<hillbrad> http://fidoalliance.org/specifications

hillbrad: draft specifications are available for download
... families: U2F; UAF
... both public key, cryptographic challenge/response protocol: universal two-factor just makes passwords stronger
... use simpler passwords, but with stronger securities
... a very simple hardware device, prove your presence with a button
... a Web site can see that you have a U2F-compatible browser/device
... the device generates a brand new keypair for that origin/site, completes challenge/response -- site stores a key handle
... the next time you come back to that site, you type in username/password, site sends the key handle back to you/your device
... your device unwraps it with your presence, and can respond to it
... at a different website, you get a different key

fjh: what if you lose your device?

hillbrad: if you lose your device, secrets are gone. devices are intended to be cheap
... doesn't specify account recovery flows, which will vary dramatically by implementation
... for some throwaway accounts, don't need account recovery at all
... banks or social networks might have very different ways for recovery
... revocation is also relying-party-specific
... if somone finds your device lying on the street, they don't also know your username and password
... though the relying party would have to delete all of them, not just yours

npdoty: how do you get a guarantee that it's a real second device, couldn't your browser just do it?

hillbrad: yes, you could build an extension that does it all
... an attestation at the time that you create the key

<jeffh> wrt the question "can't all this be done in software?" -- see, eg, https://hoba.ie/

hillbrad: from a certificate widely shared by device manufacturers
... software-only would be a self-signed assertion, some sites may be willing to accept that as well
... working on privacy-friendly ways to do better attestation
... simple certificate shared across 100,000 devices, so it doesn't create a super cookie
... UAF, expansion of modalities of authentication -- an experience completely without passwords
... fingerprint sensor to unlock the phone, same ceremony when using a browser on the phone
... assumption that there can be local storage of the key material for each web site
... UAF is really about creating a framework of trust decisions of different modalities, without constraining those modalities
... like if we invented a new type of authenticator tomorrow
... without changing protocols
... a set of metadata that describes the authenticator (manufacturer, keysizes, etc.), which can be matched against a certain policy
... risk-based authentication models, or a blacklist/whitelist

<jeffh> https://en.wikipedia.org/wiki/Risk-based_authentication

hillbrad: metadata could be self-asserted (or asserted by FIDO something), attestation comes with the metadata
... interesting part to bring to W3C will be the DOM APIs to discover, query authenticators
... discuss at an upcoming workshop regarding Web Cryptography

virginie: any particular specs that are most related to web world

<hillbrad> http://fidoalliance.org/specs/fido-uaf-client-api-transport-v1.0-rd-20140209.pdf

<hillbrad> That one is the UAF javascript APIs and HTTP bindings.

<hillbrad> http://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20140209.pdf

alex_ber: very easy reading/browsing from FIDO

<hillbrad> That one is the U2F javascript APIs

virginie: definitely considering for WebCrypto WG

<Zakim> fjh, you wanted to ask about anticipated time frame for this work, implementations

fjh: what's the timeframe? how do you anticipate this playing out?

bradhill: FIDO would like to move drafts to implementation draft in the next year, to standards groups after that

<virginie> https://fidoalliance.org/adoption/fido-ready

bradhill: some implementations are supporting this already
... still working on interop/testing plan

<jeffh> http://www.plug-up.com/

New security features : status on the 'secure services workshop'

virginie: discussion of a workshop, within WebCrypto, regarding better integration of smartcards, for example
... more use cases for accessing a secure container, or trusted execution environment
... workshop for discussion of a lot of security-related topics, open to discussion
... schedule not set yet
... what are the new security features that we want to have in the Web platform?
... virginie, hhalpin will keep this group informed

virginie will send minutes / takeaway.

virginie: schedule a call perhaps in 2 months; after STRINT report and Web Payments report are out
... will send a scheduling email as need be

<hillbrad> thanks for organizing, virginie

- DRAFT -

Web Security Interest Group

31 Mar 2014

Attendees

Contents

- Debrief of STRINT workshop

Security review and guideline

Understanding security technology : focus on FIDO

New security features : status on the 'secure services workshop'

Summary of Action Items

Scribe.perl diagnostic output