See also: IRC log
<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[End of scribe.perl diagnostic output]