Web Security Context Working Group Face-to-Face Meeting

06 Feb 2008

See also: IRC log, Agenda


Thomas Roessler, Mary Ellen Zurko, Serge Egelman, Yngve Pettersen, Rachna Dhamija, Tyler Close, Phillip Hallam-Baker, Bill Doyle, Maritza Johnson, Hal Lockhart, Ian Fette
Tim Hahn, Stephen Farrell, Anil Saldhana, Johnathan Nightingale, Dan Schutzer, Mike Beltzner, Luis Barriga
yngve, PHB, tyler, maritzaj, serge


<trackbot-ng> Date: 06 February 2008

<maritzaj> Dear Friend

<maritzaj> Please make a hotel reservation for me and tell me the nearest airport to you and await for my arrival.This is a transaction of $11m (eleven million USD) from a genuine source and duly certified.It is my inheritance with full legal right.

<maritzaj> I trust that with you I will be able to invest on the right business to maximize profit and grow my money.I am not resident in your country,pls be my partner,receive me well and 20% of the total fund is for you.Trust me.

<Mez> hi, we'll call in

<Mez> who's aaaa?

<hal> http://www.baselinemag.com/c/a/Security/Survey-Users-Believe-Internet-Is-Safer/?kc=BLBLBEMNL020608STR2

<ifette_GOOG> Has the meeting started?

<serge> yeah, you're late

<serge> wouldn't want to be in bad standing...

<ifette_GOOG> lol

<ifette_GOOG> you're having fun Serge, aren't you?

<serge> I'll take what I can get

<Mez> gm ian

<ifette_GOOG> gm mez

<Mez> how's santa monica?

<ifette_GOOG> Santa Monica is quite beautiful

<serge> so then why the hell are you calling in?

<Mez> ian, always gracious....

<tlr> ScribeNick: yngve

5.1.3 Augmented Assurance Certificates

mez: impression from yesterday, did not put any of the sections to bed
... use rest of day to figure out what can make it to last call

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

section 5.1.3

<Mez> Implementations MUST NOT use Relaxed Path Validation if the trust anchor is AA-qualified.

<Mez> Web user agents MUST establish that a trust anchor is [Definition: AA-qualified ] through some out of band mehcanism consistent with the relevant underlying augmented assurance specification.

<Mez> Marking a trust anchor as AA-qualified is a security-critical step and most often will involve the use of some application-specific out-of-band mechanism.

serge: adding roots, setting EV status in IE?

phb: user can add roots, may set EV status

<Mez> gm Audian

<Mez> come on by! :-)

<Audian> will see....can't be until later in the day

<PHB> OK problem with the definition here, the must should not be in the definition because it is a definition

<Audian> but I'll keep my eye on 'yous' guys via IRC

<PHB> A certi is augmented assurance if and only if it has been validated with strong path validation, chains up to marked root

<PHB> The MUST needs to go in a statement to the effect that browsers MUST NOT present a non-Augmented Assurance cert using the distinguished presentation reserved for AA

<tlr> ACTION: phb to write replacement text for 5.1.3 [recorded in http://www.w3.org/2008/02/06-wsc-irc]

<trackbot-ng> Created ACTION-387 - Write replacement text for 5.1.3 [on Phillip Hallam-Baker - due 2008-02-13].

5.1.4 Self-signed Certificates

<Mez> The same SSC SHOULD NOT be considered proven for more than one web site.

rachna: Are words like probation period defined in the section?

mez: yes

tlr: two ways to read: only one server per certificates, or 2) being proved is scoped for a single server, seeing it again for another host restarts probation period for that particular host

mez: section 5.1.4 connected to sec 5.1.5

<discussion about meaning of 5.1.5 SSC language>

phb: what about a SSC on a host with multiple SSL servers?

tlr: probation for each hostname:port and SSC combination, independently

hal: SSC language contradicts validation languge earlier in the section

tlr: language/defintions may be improved

hal: want some consistency in the section

tlr: language tries to capture both ordinary certificates and the exceptions, but is confusing and must be improved

tyler: probation period is new, why not ask user like SSH does?

<hal> probation period is actually number of interactions

<rachna> issue: 5.1.4 definition of "probation period" does not specify whether it is time period, number of interactions, user prompting and when user is prompted

ifette: when does the clock start ticking? e.g. inline secure image in a otherwise OK page

<ifette_SMO> I think the issue is not what browsers currently have the ability to do, but what we want them to do (obviously provided that it's feasible). We don't really seem to have an answer to what we want them to do

yngve: UAs have varioius ability to remember user OK of problem certs. Opera 9.50 can accept until expired and in periods of 90 days after expiration

ifette: what does visiting X number of times means, e.g. when a inline image is used?

<rachna> tyler: 5.1.4 algorithm for what constitutes probation period in this section is not fully baked. Hal agrees this working group should not specify algorithm

tyler: first time may be best time to accept

tlr: first time will pin the cert and domain name

ifette: use case?

<Mez> ian: what's the use case of waiting for a number of accesses being the right and desirable thing to do?

<tlr> You access https://... from behind a captive portal.

rachna: what happens in MITM situations?

tlr: warning would be displayed

hal: can't think of any cases were probation is useful

mez: put probation on hold, but use hostname binding

<Mez> The same SSC SHOULD NOT be considered proven for more than one web site.

<ifette_SMO> ACTION: tlr to update definition of 5.1.4 [recorded in http://www.w3.org/2008/02/06-wsc-irc]

<trackbot-ng> Created ACTION-388 - Update definition of 5.1.4 [on Thomas Roessler - due 2008-02-13].

<tlr> Change 5.1.4 to drop explicit probation period.

<Mez> The period starting from the time when a particular SSC and web site are first seen by a Web user agent, until that SSC and web site combination is considered (by the Web user agent) to be sufficiently secure is the [Definition: "probation period."]

<Mez> drop that

<Mez> drop for longer than the probation period.]

hal: three cases: Ordinary, AAC, proven. Are all equally good?

serge: is there an user interaction for SSC?

<yngve> yes

serge: have problem with mandating user interaction, should mandate how it should look so that it is different from worse errors

<rachna> if user is going to agree to accept a SSC cert or to trust a SSC, we should specify how errors or consent is obtained

<rachna> hal: yes-an OCSP error for a revoked cert should not generate the same error as a SSC cert

tlr: drop down passive indicator offering possibility to pin SSC to domain

<tlr> Memo to self: Add material to 5.1.4 about interaction for accepting certificates.

<tlr> (Part of ACTION-338)

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

<rachna> how many categories of certs do we have? EV 1) augmented assurance 2) validated certs that chain up to a trust root 3) SSC that are proven 4) blah 5) blah 6) no TLS

<rachna> hal: where does relaxed path validation fit?

<ifette_SMO> Please, no more categories

<ifette_SMO> this is hard enough to understand as is...

<tlr> 2 and 3 are the same

<ifette_SMO> are 4 and 5 equivalent?

<tlr> 4 and 5 is the same; innocuous validation problems / SSCs

<tlr> 6 no TLS

<tlr> 4-6 have essentially same interaction

<serge> I don't think we should distinguish between "proven" and "unproven" SSCs

<rachna> hal's summary: we have 3 categories 1) AAC EV 2) fully checked TLS 3) everything else

<rachna> hal: and user can decide to move things in third category into 2nd category...

yngve: with no interaction SSC user may still trust https part of the URL


<rachna> tlr: two classes of errors 1) path validation that failed on the way to root 2) path validation to unknown root (equivalent to SSC)

serge: need to be distinction between unverified cert and cert errors like revoked and expired

tlr: some errors are innocious
... main non-fatal errors in basic validation is expiration and revocation
... expiration is innocious when revocation is not checked

phb: no reason to distinguish, either a chain is valid or not
... attack:phishing gang get certificate, waits until it is expired, then starts using it, new alg will not check expiration

tlr: summary what cert problems should be treated as innocius?

tyler: problem when previously accessed full cert server changes to use SSC (e.g due to attack)

tlr: change of security history errors handle that

<hal> PKIX path validation: http://www.ietf.org/rfc/rfc3280.txt - section 6.1

<yngve> New cert remembering functionality in Opera 9.50: http://my.opera.com/yngve/blog/2007/12/21/new-w-not-in-kestrel5

MEZ: The relationship between change 'o security level and the various categories of certs we discussed

takes us back to 5.3 again

Serge: did we agree on anything?

Rachna: ... we agreed to clarify sections 5.1.???

<ifette_SMO> the beach is soooooo nice...

<serge> ifette_SMO: you're still in LA, so I'm not particularly jealous

tlr: what do we want to say on non fatal errors

<ifette_SMO> I'm in Santa Monica, not LA

<serge> same thing

TLR: can live iwth if trust root is unknown then ...
... That then means that Error handling for expired certs may become sharpetr than today

serge: creating different classes of error messages, seems that there are some errors more severe than others

get consensus on there should be various levels of errors

Rachna: suggests errors that should result in user notification and those that should not

serge: interested in warnings, there is actually n ANSI standard for warnings

Mez: should we classify them according to the type of advice?

Serge: yes absolutely

Mez: do we have a place to hang this already?

serge: what I would like to see is a unified browser errors

Mez: can you write it up

<serge> http://www.safetysign.com/CLDR.asp?PG=ANSIStandards4

<scribe> ACTION: Serge to write up error levels [recorded in http://www.w3.org/2008/02/06-wsc-irc]

<trackbot-ng> Created ACTION-389 - Write up error levels [on Serge Egelman - due 2008-02-13].

<rachna> phil: distinguish things that aren't worth mentioning, things that inform and things that require a warning (e.g. attacks or where use is at risk)

yngve: have not seen use of these codes for revocation reasons much, main one was out of business

<Zakim> Thomas, you wanted to ask a practical question

tlr: we have an item in 5.1 that might merge into 5.4. My action items stall on Serge completing ACTION-389.

serge: definitions we need to have a section then map it into the various sections

Rachna: I think we agree

<yngve> revocation: http://my.opera.com/yngve/blog/show.dml/508407

Ifette: might not agree on the fine detAils

serge: notice, purely informational should not popup and annoy the user
... there are multiple levels, what you provide in the various levels..

tlr: and please look at 6.4 while you are doing that

serge: m paper on phishing warnoings aout to go to print

tlr: when do I time out on you

rachna: just do it right now

tlr: end of next week or the week after next
... will time out on you on monday

<ifette_SMO> 2/18 is a holiday

serge ok

<ifette_SMO> presidents day

5.1.6 Logotype Certificates

Mez: on to 5.1.6

Have some definitions but only one line of normative language

<Mez> SSCs MUST NOT be considered logotype certificates.

tlr: can put it in 5.1.6 ot 6.? where it goes can be left to the editor

need to be consistent - do not allow SSC and require EV should be in the same place

hal: we don't use these definitions

mez: yes we do, so there, spell community correctly

hal: only use of community is in this waffly statement
... we don't seem to make use of the distinction

6.1.2 we might

RESOLVED: TLR to move pieces about and PHB to check result

<Mez> serge, you have noticed we have consulted WAI on a number of handicapped accessibility issues, right?

rachna: is there any must?

5.2 Types of TLS

mez: definitions get used later and become more interesting
... not going to do 5.2?

tlr: probably useful to sumarize for a moment...
... call something strongly protected in certain circs. and weakly protected otherwise..

rachna: this is qualifications in the second bucket...

tlr: two top buckets: AA, strong but not AA and a bottom bucket with errors, compromises etc.

tlr have buckets for certs and for how they are used

tlr: can have a fine EV cert but a weak algorithm

hal: we got hung up on some group of wise men should decide what is weak...

Mez: someone said SSL desired by specified HTTPS by typing it in

TLR: have that as a separate definition because there might be cases when someone was following a link but came up on a less than secure site.
... don't think we need this now we have knifed no interaction certs

PHB: aren't SSC effectively the same?

TLR: gets close but not so much

MEZ: ok that is it for 5.2

5.3 Change of security level

TLR: hard error, cert validates but path does not match,

HAL: had a problem

MEZ: it was with the name change of security level

hal: change of security level can happen even without an error
... should decide how we are going to use this definition and then come back

mez: 5.3.1
... these look like what Serge?

Rachna: this is validated certificate in that category

TLR: we have a cert for which we know the trust root therefore validated
... know the trust root either because we know the root, its a known CA
... signature fails, URI is wrong, whatever..
... we believe that trust root is valid but path validation fails

Rachna: why not certificate error

TLR: happy to change

5.3 renamed to error conditions are we done??

PHB and we come back to change in security level discussion

5.3.2 Redirection chains

Mez: 5.3.2

<tlr> ifette, we're in 5.3.2

ifette: redirection chains, what concerns me is third bullet: I am on some shopping site, get redirected to verified by visa. this should not be a problem, we should not throw up warnings here.

<serge> do we actually have data on how widespread this is?

ifette: regardless of if it is a good practice it is growing if we say throw up warnings, it is not going to fly

tlr: the conditions are AND ed, all must apply
... the point is that if I am in a TLs environment, I have a redirection path to a possible man in the middle attack

ifette: we need to make the spec clearer

<scribe> ACTION: tlr to make it so [recorded in http://www.w3.org/2008/02/06-wsc-irc]

<trackbot-ng> Created ACTION-390 - Make it so [on Thomas Roessler - due 2008-02-13].

yngve: does different web site also include different port on the same server name: in my opinion it should

hal: I think it depends on whether it is a regular cert or a promoted cert or an ev cert

rachna promoted cert is a good term

tlr: i like promoted as well
... don't care which way we go would like input

hal: don't normally use port

yngve: connection is to given host and port

tlr: for self signed certs pin them to a specific port, for domain and EV we don't
... OK

rachna: we going to remove the change of level stuff throughout 5.3.2 then?

mez: yes

tlr: you are an SSL site, you go to a redirect through five HTTP sites to a new SSL site so that the user can be redirected to a site of the attacker's choosing

tyler: the indicators only reflect the curent state, not how you got there

rachna: now I know the change of security levels relevance

mez: don't have worked out this category of errors

rachna: I don't even know if this is an error

mez: this is the least of them, the category error (as opposed to warning)
... need a name for this indicator, call it a Fred.
... strongest is going to be Dont do that, middle thatmay be fine, lowest blinking something

ifette: are we fine that the lowest level is going to be noted, do we tell the user about te indirect reditrect

mez: since we don't have a lotta concrete detail

hal: we should withdole judgement until we have something

ifette: didn't want us to assume that all levels are woth notification

tyler: this chan of redirect seems to have the same seto of issues as the page with included insecure items.

bill: if you are on data that you expect to be https and you find you are not that is an issue

yngve: if an attacker changes the url in mid flight, changinmg content inside a page can change the way the content is protected but not the action made by the page.
... depends on how the site is defined ...
.... opera is treating both the same ...

ifette: one more thing that might come up, might be the case that I want to protect a logon page on HTTPS but don't want to protect everything else. Under this we create an error.

yngve: you heard the side-jacking discussion

ifette: ok will read the minutes when they are out
... just wanted to raise the fact that I may have an issue

tlr: I think we are clarified I am not sure that we are in agreement

yngve: looks like it might need more work and it is not yet ready

tlr: concrete proposals?

tyler: should have a concrete proposal for how we handle mixed content.

phb: mixed content really really sucks

yngve: IE7 tried to prohibit mixed content, could not do that,

<ifette_SMO> I read the minutes from yesterday around 23:00 and I'm still very unsatisfied

yngve: issue was javascript, links to google analytics.
... that caused Microsoft to back off before IE7. ...

rachnado not want to cause disincentive to use TLS

<ifette_SMO> I do not agree with the 9.3 replacement text

tyler: before people wanted to use SSC and just not present the security indicators

yngve: that is what most browsers do today

rachna: raises LUNCH!!!!!

Mez: is thisagoodstoppintime

Mez break for 1hr to 1:15

<Mez> ian, if you like, you can also log an issue related to the email you'll send (or vice versa). that being the way to be sure nothing ever gets lost

<ifette_SMO> grabbing food, back in a sec

<ifette_SMO> back

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

<serge> ScribeNick: serge

tlr: it's specified it applies to both <reads...mumble...mumble>

tyler: if you end on an HTTP page, a change of level has occurred?
... regardless of redirects you get an error here

ifette_SMO: worried about common use case warnings

yngve: should include meta-refresh, etc.

tyler: do we agree this should be discouraged?
... to deal with errors on good SSL sites, raise the error earlier
... on the TLS, go to HTTP, nothing happens, stop when it tries to go to TLS

yngve: websites will find out, and then find it's not good and redesign

Mez: why is this insecure?

bill-d: attack happens when page was downgraded
... but we're talking about wwarning on the re-upgrade

Mez: sounds like this ends up in the middle vcategory of warning?

yngve: or separate category for augmented to non-augmented

tyler: wwhy not just break the redirect?

ifette_SMO: get on the queue
... if we break it, people will switch browsers

rachna: what about the converse? HTTP->TLS->HTTP?

yngve: there should be a link instead of a redirect
... from HTTP to TLS

ifette_SMO: happens all the time

yngve: what about EV->TLS->EV?

ifette_SMO: but there's no risk of MITM

yngve: but there's no assurance

tlr: I can argue both ways

ifette_SMO: are we tabling?

Mez: speak now or forever hold your peace

tlr: TLS continuity, indicator for site changing in the future
... 1) is the part abotu strong to weak the same?
... 2) is the part about <something something> the same?
... 3) augmented assurance

<Zakim> ifette_SMO, you wanted to complain about EV -> TLS

rachna: go from TLS to no TLS..

<Mez> issue-114 is likely to map to the middle notification category to be produced by serge

<Zakim> ifette_SMO, you wanted to give information I couldn't give earlier

<ifette_SMO> back

<Mez> we're trying to start again, but not everyone is back

<ifette_SMO> I might be able to work more once I hit LAX, but I fear that the bus ride from Santa Monica to LAX, plus the security line etc, is easily going to eat up 2h

Section 6

<tlr> ScribeNick: tyler

rachna: Does the URL count as an identity signal?

Mez: No
... trace back the definitions in the spec
... anywhere a URL appears should be accompanied by an identity signal
... derived from useful data is better than a URL

<PHB> task centered

<Zakim> PHB, you wanted to say actually people seem to think the opposite

<Mez> I've got two issues there

<Mez> one is that the url is bad. if it wasn't there as the only "source", then I wouldn't feel th eneed to counteract it

phb: we don't want to give more raw information

<Mez> so I'd love a proposal to take it off, but I believe it won't fly

phb: but sometimes things are hard to use because there's not enough information available
... sometime the information is left out because someone thought it would just confuse me

<Mez> the other issue is, I live in product lang. We fight to the death for every bit of information in the UI. Which means we all believe it's meaningful

<Mez> and my third issue about phishers going to some amount of trouble to get urls that look plausible

<Mez> I realize that's just restating the same stuff

maritza: 6.1 is about primary chrome and 6.2 about secondary chrome?

mez: yes

maritza: 6.2 is something I would support but not 6.1

mez: should we do 6.2 first?

rachna: Don't current web browsers comply with 6.2?

tlr: Some of the information is not easily accessible
... for instance OCSP results are often not available

mez: How do I get this info on IE6?

tyler: In Firefox, right click and select "View Page Info"
... I have a later version of IE

mez: IE6 seems like it is non-compliant with section 6.2.

serge: much of this information only applies to AAC pages
... we should better define what the display should be for non-AAC pages

mez: In the spirit of consistency I'd like there to always be some display
... (looking at the Opera display) I would say this is also non-compliant since it doesn't provide an answer for each of the items highlighted in 6.2
... Can you have a validated certificate when OCSP has not been done?

serge: Can an AAC certificate specify no OCSP or CRL?

tlr: 3280 is very wiggly about revocation checks

phb: we include this information in all our certificates
... some brands have never revoked a certificate
... a godaddy certificate can never be out of compliance
... you have to produce a CRL to be compliant with 3280, but you don't have to distribute it

(much laughter)

yngve: we did treat this as an error, but we don't anymore because there were too many errors
... the OCSP responder was always responding with errors

<serge> yes

<serge> you?

tlr: some hotspots require a payment before use, but will not let through an OCSP check

yngve: we don't display logotypes at the moment... there is no MAY there

<Mez> issue-141

<Mez> issue-141?

<trackbot-ng> ISSUE-141 -- More history that may be part of additional security context information -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/141

phb: We need to distinguish between subject logos and issuer logos in bullet 9
... suggest splitting this into a separate bullet point for each
... the issuer field is always augmented assurance
... it is expensive to get the audit needed to be included in the shipped CA set

tyler: This auditing has not necessarily been done for CAs the user has manually added

phb: true

yngve: Should a CA cert not distributed by the browser vendor have its logotype displayed?

phb: my kids are not allowed to install CAs

yngve: I think we need some language distinguishing vendor provided versus user provided certs

phb: the issuer logo is pulled from the end-entity cert
... root CA certs change hands from time to time
... since the brand changes, the logo changes

<ifette_SMO> 6.3?

mez: any more issues on 6.2?

tlr: back to 6.1?

mez: Some people think no recommendation about primary chrome, some yes?
... none have recommended a negative recommendation about chrome

rachna: Didn't we have a SHOULD NOT about letting the web content populate the chrome?

serge: favicons

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

rachna: some users who don't understand the URL look for something they can understand, such as the page content and the window title

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

<ifette_SMO> +1

<Mez> if I thought we'd actually do ut I'd agree with serge

<Mez> but we've been dragging our heels on that for a long time

tlr: Is serge saying we need user studies on SHOULD NOTs in this section before last call?

<ifette_SMO> speaking of which

<ifette_SMO> are we covering 6.3?

mez: I think we need a lo-fi prototype before last call. Otherwise we don't know what we're talking about

tlr: I agree

(general consensus in room)

mez: We need some more alternatives listed for 6.1

<ifette_SMO> cacophony

<ifette_SMO> 3 different conversations

<ifette_SMO> or maybe 4

<ifette_SMO> I'm so lost

(side conversations prevade)

(side conversations pervade)

<Mez> blah, blah, blah, blah

mez: We need to line up the set of proposals we have.

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

tlr: if we don't have the identity signal in primary chrome, there needs to be an easy way to get to the secondary chrome

mez: I don't see consensus yet on 6.1

<ifette_SMO> +1 to removal

page security score

serge: this is just a bad idea, let's drop it

rachna: a binary page score is like the padlock

<tlr> http://www.w3.org/mid/OFE66F7E8F.2BB71D93-ON852573D9.0050788D-852573D9.00532917@us.ibm.com

<tlr> ... that's Tim Hahn's proposal

mez: Let's go to Tim Hahn's rewrite

<ifette_SMO> I seem to still be unhappy with the rewrite

mez: need to have a conversation about what we'll do with this for June
... because of the similarity with padlock

yngve: Opera's old padlock was an implementation of a page security score based on encryption level and other problems with the certificate
... the latest version puts EV at level 4
... we only show a padlock with level 3 or above

<serge> ...it goes up to 11

yngve: we show this information in secondary chrome

mez: Is there a security confidence estimate?

yngve: no
... but there is a fraud control check, that is similar to that concept

fette: this proposed text resulted in a long email thread on the list, which left me still feeling this would not help users

serge: I firmly believe this is a terrible idea
... but if we do recommend, if every browser uses a different page scoring algorithm that would be strange

hal: same goes for the weatherman

fette: a lot of people are unhappy with the weather analogy

serge: how about making it like the homeland security color coded scheme
... how long has it been on orange
... it doesn't mean anything
... for example the netcraft toolbar always includes a portion of red just in case

hal: the major sites are all solid green

serge: google once got a smidgen of red

hal: they are using a blacklist, where as the current proposal is based on collected information at runtime
... it's more heuristic

serge: maybe all the time is useless to users

mez: No one has argued that it's not current best practice
... is some indicator which is at least binary considered a current best practice

fette: no
... I feel like all we've done is talk about stuff related to SSL, not whether or not I should trust this site
... nothing better than the padlock, so don't think we should recommend anything

phb: even if 95% of the population is not helped by this control, doesn't mean we shoudn't help the other 5%

<Zakim> ifette_SMO, you wanted to say that cluttering the screen for 5% is not necessarily good...

phb: level of trust needed for slashdot is different than for my broker

fette: That 5% doesn't need our help
... clutter
... better to use the space for content

phb: less appealing for the browser vendors, but not a less desireable practice
... user behavior today and after education may be different
... we don't have any good education to give today since the current interface is so hard to use
... so may be the other 95% will learn

<Mez> I don't see how recommending exactly what browser vendors are doing today makes it less appealing for them

<Zakim> ifette_SMO, you wanted to say that less appealing for browser vendor means less likely our spec gets adopted

fette: don't think the other 95% will learn since they didn't learn from the padlock

phb: learn what?

fette: they could click on the lock and see the cert details
... could learn how to parse a URL

tyler: they could also learn how to use ethereal to examine the raw packets ;)

<serge> +1

mez: put on the agenda for next week a discussion of lo-fi prototypes for page security score

<ifette_SMO> tyler, that would make me so happy ;-)

maritza: need a concrete proposal

rachna: if we use the lock icon as the lo-fi prototype there will be pushback

<Mez> a - would lean towards a recomendation that SHOULDed something like the padlock that displays SSL state

<Mez> b - lean towards SHOULD NOT type rec on same

<Mez> c - something else in this space, say what

<ifette_SMO> c - say nothing because I don't think we have anything useful to say beyond the existing SSL information

<yngve> a

maritza: they want something much richer than just the padlock

<Mez> a

<hal> c - sce

<bill-d> c

<bill-d> c - sce

<tyler> b since info about the SSL connection strength is more likely to give the user a false sense of security, as the padlock icon currently does, as seen in usability studies

<PHB> c - sce

<tlr> a, maybe a c -- I'd like something that talks about SSL strength, but with additional information. (I.e., I'm not sure how to parse the question.)

<serge> a

<serge> what about an indicator to indicate lack of SSL?

<maritzaj> c - ssl state should be available somewhere in a consistently displayed way ...

<serge> does a) preclude that?

<rachna> I could say anything that states binary static indicators don't work. to recommend anything more, I would need details on the implementation or proposal.

<tlr> mez: rachna, "don't do it" is a "b"

<tlr> rachna: yes

rachna: b since it's a static indicator

<maritzaj> A

<maritzaj> you guys are all freaking insane

<serge> a = should we indicate the presence/lack of SSL?

<maritzaj> then yes

<maritzaj> A

<maritzaj> something about ssl somewhere for somebody who cares

<ifette_SMO> really?

<ifette_SMO> modulo ian as well

mez: The straw poll tells me that it's possible to construct a low bar proposal that will achieve consensus

serge: an indicator for lack of SSL would be good

rachna: but most sites don't use SSL so the cue would lose its meaning

serge: yes

fette: want to see sample displays, plus the input to the algorithm
... I think the current inputs are the same as for the lock

rachna: I would also like to see the distribution of how often each indicator appears for each site

serge: we might be able to make the padlock slightly better by inverting its meaning
... banks won't put this indicator on their login pages

rachna: phishers won't try to spoof it

<serge> ....unless they're stupid

<serge> BoA might use it


<ifette_SMO> Hi Ho, Hi Ho, it's off to LAX I go...

<tlr> ScribeNick: maritzaj

mez: let's do another section, talk logistics, then go home

6.4 Error Handling and Signalling

rachna: is this the section that Serge is rewording?

mez: which ones interrupt the users flow of action and which don't, providing a nontech explanation is a good idea

rachna: what's being able to get back to the prior state

tlr: getting back to the state you were in before the error

phb: these are things you shouldn't need to test

tlr: don't interrupt for the lower class of errors, do for the heavier, make sure you don't throw away state too early
... and explain things reasonably
... and don't refer people to the page they can't access without agreeing to something

<serge> here, I mocked up some security score indicators:

<serge> http://www.guanotronic.com/~serge/security_score.png

<serge> http://www.guanotronic.com/~serge/security_score2.png

mez: sounds good, serge will be refining it

serge: i agree with this, but i plan to mostly rewrite this
... i don't like the fact about saying weak tls

tlr: i'm happy to have a layer of indirection between them

serge: these are the types of warnings, these do this

6.4.2 Handling certain man in the middle attacks

tlr: assume there's a mitm attack, but the url doesn't match the cert, so it might be the course of action to let the user go to the url that you may derive from the cert

mez: so you want to go to the url of the attacker?

tlr: yes

tyler: no. time to duck and cover

bill: yep

mez: is there something we should sub for these issues?

bill: why follow it?

tlr: you may want to go there, there is an intercept, you are talking to a specific server, not the one you wanted, you might want to connect to that server
... and yes, this is all nasty
... if people think it's too unsafe i won't put up a fight

phb: we're talking about subject information, there's the subject domain name and another for the name, so IETF argues over which should be used, most CA's populate both
... one's the standards, one's what browsers use

Section 7

mez: let's save 7, we'll do 8/9

8. Robustness

mez: 8.1.2 has the first normative text

rachna: i don't understand 8.1.1

<Mez> issue-112?

<trackbot-ng> ISSUE-112 -- Conformance models for usability? -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/112

tlr: let's throw it away if we don't need it

<Mez> issue-173?

<trackbot-ng> ISSUE-173 -- 8.1.1 Requires user testing for the purposes of conformance -- OPEN

<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/173

serge: understand the intent, but the wording isn't right
... the intent is, the website shouldn't be able to put in a lock icon or green url

bill: why did developers put logins into an http page not https then call it secure

mez: that's section 5

rachna: serge wanted to remove 8.1.2 and no one objected

serge: then what do we replace the title with?

rachna: website provided content goes in one place, everything else goes somewhere else

bill: i agree with that

serge: what else is there

rachna: status bar, title bar, the tabs, the favicon

phb: the titlebar and the tabs compete
... we can agree that the titlebar should only show text that's reliable

rachna: i don't know for sure if we should give up the title bar, it was a straw man
... it's there for a reason

bill: well there's something that's informational, but then there's the security context info

<Mez> ack +

serge: so part of the problem is the url bar
... homographic attacks, bad directory structure

tyler: the cert can be misinformation too

phb: gives a way to bind the attacker and the domain

rachna: maybe instead of chosen and not chosen we can say verifiable and not verifiable

seems like people agree, no yelling

hal: you mean it should be verified, the information was verifiable and has been verified

bill: you've been through the vetting process

hal: in the real world there's some level of accountability, there's a real business address that you can find

rachna: are we saying only ev cert go into chrome

hal: a lot of time in the 90s was spent on how to have a transaction between two parties that have never met
... there are people you can catch and people you can't

tyler: i agree with all this, but when phb pitches ev certs, he wants the green bar for ev experience and the subject name

phb: case 1, you've never done business
... case 2, you have
... in the second, it's useful for matching the online identity to the offline identity

rachna: but when there's no ev, what's displayed

tyler: i was saying there's a useful rule for ev under that specification language

rachna: so what you're saying is nothing gets into the chrome don't isn't verified

tyler: no, only the verified gets into the chrome

phb: in ev there's also the authenticated identity that they're accountable for

rachna: but ev certs won't be on every site, then what happens

bill: you can use a verified cert

rachna: but most webpages don't have those

bill: you dont know, and that's the problem

rachna: i think attackers will put whatever the icon is into the content

bill: but you have the secure chrome

rachna: so you've created the perfect environment for ev certs, but haven't solved the problem

serge: i have an idea to solve this, get rid of chrome
... the problem will get so bad, the banks have to use 2 factor

hal: they're starting
... JP morgan, deustche bank, in europe it's huge

tyler: under the current language, big banks could use ev certs and the users would be safe

rachna: and it won't work

tyler: that's why we need to integrate safe form editor with ev certs

<Mez> 8.1.2 - yes to keep, no to remove

<maritzaj> 1

<Mez> Web User Agents MUST NOT communicate material controlled by Web content in facets of the user interface that are intended or commonly used to communicate trust information to users.

<yngve> yes

<Mez> 1 is yes, 2 is no

<tyler> yes

<bill-d> yes

<tlr> abstain

rachna: i still don't see how that's provided by the website owner, the cert info

<serge> no

<PHB> yes

serge: it seemed like everyone agreed this would overhaul current chrome

<hal> yes

yngve: this might need clarification on what chrome we're talking about

<tlr> so, as far as I'm concerned, yes, but with clarification

<rachna> yes- that security indicators that aren't mixed (but I am not sure about recommendation that only verified content be presented in chrome)

<Mez> no

<Mez> yes - maritza, yngve, tyler, bill, phb, hal, rachna

<Mez> no - serge, me

<Mez> abstain - tlr

<serge> The strongest man stands alone.

tyler: what are your issues that we have to overcome

mez: it's too much to overcome

tyler: for me this works only if i can convince the mozilla guys to go with

hal: i'm expecting some very definitive instances of usefulness

serge: so studies have been done that content is more important to users than content
... i would concede that allowing anyone can put anything in the title bar

<PHB> give the users a fighting chance!


mez: we have a variant we're directing toward last call in june, need to go over section 7, 8, 9
... tlr as an editor is going to branch them?

tlr: at one point we need to fork into 2 documents, maybe not right now, or put the split within the document, appendix: this isn't in last call, but it'll stay for now
... we fork it before last call
... then we have a coherent second document

tyler: i'd rather split it, then we can refer outsiders to the document without them getting sidetracked

mez: we've done some changing and improving SCE will need some work

tlr: i basically agree, i just don't know it's the next step

mez: let's talk heartbeat reqs, we're behind

tlr: tim said it's all ok

mez: we're about to put usecases to bed
... back to xit, the next heartbeat is now

tlr: go through minutes
... i'm tempted to hold on to the draft until it's ready

tyler: when's is this due?

tlr: feb
... my expectation is to have the fixed up version of this in feb

mez: what event are you waiting for to separate

tlr: there's work to get done other than just cut and paste
... i want a working draft to show the work we've done this far

mez: has anyone reviewed xit?

tyler: firefox, opera

tlr: serge you're on the critical path now with 6.4
... fork as soon as possible, get out a working draft of june deliverable

mez: have to have a meeting on lo-fi prototypes of SCE

rachna: i don't know if we need a meeting again to discuss, without having anything to discuss

mez: if we can't produce a single lo-fi prototype we can kill it
... next meeting, may in oslo, extension in June

Summary of Action Items

[NEW] ACTION: phb to write replacement text for 5.1.3 [recorded in http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: Serge to write up error levels [recorded in http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: tlr to make it so [recorded in http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: tlr to update definition of 5.1.4 [recorded in http://www.w3.org/2008/02/06-wsc-irc]

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/02/27 14:16:30 $