Meeting record: 2007-10-24

Minutes from our meeting on 2007-10-24 were approved and are
available online here:

A text version is included below the .signature.

Thomas Roessler, W3C  <>


               Web Security Context Working Group Teleconference
                                  24 Oct 2007

   See also: [2]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


     * [3]Topics
         1. [4]Approve minutes
         2. [5]Newly completed action items
         3. [6]Agenda bashing
         4. [7]ISSUE-128 Strong / weak algorithms?
         5. [8]TAG on passwords in the clear
         6. [9]Dealing with comments on our documents
     * [10]Summary of Action Items

Approve minutes

   <tlr> [11]

   <tlr> [12]

   <tlr> [13]

   <tlr> minutes approved

Newly completed action items

   mez: any troubles or questions ?
   ... nothing

Agenda bashing

   <serge> CLT?

ISSUE-128 Strong / weak algorithms?

   <Mez> [14]


   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

   <Mez> yes


   <Mez> is what yngve is referring to


   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

   <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
   ... 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
   ... 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,

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

   <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> [19]

   <ifette> yes

   <serge> isn't this sufficient?


   <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


TAG on passwords in the clear

   <ifette> no, can someone summarize it


   mez: summarizes the issue

   <tlr> errr, that's an outdated version

   <tlr> Latest Version:

   <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

   <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

   <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

   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

   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> [24]

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

   <bill-d> [25]

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


   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

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



Received on Wednesday, 31 October 2007 15:08:48 UTC