News for hackers. Stuff that matters.

A comment on Internet Draft: SMTP Strict Transport Security. Parent comment

Re:Internet Draft: SMTP Strict Transport Security by stonogo on Sunday March 20, 2016 @09:44PM (#11325676)
>Even worse, of the domains that support STARTTLS, a sizable number either don't present certificates that chain to a widely trusted root, or don't present certificates that actually match their MX. Worse still, because many domains' MXs don't match the domain itself, even if the certificate is trusted for the MX, it may not be trusted for the domain.

This is madness, though. TLS is transport-layer security. It's not kerberos and it was never intended to be. The cert produced by the MX should be valid for the MX. Trust is an illusion, but to the extent that you decide to trust anything in the CA system, you trust it for the MX only and use SPF etc to determine if the MX is the correct one.

STARTTLS is a bad idea and should go away entirely. It forces an SMTP server to care about the transport layer, and that's entirely incorrect. I have plenty of SMTP servers that communicate on my networks without ever touching TCP/IP -- forcing them to support STARTTLS specifically is moving backwards.

This RFC is strongly dependent on the internet looking pretty much exactly like it looks today, and enforcing that mode of operation indefinitely. It's short-sighted and harmful to the entire email world.

[ Parent | on HN ]
Re:Internet Draft: SMTP Strict Transport Security by danmarg on Monday March 21, 2016 @04:09AM (#11326755)
But I think the authentication problem is in fact the hard problem. Assuming we got rid of STARTTLS (the actual verb) and just always did TLS (say, on some other port), how do you propose to solve it?
[ Parent | on HN ]
Re:Internet Draft: SMTP Strict Transport Security by stonogo on Tuesday March 22, 2016 @12:47PM (#11337842)
Fortunately, we have an extensible protocol that already supports service advertising and negotiation. There's no reason we can't have an AUTH module that works both ways (both the client and server mutually authenticate, independent of the transport-layer encryption).
[ Parent | on HN ]