[messaging] Separation of concerns, usability, and partial verification

[Ximin Luo]

On 12/03/14 15:50, Daniel Kahn Gillmor wrote:
> Hi Ximin--
> 
> I agree with the general goal that a contact manager is the right place
> to store the sort of information you're describing.
> 
> other useful material might be:
> 
>  * public key pinning information (whether HPKP or TACK or something else)
>  * version or feature-specific "latches" (as currently being discussed
> in UTA) to avoid downgrade attacks
> 
> On 03/12/2014 11:28 AM, Ximin Luo wrote:
>> For example, often people will sign all the email addresses on a GPG key, without checking if the signee actually owns each address. This is not an obvious thing to do, since everyone is so focused on (OMG) fingerprints.
> 
> yeah, this is a usability fail for GnuPG at least, including most GUI
> frontends.  Up until a few years ago, enigmail was actually reporting
> the validity metric of the highest-validated key, while displaying the
> user ID that matches the (unverified) From: header of the e-mail.  This
> was a serious flaw, as allowed mail from anyone who happened to have a
> valid key+userid to spoof mail from any other address, as long as they
> were willing to add a new User ID to their own key. :/  (i looked for
> the reference for this, but can't find it right now -- it's fixed though)
> 
>> One bug I noticed for the debian keyserver is that it performs no verification of email updates on submitted keys, so any Debian Developer can claim they own obama at whitehouse.gov, and Debian keyring infrastructure will automatically import this.
> 
> all keyservers do this; official debian keyring updates themselves are
> handled manually based on material gathered from the keyservers.  you're
> right that these manual updates should be inspected closely before
> shipping as part of the canonical debian keyring.  are you aware of any
> key that has shipped in the debian keyring with a bogus e-mail address
> associated with it?
> 

Sure - I meant to emphasize that the debian keyserver additionally then takes this information and puts it into the debian-keyring package, assuming that it is valid (in a way that other keyservers do not), and distributes this to other people with implicit authority. Fortunately, I haven't seen an actual abuse of this.

>> A further consequence is that, such an architecture would encourage contact managers to secure (auth-encrypt) ALL contact metadata.
> 
> i'm not sure what you mean by this.  can you explain more?
> 

It's a minor point - a keyring should already be auth-encrypting its secrets. If we had an integrated keyring/contacts/verification program, it would be very little effort to extend this protection to other metadata that is often treated more carelessly.

Another usability topic is to gamify the verification process - give people rewards for "doing things properly". It sounds gimmicky, but people are quite happy to do lots of even more weird/useless things. :) Some people are even gamifying entropy collection. Like the "sync to other devices" point, it would be much more suitable to do this inside a central system component, since it's quite a separate concern from secure messaging.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140312/ba2b1555/attachment.sig>