User: Password:
|
|
Subscribe / Log in / New account

Email privacy

Email privacy

Posted Nov 10, 2007 11:57 UTC (Sat) by man_ls (guest, #15091)
In reply to: Email privacy by copsewood
Parent article: Email privacy

Underlying all those technical difficulties there is a broader issue: if I want to send you a private email I need your public key, and I need to get it from you. I cannot rely on my ISP to handle public keys (as they handle domain names), since then the trust problems would be the same: ISPs might just be forced to supply their own public keys, then decrypt all messages and encrypt them with the true public key. A simple man-in-the-middle attack which would defeat your scheme.

I don't see how people can exchange public keys easily unless they physically get together. Key signing just makes the issue more complicated.


(Log in to post comments)

Email privacy

Posted Nov 12, 2007 18:55 UTC (Mon) by copsewood (subscriber, #199) [Link]

If the key certificate is in the DNS and you trust the certificate chain
down through the DNS tree from the root at the TLD, then you
can establish a measure of trust in the key that I publish in the DNS zone for my domain
genuinely belongs to me, because it was signed by the higher level domain key when I
registered or renewed the domain.

Email privacy

Posted Nov 12, 2007 20:49 UTC (Mon) by man_ls (guest, #15091) [Link]

That only works if I own the domain. Most people get their email from a higher level provider, which also own the DNS record. It is easy to redirect selected queries.

And even if I own the domain, a simple change at my domain registrar would suffice to redirect queries to another server. Or at a root server; as you say, you have to trust the certificate chain down to the root. How do you defend against that?

Email privacy

Posted Nov 14, 2007 22:03 UTC (Wed) by copsewood (subscriber, #199) [Link]

"That only works if I own the domain. Most people get their email from a higher level
provider, which also own the DNS record. It is easy to redirect selected queries."

Semantically joe@example.com carries the same global meaning in connection with working
relationships, name delegation and a potential certificate chain as joe.example.com, though I
accept that the syntax differs. 

"And even if I own the domain, a simple change at my domain registrar would suffice to
redirect queries to another server. Or at a root server; as you say, you have to trust the
certificate chain down to the root. How do you defend against that?"

If you trust the .com root key signing certificate, and .com registry has signed the
example.com certificate, to assert that this key genuinely belongs to the owner of
example.com, and the example.com key has similarly been used to sign the joe.example.com or
even the joe@example.com certificate, then a verifiable chain of trust exists. If you don't
like or trust the .com key-signing certificate, you can register example.co.uk or example.de .
In fact any community that wants to establish a certification tree can root this at any DNS
domain or subdomain that they elect to use for this purpose. As Joe, you defend against
example.com reallocating joe.example.com to someone else in the same way that you prevent .com
reallocating example.com to someone else if you are example.com . If you don't trust the next
label up the chain reallocating your identity in breach of contract, find a domain parent you
do trust to keep to its contract.

If the standards agreed for this purpose place references to locations for certificates at
regular and known places within the DNS then a chain enabling a certificate to be located and
verfied based on knowledge of the the location of the root and trust in the root certificate,
will exist so long as all parent domains to yours up to the root server operate in accordance
with the agreed standard for achieving this. Relocation is no more of an issue than it already
is if the IP address of a DNS server containing delegation records for your domain is changed
- the next level up has to be updated to contain the new address.

If a domain's DNS is spoofed e.g. through a cache poisoning attack, this will create the
possibility of a denial of service attack in the sense that the spoofed domain location will
not contain a certificate for the domain certificated by its parent, making the genuine domain
uncontactable until the redirection is resolved.

Generally domain parents don't do the reputation of their own domain
any good by playing fast and loose with identities or breaching contracts with customers, but
if a domain registration contract has been allowed to lapse, there is nothing to prevent the
identities concerned from being reallocated, just as there is nothing to prevent someone else
from having the same name as me or someone given the family name: McDonald at birth from
opening a restaurant under their own name.

Cryptography will always be seen to fail if the standard required for success is for it to be
seen as solving all of the world's honesty, security and identity problems. This doesn't
prevent crypto from being used more universally and easily than it now is. Personally I can
see some good reasons for the set of working relationships we know as the DNS to be extended
in this manner. I'm not interested in evaluating this against the assumption that this has to
give "perfect security" in all situations as all proposals will fail based on such a
criterion. I am interested in whether this enables us achieve better security than what we now
have in practice more readily than other possible approaches.


Email privacy

Posted Nov 14, 2007 23:47 UTC (Wed) by man_ls (guest, #15091) [Link]

Thanks for the lengthy explanation, it made your point much clearer at least for me.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds