See also: IRC log
<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?
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
<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
<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/
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/The code is 9744 (WSIG)// Found ScribeNick: npdoty Inferring Scribes: npdoty Default Present: +1.503.712.aaaa, BHill, terri, Art_Barstow, +1.213.337.aabb, christine, npdoty, virginie, +44.793.550.aacc, hannes, jeffh, fjh Present: +1.503.712.aaaa BHill terri Art_Barstow +1.213.337.aabb christine npdoty virginie +44.793.550.aacc hannes jeffh fjh Regrets: wseltzer WARNING: Could not parse date. Unknown month name "31": March 31, 2014 Format should be like "Date: 31 Jan 2004" Got date from IRC log name: 31 Mar 2014 Guessing minutes URL: http://www.w3.org/2014/03/31-websec-minutes.html People with action items:[End of scribe.perl diagnostic output]