> > > 2) HTTPS Call-out > > > > > Given the policy is essentially trust-on-first-use, it's not clear to me > > > why much of the STS policy cannot be transferred within SMTP itself, > > > perhaps in response to the EHLO issued after STARTTLS completes. This is > > > good enough for HTTPS's STS variant, and feels intuitively simpler for > > MTAs > > > to implement. > > > > I'm afraid you have this exactly backwards. Even if the SMTP server > > approach > > provided comparable security - and it doesn't - deploying a new SMTP > > extension > > is quite difficult; we have an abundance of fully worked examples > > demonstrating > > this point. Whereas throwing up an A record, certificate, and server that > > serves out a single document is trivially easy. These days I don't rank as > > an > > experienced IT person, and I was able to do it for a test domain in about > > 20 > > minutes. > > > > > I entirely agree that hosting a single document under HTTPS is trivial. > > This is not to say that there aren't issues implementing MTA-STS. There are > > significant issues, but they are all on the client side. Adding an HTTP > > client > > to your SMTP client significantly increases attack surface, so much so > > that I'm > > not willing to do it, and other folks have said they aren't willing to > > either. > > > > The approach I'm using is to build an MTA-STS query server with integrated > > caching support. I have one mostly coded, and while I haven't worked > > through > > all the caching and timeout issues yet, I have not found any significant > > implementation obstacles. > This workload is what I consider to be the antithesis of "intuitively > simpler". And once again I'm afraid what your intution is telling you is exactly the opposite of my experience. For me implementing this using a separate query server actually makes things much easier, not harder, in part because I'm not constrained to code things in C/C++, which is what the SMTP client is coded in. You might want to sit down and try mocking this up in, say, node.js. It may change your mind about the approach. And the client part is going to be maybe 50 lines of C code. Code of a sort I've written many, many, many times before. Hardly difficult. > > > c) Both/either of the above. > > > > > I assume the logic behind allowing a wildcard-to-wildcard match is to > > allow > > > a Google user to simply specify ".googlemail.com" and ".l.google.com" as > > > their MX identity patterns; however it feels as though Google could > > simply > > > use a known name within the certificate for all their receiving MTAs, > > > irrespective of the DNS records involved. This, of course, presupposes > > that > > > the administrator of the mail domain somehow does not know the precise > > > names of the MTAs used in their own DNS records. > > > > > I further assume the logic in mandating matches against dNSName SANs is > > > because these are readily available; however sRVName SANs, by restricting > > > their use to a particular service, have the advantage that customers > > giving > > > these to their service provider might be deemed more acceptable. > > > > A comparable effect can be achieved by using a subdomain root reserved for > > email server use. > > > > So it's a choice between an easily implemented naming convention and a > > bunch > > of PKIX esoterica. This does not strike me as a difficult choice. > > > > > Well, being *able* to use sRVName would be nice at least. The specification > as written prevents it, which seems unfortunate. I have to say I like the simplicity of the current specification, and I don't want to see added complexity in this regard without a compelling reason for adding it. > > > o MTA-STS Policy: A commitment by the Policy Domain to support PKIX > > > [RFC5280] authenticated TLS for the specified MX hosts. > > > > > Impressively, by my reading, the commitment is for the Policy Domain to > > > support PKIX for all SMTP; and not just for specified hosts. > > > > Of course that's the commitment. How could it be otherwise? > > > Then that needs rephrasing, because I didn't see any "Of course" about it. > A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated > TLS, using reference identifiers as listed. > (I'm trying to guess what was meant by "for the specified MX hosts".) The entire point of the mechanism is to say that the policy domain supports and wants SSL/TLS transfers and that the servers have validated certs with the specified names. So I really don't understand what you're getting at here. Ned
