Request for Discussion: new/PubKeyDistributionConcept/FallbackServer

[Bernhard Reiter]

Am Mittwoch, 15. Juni 2016 11:04:45 schrieb Neal H. Walfield:
> On Wed, 15 Jun 2016 10:26:15 +0200,
>
> Bernhard Reiter wrote:
> > Am Dienstag, 14. Juni 2016 15:29:09 schrieb Neal H. Walfield:
> > To give my personally summary (of my current state):
> > Right now I believe that the introduction of WKD will have a better
> > overal security balance, because many more communication partners and
> > many more encrypted emails.
>
> But does it create a false sense of security?  

In my mental model it does not.
It builds on the trust you have in your personal MSP
and does not go far beyond it.

> We want to be better 
> than x509, right?  If not, then just use S/MIME.

No, we do not want to get better in all aspects.
PKIX (x509) is central where you have to trust a hierarchy.
Okay you can have several trust anchors, so it is not one single
trust anchor, but there is no practical way to 
a) find good trust anchors (without advanced crypto knowledge)
b) start low cost
c) update to stronger trust modules
d) have communication history flow in
e) come with a reasonable default configuration.

> > > The only defense against this
> > > is if Alice anonymously and regularly checks that the WKD server
> > > returns the correct public key, which isn't a terribly good defense.
> >
> > I claim that there are more defense possibilities and it is better
> > to trust a number of MSPs a bit that you will have to give some trust
> > anyway. (They could always just chose not to deliver an email
> > and send their own encrypted email to Alice.)
>
> To prevent a MitM, you need a secure channel.  You can decrease the
> change of a MitM be using multiple insecure channels.  These insecure
> channels can be either in space (different network routes) or time
> (last year, last month and yesterday).  This is what TOFU exploits.
>
> WKD uses a single insecure channel multiple times.  This does not add
> trust.

WKD over TLS is a secure channel to the MSP.
Adding the other channels (signature, other communication) and time
there is some protection against single malicious MSPs.

> > The big problem we are trying to solve is that for many user
> > groups we need to design a system that does not require advanced
> > experience with crypto concepts. To overcome this obstacle we try to find
> > one pubkey that is (medium) likely to belong to the person that controls
> > the email address I want to encrypt to.
>
> Well WKD doesn't get you medium assurance.  Or, you idea of medium is
> much different from mine.

Yes, this seems to be the case.
My argument is that is harder (more expensive) to attack than
publishing malicous pubkeys with keyservers or
initiatiating a low number of email interactions with a faked 
email address.

> > So it can be done automatically in 99.9% of
> > all cases. As you can see from the discussion in the wiki, WKD can be
> > helpful, but leaves the atack vectrr of the MSP oben. It is much better
> > than chosing a pubkey from a public server where everybody can upload
> > rouge pubkeys, because the attack against an MSP is much more expensive
> > and there are many MSPs to chose from. You could chose some residing in a
> > country that does not have national security letter like the US has.
>
> I disagree.  Using a key server means you get multiple routes, which
> is better.

Using a key server will not get a pubkey selected, there is no way to decide 
which key is bad or not. This does not change if you get those pubkeys
from several sources or not, there is no indication at all that they belong
to the owner of the email address.

> > However I believe because of
> > other reasons, that end-to-end encryption with OpenPGP needs to do
> > something and thus a more lightwright approach is good. Once a system
> > linke CONIKS is there, we can switch to it with comparatively small
> > efforts.
>
> I disagree.  AS I've stated in other mails, I think it will be harder,
> because MSPs will rightly see that Coniks increases their liability
> and they can say that they already implement a security measure.

I accept the argument that having one system in place that solves
(a part of) the problem will decrease the likelyhood of a more improved
system to be adopted. I give it less weight though. The reason is:
If OpenPGP does not come over the principal challenge, it will be 
superceded by more practical systems implementing something 
like the Signal protocol. I believe that OpenPGP has merits
over the Signal protocol, so I want OpenPGP implementations to improve.
In addition, clients could implement a common view system without the support 
of MSPs later if they have WKD in place.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160615/43f5ab93/attachment.sig>