- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 27 Feb 2008 15:17:31 +0100
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2008-02-06 were approved and are
available online here:
http://www.w3.org/2008/02/06-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
06 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, Ian Fette
Regrets
Tim Hahn, Stephen Farrell, Anil Saldhana, Johnathan Nightingale,
Dan Schutzer, Mike Beltzner, Luis Barriga
Chair
Mez
Scribe
yngve, PHB, tyler, maritzaj, serge
Contents
* [4]Topics
1. [5]5.1.3 Augmented Assurance Certificates
2. [6]5.1.4 Self-signed Certificates
3. [7]5.1.6 Logotype Certificates
4. [8]5.2 Types of TLS
5. [9]5.3 Change of security level
6. [10]5.3.2 Redirection chains
7. [11]Section 6
8. [12]page security score
9. [13]break
10. [14]6.4 Error Handling and Signalling
11. [15]6.4.2 Handling certain man in the middle attacks
12. [16]Section 7
13. [17]8. Robustness
14. [18]logistics
* [19]Summary of Action Items
__________________________________________________________________
<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>
[20]http://www.baselinemag.com/c/a/Security/Survey-Users-Believe-Intern
et-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>
[21]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
[22]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 [23]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
[24]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>
[25]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
[26]http://my.opera.com/yngve/blog/show.dml/461932
<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: [27]http://www.ietf.org/rfc/rfc3280.txt -
section 6.1
<yngve> New cert remembering functionality in Opera 9.50:
[28]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> [29]http://www.safetysign.com/CLDR.asp?PG=ANSIStandards4
<scribe> ACTION: Serge to write up error levels [recorded in
[30]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: [31]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
[32]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>
[33]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> [34]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>
[35]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dont
mix
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>
[36]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>
[37]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dont
mix
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>
[38]http://www.w3.org/mid/OFE66F7E8F.2BB71D93-ON852573D9.0050788D-85257
3D9.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
break
<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> [39]http://www.guanotronic.com/~serge/security_score.png
<serge> [40]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> [41]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> [42]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!
logistics
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
[43]http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: Serge to write up error levels [recorded in
[44]http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: tlr to make it so [recorded in
[45]http://www.w3.org/2008/02/06-wsc-irc]
[NEW] ACTION: tlr to update definition of 5.1.4 [recorded in
[46]http://www.w3.org/2008/02/06-wsc-irc]
½
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [47]scribe.perl version 1.133
([48]CVS log)
$Date: 2008/02/27 14:16:30 $
References
1. http://www.w3.org/
2. http://www.w3.org/2008/02/06-wsc-irc
3. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0019.html
4. http://www.w3.org/2008/02/06-wsc-minutes.html#agenda
5. http://www.w3.org/2008/02/06-wsc-minutes.html#a
6. http://www.w3.org/2008/02/06-wsc-minutes.html#b
7. http://www.w3.org/2008/02/06-wsc-minutes.html#c
8. http://www.w3.org/2008/02/06-wsc-minutes.html#d
9. http://www.w3.org/2008/02/06-wsc-minutes.html#e
10. http://www.w3.org/2008/02/06-wsc-minutes.html#f
11. http://www.w3.org/2008/02/06-wsc-minutes.html#item01
12. http://www.w3.org/2008/02/06-wsc-minutes.html#item02
13. http://www.w3.org/2008/02/06-wsc-minutes.html#item03
14. http://www.w3.org/2008/02/06-wsc-minutes.html#item04
15. http://www.w3.org/2008/02/06-wsc-minutes.html#item05
16. http://www.w3.org/2008/02/06-wsc-minutes.html#item06
17. http://www.w3.org/2008/02/06-wsc-minutes.html#item07
18. http://www.w3.org/2008/02/06-wsc-minutes.html#item08
19. http://www.w3.org/2008/02/06-wsc-minutes.html#ActionSummary
20. http://www.baselinemag.com/c/a/Security/Survey-Users-Believe-Internet-Is-Safer/?kc=BLBLBEMNL020608STR2
21. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sect-evcerts
22. http://www.w3.org/2008/02/06-wsc-irc
23. https://../
24. http://www.w3.org/2008/02/06-wsc-irc
25. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#selfsignedcerts
26. http://my.opera.com/yngve/blog/show.dml/461932
27. http://www.ietf.org/rfc/rfc3280.txt
28. http://my.opera.com/yngve/blog/2007/12/21/new-w-not-in-kestrel5
29. http://www.safetysign.com/CLDR.asp?PG=ANSIStandards4
30. http://www.w3.org/2008/02/06-wsc-irc
31. http://my.opera.com/yngve/blog/show.dml/508407
32. http://www.w3.org/2008/02/06-wsc-irc
33. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-redirects
34. http://www.w3.org/2006/WSC/track/issues/141
35. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dontmix
36. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
37. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#requirement-dontmix
38. http://www.w3.org/mid/OFE66F7E8F.2BB71D93-ON852573D9.0050788D-852573D9.00532917@us.ibm.com
39. http://www.guanotronic.com/~serge/security_score.png
40. http://www.guanotronic.com/~serge/security_score2.png
41. http://www.w3.org/2006/WSC/track/issues/112
42. http://www.w3.org/2006/WSC/track/issues/173
43. http://www.w3.org/2008/02/06-wsc-irc
44. http://www.w3.org/2008/02/06-wsc-irc
45. http://www.w3.org/2008/02/06-wsc-irc
46. http://www.w3.org/2008/02/06-wsc-irc
47. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
48. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 27 February 2008 14:17:47 UTC