How to show TOFU / Web Key Directory trust in Mail user Agents

[meskio]

Quoting Andre Heinecke (2016-06-10 10:35:08)
> I'm currently writing a plan how we will implement support for TOFU in KMail 
> for signature states this is relatively clear to me. We only show a "Green" or 
> Valid / Trusted signature once we have the reached the "Key with enough 
> history for basic trust" state. Well actually we will probably follow what 
> GpgME tells us.
> 
> But for sending I'm unsure how to handle encrypting to a recipient that does 
> not have enough history for basic trust.
> 
> Currently KMail warns if a Key for a UID is selected where the UID Validity is 
> less then Marginal. In the Future [1] we want to show an icon representation / 
> and  simplified Tooltip of the Key Validity next to the Recipient entry field. 
> Where  a click on the Icon would open a Details dialog with more explanations.
> 
> Unknown / key without history: Some kind of Warning / Question Mark Icon and a 
> tooltip with something simple like "Security Unkown".
> 
> But the next point is where I am unsure about:
> Marginal / key with too little history for basic trust: I'd like to show 
> something like "Security Good" / Green check mark in that case already. 
> Because:
> a) Encrypting with this key means you are already protected against all 
> passive attacks and just using OpenPGP is way better then sending an 
> unencrypted mail.
> b) We are using TOFU (Trust on _first_ Use) not TOTU (Trust on tenth use ;-) )
> c) I don't know what else the user could do to increase that trust in the Tofu 
> model. "Hey please send me 10 more mails before I will respond to you with all 
> my secret data."
> 
> Full Details with TOFU History would be available on click in the details 
> Dialog for technically interested users.
> 
> But of course this leaves you open to an attack that would prompt you to 
> encrypt data to a Mail Address, sent in a signed Mail and the Reply would 
> already show "Good" security as you have verified one signature from that key.
> 
> Because of this I was critisized that this is a too "relaxed" UI and that we 
> should rather show some "There is no indication that this Key belongs to the 
> User" warning for cases where TOFU Trust is "Key with too little history".
> 
> Which leads me to another Problem. How to show / handle the case where a Key 
> was obtained from the Drafted Web Key Directory [2]. In this case there is 
> already an indication that the Key belongs to the owner of the Mail account as 
> the provider / web key service told us this. But in the TOFU Trust model this 
> key would be handled like a key with too little history.
> 
> I think ideally such a key would be treated like a key with enough history for 
> basic trust as an Attack would have been more expensive then just "tricking" 
> the user into verifying one mail.
> 
> Do you have any suggestions how we should handle this in the UI? And how to 
> treat Web Key Directory keys?

Pretty interesting this 'key with enough history for basic trust' concept. At 
bitmask[0] we have something similar but simpler where we do kind of TOFU once 
we have sent an encrypted email and received a signed one.

About how to treat Web Key Directory keys maybe you can get some inspiration on 
how we do it. We don't have support for Web Key Directories yet, but will be 
easy to add to our trust model, we have something similar were the providers 
certify the keys of it's users[1]. We have a numeric representation of the level 
of trust of the source of the key, we call it Validation Level. And we use this 
validation levels combined the use of the keys to see if we should trust a new 
key we found for this email address or not. See a longer explanation at:
https://leap.se/en/docs/design/transitional-key-validation


[0] https://bitmask.net/
[1] https://leap.se/en/docs/design/nicknym

-- 
Ruben Pollan  | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: </pipermail/attachments/20160610/2256d39e/attachment.sig>