Re: PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 22, 2015 at 2:59 AM, Harald Alvestrand <harald@xxxxxxxxxxxxx> wrote:
Warning: random PGP musings ahead....

it's been obvious to me since the 90s that the hierarchical models of
trust (CAs, corp signing authorities) are simply restricted webs of
trust. So the WoT model is a more general one than the hierarchical one:
you can represent hierarchy as a WoT (the user trusts the root keys,
trust flows from there), but not vice versa.

I've been saddened by the crippled state of WoT-manipulating user
interfaces since roughly forever.
They seem to be utterly incompetent in answering questions like:

In the wake of PRISM I set out to design a system for end to end email security that would meet a longstanding usability goal I had suggested of making secure use of the application require mo more effort than insecure use.

SSL was successful because it demands absolutely nothing of the user. The user does not even have to look at the padlock icon if they don't want to and they certainly don't need to do checks unless they have a security concern - visiting their bank site for example.

People did point out that SSL isn't ideal and they are right. SSL came out in 1995 when standards were much lower and users were willing to learn new things. Today the standard for usability is the iPhone/Jobs standard. If you would not be comfortable pitching the scheme to Steve then don't bother proposing it.

So I have demonstrated my S/MIME client that does not demand anything of the user beyond running the profile application once. PKI should never require effort on the part of the end user. If a procedure can be reduced to a set of 'easy to follow instructions' it can be reduced to code. And code is much cheaper than customer service calls. There is absolutely no reason you can't automate every step in PKI management. The original PROSMProof scheme uses S/MIME because that is what is already supported in the email clients. The plan all along was to support both S/MIME and OpenPGP for production.


A few months back I realized that I had the criteria wrong. It is even tougher than 'do no harm'. To get people using strong crypto you have to do better than not making things any worse. You have to make life easier for the user.

Which is how I came up with the idea of the CryptoMesh which has a primary function of serving as a username/password manager that cannot be compromised by a cloud breach. It also makes it really easy to configure new devices with existing network settings. So instead of having to type in that incomprehensible nonsense to configure your inbound/outbound server ports (there are three possible values for each) for each new phone, that can be copied.

The Mesh will also copy the crypto configuration at the same time of course. And why wouldn't the user have one?


At this point it is clear that everyone thinking about the problem seriously understands that:

* There are applications where a hierarchical trust model is essential (e.g. government use).

* There are applications where it is not.

* There are situations where a direct trust model (i.e. fingerprint of key) is appropriate.

* There are situations where an opportunistic trust after first contact approach is appropriate.

* All of these are sub-classes of a Web of Trust approach.


The last point is important because trust links are like GOTO statements. If you don't have some structure and discipline when you use them you are going to have no idea what you have created actually means.

To work out what a trust link means you have to have a model. The model I use is to look at the work factor required to make a false claim. This is a dollar cost rather than a number of CPU cycles but it is still a work factor.

The reason blockchain/CT/hashchain type approaches have so much power is that they increase the work factor to essentially infinity for postdating an assertion. 


I don't see the DANE approach as remotely practical for any user based assertion. I don't think it has much work factor leverage either. It is much easier for an attacker to compromise my DNS provider than the systems I control directly.

But getting back to Harald's original challenge, there are plenty of ways of automatically generating interesting Webs of Trust.

For example, lets sat my UDF fingerprint is MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Lets say that this email had that fingerprint in the email headers:

SenderUDF: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Now lets say one of you sends me an email and your email client presents me with a challenge:


SenderUDF: MIRXW-4J3UE-BDHKY-3LEBI-GSZ3T
Challenge: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=KRXXE2LFOMQGC3DMEBTHKY3LEBYGSZ3TBI

At this point your email client has presented my email client with a challenge against my purported personal PKI. My client can now respond and prove to you directly that a party with a key that is credentialed under the original fingerprint 

SenderUDF: MIRXW-4J3UE-BDHKY-3LEBI-GSZ3T
Challenge: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=JF2HGIDHN5UW4ZZANFXCAYJAOBUWO4ZANVXXK
Proof: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ;
    nonce=KRXXE2LFOMQGC3DMEBTHKY3LEBYGSZ3TBI ;
    nonce2=KNUXIIDEN53W4IDZN52XEIDGOVRWW2LO ;
    value= NB2HI4DTHIXS653XO4XHS33VOR2WEZJOMNX
      W2L3XMF2GG2B7OY6UMQTQKFFDSODSKI2G6CQ


This type of trust building mechanism can be made completely transparent to the end user.


Now to make this completely seamless and cope with real corner cases you need a lot of PKI. But the user doesn't need to see any of it. 

People who are asking whether OpenPGP or S/MIME is the answer are both wrong. Both specs have a message format but neither is sufficient to meet real world needs for a personal PKI.

OpenPGP fingerprints are a good idea. But the fingerprint that is exchanged should be the fingerprint of a personal trust root and not a particular application key. Binding everything to application keys made sense in 1995 when few people even had access to more than one device and machines were slow making path math a major drag. Today we have different requirements and fewer CPU constraints.


Anyway, I am going back to complete the code between laughing at my Oxford acquaintance who is now trying to make my sort of work criminal in the home country.

I really need a lot more help to make this happen. If people want to build a trust infrastructure that makes the Web easier to use then lets do it.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]