Re: [Freedombox-discuss] DNS std for Freedomboxes? [was Re: Establishing Communicationbetween Freedomboxes]
On Wed, Aug 03, 2011 at 11:37:58AM +0800, Sandy Harris wrote: On Wed, Jul 20, 2011 at 2:53 AM, Tony Godshall t...@of.net wrote: Any downside to letting your adversary know what domains you are emailing to? Well, the mice probably don't want the octopus know that they are emailing via @octopusnotsogreat.org? But then again SMTP itself is not encrypted either... There is an opportunistic SSL-based encryption option for SMTP. http://tools.ietf.org/html/rfc3207 Sure, but as always with SSL, this is completely efficient only if you are able to first verify the certificate... This is still better than nothing but isn't a complete protection. AFAIK a monkeysphere implementation for SMTP is being worked on. This won't completely address the issue but will certainly help. Any two servers with that set up will automatically encrypt all mail transfers. If the Box runs a mail server, I'd say enabling that is a no-brainer. The only question is whether, when the other server does not support it, the Box should proceed with unencrypted transfer, or bounce the mail back to the user with some cannot send securely message, or try some alternate routing method. There's also Using TLS with IMAP, POP3 and ACAP http://tools.ietf.org/html/rfc2595 That covers the client-to-server transfer of mail. If the Box runs a mail server, that's another obvious requirement. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] DNS std for Freedomboxes? [was Re: Establishing Communicationbetween Freedomboxes]
a nice point to why we should have protocols that are secure by design, and are developed to protect privacy from the gitgo a user connecting to the network with unsecure settings, that is using unsecure protocols and encryption methods that are easily cracked is a security risk, and shouldn't not be welcome on the network. They pose a risk of being an intermediary node transferring data between the Egyptian user attempting to relay information from a repressive government which could help with identifying a source. this is one of those areas where enforcement is a must. On Wed, Aug 3, 2011 at 3:47 AM, berta...@ptitcanardnoir.org wrote: On Wed, Aug 03, 2011 at 11:37:58AM +0800, Sandy Harris wrote: On Wed, Jul 20, 2011 at 2:53 AM, Tony Godshall t...@of.net wrote: Any downside to letting your adversary know what domains you are emailing to? Well, the mice probably don't want the octopus know that they are emailing via @octopusnotsogreat.org? But then again SMTP itself is not encrypted either... There is an opportunistic SSL-based encryption option for SMTP. http://tools.ietf.org/html/rfc3207 Sure, but as always with SSL, this is completely efficient only if you are able to first verify the certificate... This is still better than nothing but isn't a complete protection. AFAIK a monkeysphere implementation for SMTP is being worked on. This won't completely address the issue but will certainly help. Any two servers with that set up will automatically encrypt all mail transfers. If the Box runs a mail server, I'd say enabling that is a no-brainer. The only question is whether, when the other server does not support it, the Box should proceed with unencrypted transfer, or bounce the mail back to the user with some cannot send securely message, or try some alternate routing method. There's also Using TLS with IMAP, POP3 and ACAP http://tools.ietf.org/html/rfc2595 That covers the client-to-server transfer of mail. If the Box runs a mail server, that's another obvious requirement. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss -- Thank you for your time ~Nathan nathan1...@gmail.com ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] DNS std for Freedomboxes? [was Re: Establishing Communicationbetween Freedomboxes]
On Wed, Jul 20, 2011 at 2:53 AM, Tony Godshall t...@of.net wrote: Any downside to letting your adversary know what domains you are emailing to? Well, the mice probably don't want the octopus know that they are emailing via @octopusnotsogreat.org? But then again SMTP itself is not encrypted either... There is an opportunistic SSL-based encryption option for SMTP. http://tools.ietf.org/html/rfc3207 Any two servers with that set up will automatically encrypt all mail transfers. If the Box runs a mail server, I'd say enabling that is a no-brainer. The only question is whether, when the other server does not support it, the Box should proceed with unencrypted transfer, or bounce the mail back to the user with some cannot send securely message, or try some alternate routing method. There's also Using TLS with IMAP, POP3 and ACAP http://tools.ietf.org/html/rfc2595 That covers the client-to-server transfer of mail. If the Box runs a mail server, that's another obvious requirement. ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] DNS std for Freedomboxes? [was Re: Establishing Communicationbetween Freedomboxes]
On Tue, Jul 19, 2011 at 11:08:50AM -0700, Tony Godshall wrote: Is Tor centralized this way? The Tor directory authorities are centralized, but the effect of compromising a DNS root server is probably worse than compromising a Tor directory authority. Right. Since Directory Protocol v2, statements made by a Directory authority are believed by a Tor client iff they were attested to by more than half of the authorities, so an adversary needs to compromise more than half of the Tor Directory authorities to be able to lie effectively to Tor clients. See dir-spec-v2.txt in the torspec Git repository¹ for details. The 0.1. History section of the (WIP) dir-spec.txt is a nice introduction to how such matters are dealt with by Tor. 1. git://git.torproject.org/torspec.git Bye, Thanks Is there any reason why Tor-based DNS should not be the default for the freedombox? DNS torification (using the DNSPort Tor option) actually only support A requests, meaning if the FreedomBox is setup to be a mail server, it can't work properly (at least MX DNS requests can't be resolved that way). But there are ways to configure a system so that it can use Tor for the A queries, and plain DNS for the rest. Maybe that should be an option chosen by the user? The arguments in favor would seem to be that it - is well tested - bypasses DNS manipulation by an ISP or adversary capable of compromising less than half of Tor - makes DNS lookups encrypted It does not, however, keep an adversary from logging connections by actual ip address (except for those that go through the high-latency Tor hidden service mechanism of course) Tony ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] DNS std for Freedomboxes? [was Re: Establishing Communicationbetween Freedomboxes]
On Tue, Jul 19, 2011 at 11:21 AM, berta...@ptitcanardnoir.org wrote: On Tue, Jul 19, 2011 at 11:08:50AM -0700, Tony Godshall wrote: Is Tor centralized this way? The Tor directory authorities are centralized, but the effect of compromising a DNS root server is probably worse than compromising a Tor directory authority. Right. Since Directory Protocol v2, statements made by a Directory authority are believed by a Tor client iff they were attested to by more than half of the authorities, so an adversary needs to compromise more than half of the Tor Directory authorities to be able to lie effectively to Tor clients. See dir-spec-v2.txt in the torspec Git repository¹ for details. The 0.1. History section of the (WIP) dir-spec.txt is a nice introduction to how such matters are dealt with by Tor. 1. git://git.torproject.org/torspec.git Bye, Thanks Is there any reason why Tor-based DNS should not be the default for the freedombox? DNS torification (using the DNSPort Tor option) actually only support A requests, meaning if the FreedomBox is setup to be a mail server, it can't work properly (at least MX DNS requests can't be resolved that way). But there are ways to configure a system so that it can use Tor for the A queries, and plain DNS for the rest. Thank you for pointing that out. Any downside to letting your adversary know what domains you are emailing to? Well, the mice probably don't want the octopus know that they are emailing via @octopusnotsogreat.org? But then again SMTP itself is not encrypted either... Maybe that should be an option chosen by the user? Too many options chosen by the user and we end up with a Linux Box rather than an appliance. A freedombox should be operational with minimal configuration- it should have rational functional secure-as-practical defaults. And of course a user with expertise can tweak them but it should not be demanded that newbies choose too much. Tony The arguments in favor would seem to be that it - is well tested - bypasses DNS manipulation by an ISP or adversary capable of compromising less than half of Tor - makes DNS lookups encrypted It does not, however, keep an adversary from logging connections by actual ip address (except for those that go through the high-latency Tor hidden service mechanism of course) ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
