IncreaseWKDUsage2021 bachelor thesis [WIP]

Christoph Klassen is writing his bachelor thesis (at Intevation) about how usage of WKD can be furthered. Bernhard Reiter does the mentoring, see gnupg-devel@ for discussion and for contacting Christoph or Bernhard.

Started at 2021-10
End: 2022-02-18

Goal

WKD is easy to implement and brings the advantage of good usability. Because of that it is desirable to spread it and increase its usage. At first, the aim was to find out, which measures are effective to spread WKD. But, while different products were tested, it became obviously that it isn't 100% clear, how to implement WKD.
For example, products have to use the advanced method, when the subdomain "openpgpkey" is available. The question is how to check this availability. While implementing the advanced method for Mailvelope it was found out that Chrome doesn't offer the possibility to resolve a DNS-name. In the section about Mailvelope you can see how this problem was solved in this work.
Another aspect that became visible after testing the products was that the developers of the products have very different ways how they integrated WKD into theirs products. Very often it was not user-friendly how WKD was made available to the users. Sometimes it was complicated to make the product ready for WKD or it was difficult to find out how to enable it.
This are reasons for finding measures to make the implementation of WKD easier for developers. Also, it is important that WKD can be used easily. That means that the usability of it has to be increased.

Use Cases

It is necessary to define use cases, so it is easier to speak about how to implement the WKD-standard. These use cases were written by using Cockburns template [1].

Use Case #1: Write an encrypted email

Goal: Sending a confidential message.
Precondition:

• An email-client, which uses the OpenPGP-standard, was installed
• The person, who wants to write the email, does not have the pubkey of the receiver yet
• The receiver did create a pubkey and made it available on a WKD server
• The pubkey of the receiver needs to be fetched automatically

Success: An encrypted email was sent
Failure:

• An unencrypted email was sent
• No email was sent
• The receiver cannot decrypt the encrypted email

Actors: A random person
Trigger: A person wants to write a confidential message to another person in a way that no other person can read its contents.
Description:

1. Person opens the email-client
2. Person opens the area to compose an email
3. Person enters address, subject and message
4. Person sends the email

Extensions:

1. Person checks, if the pubkey is trustworthy
2. Person checks, how trustworthy the pubkey is

Use Case #2: Validate the signature of an email

Goal: Check, if an email was written by the person, whose email address was used.
Precondition:

• An email-client, which uses the OpenPGP-standard, was installed
• The person, who sent the email, created a pubkey and made it available on a WKD-server
• The pubkey of the sender needs to be fetched automatically
• The person, who wants to check the signature, does not have the pubkey of the sender yet

Success: The signature of the email could be checked
Failure: The signature of the email could not be checked
Actors: A random person
Trigger: A person receives an email with important information and wants to know, if it was really written by the person, whose address was used to send the email.
Description:

1. Person opens the email-client
2. Person opens the area with all received emails
3. Person opens a signed email
4. Person starts the verification of the signature
5. Person sees if the signature of the email is valid

Extensions:

1. Person checks, if the pubkey, which was used to check the signature of the received email, is trustworthy
2. Person checks, how trustworthy the pubkey is, which was used to check the signature of the received email

Activity diagram for use case #2:

Criterions for implementing WKD with a good usability

• The product is compatible to the last version of the WKD-standard
• WKD is enabled by default.
• WKD is offered in the area, where users enter an email. When users have to search for a key manually, the button for WKD should be in the area, where they can write an email.
• WKD is used automatically, when users enter an email. The users do not have to press a button to retrieve a key via WKD.
• WKD is offered, where users can validate the signature of an email.
• The UI of the product shows, if a pubkey has a basic trust level, right where the user needs this information (in the area to compose an email or check a signature)
• The UI shows, how trustworthy a pubkey is in an interval of different steps (Here is some information about trust levels).

Another way to evaluate products is to do a heuristic evaluation. Jakob Nielson created ten different heuristics to examine the usability of products. On [2] is a recent article, where he summarizes the heuristics. The essence of these heuristics is that users want to be able to predict the softwares behavior and to have the feeling of control about the software. Therefore it is necessary that the application gives users enough information to know, what is going on. On the other hand users shouldn't be overwhelmed with to much information or too many choices and UI elements. It is also important that a software is consistent in itself and with other applications, which the users also use, so they can re-use their experience.

State of products and progress

Here it will be described what state different products had at the beginning of the work and what measures were taken to increase the usage of WKD.
For some products it is necessary to prepare them for encryption. But after doing that WKD is enabled by default. For this reason they fulfill the criterion "WKD is enabled by default".

Overview

°: Users need to click on some buttons and open two additional windows before they can search for a key via WKD, so the WKD-button is a bit more hidden.

Mailvelope

Previous state (analyzed version 4.4.1)

• Does use WKD and WKD is used automatically
• The implementation is not up-to-date since it doesn't contain the advanced method
• There is an issue for the advanced method on Github: https://github.com/mailvelope/mailvelope/issues/774
• It should be possible to check the signature, but when sending signed emails from different email clients to an account on mailbox.org, there was no sign of a signature check
• Does not show information about the trust of a key

Measures

• As part of this work a branch was created to implement the advanced method: https://github.com/c8k/mailvelope
  
  This section explains, how it was decided, when to use the direct and when to use the advanced method in the new implementation for Mailvelope. Firefox offers the method browser.dns.resolve() to resolve a DNS-name. If the resolve was successful, the advanced method has to be used. In the other case it's the turn of the direct method. But, Chrome doesn't have this method. So, there has to be another way to decide between direct and advanced method. The alternative is to only use the method fetch().
  On Chrome we try the advanced method at first (because it has the higher priority). If it's successful, we get a key and everything is fine. When there is an error, another decision has to be made. If the response contains a status code like 404, it is clear that the subdomain exists because the server does give an answer. But, there are also cases, in which a TypeError will be thrown and then we don't know, what the reason is. One option is that the subdomain exists, but the server is not reachable in that moment. Because we can't be sure, we just use the direct method.
  The following image shows an activity diagram, where you can see the decisions that are made.

Claws Mail

Previous state (analyzed version 3.18.0)

• Integrated WKD since version 3.18.0 / 4.0.0
• Pubkeys can only be retrieved, when users get an encrypted email
• How to enable encryption and use WKD can be found on this wiki page
• When a user opens an email an presses "C" on the keyboard, the signature will be checked. Then the level of trust will be displayed at the bottom of the email
• No information about the trust level of a pubkey is shown when composing an email

Measures

• Request: In the compose window users can right-click on an email address to open a context menu, where they can e.g. add this address to their address book. To give users the possibility to retrieve keys of email addresses, from which they didn't receive an email yet, it was requested to implement another action to do just that. Optionally, this action could be shown only, if the user enabled a privacy system.
• Request: Automatically enable a privacy system as soon as an user adds one, when loading a plugin.

FairEmail/ K9Mail

Previous state

• Use OpenKeyChain to retrieve keys via WKD and encrypt emails
• It is necessary to open OpenKeyChain to retrieve keys. This step is not possible in the GUI of the products
• OpenKeyChain is not compatible with the last version of the WKD-standard because it uses the direct method, even if the subdomain "openpgpkey" exists

FairEmail

Previous state (analyzed version 1.1776)

• Heuristic Evaluation of FairEmail
• Does not show any information about the pubkey that was used to check a signature
• No information about the trustworthiness of a key is shown when composing an email

Measures

• Requested an easier way to open the OpenKeyChain app, so users can open it from FairEmail and don't have to go to the settings of the phone to start the OpenKeyChain app there.
• Reported a bug: When an encrypted mail was recieved and that mail was decrypted with FairEmail, a message appeared saying, that the mail isn't signed. But when the mail is decrypted there is an icon left of the lock icon and after a tap on it, a message appears, which tells that the signature is valid. So the first message seems to be incorrect.
  • Was fixed in a newer version
• Recommended to edit the UI in the compose window. There are three icons. Two of them can be interacted with and one not, but all of them have the same style (no borders, no background, same color etc.). To be more consistent it was suggested to remove the icon without function or to adjust the style of the icons, so that the one, which can't be interacted with, has a different style.
  • The icons got different colors in a newer version

K9Mail

Previous state (analyzed version 5.806)

• Shows, if a key for an email is available
• The icon for encryption changes in the composing window, when a key was signed in OpenKeyChain, but there are also only the same information as for the key that was used to sign an email
• When a received email was signed, an icon will be displayed:
  • question mark = unknown pubkey was used
  • check mark = a pubkey was used that is in the keyring of OpenKeyChain
  • check mark with three dots = a pubkey was used that is in the keyring of OpenKeyChain and was signed there

KMail

• Serves as a reference in this work
• It was analyzed (version 5.18.3), but no measures were taken
• KMail implements the latest WKD-standard
• WKD is not enabled by default. How to change this can be found here.
• Pubkeys are fetched automatically in the composing window, if WKD is enabled.
• Pubkeys are not fetched automatically, when checking a signature
• The icons only differentiate between an ultimately trusted key and keys with less trust (composing and signature checking)

Thunderbird

• Was also only analyzed (version 97.0a1) because it will probably be difficult to contribute to such an extensive product
• Implements parts of the WKD-standard
• If a key is not available, the direct method will be used, even if the subdomain openpgpkey exists. This is not compliant with the standard.
• WKD is enabled by default...
• ...but the search has to be started manually.
• It is mentioned that Thunderbird uses WKD in the user documentation.
• WKD can not directly be used in the composing window. Users have to open a few windows beginning by pressing the "Security"-button in the composing window.
• There is a button (see Screenshot) to retrieve the pubkey to check the signature, but the search does not include WKD.
• Users can choose, if they accept a pubkey for encryption and tell, if they have verified the key (see Screenshot). When they write an email, they don't see any information about a pubkey. When they open a received signed email, they see an icon, which depicts, if they accepted the key. So, Thunderbird itself doesn't inform, if a pubkey is trustworthy, but the user has to decide, if that is the case.
• There is no additional information about the trustworthiness of a pubkey.

mail.de

The email-provider mail.de is a special case in this work because it represents the server-side of WKD and not the client-side as the other products.

Previous state

• It was found out that mail.de did offer a WKD-server, where users could upload their keys via the settings of mail.de
• A test with GnuPG 2.2.27 (gpg -vv --locate-keys --auto-key-locate clear,nodefault,wkd) showed that it was not possible to get the key via WKD
• Ingo Klöcker found the reason with dirmngr [3]: Resolving openpgpkey.mail.de didn't end with an error, so GnuPG didn't use the direct method of WKD.
• Versions of GnuPG that were released before GnuPG 2.2.17 could receive keys from mail.de because they only supported the direct method. The advanced method was introduced in the 7th version of the WKD-draft [4], which was implemented in GnuPG 2.2.17 [5])

Measures

• The contact form of mail.de was used to contact the support team and tell them about the problem
• After communicating with Michael Kliewe, the Chief Security Officer from mail.de, a TXT record was created for the domain openpgpkey.mail.de
• The result of another test showed that GnuPG now was using the direct method
• Michael Kliewe also gave the information that 165 accounts did upload 171 on the WKD-server since the server was available. That means that there are 171 keys, which can now also be retrieved by clients that are implementing the current WKD-standard

Sources

[1] H. Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Edition, Spektrum Akademischer Verlag Heidelberg: 2009
[2] J. Nielsen, 10 Usability Heuristics for User Interface Design, https://www.nngroup.com/articles/ten-usability-heuristics/ [Accessed 15.12.2021].
[3] I. Klöcker, Error when trying to locate key via WKD, https://lists.gnupg.org/pipermail/gnupg-users/2021-October/065510.html, [Accessed 15.12.2021].
[4] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/07/, [Accessed 04.01.2022].
[5] Release GnuPG 2.2.17, https://dev.gnupg.org/T4606, [Accessed 04.01.2022].