@Paul Smith
This was my point. I'm not sure what SMTPS gains us over protection against
STARTTLS downgrade, so protect against STARTTLS downgrade by all means, but
the alternative port is a red herring and unnecessary complexity (IMHO)
We need alternative port to provide Implicit TLS. To do that, first we all
need to be convinced with the fact "Implicit TLS > Opportunistic TLS".
Today, we all can safely browse NSFW sites via browser because HTTPS
protects everything from top to bottom. My SMTPS proposal can do the same
job for email.
To be clear, this is the problem with Opportunistic TLS.
A guy who sends an email to AshleyMadison support team probably cheating
his wife. He can protect the real conversation by upgrading the connection
to a secure connection with the help of STARTTLS. But the handshake before
the upgrade goes like this in plain text.
220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready
That one line says plenty enough about this guy. You don't have to read the
real conversation to figure out what's going on here.
AshleyMadison is the best example I can give. But there might be more
serious privacy issues too. So, in my opinion, Implicit TLS is better than
Opportunistic TLS.
Like I mentioned earlier, I have no issues if the proposal gets turned
down. But you guys need to convince me with why you all think
"Opportunistic TLS" is enough for SMTP.
On Wed, Jan 9, 2019 at 3:25 AM Ted Lemon <mellon(_at_)fugue(_dot_)com> wrote:
Sure, although a simple TXT record doesn't really seem like a useful
answer, particularly without DNSSEC. Regarding your point about SRV, have
you seen RFC 7673, Using DANE TLSA Records with SRV Records?
On Tue, Jan 8, 2019 at 2:38 PM Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk>
wrote:
This was my point. I'm not sure what SMTPS gains us over protection
against STARTTLS downgrade, so protect against STARTTLS downgrade by all
means, but the alternative port is a red herring and unnecessary complexity
(IMHO)
On 8 January 2019 18:44:01 Ted Lemon <mellon(_at_)fugue(_dot_)com> wrote:
On Jan 8, 2019, at 12:23 PM, valdis(_dot_)kletnieks(_at_)vt(_dot_)edu wrote:
Hint: If starttls is subject to a downgrade attack, what prevents the
same attack
against the same pair of hosts attempting smtps instead?
IOW, if the server is only listening on port 26, and the client is being
MITM'd, the attacker can listen on port 25 and then tunnel the client
connection to the server's port 26. Only if the client knows that the
server supports TLS can you prevent a downgrade, and then STARTTLS works
fine. So you need some secure way of signaling this, e.g. DNSSEC, and if
you have that, then you don't need a second port allocation.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates <http://http://www.pscs.co.uk/go/subscribe>
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp