[Servercert-wg] Displaying secure sites to Internet users

[Ryan Sleevi]

On Sun, Nov 17, 2019 at 3:38 PM Christian Heutger <ch at psw.net> wrote:

>
>    - While I'm quite familiar with ISO 27001, I don't think this
>    dichotomy exists like you suggest. SSL/TLS already provide robust
>    authentication of a domain name, which is how SSL/TLS is used on the
>    Internet, and what the CA/Browser Forum concerns itself with. This robust
>    authentication, when done following the Baseline Requirements and browser
>    root programs, helps ensure users can reliably connect to secure sites on
>    the Internet.
>
>
>
> And that’s the main problem. The users expect (as it‘s common to expect if
> looking at similar techniques like TIA (in Germany TUEV) seals on cars,
> passport control on immigration etc.), that they are connected to the
> “correct” site and want to be able to verify, they are.
>

There's plenty of peer-reviewed empirical data that contradicts this.
That's often one of the interesting things of doing research - assumptions
can be tested, and more often than not, don't hold up to real scientific
rigor.


> Domain validation is somehow the absolute minimum method possible for
> having the encrypted connection established without errors using
> certificates, but it’s not worth the word of validation, as everyone can
> register a domain without any (strong) restrictions or control.
>

I think this gets closer to the point. This is a view that encryption
shouldn't be available to everyone, which is a view I don't think most
members will share. After all, in our modern age, we know that encryption
is core to being safe online, and encryption is only possible to the domain
name. This is why it's important to participate in SDOs with real expertise
in the underlying technologies, which we know the CA/B Forum lacks (by
design), to understand how the Web works and the relevant encryption
technologies work.

If your premise is that domain validation is insufficient, there's a lot
more work to be done to establish that before it would be appropriate to
discuss in the CA/Browser Forum. Simply drawing that connection now would
be accepting many demonstrably-flawed premises and assumptions, and we know
that's how poor decisions are made.


>
>
>    - All of these things seem well-within our chartered scope. Discussions
>    of UI, of course, are completely outside the scope of our charter, and well
>    outside the expertise of members of this Forum. After all, we've seen folks
>    acknowledge that it requires product and UI expertise, and that's
>    inherently per-product. Just as we wouldn't expect Windows and macOS to
>    look identical, given how much their product experiences differ, it's
>    completely unrealistic to discuss trying to normalize UI.
>
>
>
> Why not, we have all the players on the boat. The CA with the contact to
> the certificate providers (I name this one the audience of server
> administrators, who run the certs on their servers) with experience in
> their environment, how to setup certs, how to maintain certs, but also how
> they are used, how their customers expect them to be etc., it’s a good way
> to gain end user feedback, as they are their users, I’m quite unsure, how
> else the ones, you built your browsers, operating systems, etc. for could
> be asked better (than by studies, which may always run in trouble of how
> independent they really are), all major browser, operating system etc.
> responsible with their UI teams in the back, some interested parties, which
> are, as their name says, interested parties in this ecosystem etc.
>

There's a lot to unpack here, but as appealing as this argument is, it's
quite deeply flawed.

I think the most significant flaw to point out is incorrectly assuming that
site operators are the end-users of certificates. That's certainly
tempting, but sadly, quite misguided. Certificates are merely a
technological means of providing relying parties with the assurances they
need or desire, with Browsers acting on behalf of and representing Relying
Parties.

You've taken several steps here without showing your work though, and
that's the presumption that there is something wrong with certificates that
authenticate the domain name. As noted several times, this misunderstands
the fundamentals of how online security works, since that is based on
domain name, and in the context of the Web, the origin. If you'd like to
suggest that something more is needed for certificates, it's necessary to
show the work there, and to establish with Relying Parties - not site
operators, and certainly not CAs - that such issues can and should be
solved with certificates.

Of course, it would be premature to even begin discussing the display of
such information, without first establishing the problem to solve and how
specific technological choices would or could solve it.

However, I'd also like to shift to the topic originally stated, as I think
you've perhaps lost sight of that. That's quite understandable, given that
it wasn't originally posted, but is now shared at
http://cabforum.org/pipermail/servercert-wg/attachments/20191116/b60c1603/attachment-0001.pdf
. You can see that this presentation similarly was deeply flawed, on many
levels, and took many intellectual short-circuits that avoided doing the
necessary work. The proposal was to attempt to define standards for browser
UI of certificates, but of course, it overlooked how unreliable the
standards for certificates are.

So, again, I'd like to ask for a clear problem statement. Then, while it
seems there's an implicit assumption that the solution is "more
certificates", we can discuss whether or not they're the right and
appropriate technology for such a problem. Of course, even if they are,
we'd need to establish the correct way to use such technology. We know that
despite over a decade of effort, the EV Guidelines, as written, fail to
provide even a basic degree of identity that can be relied upon as
consistently validated when adhering to the Guidelines, so we know there's
still significantly more work to be done there. And, of course, only once
such work is completed might it be reasonable to discuss how to apply that
work to solve these problems.

>
>
> Why reinvent the wheel instead of planning a better basement to settle up
> on (if the current one is not working as expected), get the wheel running
> (again, as we maid the system worse from where it started of) and improve
> the system on incidents and non-compliance arising?
>

I'm sadly not sure I follow the analogy. Arguments by analogy tend to have
that flaw, but you'll forgive me if I introduce another saying "Why throw
good money after bad?" Or, in the immortal words of Kenny Rogers, "You've
got to know when to hold 'em, know when to fold 'em, know when to walk
away, and know when to run"

I think we're in clear agreement that the EV Guidelines do not serve as a
solid foundation, as we see from the many ongoing CA incidents -
https://wiki.mozilla.org/CA/Incident_Dashboard . I think it's important to
highlight: these are incidents that resulted from the existing language in
the EV Guidelines and were not detected by audits, but instead by relying
parties who were mislead by the information in certificates. So we know
that there's significant opportunity here to improve the foundation,
significant cracks, and that building any house on it - as some CA members
are suggesting - is simply foolish. We should definitely focus on improving
these basic steps, to ensure the audits are sufficiently robust, and the
Guidelines sufficiently clear and free from interpretation, before any
discussion of UI or how end users - the billions of users using web
browsers - might rely on this. After all, with today's EV Guidelines,
there's really not much assurance difference between domain validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191117/b006b12c/attachment.html>