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 at http://www.pscs.co.uk/go/subscribe
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp