ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal

2019-01-08 20:45:56


On 9 Jan 2019, at 1:34 pm, Viruthagiri Thirumavalavan 
<giri(_at_)dombox(_dot_)org> wrote:

Why do you think all MiTM attacker will have control over DNS?

Because they ARE IN THE MIDDLE.  You can modify DNS responses as easily as SMTP 
streams.  Firewall vendors that strip STARTTLS will just modify the DNS 
responses if this draft gets published.

If that's the case, then we have been fooled by STARTTLS saying it's secure 
for the past 20 years. 

Why do you think DANE requires signed and validated as secure DNSSEC responses 
to the MX/SRV/AAAA/A lookups before it even attempts
a TLSA lookup?  You need to know that the inputs have not been spoofed before 
deciding if you can trust a CERT being presented.

If your SMTP service provider does not support DANE they DO NOT REALLY CARE 
ABOUT SECURITY.

Mark

On Wed, Jan 9, 2019, 7:56 AM Mark Andrews <marka(_at_)isc(_dot_)org wrote:


On 9 Jan 2019, at 1:19 pm, Viruthagiri Thirumavalavan 
<giri(_at_)dombox(_dot_)org> wrote:

The simple answer is WE DO NOT *NEED* MTA-STS.  Additionally it can be 
spoofed
without DNSSEC.  The only thing it does is reduce the number of players 
involved
if you are not self hosting.

I get it. You are a fan of DNSSEC. But you should know that I'm not against 
DNSSEC (or even STS for that matter). If you think like that, then you have 
not read my proposal. 

My proposal introduces SMTPS for better security and signal the port via a 
prefix. But authentication steps should be given to either DNSSEC or STS.

Also note, my proposal only trying to INTRODUCE the SMTPS via port 26. It 
doesn't force anyone to use SMTPS.

If you use the prefix in your mx host like smtps-mx1.example.com, you are 
saying that your server supports both port 26 and 25. Clients should drop 
the connection if the certificate is invalid in either port.

Which will be defeated by a MiTM attack unless DNSSEC is used.  Strip the 
“smtps-“ prefixes from the responses and dummy up non “smtps-" records.

If you use the prefix in your mx host like starttls-mx1.example.com, you 
are saying that your server supports only port 25. Clients should drop the 
connection if the STARTTLS command not found in the EHLO response or valid 
certificate not found.

Again it can be defeated by a MiTM attack.  Same method.

On Wed, Jan 9, 2019 at 7:38 AM Viruthagiri Thirumavalavan 
<giri(_at_)dombox(_dot_)(_dot_)org> wrote:
Oh? In what way is it "pretty good"?  Yes, SMTPS would hide the initial 220
message, the EHLO and the response - but there's no info in those two that
aren't already known after the 3-packet handshake and a few DNS PTR queries
or obtained by other means - you're going to have  a really hard time 
claiming
that things like 8bitmime being advertised in the EHLO reply constitute
sensitive info.

Not every PTR queries resolves to the correct domain.

74.125.129.26 => jm-in-f26.1e100.net (A google IP address, but point to a 
different domain owned by google)

I would be ok with indirectly someone getting the info rather than directly 
providing it.  


On Wed, Jan 9, 2019 at 7:27 AM Mark Andrews <marka(_at_)isc(_dot_)org> 
wrote:


On 9 Jan 2019, at 12:42 pm, Viruthagiri Thirumavalavan 
<giri(_at_)dombox(_dot_)org> wrote:

You just invalidated all my arguments even though I provided sources. 

So let me try in a different way.

If you think DNSSEC is so simple and not controversial, why do we need 
MTA-STS?

The simple answer is WE DO NOT *NEED* MTA-STS.  Additionally it can be 
spoofed
without DNSSEC.  The only thing it does is reduce the number of players 
involved
if you are not self hosting.

On Wed, Jan 9, 2019, 7:02 AM Mark Andrews <marka(_at_)isc(_dot_)org wrote:


On 9 Jan 2019, at 11:30 am, Viruthagiri Thirumavalavan 
<giri(_at_)dombox(_dot_)org> wrote:

@Mark Andrews

First, When I mentioned "The former requires a HTTPS server and the 
latter requires DNSSEC.", I didn't mean DNSSEC is HARD to implement. I 
meant DNSSEC is CONTROVERSIAL

Read some of these articles.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

A whole heap of half truths and poor analysis.  If that was presented as 
a peer reviewed article it would not be published.  You have been had if 
you believe that blog post.

https://www.theregister.co.uk/2016/02/23/dnssec_more_problem_than_solution/

“Oh Dear, Big Responses, The World is Going To End!!!!!”.  This is click 
bait journalism.  We have standard track RFCs which provide the 
equivalent of TCP’s three way handshake for DNS/UDP.  This has been 
deployed for 4+ years now along with other measures for clients that 
don’t implement the RFC.  8% of the TLD servers currently implement that 
RFC.  It is on by default in all current implementations of BIND (both 
client and server side) and with the exception of a handful of (non RFC 
compliant) servers it causes no issues.

Second, unless top domains like Google, Facebook etc. start to use 
DNSSEC, you are gonna see questions like this.

https://security.stackexchange.com/questions/21121/if-dnssec-is-so-useful-why-is-its-deployment-non-existent-for-top-domains

28171 of 895949 zones which gave good answers from the alexa to 1M are 
signed based on the run I started 2018-12-23T00:00:05Z.  The EDNS 
compliance testing I do also reports whether the returned result is 
signed (ok,yes) or not (ok).

% awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ { ok[$1] = 
1} END { print length ( yes ) , length ( ok ) } ' 
reports/alexa1m.2018-12-23T00:00:05Z
28171 895949
%

So if you wanna convince others to use DNSSEC, you should start with 
big brothers like Google. 

Third, Yes DNSSEC is HARD. Maybe not for you. [You seem like a person 
who knows your stuff]

No it isn’t.  In Unbound it is a checkbox where the server generates the 
DNSKEYs and choosing the algorithm.  Are you saying ticking a checkbox is 
HARD?  There TLD’s with +70% of the delegated zones signed.  You don’t 
get to that level with “DNSSEC is HARD”.  The only reason DNSSEC is not 
deployed more is COMPLACENCY and FEAR OF SOMETHING NEW.

Neither if these reasons == HARD.

We are talking about mail servers here. Many of these users are 
non-tech savvy users who depends on third-party mail hosting services 
like G-Suite.

Which almost certainly are using STARTTLS today and maybe using DANE 
today as well on the outbound side.

As an engineer you can do those stuffs easily. But a doctor can't do 
that. Just because he can't configure DNSSEC doesn't mean he don't 
deserve security 

And he can get DNSSEC today.  There are DNS hosting providers that will 
do DNSSEC.  Almost all the
TLDs support DNSSEC.  There are DNS hosting providers that turn DNSSEC ON 
BY DEFAULT.  Arguing that you can’t deploy a DNSSEC signed zone today 
even as a lay person doesn’t bear up to scrutiny.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka(_at_)isc(_dot_)org


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka(_at_)isc(_dot_)org



-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka(_at_)isc(_dot_)org


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka(_at_)isc(_dot_)org

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>