See also: IRC log
<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
mez: any troubles or questions
?
... nothing
<serge> CLT?
<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
<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
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