Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS verification #6

Closed
BlauerHunger opened this issue Dec 28, 2016 · 3 comments
Closed

TLS verification #6

BlauerHunger opened this issue Dec 28, 2016 · 3 comments

Comments

@BlauerHunger
Copy link

Why don't you verify the smtp server's onion service with the tls certificate they offer on direct connect? This would make trolling etc harder

@meskio
Copy link
Contributor

meskio commented Dec 29, 2016

I guess you are talking about the SRV proposal. So to validate that the onion domain appearing in the DNS record you do first a connection to the 'normal' MX and check if the TLS key matches with the one of the onion address. Isn't it?

I see few problems with this approach:

  • The 'normal' MX address I get them doing a DNS request, so I have to trust the same source than for getting the onion address.
  • Doing a connection to the MX address for each delivery will leak metadata that we try to protect. But this could be improved by some caching.
  • Some providers do have several servers with different TLS certificates, so a failure in matching the cert might not mean that is not the same provider.

@BlauerHunger
Copy link
Author

Let me try to clarify my idea: The server should authenticate itself like when a connection goes in on the classic way (MX). For this you don't need a connection to the smtp service over the clearnet, and you have additional authentication on the onion service. You just need to check whether the certificate the server presents on its onion service would be accepted by the sender server if it would connect directly (match domains)

@micah
Copy link
Contributor

micah commented Mar 1, 2017

In general we saw MX records as a possible solution, but we were worrying how different MTAs are dealing with such records. Given that we need to anyway setup a dedicated route within MTAs configuration and they won't just transparently route email towards onion services (remember this is a solution where 99% of the traffic still flows over clearnet), we didn't really see anymore an advantage in an already occupied and very specific DNS type. SRV records are in our opinion a more generic and better approach to model such lookups.

We are working on a more formal document that describes our reasoning and also how we envision tranports to use SRV records.

I will close this ticket and like to ask any further disucssion to happen on the mailinglist: https://lists.immerda.ch/mailman/listinfo/onionmx

@micah micah closed this as completed Mar 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants