<NSA> We are watching.

<kaie> NSA: how much longer will you be able to?

<BenL> its notable that I couldn't connect to this server with SSL

<BenL> w3c == nsa pawns?

<kaie> Where is expo 23?

<kaie> Asking for later

<kaie> Ok, it's the primary big room we've been in

<cabo> Please shout out that everybody else should be $here instead…

<scribe> scribenick: npdoty

cheshire: tentative title "Client changes to improve certificate quality"
... has been described as "browser stuff" but lots of other clients will be very important too
... like IM or calendar or other clients where you're about to send username/password and you have a cert error
... common frustration over these certificate errors
... a "blizzard of alerts" on an airport captive portal

phb: worst case is accepting a certificate accidentally and storing it as a trusted entity going forward

BenL: several failures aren't specific to certificates, shouldn't send credentials in the clear anyway

<BenL> sorry, should've said my name

torgo: we all have frustrations with captive portals, but is that really what we're here to solve?

<BenL> which is Ben Laurie :-)

torgo: we're trying to determine when the user is being tricked

cheshire: hotspot interception is part of a general background of bogus certificate errors
... fatigue for the user opens the door for surveillance, hard to spot the stand-out certificate error
... each one individually isn't so bad
... but with so many failures, why do we even bother?

DThaler: not just about sending password, but also just the username is an information disclosure
... choice: get work done or try to be safe -- so users always click OK
... captive portal case is arguably legitimate; misconfigured certificate; third case is an attack
... make the first two cases less common, so users won't be trained to click OK

<PHB> Ben: Do you know that gmail ONLY offers LOGIN and PLAIN (plus openid) for IMAP

DThaler: captive portals are supposed to spoof HTTP, that's the only way to do it

wseltzer: are we asking users questions we can reasonably expect them to answer?
... improve certificate quality OR improve interface/questions for the user

cheshire: paper on what is the right way to ask users
... (except maybe the answers we get from them are just as bad)

pde: all of these are incomprehensible, even to the experts
... the only interface should be "none"
... if we have to break use cases, then so be it

Pritikin: stop asking users questions they don't have an answer to
... instead, just show them scary flashing red lights for all the time that they're using that website
... so that they might question what that bad thing is

cheshire: improving the UI might be getting rid of it
... if we have consensus among browser makers, that would be useful
... but are there other agenda items?

<wseltzer> [I agree the best UI could be no UI]

<wseltzer> [don't ask users irrelevant questions, or questions to which they have no reason to know the answer]

@@@: @@@@

<rbarnes> @@@?

Juan-Carlos Zuniga: only well-educated scientific people in my family cared about the expressed privacy; others just trusted everything to work

phb: regarding no UI, certificates include 4 parties: user, site, CA, browser
... browser has the problem that they want users to be able to connect to everyone and quickly
... instead you could choose your antivirus-for-web-provider when you start your browser
... and that provider / broker would tell you the DNS and the appropriate cert

<wseltzer> npdoty: I like the no UI or minimized UI idea.

<wseltzer> ... self-signed certs, why the scary error, instead of saying, "this is just like HTTP"?

DThaler: can narrow down to cases where you know whether or not you're behind the captive portal
... 2 cases, for captive portal, just fail safe
... for misconfigured and attacker case, just provide scary UI but assume they want to continue
... could change user behavior

pde: could have a flag day, a 9-month deadline at which point all hotel captive portals will break
... if the browsers were all in it together, would that make you willing?

<general disagreements in the room>

<phb> Better choice is often to degrade

BenL: while it's motivating to break broken stuff, if other UAs aren't going to do it, then the user will blame the specific browser and switch, we helps no one

<phb> To break stuff: FIRTS determine the requirement for the brokenness, SECOND meet it THIRD degrade the deprecated path FOURTH disable the deprecated path

BenL: if the user had typed/bookmarked HTTPS or if the site had redirected to it, then not getting HTTPS should be a warnable thing

DThaler: lots of very old hotel software that isn't going to change in time, it would have to be very far away

BrianTrammell: flag day would get us pushback about being a cabal, and lots of very small hotels are using very old systems
... a common interface for applications themselves to state what kind of failure in making an HTTP request they want

<DThaler> @@ = Brian Trammell

BrianTrammell: that is, solve this for more than just the browser

Ted: symptom of a much larger problem -- users are presented with credentials that they can't verify
... in the US, you probably bought a phone from a store cooperating with a particular carrier
... and so your phone probably includes a root certificate from the carrier
... user/app developer can't distinguish between valid certificate because actually the real site and valid certificate because of the installed root
... have to fix the fundamental problem in the web security model (that any cert can apply to any name)

cheshire: 1) "do you look for this lock icon?" "why would my web browser connect me to the russian mafia?"
... why does the browser think it's reasonable to connect to the wrong thing and just show a tiny indicator?
... 2) regarding the older hotel software, Apple like many OSes was using a small fetch to its own site
... ... which then created an arms race because some hotspots didn't like that, and they even reverse engineered the list of a couple hundred domains
... 3) flag day proposal:
... ... a) short term, do a more strongly worded warning to the user, harmonizing language across vendors
... ... b) give dates and advance notice, that by, say, 2015, it won't be as easy for users to click through
... ... and that by, say, 2016 it will no longer be possible
... ... and provide simpler functionality for installing a new cert for a particular site

Ted: but that gives the authority to sign for any name (not just for the site referenced to in the email)

cheshire: telling user to install a new trust anchor is burdensome enough that it becomes easier for the site to do the right thing

@@: shouldn't specify user interface

scribe: shouldn't put the onus on the user to install something
... currently, HTTPS is an entirely different mode for the browser

torgo: regarding stronger wording, ratcheting up the health warning language on cigarette packs, doesn't seem productive
... more user Web interaction are in Web views not just the full-on browser
... cutting-off makes more sense rather than scary UI
... hotel operators reverse-engineering anecdote makes me depressed about humanity
... should find out why they're doing this, have a workshop with them -- Captive Portal Workshop, where we understand their real needs

cheshire: our web sheet has limited functionality -- doesn't show video, which breaks the business model of those who want video ads

pete: both flag day and the no-UI put costs on the wrong place
... support calls will go to ISP, browser vendor, friends/family
... red flashing display in the fail case -- still see the web site content, and so they'll make the support call to the web site

wseltzer: should do some user research

Marc Blanchet: flag day not likely to work at Internet scale

scribe: access points don't feel the incentive to change; think browsers will give in and switch back very quickly

cheshire: why do captive portals modify HTTPS connections?

marc: what about kids who go to HTTPS-only Facebook as their first page, because they're trying to be secure

cheshire: but the first connection should be the OS-level captive portal detection request which is HTTP
... also, why do these captive portals intercept my IMAP connection instead of just blocking it?

DThaler: setting a deadline isn't enough, have to make misconfiguration less likely
... makes it worse to help the user install a root certificate
... getting a certificate with no UI (like DANE / DNSSEC) would be better
... layering problem, what should you surface to the next level of the code (not user interface) about certificate errors?

kaie: there are some browsers that already make it harder than one click (Firefox today is 3 clicks)
... user research from @__apf__ on how users respond to security warnings

<DThaler> clarification: getting a certificate _scoped only to a given name_ with no UI would be better

kaie: go ahead and display the content anyway? but what if we leak secure cookies or important URL parameters
... could instead invalidate session/cookies and URL parameters and then show some warning to the user along with content

pde: clarification: not proposing flag day for stronger warnings, but instead just breaking captive portals and other MITM
... treat domains that have had valid certs in the past differently from those that hadn't (via a list in the client)
... why not have clients just use a small sample of sites known to have a valid x509 cert?

cheshire: some portals aren't intercepting https; want sites with constant content to make testing straightforward

@@: +1 Ted on dangers of installing a new root ca; need to support confidential but without identity

@@@: browser should be able to distinguish between lists of certificates of different types (like hotspot providers)

scribe: assumes that users will update the browsers -- it's true that many browsers are now auto-updating, but old clients persist

cheshire: just need enough users that sites have an incentive to fix their problem

@@@: have to consider chromeless interfaces as browsers become more OS-like

phb: "click here and the kitten dies"
... could instead increase the weight of the success signals
... like putting brand logos as an extension for certificates, show the company logo in chrome that can't be faked

BenL: chrome that can't be faked is hard
... like flag day idea and would be happy to champion it
... +1 to pde about list of sites that should have certificates, but it's hard to install a very large list in the browser
... installing a locally trusted cert that's only good for a particular site or a particular hierarchy is good, but UI needs to prevent trickery
... skeptical about zero UI because aren't we trying to fix the CA problem we have now?

hhalpin: users currently have private browsing modes; what if they had a secure browsing mode with more details about certs etc.

carlos: overlap with on-by-default

rigo: I care about self-signed certificates, would we remove those too? makes users feel powerless

<rigo> removing support for invalid certificates removes self signed certificates? => 80% of the certificates that matter to me are self signed => what is a valid cert and how can a user find out? => have a feeling that you are deciding for the user, not good IMHO

<rigo> removing empowerment from the user. At least allow people who know what they

<rigo> do to continue what they are doing. No UI means even less control

<rigo> by the user who are already feeling powerless.

<rigo> For PM we want TLS by default, will create more errors, how will

<rigo> you communicate to the user.

crocker: stronger message to users may make them feel worse but not help
... flag day didn't work even as far back as 1983
... assertions by fiat won't help; security has adoption problems because of lack of usability

cheshire: more like IPv6 Day, where coordinated voluntary action would reduce any potential pushback on one of them
... I'm supportive; champion in Chrome; supporters from Firefox; etc.

<hhalpin> A realistic solution that involves the rest of the browservendors W3C would be happy to help with.

<hhalpin> Test-cases :)

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.99)

Succeeded: s/@@:/BenL:/
Succeeded: s/@@/Pritikin/
Succeeded: s/@@@:/Juan-Carlos Zuniga:/
Succeeded: s/@@: flag/BrianTrammell: flag/
Succeeded: s/@@@/Marc Blanchet/
Found ScribeNick: npdoty
Inferring Scribes: npdoty

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Ben BenL Bert BrianTrammell DThaler NSA PHB Pritikin Ted barryleiba bht bjoern cabo carlos cheshire clarification crocker donnelly hhalpin hildjj jphillips jphillips2 kaie marc npdoty oleg pde pete rbarnes rigo scribenick torgo wendyg wseltzer xnyhps
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 01 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/01-client-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report