On 12 April 2018 at 00:49, Ned Freed <[email protected]> wrote: > > > 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. > > That's all well and good, but people are saying that DANE is simple enough to implement too.
> > > > 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. > > OK, as long as you understand this embeds a hack into PKIX. > > > > 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. > It says "MX host", which, as near as I can guess, is used elsewhere to mean a host used as a Mail Exchanger, and not either of the "MX Hostname" or the "Reference Identifier". Dave.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
