Re: [Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

[Dave Cridland <[e-mail]>]

On 12 April 2018 at 00:49, Ned Freed <[e-mail]> 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.