Trying to be more precise
Update thoughts on automated conflict resolution and change wording to say that this should be done.
|Deletions are marked like this.||Additions are marked like this.|
|Line 193:||Line 193:|
|# There is a man in the middle trying to intercept encrypted communication.||# There is a man in the middle trying to intercept encrypted communication and he did not control all of your communication history.|
|Line 203:||Line 203:|
The first misuse case should be handled on the senders side. The second
misuse case may be handled or mitigated by using slightliy authenticated
source for the key retrieval.
Both misuse cases should be handled on the senders side because
he controls or lost control of the involved keys and can take steps /
inform himself what went wrong.
|Line 216:||Line 216:|
|Similarly, if a signature is verified by a mua and there are secret||Similarly, if a signature is verified by a MUA and there are secret|
|Line 229:||Line 229:|
|=== Resolving conflicts on the receivers side ===
We will have to see in practice how often tofu conflicts happen and
if there are different means we can avoid them. For now the preferred
solution is the Conflict Dialog. An alternative approach for
discussion is the automated resolution. Resolution through a conflict
Dialog hurts the goal to automate encryption. The goal should
be to try hard to avoid it.
==== Conflict Dialog ====
A dialog should be offered that asks
the user to check with the sender / call his IT Support and then:
* Use the new key from now on. (Policy auto on the new Key, Policy bad on the old key)
* Reject the new key (Policy bad on the new key, Policy auto on the old key)
The key used to secure this message differs from the key usually used to secure
messages from "firstname.lastname@example.org"
Please call "email@example.com" or your IT Support to call what happend
and check if the new key to secure your communication with him has
1101 C077 198C 91E3 5BB9 CC78 856B 9E7E 60A1 542A
Secure communication with "firstname.lastname@example.org" is no longer possible
until you have ensured that the new key is legitimate.
[Ask me later] [Use new key] [Keep using the old key]
There should be no option to mark both keys as "good" this case needs
to be handled on the sender side to avoid that this becomes common
practice and many uses that communicate with the sender run into
==== Automated Resolution ====
A conflict could be automatically resolved by keeping the old key
|==== Automated conflict resolution by recipients ====
Recipient means here that if there are two keys seen for one sender
address when verifying a mail, the recipient is the person doing
A conflict should then be automatically resolved by keeping the old key
|Line 273:||Line 239:|
|Technically this is not planned for in the TOFU trust model,
but this is an idea for discussion and could be implemented in a MUA. Probably
by setting policy to good for both keys and handling that specially in validity
The conflict would be detectable in the interface for a user who cares about it
because it will no longer be shown that the sender is somewhat verified
and that there is no basic history yet. Meaning the sender is back to
This necessitates an option to mark the old key explicitly as bad. E.g if
your communication partner has lost his old key through misuse. But that
would then be needed to be triggered by the sender when he receives replies
that he can't decrypt. With the assumption that the sender already knows
more about what happened and can explain this then to the recipient.
|* Policy bad for the new key.
* Policy ask for the old key.
The conflict would be detectable in the interface because it will no
longer be shown that the sender is verified. A details dialog should
provide a clear and easy option to switch keys for this recipient.
The new key will then get policy auto and the old key as policy bad.
E.g if your communication partner has lost his old key through misuse.
|Line 291:||Line 252:|
|* A man in the Middle attack will be cheaper because it won't require
manual interaction of the user. (This is partly mitigated by keeping the old key in use for encryption.)
* Impostor attack would still be prevented until the impostor has built up
enough communication history.
|* A man in the Middle attack will be prevented and may be detected.
* Impostor attack would still be prevented because the new key is never shown
as valid / verified unless user interaction is done.
|Line 298:||Line 258:|
===== Opinion of aheinecke: =====
While I like the idea of still keeping to use the old key in case of conflict as it
moves the misuse problems from the receiver to the sender and the usage of the old
key will mitigate a Man in the Middle, as a first step automated conflict
resolution is a step too far, we need to see if false positive conflicts are
really a thing in practice and then think in a next
step about automated resolution.
Automated encryption already "lowers" security compared to the theoretical web of trust,
(Imo not compared to the wot as used in practice) and it might lead to bad publicity
and won't be accepted by the existing community.
So my conclusion here is that this goes a step too far.
- Trust Levels
- Signature Status
- Conflict handling
- Key discovery and Opportunistic Encryption (Mail only)
- Screenshots from GpgOL
This page is intended as a discussion base for validity display and opportunistic mail encryption and how to use the trust-model tofu+pgp for automated encryption.
Things to do after discussion and Feedback not integrated in this draft
- The yellow checker does not work as a symbol.
- Level 5 is not part of the screenshots.
userid Means the userid on a key that matches the smtp Address of the recipient / sender.
(userid.validity <= Marginal AND tofu.signcount == 0 AND tofu.enccount == 0 AND key.source NOT in [cert, pka, danke, wkd])
With trust-model tofu+pgp this level is only for Keys that were never used before to verify a signature and not obtained by a source that gives some slight indication that this is an actual key for this address.
Key should not be used for opportunistic encryption to avoid the problem that the recipient might not be able to decrypt the message because it is a wrong or outdated key.
- Do not automatically encrypt to Level 0.
((userid.validity == Marginal AND tofu.validity < "Key with enough history for basic trust") AND key.source NOT in [cert, pka, dane, wkd]):
This level means that have weak confidence that the recipient actually can use the key as we have seen at least one signature or we have a weak trust path over the web of trust.
OK to use that Key for Opportunistic encryption but when receiving a signed message it should only show in details that a message was signed.
There may be some indication that the sender demonstrated a willingness to use crypto mails, especially if opportunistic encryption is disabled.
- Automatically encrypt to Level 1
- Don't show verified messages as much more trusted then an unverified message.
(userid.validity == Marginal AND ((tofu.validity >= "Key with enough history for basic trust" AND tofu.signfirst >= 3 Days ago) OR key.source IN [cert, pka, dane, wkd])):
Basic confidence that the Sender is who he claims because we either have an established communication history or the source of the key (e.g. the mail provider) provided the key for this sender.
This is the highest level you can achieve without user interaction.
- Automatically encrypt to Level 2
- Show verified messages as more trusted then an unverified message.
userid.validity == Full AND "no key with ownertrust ultimate signed this userid."
This is reached either through Web of Trust or if a user explicitly set the tofu Policy to "Good" for this key.
Automatically this Level can only be reached through WoT.
- Automatically encrypt to Level 3
- Show verified messages as much more trusted then an unverified message.
userid.validity == ultimate OR (userid.validity == full AND "any key with ownertrust ultimate signed this userid.")
This level is equivalent to a key valid if gnupg would use trust-model direct.
Either yourself or someone that is allowed to make that e.g. your central "CA" style person you may have in an organisation has signed that key.
- Automatically encrypt to level 4
- Show verified messages as "the best".
The "automated user" that never uses any Certificate Manager or or GnuPG will only see Level one and Level two.
With level one being nearly presented as an "Unsigned" mail the Trust visualisation from Level two will be the only level that is really visible. So there are not many levels in this case.
For more advanced users and from a "Ui Language" point of view only two levels would be too simplistic because we have to distinguish still between just automatic Trust based on history and trust from Web of Trust or manual checks. This is because without a manual check we can never make the "full" claim that the senders identity was verified.
Level 4 is the level for manually checked keys, we can offer that option e.g. from a details dialog. So that a user can mark "Ok with this communication partner I want to be absolutely sure that I'm always using the right key. So I manually verify the fingerprint.".
That's a *can* it should not be suggested that this needs to be done, but it should be offered.
The additional Level's also give flexibility for Organisational Measures like: You may only send restricted documents to Level 4 keys.
Time delay for level 2
A time delay is supposed to make it more expensive for an attacker to reach level 2 as we then start to make claims about the attacker.
The assumption is that an attack that is kept up over some time is more difficult. Especially if it involves some external factors, like a phishing website etc. which might be turned off.
A time delay gives others the chance to intervene if they detect an attack e.g. if it is organisationwide.
It also mitigates User Experience problems arising from the use of the encryption count in GnuPG's calculation for basic history because if you encrypt 20 drafts or 20 mails / files quickly to the same key it should not become level 2 before you have seen a signature.
A concern is that using the time of the first signature verification before reaching level 2 make lead to bad user experience. E.g.: You look at the same message after three days. Now it's level 2, last time you looked it was level 1.
There should only be one prominent information when reading a signed mail:
- Is there additional information that the sender is really is the intended communication partner. (Level 2 + Level 3)
This could be displayed as a checker or a seal ribbon or something. It should be prominent and next to the signed content. There should be a distinction between Levels two, three and four but it may be slight.
Don't treat signed mails worse then an unsigned mail
A MUA should not treat any signed mail worse then an unsigned mail. If a sender is not verified it should be displayed similar to an unsigned mail because in both cases you have no information that the Sender is actually your intended Communication partner. You may want to show a tofu Conflict more prominent as user interaction is required at this point.
Especially: ignore GPGME's Red suggestion An attacker would have removed the signature instead of invalidating it. It should be treated like an unsigned mail and only additional info in details should be shown for diagnostic purposes. Similarly when Red is set because a key is expired or so. It's not more negative then a unsigned mail.
What happens when there is a conflict in the tofu trust model, so you have seen two keys for a senders mailbox and the keys are not cross-signed and both are valid.
When can this happen:
- There is a man in the middle trying to intercept encrypted communication and he did not control all of your communication history.
- There is an impostor trying to claim a false identity.
- There is a DOS attacker trying to hurt usability so much that automated encryption is no longer used.
- A user generated two keys e.g. on two devices and did not cross sign them and uses both.
- A user lost control of his old key, and did not have a revocation certificate.
Both misuse cases should be handled on the senders side because he controls or lost control of the involved keys and can take steps / inform himself what went wrong.
Resolving conflicts on the senders side
A tofu aware GUI should (even when TOFU is disabled) check when a secret key is used for signing if there are other secret keys with the same uid available and they are not cross signed a GUI should offer that option.
Similarly, if a signature is verified by a MUA and there are secret keys available with the same userid and they are not cross signed this should be told to the user and offered to do if possible.
A tofu aware GUI should check when signing or from time to time if a different key is uploaded to a WKD for this userid and warn in that case. This will also make a permanent man in the middle attack by a mail service provider more expensive as it would mean providing a different key to the attacked user then to others.
Automated conflict resolution by recipients
Recipient means here that if there are two keys seen for one sender address when verifying a mail, the recipient is the person doing the verification.
A conflict should then be automatically resolved by keeping the old key in use for automated encryption to this address until it is revoked or explicitly marked as bad and treating the new key for validity display just like a fresh key.
- Policy bad for the new key.
- Policy ask for the old key.
The conflict would be detectable in the interface because it will no longer be shown that the sender is verified. A details dialog should provide a clear and easy option to switch keys for this recipient.
The new key will then get policy auto and the old key as policy bad.
E.g if your communication partner has lost his old key through misuse.
How would this relate to attacks?
- A man in the Middle attack will be prevented and may be detected.
- Impostor attack would still be prevented because the new key is never shown as valid / verified unless user interaction is done.
- The DOS Crypto Attack will be prevented as conflicts are not shown so prominent.
Key discovery and Opportunistic Encryption (Mail only)
A MUA should offer automated key discovery and opportunistic encryption. The WKD / WKS helps with automated key discovery and should be used (by using --locate-key)
To determine if a mail can be sent automatically encrypted one of the following rules must match for each recipient:
- There is a Fully / Ultimately valid key for the recipient.
- This is a marginally valid key for the recipient and the first UserID that matches the recipients mailbox has a signcount of at least one. Or the recipients key was obtained through a slightly authenticated source (e.g. WKD).
Auto Key Retrieve
Additionally to WKD lookup, if you receive a message from an Unknown Key a MUA should automatically retrieve it from a public keyserver or a Web Key directory. This Key can then be used for opportunistic encryption because you have seen a signature it is very likely that the recipient can decrypt. (auto-key-retrieve in gnupg)
Screenshots from GpgOL
No key was found. Level 0.
The first signed message form someone else. Level 1.
The second message. Level 1.
Basic trust! Level 2.
Full trust! Level 3.
Invalid sig. Level 0.
Tofu conflict. User attention required.