RE: ISSUE-108: Should Safe Browsing mode restrict users to a specific set of sites? [Techniques]

Thanks. We are open to best approaches for achieving our SBM objectives, and
reaching a consensus that can be globally accepted. We are starting to get
some concrete proposals from Microsoft as to how they might achieve these
goals with IE7 and EV certs; and also how they might achieve these goals
with CardSpace. We will share these with everyone. We are also interested in
hearing from Mozilla how they might best implement the spirit of SBM. I am
also connecting with people from the Higgins project to get their input. We
would appreciate any input you can provide with your best recommendations.
It would be great if we could pilot something in the near future.

 

Best Regards

 

Dan

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Ian Fette
Sent: Friday, September 21, 2007 12:22 PM
To: Dan Schutzer
Cc: michael.mccormick@wellsfargo.com; johnath@mozilla.com;
public-wsc-wg@w3.org
Subject: Re: ISSUE-108: Should Safe Browsing mode restrict users to a
specific set of sites? [Techniques]

 

I personally haven't really convinced myself that I prefer handshake after
initial validation vs. handshake as validation. There's significant
drawbacks to both - we've talked about the drawbacks of handshake as
validation (connecting to some random host), there's also drawbacks to a
pre-validation. Pre-validation would basically mean the client storing a
whitelist, or connecting to some service in an online fashion and caching
the result (which wouldn't be *too* bad, i.e. first time I connect to
bankofamerica.com my browser queries X to ask if this is OK.) Problem with
this is that let's say users aren't really that well adapted to SBM at
first, and they start trying to go to normal sites in SBM - you're going to
be generating a lot of queries, and you need to be able to handle that. 

I wasn't throwing in my towel into either ring yet, I just wanted to make
sure that the distinction between the two was clear.

As for 2. There definitely needs to be a globally accepted approach. I would
caution though that "US banks validated by US authority" is still a
complicated proposal. 

I know most Americans probably only have accounts in the U.S., but there's
still a nonzero number that have accounts offshore (and I don't mean swiss
bank accounts, I mean like having a pound or euro denominated account at
Citi UK or DeutscheBank). Within the EU I would hazard to guess that it's
even more common to have accounts across country lines (but if you treat the
EEA as a single banking region, then it's probably similar to the U.S.
case).

In either case, it probably needs to "just work". I.e. if I'm an American,
and I want to connect to DeutscheBank (or, conversely, if I'm on my German
friend/family member's computer and want to connect to my Bank of America
account), I shouldn't have to go through some cumbersome process to do so. 

This doesn't imply that US banks can't be validated by a US entity, it
rather means that I would much prefer something like trusting a single root
(SWIFT might not be a bad example), and having that root delegate authority
as appropriate (which could be something like intermediate signing
certificates, or could simply be that ABA/FSTC validates a package sent in
by a US bank and then forwards on the completed application to SWIFT via
approved channels.) 

-Ian

On 9/21/07, Dan Schutzer <dan.schutzer@fstc.org> wrote:

I agree that:

1. Their SSL handshake determined that a site was allowed for SBM. The
validating of the site should take place first

2. Their needs to be a globally accepted approach; e.g. US banks could be
validated by a single US authority, but there would have to be an equivalent
authority for each country; or alternatively we would need some recognized
international association, such as SWIFT.

 

  _____  

From: public-wsc-wg-request@w3.org [mailto:
<mailto:public-wsc-wg-request@w3.org>  public-wsc-wg-request@w3.org] On
Behalf Of Ian Fette
Sent: Thursday, September 20, 2007 8:47 PM
To: michael.mccormick@wellsfargo.com
Cc: johnath@mozilla.com; dan.schutzer@fstc.org; public-wsc-wg@w3.org


Subject: Re: ISSUE-108: Should Safe Browsing mode restrict users to a
specific set of sites? [Techniques]

 

I don't think there was argument that SBM should be SSL only (and I would
not carve out any exceptions for images - they too can be an attack vector.
Mixed content should not be allowed in a "safe" mode - it should be SSL and
everything should validate and there should be no problems with anything.
Period.) 

I think the question is whether the SSL handshake took place *before*
validating that a site was allowed for SBM, or whether the SSL handshake
*determined* that a site was allowed for SBM.

The distinction is this: 

There is a (small, but nonzero) surface of attack exposed when you connect
to some random site. It could try to exploit a buffer overflow in a SSL
handshake, or some other weird attack. If you use the SSL handshake as the
first step in SBM, then you are opening yourself up in a mode that is
supposed to be "safe". It's not huge, but it's there. The alternative is to
do some validation before connecting. That is, something along the lines of
"The user wants to connect to https://www.wellsfargo.com. Wellsfargo is an
"approved" site, so assuming the certificate checks out then everything is
fine. Now the user wants to connect to https://www.IStealYourMoney.com.
IStealYourMoney.com is not an "approved" site, so I am not even going to
connect to IStealYourMoney.com and ask for a certificate, because it's not
an approved site anyways." 

I hope that clarifies the distinction that was being raised earlier that
Johnathan was raising about having a list + EV, in that it allowed you an
initial sanity check before connecting to some random host.

The other point was that, even within CAB, Logotype extensions aren't
standardized / finalized (PHB please correct me if I'm wrong). 

Also, I'm a bit concerned about the example of using the ABA - Unless I'm
mistaken, ABA stands for the "American Bankers Association", and it's not
clear to me that the ABA should be validating DeutscheBank or HSBC, for
instance. I think we want to give a lot of thought to who or what is the
root authority/authorities. I think a national organization might be a hard
sell (even something like FSTC would be a hard sell in my mind, because I
could easily see a UK customer asking why they're trusting FSTC instead of
APACS). On the other hand, I don't want to end up creating a mess like SSL
is where most browsers have tons of root CAs that I really have no idea
whether I should trust them or not. 

For instance, right now, my browser "trusts" a certificate from Staat der
Nederlanden - why should my browser trust the Dutch government? Who is
Swisscom? Who is Starfield? (Didn't it get bought by GoDaddy or something?)
And Unizeto Sp. z o.o.? Heck, even scarier, my browser has a "Wells Fargo
Root Certificate Authority"... no offense, but I don't trust Wells Fargo to
be a root of trust after it leaked private data back in 2006 (and stolen
laptops, etc.) 

Anyhow, I'm not trying to go CA bashing, or bank bashing, or consortium
bashing, or anything like that. I love banks, my family works for banks, I
think they're great and all that - I'm just saying that we need to be very
careful in creating a root of trust for SBM, because this is a very
international issue, and it should be very clear to the user why a certain
site is trusted - and I don't really think that, for the average person on
the streets of New York, that the answer "Because Unizeto Sp. z o.o." is
good enough (and frankly, on the streets of Berlin, I don't think the ABA is
a good enough answer.)

It's a hard problem, I'm not saying I have the answer, I'm merely trying to
raise a caution flag. 

-Ian

On 9/20/07, michael.mccormick@wellsfargo.com <
michael.mccormick@wellsfargo.com <mailto:michael.mccormick@wellsfargo.com> >
wrote:


First of all, I feel SBM should be SSL-only (only https allowed, 
possible exception for certain MIMEs like GIF) so to me always requiring
a TLS handshake isn't a problem.

I agree a EV cert by itself provides little or no assurance of
trustworthiness or safety, but I didn't think SBM was proposing to use 
vanilla EV.  My understanding was that EV communities would be formed
and managed by a central authority that imposes additional controls on
issuing CAs.

For example, a banking community could be managed by an association such 
as the ABA, and ABA would require all participating issuers to meet (and
impose) certain criteria that go above & beyond what CAB Forum mandates.
In that scenario, possession of a EV SSL cert with the ABA community 
logo seems to me equivalent in every meaningful way to having one's URL
on a ABA managed white list... without all the well-known inherent
disadvantages of white listing (not scalable, not real-time, not secure, 
etc.)

Mike

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org ]
On Behalf Of Johnathan Nightingale
Sent: Wednesday, September 19, 2007 4:54 PM
To: Web Security Context Working Group WG
Subject: Re: ISSUE-108: Should Safe Browsing mode restrict users to a
specific set of sites? [Techniques] 


Using EV certs as the stand-in for a whitelist seems wrong, to me.
EV certs make strong identity claims, but not trustworthiness or safety
claims, which I think SBM envisions.  EV certs in combination with a 
whitelist seem like a more natural fit, if we're going to recommend this
at all.

I think the argument has been advanced that we could use the community
logotype field of an EV cert as a proxy for the whitelist, basically 
that having (say) the FSTC logo in there acts as de facto whitelist
membership.  One downside I see there is that it still requires the SSL
handshake to take place (in order to acquire the certificate for
inspection) which exposes some, albeit limited, attack surface.  In an 
EV+Whitelist world, that initial connection wouldn't occur because the
"Your accounts are being closed" email link would presumably point to
some non-whitelisted domain, and the connection would not be built in 
the first place.

I've said in the past that I don't think the maintenance and generation
of these lists can be accurately foreseen, and hence that I don't think
it's really the right kind of thing for our group to mandate, since that 
compels us to declare "non-conforming" any
browser that doesn't think the lists are mature enough.
Nevertheless, if we *are* to make such a recommendation, it feels like
EVs shouldn't be used as a surrogate for "trustworthiness" 
determinations.

Cheers,

Johnathan

On 18-Sep-07, at 8:59 AM, Web Security Context Working Group Issue
Tracker wrote:

>
> ISSUE-108: Should Safe Browsing mode restrict users to a specific 
> set of sites? [Techniques]
>
> http://www.w3.org/2006/WSC/track/issues/
>
> Raised by: Thomas Roessler
> On product: Techniques 
>
> In the current draft:
>
>   Editor's Draft $Date: 2007/09/18 12:50:20 $
>
> safe browsing mode includes a requirement that Web user agents only
> be able to access EV (or EV-like) sites when in Safe Browsing 
> Mode.  From discussions, this is one possible approach; the aim
> seems to be to have some whitelist of truted sites that can be
> accessed in this mode.
>
> Questions:
>
> - Should such a whitelist exist at all? 
> - If it exists, are EV certificates the right criterion?
>
>
>
>
>
>

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com  <mailto:johnath@mozilla.com>