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>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp