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:paul(_at_)nohats(_dot_)ca]
Sent: 21 de abril de 2017 00:41
To: Rui Costa
Cc: ietf(_at_)ietf(_dot_)org
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:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Rui Costa
Sent: 20 de abril de 2017 23:37
To: ietf(_at_)ietf(_dot_)org
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