Request for Discussion: new/PubKeyDistributionConcept/FallbackServer

[Bernhard Reiter]

Hi Neal,

Am Dienstag, 14. Juni 2016 15:29:09 schrieb Neal H. Walfield:
> Please explain to me how a WKD being run by an MSP is not almost the
> same thing as using key escrow?  Let's say Alice's MSP runs WKD¸ I
> look up her key using WKD, and her MSP returns the public part of a
> fresh key.  When I send her an email, the MSP reencrypts the message
> and neither I nor Alice is any wiser. 

thanks for asking the question on a pointed way!
This is why I am asking. There are a number of considerations.
They need to be discussed and fully explored.

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.

> 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.)

There is also communication history that can serve as a defense against
malicious MSPs and there is the possibility for Bob who wants to send email to 
Alice to change the trust values of signatures and communication history.
For this Bob needs to be an experienced user, because he will have to argu 
about trust explicitely. 

> So, no, WKD is not add a "medium" amount of validity to the key.  In
> fact, using a key server and guessing which key is right is probably
> better than this scheme, because it uses a different network path,
> which means your MSP couldn't be compromised by an NSL!

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. 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.

> Note: it would be possible to save this scheme if we augmented WKD
> with something like Coniks [1], but Werner doesn't like this, because
> it adds complexity and will take too much time to implement and we
> need to ship in the near future.
>
>   [1] https://coniks.cs.princeton.edu/

I agree with Werner here (you did see the coniks an other concept mentioned
on the wiki page?) Coniks is to heavy to introduce now, time and number of 
parties that we will have to win over are an issue. There is a conflict line 
with the EasyGPG2016 contract, because this contract has a limited time line.
(This is why I am openly talking about this.) 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.

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/de757adb/attachment.sig>