RE: Why are mail servers not also key servers?

[Rui Costa <[e-mail]>]

Thanks Paul. We're considering untrustable email/DNS/... servers. OK.	

This particular email hasn't any jurisprudence value. However, it could have the same value as a registered letter, couldn't it? (Can't layers' emails?) I suppose the difference is some digital signature, which i guess will mean some certificate issued by some trusted entity. (Which means, at least once, the 2 ends can't avoid "having to meet" (not to set new keys but) to know each other's signature. (I actually don't know which entity grants them.))	

Why doesn't that solve the doubt about "who gave [...] the key"? And again, what have the networks in between to do with it?	

In traditional mail, the only thing one needs is the delivery registry and signatures. (Perhaps wrongly, i'm extrapolating Portuguese law to other countries'.) From that, you're sure you're writing who you want to write to. If on top of that you want, both of you can exchange keys and encrypt. However, that's inside the envelope. The mail service doesn't really care or know what's in there and wouldn't understand the message if the envelope was violated. Its role is simply...	
-transport	
-providing you the proof you sent the letter	
-providing you the proof the other end sent you the receipt (with its own signature)	

(But i fear you'll point out why this won't work with email, if you carry on the babysitting :-) Kind Regards	

-----Original Message-----
From: Paul Wouters [mailto:[e-mail]] 
Sent: 21 de abril de 2017 00:41
To: Rui Costa
Cc: [e-mail]
Subject: RE: Why are mail servers not also key servers?

On Thu, 20 Apr 2017, Rui Costa wrote:

> So, can someone point me to some 
> URL/documentation/https://mailarchive.ietf.org/arch/msg/ietf/xyz 
> explaining the point on having keys/cryptography somewhere in between 
> these 2 end points? (And thus i guess i'm saying i don't understand 
> cryptography's point on scenarios other than what i think people have 
> called on these threads "E2E".)

I want to send you an encrypted email. I need your key. I can send a plaintext email asking you for the key. I have to hope that it really reached you and that it is you who gave me the key and that the key was not modified in transport.

versus:

You publish your key somewhere with a verifiable link of key to your email address. Now your first contact with me will be encrypted and secured.

People have different ideas of what minimums and maximums to use for "verifiable link of key to email" (or even key to human)

Paul




-----Original Message-----
From: ietf [mailto:[e-mail]] On Behalf Of Rui Costa
Sent: 20 de abril de 2017 23:37
To: [e-mail]
Subject: RE: Why are mail servers not also key servers?

Although having read some of the DANE discussions that took place ~1 year ago, being PGP illiterate, a little less about SMTP, certificates, ... i don't understand this:	

Cryptography (at least "in the beginning") was created for E2E communication, independently of your network's layers or the hops/people it goes through.	
PK allowed something Caeser (or Dönitz, or other Enigma's users, or...) hadn't: the ability to avoid the 2 E2Es having to meet in order to set new keys.	

I guess (maybe wrongly) certificates handle something the internet brought, formerly inexistent: the answer to "is this person that sent me her/his public key REALLY the person she/he says to be, with whom i want to talk to?" In other words, some means of trust/signature, once "we can't see" with whom we speak/write.	



So, can someone point me to some URL/documentation/https://mailarchive.ietf.org/arch/msg/ietf/xyz explaining the point on having keys/cryptography somewhere in between these 2 end points? (And thus i guess i'm saying i don't understand cryptography's point on scenarios other than what i think people have called on these threads "E2E".)	


Some time ago a friend of mine told me her company changed the old firewall/proxy into zscaler. When the browser presented her new certificates asking her trust, she asked network support why didn't they explain people the implications: often on lunch breaks people use the network for private purposes like going to the bank, f.i. Network support pointed her to corporation network support which said it was that corporation's company own decision. She asked her director, that told her "we'll talk about it in the afternoon", an afternoon ~2 years ago. This makes me wonder whether people that have to take these decisions understand the implications.	

Most people think "https" means they're talking directly to the other end via a secure channel, know nothing about "man in the middle" or similar concepts. Why give them false confidence on scenarios other than E2E?	

King Regards,	
Rui