Web Security Context Working Group Teleconference
24 Oct 2007

See also: IRC log


Mary Ellen Zurko, Ian Fette, Jan Vidar Krey, Cristian Serban,  Anil Saldhana, Yngve Pettersen, Bill Doyle, Thomas Roessler, Tyler Close, Hal Lockhart, Serge Egelman, Phillip Hallam-Baker, Rachna Dhamija
Maritza Johnson, Tim H, Luis B, Dan S, Jonathan N
Mary Ellen Zurko
Cristian Serban


Approve minutes

<tlr> http://www.w3.org/2007/10/02-wsc-minutes.html

<tlr> http://www.w3.org/2007/10/03-wsc-minutes.html

<tlr> http://www.w3.org/2007/10/10-wsc-minutes

<tlr> minutes approved

Newly completed action items

mez: any troubles or questions ?
... nothing

Agenda bashing

<serge> CLT?

ISSUE-128 Strong / weak algorithms?

<Mez> http://www.w3.org/2006/WSC/track/issues/128

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#strong-algos

mez: most people suggested we reference and make some suggestions about what chipers are adequate to use

<Zakim> ifette, you wanted to talk about strong vs weak

iffete: browsers already have knowledge about strong vs weak encryption

serge: is not convinced that this is in the group's scope

<serge> that was an example

serge: there are many references out there

yngve: detailed a list of possibilities on what we can include in the document

<Mez> yes

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0014.html

<Mez> is what yngve is referring to

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#strong-algos

mez: which exact issue is referencing, from those mentioned?

yngve: this document makes comparisons of what lengths are equivalent to what alghorithms

<serge> who cares where it's from, if there's a group already doing this, we should just reference it

<Mez> +1

bill-d: tries to find a standard document describing all chiphers lenghts and where each to be used

<tlr> ACTION: doyle to look for cyphersuite strength standard that we can reference [recorded in http://www.w3.org/2007/10/24-wsc-minutes.html#action02]

<trackbot-ng> Created ACTION-321 - to look for cyphersuite strength standard that we can reference [on Bill Doyle - due 2007-10-31].

mez: we should find the best reference to point to

iffete: wonders if we decided on a reference
... suggests that references be left to vendors
... if we point to a document, it will be out of date at some time
... a browser vendor should be able to make a dettermination

phb: whatever decision we make today, it will look bad in times

<tlr> 40bit didn't!

<tlr> right

phb: weak vs strong is delicate to describe
... suggests deprecated instead of weak
... and consensus for strong
... we are not choosing the strong chiphers
... the purpose of this group is to recognize the consensus of good chipers
... we can do like EV, pointing it without fully resolving it
... the strong chipers should not be presented by the browser as strong

<ifette> I hope?

phb: important is when a chipers is no longer strong

<rachna_> yes

phb: it is a user's choice not a browser choice
... each user can sustain what he wants, and always there are different oppinions
... maybe we don't need to create a body, only make a reference

iffete: we have following options:

<ifette> a) leave to browsers

<ifette> b) Reference a document (or standard bodies rec) listing strong/weak ciphers

<ifette> c) Give requirements for "strong" (have a group monitoring, etc)

<tlr> one can always reference to some standard or whatever supersedes it

<PHB2> I think we can probably reach consensus on the wording of weak/strong versus deprecated/consensus/strong first

<ifette> use what @tlr said for b)

phb: there is not so much need for a document

mez: if you want to propose a rewording

<PHB2> My proposal:

asaldhan: looks for an option to combine b and c

<PHB2> 1) consider an algorithm to be deprecated if it has been delared as such by IETF, W3C or OASIS

<Mez> a) leave to browsers

<PHB2> 2) consider an algorithm consensus if it is specified as a mandatory cipher in standards issued by IETF, W3C and OASIS (note AND)

<Mez> b) Reference a document (or standard bodies rec) listing strong/weak ciphers

<Mez> c) Give requirements for "strong" (have a group monitoring, etc)

<Mez> (just restating for all)

iffete: people have an idea on what is a strong chiper

<PHB2> 3) allow a browser provider to decide for themselves if a cipher meets specified criteria for being considered strong

<PHB2> 4) Recommend that browsers only represent consensus or deemed strong ciphers as being secure

iffete: 3) give criteria to when a browser should decide on an chipers to be weak

<PHB2> Thats the idea

<PHB2> Consensus forming...

<ifette> a) leave to browsers

<ifette> b) Reference a document (or standard bodies rec) listing strong/weak ciphers and its successor

<ifette> c) Give requirements for "strong" (criteria, possible info references etc)

<PHB2> I guess my proposal is a version of C

Rachna: B

<ifette> b is "assuming X exists"

rachna_: B and ... otherwise A

phb2: C

bill-d: B

tyler: abstain

hal: b

<asaldhan> C (with some references to documents from B)

<tlr> C (with some references to documents from B)

<scrissti> B

<ifette> A

mez: b

<jvkrey> jvkrey: b

<ifette> so it sounds like mostly B and C

<ifette> whch for a straw poll sounds reasonably precise

<yngve> yngve: b or c

<ifette> especially given the attendance

<serge> http://csrc.nist.gov/publications/PubsSPs.html

<ifette> yes

<serge> isn't this sufficient?

<serge> http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

<PHB2> We can all lve with B if soeone else does it

asaldhan: they're recommendations, I'm not sure that matters

serge: We can add them as references as per b)

asaldhan: that's my whole point

asaldhan: the point is, I think I found it.

tlr: if be exists there is no point for c

serge: bill-d email has other docs

bill-d: we want to have some standards even they go outdated

phb: i don't want to reference a document but a process

hal: objection: some browsers say a chiper is strong, others say it is weak

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0027.html

TAG on passwords in the clear

<ifette> no, can someone summarize it

<Mez> http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20061113.html

mez: summarizes the issue

<tlr> errr, that's an outdated version

<tlr> Latest Version: http://www.w3.org/2001/tag/doc/passwordsInTheClear-52

<Zakim> tyler, you wanted to state a hot fact and to complain about the tag thing (now I remember it)

iffete: recomandation for what browsers should do
... website should request password on ssl, but doing it on the client side is not good
... a browser does not know what is a password

<tlr> oh yes, password entry with t9

tyler: we don't have support for resolving the issue as the reasons presented are not "solid"

<ifette> I think that given the typo of ifette->iffete, my s/ifette/tyler is going to cause a problem and attribute my last comment about website should request password on ssl to be attributed to tyler. Someone is going to have to clean that up.

<rachna_> openid has serious flaws (protocol and interface wise)

<ifette> yes it does, but it still solves some of the issues and provides a starting point for further work...

<ifette> i will concede that the interface has huge problems

<serge> recommending known flawed systems might not be the best way to proceed

<ifette> wasn't recommending anything... merely pointing to someting in a /me

phb: phishing attacks are a problem

hal: i agree tyler, masking rarely provides a benefit today

<tlr> well, that objection applies to most *good* shared-secret protocols

<Zakim> ifette, you wanted to talk about masking

hal: digest can't be used

ifette: i think masking is very important today, in presentations for example

iffete: there are other issues, we should not kill the masking

<hal> digest is not practical because most organizations store a salted hash of the password, which makes it impossible to use digest

<tlr> hal, doesn't that make most other protocols shared secret protocols impossible to use as well?

tyler: we should not sustain that browser MUST user masking

<hal> many organizations have a written security policy which prohibits storing passwords in the clear

<Zakim> ifette, you wanted to talk about passwords in clear on network

tyler: "ssl should be used", this is the only good thing in the current draft

ifette: recomandation to wesite owners or to browsers ?

hal: there are ways around that.

ifette: website knows better about its content
... website should use SSL instead of brwoser should use ssl

Dealing with comments on our documents

mez: please find tools to help us

<Mez> http://www.w3.org/2006/WSC/track/actions/274

tlr: somebody assembles manualy and generate a report
... several manual steps

<bill-d> http://www.w3.org/2006/02/lc-comments-tracker/39814/

<ifette> i'm getting a timeout on that link

<tlr> http://www.w3.org/2006/02/lc-comments-tracker/39814/wsc-usecases/

mez: last link requires authentication, is it not public ?
... bill voluntered to do the work

bill: this helps us track comments but we still to email to public

ifette: can we use something like bugzilla?

mez: looks for someone to take charge in this and take care of the entire job

tlr: i did see bugzilla in a working group

mez: i will pay more attention on the open issues

Summary of Action Items

[NEW] ACTION: doyle to look for cyphersuite strength standard that we can reference [recorded in http://www.w3.org/2007/10/24-wsc-minutes.html#action02]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/10/31 15:07:27 $