- 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