Web Security Context Working Group Face-to-Face Meeting

<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> 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> 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> 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> http://www.w3.org/2005/Security/wsc-charter

<Mez> 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> http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-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> 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-interactively

yngve: this is a good practice, this is a bad practice

<Mez> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

rachna: what are they doing that we would recommend?

<tlr> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-indicator-images

<tyler> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tls-login-pages

<tyler> 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> http://www.w3.org/Guide/

<Mez> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

<tlr> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis

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

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0233.html

tyler: browser's inability to prevent applications from obscuring browser content

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

<Mez> 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirements-robustness

<tlr> 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> 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> http://www.flickr.com/photos/roessler/107144618/

<tlr> ScribeNick: bill-d

<tlr> 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath

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 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 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> 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> 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 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 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> http://blog.johnath.com/index.php/2008/01/10/standardizing-ui-and-other-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 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> 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> 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#weak-tls

6.1 Identity and Trust Anchor Signalling

<tlr> 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> 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> 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