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: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>
> 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
>
>
>
>
>
>
>