[Fixing the From to match list membership]

On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote:
> > Based on this discussion, I propose adding the following statement to the
> > Mozilla Forbidden Practices wiki page [1]:
> >
> > ** Logotype Extension **
> > Due to the risk of misleading Relying Parties and the lack of defined
> > validation standards for information contained in this field, as
> discussed
> > here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or
> > Subscriber certificates.
> >
> > Please respond if you have concerns with this change. As suggested in
> this
> > thread, we can discuss removing this restriction if/when a robust
> > validation process emerges.
> >
> > - Wayne
> >
> > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> > [2]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ
>
> People find logos very helpful.  That is why many browsers display a tiny
> logo in the toolbar.
>
> I would suggest that a better way forward is to start the hard work on the
> validation process.  It will not be difficult for that to become more
> robust and accessible than the logos in the toolbar.
>

[I am not currently employed by a CA. Venture Cryptography does not operate
one or plan to.]

I agree with Russ.

The Logotype extension has technical controls to protect the integrity of
the referenced image by means of a digest value.

I do find the discussion of the usability factors rather odd when I am
looking at my browser tabs decorated with completely unauthenticated
favicons. Why is it that browser providers have no problem putting that
information in front of users?

If Mozilla or Chrome or the like don't see the value of using the logotype
information, don't. But if you were to attempt to prevent others making use
of this capability, that looks a lot like anti-Trust to me.

The validation scheme I proposed when we discussed this some years back was
to build on the Madrid Treaty for registration of trademarks. International
business is already having to deal with the issue of logos being used in
multiple jurisdiction. It is a complex, difficult problem but one that the
international system is very much aware of and working to address. They
will take time but we can leave the hard issues to them.

I see multiple separate security levels here:

1) Anyone can create a Web page that appears to look like Ethel's Bank

2) Ethel's Bank Carolina and Ethel's Bank Spain both have trademarks in
their home countries and can register credentials showing they are Ethel's
Bank.

3) When someone goes to Ethel's Bank online they are assured that it is the
canonical Ethel's Bank and no other.

There are obvious practical problems that make (3) unreachable. Not least
the fact that one of the chief reasons that trademarks are often fractured
geographically is that they were once part of a single business that split.
Cadbury's chocolate sold in the US is made by a different company to that
sold in the UK which is why some people import the genuine article at
significant expense.

But the security value lies in moving from level 1 to level 2. Stopping a
few million Internet thieves easily setting up fake web sites that look By
Ethel's bank is the important task. The issue of which Ethel's Bank is the
real one is something they can sort out (expensively) between themselves,
20 paces with loaded lawyers.


For the record, I am not sure that we can graft logotypes onto the current
Web browser model as it stands. I agree with many of Ryan's criticisms, but
not his conclusions. Our job is to make the Internet safe for the users. I
am looking at using logotypes but in a very different interaction model.
The Mesh does have a role for CAs but it is a very different role.

I will be explaining that model elsewhere. But the basic idea here is that
the proper role of the CA is primarily as an introducer. One of the reasons
the Web model is fragile today is that every transaction is essentially
independent as far as the client is concerned. The server has cookies that
link the communications together but the client starts from scratch each
time.

So imagine that I have a Bookmarks catalog that I keep my financial service
providers in and this acts as a local name provider for all of my Internet
technology. When I add Ethel's bank to my Bookmarks catalog, I see the
Ethel's bank logo as part of that interaction. A nice big fat logo, not a
small one. And I give it my pet name 'Ethel'. And when I tell Siri, or
Alexa or Cortana, 'call ethel', it call's Ethel's bank for me. Or if I type
'Ethel' into a toolbar, that is the priority.

Given where we have come from, the CA will have to continue to do the trust
management part of the WebPKI indefinitely. And I probably want the CA to
also have the role of warning me when a party I previously trusted has
defaulted in some way.

Putting the logo in the user's face every time they go to a Web site is
going to be problematic usability wise. Doing that when they sign up is a
very different matter.

I have also been looking at one of the solutions proposed for stopping
phishing and taken it to an extreme. This is the idea of a limited Web
browser that is only used for the important parts of a bank or brokerage
site. Confirming trades or bill payments, etc. And I cut down the browser
again and again until all I was left with was a browser where the site
could ask 'Do you want to do X' and the user could respond yes or no. This
is a browser I can fit on my watch and yes, I want the logo of the party
asking the question.


Since leaving Comodo last year, I have rethought every part of the Internet
security infrastructure. The result is described here:

http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html


-- 
Website: http://hallambaker.com/
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to