<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?
<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
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].
<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
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: 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
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?
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
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
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
<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
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
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
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
mez: let's save 7, we'll do 8/9
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
