Houston, we have a problem

[Andrew Gallagher]

On 22/09/17 20:40, Kristian Fiskerstrand wrote:
> On 09/22/2017 09:34 PM, Stefan Claas wrote:
>>>> O.k. i just tested a bit and this is a bug int the Web Interface
>>>> and in GnuPG's CLI Interface.   
>>> I don't see a bug here.
>> Now i am a bit confused... Then maybe a "funny" design flaw? I mean
>> what should users unfamiliar with the whole WoT procedure may
>> think when seeing a fake "sig3" (which they may not spot) and then
>> clicking on the key-id in question, which then links to the original
>> key?
>>
> 
> No, its not a design flaw, it is valid design. OpenPGP keyblock
> information is based on an object based security model where packets are
> added, but don't carry any meaning until the signature has been
> verified. The public keyserver network is by design not a trusted third
> party, and can not be

Absolutely. But it can *appear* to be trustworthy, and this is a problem
in itself.

The issue is UX and user expectation. If I go to a server and ask for
some specific data, and the server gives me that data, then there is an
implied authority to that data. We can argue here until the heat death
that users *should not* read any sort of endorsement into a server
merely providing data. But that's not the way human beings think. And
trying to train human beings to constantly fight against their instincts
is like trying to train cats not to catch birds.

If we don't want people to read anything into unverified data, then we
should not display unverified data in a form where people may mistake it
for verified data. So in this case, the problem arises not because the
server has provided a signature on a key, but because it has naively
repeated the (unverified) claim that a particular signature was made by
a key that has a particular ID bound to it, in human readable form and
without a giant red flashing neon sign saying *THIS IS ALL LIES*.

As you say, we know nothing meaningful until the full signature chain
(including any SBINDs) has been validated. The problem comes when
software is "being helpful" and blindly regurgitates unverified
(therefore meaningless, therefore *misleading*) data. Average users
cannot be expected to remember when data has been verified and when it
has not. The only way to stop people making the same mistakes over and
over again is to stop facilitating those mistakes.

We can draw a parallel with fake news. No matter how many times you tell
people "Do not trust anything you read on the internet", the default
state of the human brain is to believe what it is told unless suspicion
is aroused. It can only be thus. If you doubted every single thing you
were presented with every day, you would never get out of bed.

So when SKS lists the signatures on a key, people believe it. When
Enigmail says "untrusted good signature", people read the "good" and
gloss over the "untrusted". The only way to stop people believing things
that may not be true is to stop telling them things that may not be true.

So SKS should just say "unverified signature from <fingerprint>". It
should not repeat the purported user ID, nor provide a search link that
returns completely unrelated keys that happen to have the same purported ID.

But user-facing software shouldn't be exposing unverified IDs *at all*.
Enigmail now sort-of does this - the latest versions won't even admit to
the existence of a signature by a key that's not in the keyring. It
could do even better - it should stop saying "untrusted good signature"
and just say "unknown signature". If people want the gory details, they
can click the details button.

The gpg command itself should cryptographically verify signatures when
performing --list-sigs, so that at least it can throw a warning when an
invalid signature packet is found. Ideally it should not display invalid
packets at all (by default). Displaying a genuine-looking signature on a
key that doesn't result in a valid chain of trust is a sure way to
encourage people to work around the safeties.

It is not enough that something bad is forbidden. You have to make it
obvious at all times *why* it's forbidden, otherwise people think the
system is broken and fight against it.

The fact that technically-proficient people have been coming in here for
twenty years with the same misconceptions about what is and isn't
verified and/or trustworthy is a sign that there's something
fundamentally broken with the ecosystem's UX.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170926/427b5cfb/attachment.sig>