- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 27 Feb 2008 15:17:22 +0100
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2008-02-05 were approved and are
available online here:
http://www.w3.org/2008/02/05-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Face-to-Face Meeting
05 Feb 2008
See also: [2]IRC log, [3]Agenda
Attendees
Present
Thomas Roessler, Mary Ellen Zurko, Serge Egelman, Yngve
Pettersen, Rachna Dhamija, Tyler Close, Phillip Hallam-Baker,
Bill Doyle, Maritza Johnson, Hal Lockhart
Regrets
Tim Hahn, Ian Fette, Stephen Farrell, Anil Saldhana, Johnathan
Nightingale, Dan Schutzer, Mike Beltzner, Luis Barriga
Chair
Mez
Scribe
rachna, bill-d, hal
Contents
* [4]Topics
1. [5]Agenda Bashing
2. [6]Game Plan till June
3. [7]Identifying Low-hanging fruit
4. [8]8.3 APIs exposed to Web content
5. [9]9.3 Use TLS Consistently across the web site
6. [10]9.2 Use TLS for Login Pages
7. [11]5.3 Change of security level
8. [12]6.1 Identity and Trust Anchor Signalling
9. [13]6.2 Additional Security Context Information
* [14]Summary of Action Items
__________________________________________________________________
<Mez> special thanks to Commercenet for hosting
<Mez> hal points out the kleenex is a nice touch
Agenda Bashing
Mez: we will discuss recommendations, ...
... then look at mature recommendations ...
... and resolve issues in them ...
... then what usability testing means for recommendations ...
... then process plans on mature recomendations ...
... today we'll decide which are mature recommendations...
... tomorrow we'll discuss future looking recs ...
<Mez> [15]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
Game Plan till June
Mez: what subset should make it to last call (before our charter ends
in June)
tyler: our next document can discuss status quo & what the browsers are
already doing
... I would be surprised if anything not implemented will be a
recommendation
... don't believe a lot of these things will have impact
... need user studies
mez: that's not process so far, you can put this as an issue in tracker
<tlr> [16]http://www.w3.org/2006/WSC/track/issues/new
mez: anything that you have a problem with, create an issue using url
above
... make issues well formed
<Mez> [17]http://www.w3.org/2006/WSC/wiki/WriteGoodIssue
tyler: there is an implicit issue with all recs that they must provide
evidence of working
mez: no not true, it is not implicit- you should raise an issue
formally
<Mez> [18]http://www.w3.org/2005/Security/wsc-charter
<Mez> [19]http://www.w3.org/2006/WSC/wiki/SuccessBaseline
mez: reviewing success baseline (what makes a successful
recommendation?)
tyler: success baseline says demonstrably better
mez: move to look at recommendations that have few issues
tyler: we might get more buy in from browser vendors to start with a
document that describes the status quo
mez: let's start with recs that are current best practice
tyler: a document that just introduced nomenclature and status quo
would be a significant chunk of document
mez: there are aspects of status quo that we don't address
... page security score is the only thing that gets near the padlock
... another strategy is to address problems we have with status quo,
take a look at what else is status quo that we haven't addressed (e.g.
padlock)
... anotehr part of status quo: what to do about urls (the only
identity signal we have now)
... three options for how to address status quo: 1) recommendation
about 2) we achieve consensus on silence or 3) we don't achieve
consensus
tyler: one of benefits of this doc is if you are implementing a new
browser, you have reference to consult about what everyone else has
done
mez: e.g. yes, the mobile platform is an example
tyler: each new platform/browser team repeats past mistakes
mez: let's see which recs are status quo, what we have to say about
status quo and which recs make our cut for being mature
tyler: do we want to discuss nomenclature?
mez: let's do recs first, then nomenclature
tlr: one warning about nomenclature- I merged Stephen's rewrite (what
is a secure page has been lost)
... section 5 changed sustantively
yngve: I'm coming up with a similar issue re augmented assurance
<tlr> the secure page thing is in ISSUE-182
tlr: that section needs another round of review
yngve: ?
hal: what is the gameplan after that doc?
mez: we may need to ask for charter extension
thomas: my expectation is charter extension
tyler: on other side of fence, jonathan questions whether it is worth
proceeding with this group
<tyler>
[20]http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-o
ther-crazy-ideas/
tyler: one possibility is to document the status quo and call it a day
hal: how long can we extension?
thomas: rechartering means changing scope
<Mez> we will carve out a subset of our recommendations for a document
that can make last call by June. it will include at least whatever
recommendations address the status quo for which we have concensus. It
may include new recommendations on the status quo we have concensus on,
nomenclature (for that set of recomendations and perhaps beyond), and
may include other recommendations we have concensus on.
thomas: extension is w3c decision, can be 3 months, 6 months, there is
no process inherent limit,...
... the limit includes the time for a check point ...
... no groups that produce recs are shut down, ...
... but are put into hibernation, so you don't lose patent committments
...
mez: creepy
hal: controversial. agenda du jour blank check.
tyler: another reason for documenting status quo is usability testing
is resource intensive
mez: when I say recommendation, I mean recommendations that we are
ready to make by June
tyler: I would like next document on what browsers are doing now
maritza: these are the recommendations we have that may or may not
address- this is what we evaluate
hal: "this is what's on the table"
phb: anything we recommend is by nature a change
<Zakim> tyler, you wanted to say recommendations do sometimes document
current implementation practice
phb: acceptability is a factor (e.g. browser people push back on
anything that takes pixels)
<Mez> [21]http://www.w3.org/TR/wsc-usecases/
maritza & tyler: talking about coming up with more thorough use
cases...
thomas: we are mixing up 3 things: 1) documenting current practice
(e.g. you can resize windows, which is an anti-pattern)
2) document best practice (things we endorse)
<Mez>
[22]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
3) framework- "here's a way to think about current practice"
<Mez> I believe this is best current practice, it is robustness, and
it's ready for lc, imo
tyler: if we have a doc that is current best practice, can this be a
recommendation?
mez and thomas: yes
thomas: normative language, so there is a notion of conforming and
non-conforming
hal: is it worth documenting what is on the table?
thomas: if there is stuff that we don't want to love, but we don't know
that we are stopping work on, that can be dropped into a note
... we can say that we have a second rec document and produce a working
draft
... there is some things in xit that are being tried in the wild- I
don't know that everything is in xit
<tlr> Mez: we will carve out a subset of our recommendations for a
document that can make last call by June. it will include at least
whatever recommendations address the status quo for which we have
concensus. It may include new recommendations on the status quo we have
concensus on, nomenclature (for that set of recomendations and perhaps
beyond), and may include other recommendations we have concensus on.
rachnaconfused by what status quo means
mez: status quo= practices in use by current web user agents
thomas: practices for which there is implementation
... best current practice= implementation or where we are close to
having implementation experience
mez: ssl error messages
thomas: not sure if browser vendors can claim conformance with all
language in ssl error section
<tlr> thomas: but I also think the basic approach is very close
<Mez> not exactly what I meant, but
<Mez>
[23]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-interactivel
y
yngve: this is a good practice, this is a bad practice
<Mez>
[24]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-certerrors
tyler: what if we picked a set of user agents and we list things they
do that is a good idea
rachna: how about bad ideas?
tyler: there are too many bad ideas?
thomas: we are vendor neutral, so we don't want to list them
tyler: the list doesn't need to be in document
<Mez>
[25]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
rachna: what are they doing that we would recommend?
<tlr>
[26]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
<tlr> ha, mez beat me to it
mez: 8.3 robustness, API...
resolution: go through trees, rather than forest: let's step through
xit to see what is ready for last call
thomas: what is reasonable to get to last call (no fundamental
disagreements)
mez: yes- no issues logged, or issues can be addressed in a week
... what is definition of last call?
<tyler> I'm going to paste a few that seem like likely candidates for
Best Current Practice:
<tyler>
[27]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-indicat
or-images
<tyler>
[28]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-login-pages
<tyler>
[29]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
<tlr> Purpose: A Working Group's Last Call announcement is a signal
that:
<tlr> * the Working Group believes that it has satisfied its relevant
technical requirements (e.g., of the charter or requirements document)
in the Working Draft;
<tlr> * the Working Group believes that it has satisfied significant
dependencies with other groups;
<tlr> * other groups SHOULD review the document to confirm that these
dependencies have been satisfied.
<tlr> In general, a Last Call announcement is also a signal that the
Working Group is planning to advance the technical report to later
maturity levels.
<Mez> [30]http://www.w3.org/Guide/
<Mez> [31]http://www.w3.org/2005/10/Process-20051014/
<tlr> thomas: rambling from process document
<tyler> tyler: 8.3 from xit looks like it could be expanded to be a
useful part of our BCP document
thomas: there is stuff that is low hanging fruit, where there is
experience or will be soon, let's go through the doc and see which of
those we can get to last call by June
... there is implementation or implementations that are known to come
rachna: what about implementations we do?
mez: we are the public
<tlr> So resolved.
Identifying Low-hanging fruit
<Mez> there is stuff that is low hanging fruit, where there is
experience or will be soon, let's go through the doc and see which of
those we can get to last call by June
<Mez> 8.3
mez: we can take one at a time, full list or partial list
<serge> are we there yet?
<Mez> there is stuff that is low hanging fruit, where there is
experience or will be soon, let's go through the doc and see which of
those we can get to last call by June
<Mez>
[32]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
<tlr>
[33]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
mez: directed to Serge, whatever recommendations we have for what works
well for errors needs to go in doc
<Mez> spend time fleshing out 8.3
<Mez> 9.1
<Mez> 9.2
<Mez> 9.3
<Mez> all of 9
<Mez> 5.3
<Mez> 7.9
<Mez> 4.2
<Mez> all of 8
<Mez> section 5
<Mez> 5.1.2
<Mez> 7.8
<Mez> 8.2
<Mez> 6.1
<Mez> 6.4
<Mez> 5.2
8.3 APIs exposed to Web content
<Mez>
[34]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
<Mez> [35]http://www.w3.org/2006/WSC/track/issues/95
<tlr>
[36]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0233.html
tyler: browser's inability to prevent applications from obscuring
browser content
<Mez> [37]http://www.w3.org/2006/WSC/track/issues/131
<Mez>
[38]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0246.html
??problem with whack-a-mole attack
phb: rename whack-a-mole attack
rachna agrees that wahck-a-mole is not a technical attack name
<Mez>
[39]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#whack-a-mole
mez: can someone propose a name?
<PHB> I suggest user control hijacking attack
<Mez> user control highjacking attack
<serge> how about Attack #894875/A ?
<Mez> window popup attack
<Mez> simon sez attack
<Mez> click through attack
<Mez> interaction flooding attack
mez: proposal change text of whack s mole to "interaction flooding
attack"
<Mez> rachna: what is the scope for the defn of this section?
<Mez> ... if a cert error dialog pops up, these extensions will prevent
the dialog will pop up
<Mez> tlr: they are part of the ua
<Mez> rachna: this only applies to content
<Mez> tlr: a web page shouldn't be able to make that happen
<tlr> Web user agents MUST prevent web content from obscuring, hiding,
or disabling security UI.
<tlr>
[40]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirements-rob
ustness
<tlr>
[41]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#definitions
tyler: second bullet under 8.3.1. are active X controls outlawed under
this?
mez: active x controls are installed, user interaction is required if
signature is not trusted
thomas: we elaborate on what constitutes software download
rachna: summarizing my concern from earlier... 8.3 should not cover
user agents that prevent the display of SSL warning messages
phb: what about interactions that allows you to say all active x
controls from this provider can run?
... don't want to have a "must" that requires users to individually
agree to each activx control, rather than agreeing to all active X
controls from one provider (e.g. Microsoft)
bill: this applies to the language about "allowing users to preconsent"
tyler: if a browser that comes shipped with pre-installations that does
not ask for preconsent is not compliant?
phb: what if you ship a trusted configuration of browser
(pre-configured) version of browser?
... some extensions are pre-configured, while other extensions are
"after market". Our document does not distinguish between the two.
mez: if you shipped as part of browser, is it the browser or an
extension to the browser?
... it is arguable that active x controls don't make a user agent not
compliant with this section (only violating MUSTS, not SHOULDS)
bill: is active x a class you allow?
<PHB> We need to have a place where we define the term 'extension' as
opposed to 'component'. A component that ships with the browser is not
an extension by definition. The browser provider is responsible for the
browser and all components published with the browser
tyler: main carve out only covers consent from user. I am pretty sure
that IE ships with certain certain certs that allow active x controls
to run without consent from user.
bill: I don't think that there is any security around a non-signed
active x control
<Zakim> PHB, you wanted to point out that it is not user consent that
is the issue, it is owner of the machine consent
phb: user is not always the person who has the right to install
software on the machine. some corporate machines or hospital machines-
you don't want to allow user to install active x controls.
mez: nothing in this section allows for policy or system administration
control - this sounds like a new issue.
tyler: something we haven't written is that there be away to see what
user has consented to.
mez: do we want to address the fact that pre-configured browsers that
allow active x to run w/o consent of user
thomas: addressing phil
... addressing phil's issue about pre-configured policies might also
address the active-x issue
... we don't want to disallow corporate policy, global policy that
might install software without user consent
<tlr> phb: no software components to be installed without authority
phb: language should be that "no software can be installed without
policy. If the policy is to allow the user to set the policy, then user
consent must be obtained"
<tlr> If user has authority, then don't presume .. $( insert current
text here )
tyler: what do mean by execution of privileged code?
... priviledged code would include API for reading files (hal: reading
specific files)
phb: we don't have a good boundary for what is privileged.
thomas: there is in commonly deployed browsers a user expectation that
"I have stuff on my machine that I interact with normally that is not
affected by my browser"
... maybe we need to say that browsers won't change anything outside
browser
rachna: this is like saying browsers should be self contained VM
hal: leaky
tyler: there isn't a current best practice
... we can say we've identified major issue, we'll developing a model
how installation should be handled
mez: there are two bullets in 8.3.1. let's consider the first bullet in
8.3.1.
thomas: we should separate the bullets in 8.3.1, since they deal with
two separate issues
reading 8.3.2....
tyler: three categories: whack a mole, installation and general
security guidleines
phb: understand why interaction flooding attack is mentioned here.
there must be some control that javascript can only open up a window
with some user action.
... pop-up and pop-under windows ...
<tlr> [42]http://www.flickr.com/search/?q=padlock&w=all
<tlr> ... would violate 9.1 as phrased
<tlr> oooops
rachna: schemes like SiteKey also violate 9.1
<tlr> [43]http://www.flickr.com/photos/roessler/107144618/
<tlr> ScribeNick: bill-d
<tlr>
[44]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
tlr: rewrite of robustness section
mez: rewrite sections 8.3.1
... everyone review
rachna: issue with third bullet
mez: normative language lost in translation
<Mez> Difficult-to-spoof UI elements that cross the chrome-content
border, such as the anti-phishing warning bubble
<Mez> [45]http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice
tyler: technique for alerting is lost in current MUST
<rachna> the technique being referred to (e.g. firefox anti-phishing
warning) is about robustness, spoofing and user attention
mez: third bullet does not belong where it now is, don't know where it
belongs - robustness?
tlr: trusted path and user attention
rachna: harder to obscure
mez: third bullet could be defense in depth
rachna: section is about obscuring?
mez: have to do both of the MUSTs and then two shoulds and should nots
... is right place because supports the ability to restrict obscuring
the secure chrome
tyler: should have a section that destingishes secure chrome
<tlr>
[46]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trust
edpath
tlr: it is 8.2
tyler: crosses chrome content area - prevention of web content can't
draw it in a way that obscures secure chrome
tlr: must not let web content paint over, technique for things that are
supposed to be seperate please use this tequnique for this. trusted
path, unique chrome contect distinctions.
... more 8.2. 8.4 - more combining to secure ui sections
tyler: move 3rd bullet to establish trusted path
rachna: trusted path means that the user took some action
tlr: another rewrite
... 8.2. 8.4 and chrome ui - 8.3 cannot paint across boundary
... 8.4 split between the two
rachna: why is the UI attack spelled out specifically?
mez: just an example
<tlr> ACTION: thomas to change editor's draft as outlined above
[recorded in
[47]http://www.w3.org/2008/02/06-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-383 - Change editor's draft as outlined
above [on Thomas Roessler - due 2008-02-12].
<tlr> (memo to self: see written notes)
rachna: don't understand why the specific attack is brought out.
tlr: causing the user to pause is a way to get user attention
... just keep hitting accept until window goes away, user gets used to
hitting the accept button
mez: turning 8.3 text to something that eveyone can agree upon
... to move forward without waiting for rewrite if nothing surprising
introduced can the group agree on 8.1
serge: is secure UI defined?
mez: what is the problem with text - and how can it be fixed
serge: any chrome can be security chrome
tyler: the boundary of the window is security information, bottom strip
is security ui
PHB: not our place design, but tell designers how to differentiate
PHB: each platform or device is going to be different
rachna: one the designer defines what is secure UI, they need to be
consistent with it
mez: place in document that defines secure UI?
yngve: 4.2.1 - place for it
tlr: 4.2.1. currently is a place to store info, needs to be built out
rachna: what about secondary chrome
mez: seconday is only shown by demand
serge: should not be able to open browsers without chrome present if
security info is available
<rachna> 8.3.1. section does not distinguish between primary and
secondary chrome (security context info refers to both)
serge: if we generalize it must be inclusive for all cases
rachna: serge are you saying developers should never allow secure
chrome to be over written.
tlr: if a pop up over writes part of the primary page, is this a
problem. all secuirty context should be in new windows chrome
rachna: used by attackers, new windows lacks security info, old window
is displayed that has security info, users infer that new windows has
inherited security context
<rachna> rachna will bring up issue: this section does not address the
reverse problem where attackers pop up a window that *does not obscure*
the underlying security context UI. For example, a non-SSL protected
pop-up window may appear over a SSL-protected page so that the user
thinks the chrome from the original window applies to the window above
it.
serge: if the chrome is not secuirty UI then should not be trusting it
<Mez> Web user agents SHOULD NOT allow web content to open new windows
that hide the user agent's chrome.
mez: would have problems with this if chrome does not have security
info
... is this acceptable
tlr: maybe we don't want user to see old page and old security
info.make user believe that new page has inherited security context
... , should always be one set of security chrome on the screen - the
chrome of the current window
<tlr> distinguish context of window user is interacting
<tlr> ... with
mez: take a break get a proposal?
serge: half baked idea to bind pop-ups to secure chrome. popups can't
go outside
<tlr> ACTION: thomas to propose lang about currently interacted primary
chrome always visible on screen [recorded in
[48]http://www.w3.org/2008/02/06-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-384 - Propose lang about currently
interacted primary chrome always visible on screen [on Thomas Roessler
- due 2008-02-12].
tlr: 8.3.1 tasks to editing the docuemnt the basic requirment is not to
prevent content from hiding or obscuring - content executiting within
the window must not turn of or prevent the current primary chrome,
including APIs
... include chrome content boundary - APIs and rephrase in terms of
general way
mez: is it possible to rewrite and agree?
tlr: clarification - on do we believe that group can agree on phrasing?
tyler: due to spoofing issues, it is a rewrite of section 8 and how
chrome is being used as a security interface
mez: two ways to do the painting of pages, goal is chrome not being
stacked on, distinctive chrome - user to distinguish UI and security
info
tlr: suggests certain restrictions on APIs, security bias
tyrler: have not conqured overhapping issue, includes other browser
windows. open page in new window including web content
yngve: opera new window inside the same frame
hal: differences exist in browsers and presentation of tabbed browsing
serge: primary window - controls all secutity context - take out
pop-ups
tyler: more on - take a look at 9.3
mez: 8.3.2 banged about a lot. didn't talk about 8.3.3 and 8.4 not run
to ground
9.3 Use TLS Consistently across the web site
<tyler>
[49]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
<tlr> ISSUE-162?
<trackbot-ng> ISSUE-162 -- Recognize there are other forms of network
security -- OPEN
<trackbot-ng> [50]http://www.w3.org/2006/WSC/track/issues/162
mez: is issue 162 the only issue against this?
... requires secure login
tlr: use the same security settings, e.g. ciphers for the entire
transaction
<tlr> If a web site requires entry of user credentials, then all
transactions and presentation based on the user's credentials as well
as the service provided credential token itself MUST be protected by
the same level of security.
<tlr> Servers MUST NOT set credential cookies from secure servers that
can be sent unencrypted.
hal: using - lets say tls to protect credentials, is TLS then needed to
protect all the rest of the data
... orginal motive for this is that they encrypt the password and send
all application data in the clear
mez: passwords may be reused, another reason for protection req.
tlr: long term secret, short term secret
tyler: web application that requests secret MUST alwasy use same level
of security, derived secret can be at lower level.
tlr: derived secret can be at the same level and should be protected at
same level
mez: need to work on section
tlr: hopes that tyler has some ideas
yngve: something can be sent unencrypted it should not have aiuthorizty
to do sensitive transactions
tlr: TLS protected - long term, powerful
<tyler> If a web application solicits a secret, such as a password,
over TLS, then it MUST always transmit that secret using that same
level of protection. A secret derived from the TLS protected secret
SHOULD also be given the same protection. If the derived secret conveys
as much authority as the original secret it MUST also be protected at
the same level as the original secret.
<tlr> works for me
<hal> Sensitive transactions also MUST be protected using the same
level of protection.
If a web application solicits a secret, such as a password, over TLS,
then it MUST always transmit that secret using that same level of
protection. A secret derived from the TLS protected secret MUST also be
given the same protection unless the derived secret conveys less
authority as the original secret.
<tlr> f a web application solicits a secret, such as a password, over
TLS, then it MUST always transmit that secret using that same level of
protection. Any derived secret that convey a similar level oIf
authority as the original secret it MUST also be protected at the same
level as the original secret. Other derived secrets SHOULD also be
given the same protection.
<tlr> same level -> at least same level
<tlr> ACTION: thomas to replace 9.3 by text above [recorded in
[51]http://www.w3.org/2008/02/06-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-385 - Replace 9.3 by text above [on Thomas
Roessler - due 2008-02-12].
<PHB> If a web application solicits a secret, such as a password, over
TLS, then it MUST always transmit that secret using that level of
protection or better.Any derived secret that convey a similar level of
authority as the original secret it MUST also be protected at the same
level as the original secret. Other derived secrets SHOULD also be
given the same protection.
mez: replaces text in 9.3
<tlr> mez: ISSUE-162 moot
tyler: add clause then sensitive transaction details should also be
protected by same level of security
mez: if we have additional issues raise them
yngve: cookie may not always be associated with the certificate that
was the basis for the cookie's creation -
<hal> Sensitive transactions also MUST be protected using the same
level of protection.
<tlr> (memo to self: see written notes)
<tlr> +1 to change
hal: not dictating what sensitive transaction is
<Mez> 10 01If a web application solicits a secret, such as a password,
over TLS, then it MUST always transmit that secret using that level of
protection or better.Any derived secret that convey a similar level of
authority as the original secret it MUST also be protected at the same
level as the original secret. Other derived secrets SHOULD also be
given the same protection. Sensitive transactions also MUST be
protected using the same level of protection.
<tyler> In a web-application, a secret may be used to authorize a
transaction. The details of that transaction SHOULD also be transmitted
using the same level of protection afforded the secret itself.
hal: agrees with mez version
tlr: merge both tyler and mez versions
<Mez> a - mez text
serge: does not like term "sensitive" transaction
<Mez> b - replace last line of mez text with tyler text
<Mez> c - concatenate tyler text onto mez text
<tlr> c
<Mez> d - abstain
<maritzaj> A
<hal> C
<serge> B, final answer
<bill-d>c
<yngve> b
<tyler> b
<Mez> d
<PHB> c
<tlr> s/phb:c//
<rachna> c
<Mez> a - 1
<Mez> b - 3
<tyler> Further clarification: For example, a web page which supports
submission of a request authorized by a secret SHOULD NOT include
representations that were not transmitted using TLS.
<Mez> c - 5
<Mez> d - 1
<yngve> SSL performance article
[52]http://boblord.livejournal.com/1538.html
<Mez> c - 5
<Mez> b - 3
<Mez> a - 1
<Mez> d - 1
<tlr> ACTION-385: implement option c
<Mez> I like 5.3 as the next topic
<Mez> starting at 3:45pm local time
<Mez> taking other votes though
9.2 Use TLS for Login Pages
<tyler> I like a variation of 9.2 next. We just said "use MUST use TLS
consistently". Now let's say, "You SHOULD use TLS"
<tyler> I like a variation of 9.2 next. We just said "you MUST use TLS
consistently". Now let's say, "You SHOULD use TLS"
<tyler> An author MUST NOT create a web page which mixes
representations served using TLS with representations that are not
served using TLS.
<tyler> An author MUST NOT create a web page which mixes
representations served using TLS with representations that are not
served using at least that level of protection.
<tyler> An author MUST NOT create a web page which mixes
representations served using TLS with other representations that are
not served using at least that level of protection.
<tyler> I think the above text is an implied consequence of the text
that Hal proposed and we just voted on. I think the above text should
be included in addition.
<tyler> An author MUST NOT create a web page served using TLS that
includes other representations that are not served using at least that
level of protection.
<tyler> An author MUST NOT create a web page served using TLS that
includes other representations not served using at least that level of
protection.
<tyler> I think the above text is an implied consequence of the text
that Hal proposed and we just voted on. I think the above text should
be included in addition.
<tyler>
[53]http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-o
ther-crazy-ideas/
<tyler> Web page authors SHOULD use TLS, or similar protection, to
protect transmission of secrets.
<tyler> Web page authors SHOULD use TLS, or similar protection, to
protect transmission of secrets, such as passwords.
<tyler> Web page authors SHOULD use TLS, or similar protection, to
protect both the transmission and solicitation of secrets, such as
passwords.
<tlr> Login page must be authenticated / integrity protected using TLS
or similar protection; password that's returned needs privacy
protection using TLS or similar protection.
<tlr> "needs" = "MUST"
<tlr> or, "SHOULD"?
<tlr> Web pages SHOULD use TLS to protect the privacy of secrets, such
as passwords, in transmission. If passwords are submitted in this way,
solicitationi pages MUST be authenticated and integrity protected using
TLS or similar techniques.
<yngve> A web service that solicits a secret transmitted using TLS
protection, MUST solicit that secret from a TLS protected form. A
non-TLS protected page MAY carry a link for the user to click to be
taken to a TLS protected page to enter login information. This link
MUST NOT carry a padlock along with it
<tlr> Web pages SHOULD use TLS or comparable mechanisms to protect the
privacy of secrets, such as passwords, in transmission. If secrets are
submitted in this way, solicitation pages MUST be authenticated and
integrity protected using TLS or comparable techniques.
<tlr> (note to self: look for better words instead of "solicitation
pages"
<tlr> )
<tlr> ACTION: thomas to update 9.2 with statement above [recorded in
[54]http://www.w3.org/2008/02/06-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-386 - Update 9.2 with statement above [on
Thomas Roessler - due 2008-02-13].
<tlr> solicitation -> secret solicitation (editorial)
<Mez> 10 01Web pages SHOULD use TLS or comparable mechanisms to protect
the privacy of secrets, such as passwords, in transmission. If secrets
are protected in this way, solicitationi pages MUST be
cryptographically authenticated and integrity protected using TLS or
similar techniques.
<Mez> Web pages SHOULD use TLS or comparable mechanisms to protect the
privacy of secrets, such as passwords, in transmission. If secrets are
protected in this way, solicitation pages MUST be cryptographically
authenticated and integrity protected using TLS or similar techniques.
<PHB> Web pages SHOULD use AUTHENTICATED TLS ....
<PHB> Where authenticated means either trusted cert or a self signed
that is explicitly trusted
<Mez> 04 01Web pages SHOULD use authenticated TLS or comparable
mechanisms to protect the privacy of secrets, such as passwords, in
transmission. If secrets are protected in this way, solicitation pages
MUST be cryptographically authenticated and integrity protected using
TLS or similar techniques.
<Mez> [definition: Autenticated TLS means either using a trusted cert
or a self signed that is explicitly trusted]\
<serge> Web pages SHOULD use TLS or comparable mechanisms to protect
the privacy of secrets, such as passwords, in transmission. If secrets
are protected in this way, solicitation pages MUST be cryptographically
protected.
<PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
to protect the privacy of secrets, such as passwords, in transmission.
<PHB> definition: Autenticated TLS means either using a trusted cert or
a self signed that is explicitly trusted
<Mez> [55]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
<PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
to protect the confidentiality of secrets, such as passwords, in
transmission.
<PHB> Web pages SHOULD use authenticated TLS or comparable mechanisms
to protect solicitation pages for secrets.
<Mez> 10 01Web pages SHOULD use authenticated TLS or comparable
mechanisms to protect the confidentiality of secrets, such as
passwords, in transmission.
<Mez> If secrets are protected in this way, 10 01web pages SHOULD use
authenticated TLS or comparable mechanisms to protect solicitation
pages for secrets.
<Mez> definition: Autenticated TLS means either using a trusted cert or
a self signed that is explicitly trusted
<Mez> 10 01Web pages SHOULD use authenticated TLS or comparable
mechanisms to protect the confidentiality of secrets, such as
passwords, in transmission.
<Mez> 01If secrets are protected in this way, 10 01web pages MUST use
authenticated TLS or comparable mechanisms to protect solicitation
pages for secrets.
<Mez> 01definition: Autenticated TLS means either using a trusted cert
or a self signed that is explicitly trusted
<tyler> Web page authors SHOULD use TLS, or similar protection, to
protect both the transmission and solicitation of secrets, such as
passwords.
<Mez> Web pages SHOULD use authenticated TLS or comparable mechanisms
to protect the confidentiality of secrets, such as passwords, in
transmission.
<Mez> Web pages SHOULD use TLS or comparable mechanisms to protect the
confidentiality of secrets, such as passwords, in transmission.
<tyler> Web page authors SHOULD use TLS, or similar protection, to
protect both the solicitation and transmission of secrets, such as
passwords.
<tlr> also, it's not web page authors, but I consider that an editorial
question...
<Mez> Web sites SHOULD use TLS, or similar protection, to protect both
the solicitation and transmission of secrets, such as passwords against
disclosure to unauthorized parties..
<Mez> Web page authors MUST use TLS, or similar protection, to protect
both the solicitation and transmission of secrets, such as passwords.
<serge> PHB: so then you're forced to pay ~$20/yr to use your own file
server securely?
<tlr> Web pages SHOULD use TLS, or similar protection, to protect both
the solicitation and transmission of secrets, such as passwords,
against disclosure to unauthorized parties.
<Mez> Web pages MUST use TLS, or similar protection, to protect both
the solicitation and transmission of secrets, such as passwords,
against disclosure to unauthorized parties
<PHB> MUST
<Mez> a - should
<tlr> MUST
<Mez> b - must
<serge> MUST
<Mez> c - abstain
<maritzaj> should
<PHB> b
<tyler> a
<yngve> a
<tlr> b
<rachna> must
<hal> must
<Mez> abstain
<Mez> should/a - maritzaj, tyler, yngve
<Mez> must/b - phil, thomas, serge, rachna, hal
<Mez> abstain - mez
<bill-d^gt; a
<tlr> tyler: will change toward "must"
<tlr> mez: fine
<tlr> resolved: MUST
<Mez> Web pages MUST use TLS, or similar protection, to protect both
the solicitation and transmission of secrets, such as passwords,
against disclosure to unauthorized parties
<tlr> ACTION-386 refers to *this* text.
<tyler> An author MUST NOT create a web page served using TLS that
includes other representations not served using at least that level of
protection.
5.3 Change of security level
<Mez>
[56]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
<tlr> ISSUE-114?
<trackbot-ng> ISSUE-114 -- Self-signed certificate changeover -- OPEN
<trackbot-ng> [57]http://www.w3.org/2006/WSC/track/issues/114
<Mez> users should be able to visit a site protected by a self signed
certificate
<Mez> users should not be told that a site protected by a self signed
certificate is trustworthy [absent additional information]
<tlr> [58]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#weak-tls
6.1 Identity and Trust Anchor Signalling
<tlr>
[59]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
<tlr> During interactions with a Web page for which any of the
resources involved was retrieved through a weakly TLS-protected
transaction, the identity signal must be indistinguishable from one
that would be shown for an unprotected HTTP transaction, unless a
change of security level has occured.
<Mez> 6.1.2
<Mez> hey bill!
<Mez> :-)
<maritzaj> in 6.1
<Mez> [60]http://www.w3.org/2006/WSC/track/issues/137
<maritzaj> No claim is made about the effectiveness of these signals
<tlr> hal, can you scribe?
<tlr> hal?
<tlr> ScribeNick: hal
PHB: Identity signals are so weak users give password away even if told
it is aphishing cite
... but still is worth doing
... if you are most vulnerable help deskk calls go way up increasing
cost
... need to look at all costs, not just fraud
tyler: current signals not sufficient?
phb: need to give usable instructions
... other problem is when you know one signal is hard to change
... phishers create concern about security
... can't determine effect in usability tests
tyler: phil may be right about reducing calls, if so I would still not
recommend
serge: +1
mez: disagree
<serge> we're arguing real security vs. perceived security
rachna: trying to figure out what conforms and does not
... anything which is static will be copied by attackers
phb: so far we are only talking about English language
mez: agreement users can not deal with URLs
tyler: cannot even deal with domain names
serge: disagree with requiring EV certs
<Mez> enable users to come to a better understanding of the context
that they are operating in when making trust decisions on the Web;
mez: do static indicators do this?
tyler: no
rachna: users could be trained
<Mez> A W3C Recommendation that specifies a minimal set of security
context information to be made accessible to users, and best practices
for the usable presentation of this information;
maritzaj: putting it in primary chrome may not be good idea, but should
make recommendation about secondary chrome
phb: web has no clear instructions
6.2 Additional Security Context Information
<Mez>
[61]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
phb: agreeing with Tyler that users will respond if integrated with
task
... like petname tool
... preferable would be like cardspace
... strong signal to user
... a part of task, e.g. banking
... if not present user knows they have to pay more attention
rachna: approaches are opposite
<Mez> it's time to stop
<Mez> for the day
rachna: identity signal vs. cardspace approach
serge: when users see sites marked as untrusted that they know are
trustworty, will undermine signal
... initially most sites will not be trusted
Summary of Action Items
[NEW] ACTION: thomas to change editor's draft as outlined above
[recorded in
[62]http://www.w3.org/2008/02/06-wsc-minutes.html#action01]
[NEW] ACTION: thomas to propose lang about currently interacted primary
chrome always visible on screen [recorded in
[63]http://www.w3.org/2008/02/06-wsc-minutes.html#action02]
[NEW] ACTION: thomas to replace 9.3 by text above [recorded in
[64]http://www.w3.org/2008/02/06-wsc-minutes.html#action03]
[NEW] ACTION: thomas to update 9.2 with statement above [recorded in
[65]http://www.w3.org/2008/02/06-wsc-minutes.html#action04]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [66]scribe.perl version 1.133
([67]CVS log)
$Date: 2008/02/27 14:16:30 $
References
1. http://www.w3.org/
2. http://www.w3.org/2008/02/05-wsc-irc
3. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0019.html
4. http://www.w3.org/2008/02/05-wsc-minutes.html#agenda
5. http://www.w3.org/2008/02/05-wsc-minutes.html#a
6. http://www.w3.org/2008/02/05-wsc-minutes.html#b
7. http://www.w3.org/2008/02/05-wsc-minutes.html#c
8. http://www.w3.org/2008/02/05-wsc-minutes.html#d
9. http://www.w3.org/2008/02/05-wsc-minutes.html#e
10. http://www.w3.org/2008/02/05-wsc-minutes.html#f
11. http://www.w3.org/2008/02/05-wsc-minutes.html#g
12. http://www.w3.org/2008/02/05-wsc-minutes.html#h
13. http://www.w3.org/2008/02/05-wsc-minutes.html#i
14. http://www.w3.org/2008/02/05-wsc-minutes.html#ActionSummary
15. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html
16. http://www.w3.org/2006/WSC/track/issues/new
17. http://www.w3.org/2006/WSC/wiki/WriteGoodIssue
18. http://www.w3.org/2005/Security/wsc-charter
19. http://www.w3.org/2006/WSC/wiki/SuccessBaseline
20. http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-crazy-ideas/
21. http://www.w3.org/TR/wsc-usecases/
22. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
23. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-interactively
24. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-certerrors
25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
26. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
27. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-indicator-images
28. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-login-pages
29. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
30. http://www.w3.org/Guide/
31. http://www.w3.org/2005/10/Process-20051014/
32. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
33. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
34. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
35. http://www.w3.org/2006/WSC/track/issues/95
36. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0233.html
37. http://www.w3.org/2006/WSC/track/issues/131
38. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0246.html
39. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#whack-a-mole
40. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirements-robustness
41. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#definitions
42. http://www.flickr.com/search/?q=padlock&w=all
43. http://www.flickr.com/photos/roessler/107144618/
44. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis
45. http://www.w3.org/2006/WSC/wiki/NoteMozillaCurrentPractice
46. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath
47. http://www.w3.org/2008/02/06-wsc-minutes.html#action01
48. http://www.w3.org/2008/02/06-wsc-minutes.html#action02
49. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-consistency
50. http://www.w3.org/2006/WSC/track/issues/162
51. http://www.w3.org/2008/02/06-wsc-minutes.html#action03
52. http://boblord.livejournal.com/1538.html
53. http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-crazy-ideas/
54. http://www.w3.org/2008/02/06-wsc-minutes.html#action04
55. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
56. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#levelchange
57. http://www.w3.org/2006/WSC/track/issues/114
58. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#weak-tls
59. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content
60. http://www.w3.org/2006/WSC/track/issues/137
61. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
62. http://www.w3.org/2008/02/06-wsc-minutes.html#action01
63. http://www.w3.org/2008/02/06-wsc-minutes.html#action02
64. http://www.w3.org/2008/02/06-wsc-minutes.html#action03
65. http://www.w3.org/2008/02/06-wsc-minutes.html#action04
66. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
67. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 27 February 2008 14:18:12 UTC