Hello to all those who saw my presentation at APNIC20 APOPS BoF and those
who missed it.
If you missed it, you can get it at
http://www.apnic.net/meetings/20/docs/other/apops-pres-narula-weakness-sol.p
pt
First off, I would like to tank all of you who attended especially those who
stated their comments.
It was a great pleasure to get into discussions with you all.
Let's get back to the point. Yes TLS vs. DKIM as brought up by Dr. Kazuhiko
Yamamoto.
These 2 are completely 2 different technologies. DKIM is meant more for
authentication and it also involved the use of DNS while TLS provides
different kind of authentication along with full confidentiality of the
email.
Let's try to compare DKIM and TLS here:
DKIM:
-Provides authentication of sender domain
-Provides authenticity verification of the message (message cannot be
tampered)
-Does not provide confidentiality of the email (message can still be snooped
and even if it can provide confidentiality, the level of confidentiality
would not be high enough as they are not 3rd party signed certificates)
-!!!Does not provide mechanism for verification of the receiving email
server
-Involves DNS for key information, this could be extra point of failure
TLS with key signed by CA:
-Provides highly secure authentication method that is fool-proof (3rd party
signed certificate)
-Provides authenticity of email (message cannot be tampered as the content
gets encrypted)
-Provides high level of confidentiality with 3rd party signed certificate
-!!!Provides both way certification (the sending server can check receiving
server's authenticity as well)
-With 3rd party signed certificate, the signer will hold full information of
the sending server party this will include but not limited to Company name,
Admin name, Address, Telephone number. On top of that there will also be a
money trail for the payment of the certificate.
-Do not involve DNS for key information
Why is SSL successful today? There are several reasons for this, and one of
them is that it is not free.
Anything that is free gets abused. Charging a low fee for email certificate
signing makes sense.
With payment required, 99% of bad guys would go away. Ask yourself, do you
trust SSL?
No solution is a perfect one or will be a perfect one. But what we are
trying to achieve together is to bring email system to the next level.
What would you think of this:
1st step, allow TLS to work with non-TLS servers and collect data and
feedbacks
2nd step, Once enough data has been gathered, evaluate the outcome and make
plan for rectifying the related issues
3rd step, Fix the issues and setup a cut-off date
4th step, project a suitable cut-off date to implement TLS-only email
Please let me know what you think. All comments, suggestions, inputs,
outputs, stderrs, will be highly appreciated.
The initial pilot could be done, for example in Japan by the larger
providers as models. Once the whole of Japan implements TLS, it will mean
that the whole Japan's email system security gets to the next level then the
model could be replicated in other parts of the world.
-Ram Narula
Plus Lab co., ltd
