Re: [Uta] MTA-STS-03 review

[Alberto Bertogli <[e-mail]>]

Hi!  Not sure if it's worth much, but my 0.7 cents inline :)


On Wed, Mar 22, 2017 at 01:39:54PM +0100, Daniel Margolis wrote:
> > Here, as discussed on the list, serious consideration should be given
> > to changing the semantics from validating the MX hostname to specifying
> > the names allowed in the server's certificate.  This simplifies MX
> > processing
> > (which remains unmodified) and merely changes the conditions under which an
> > MX host is considered suitably authenticated per the policy.
> 
> > Which, for example, allows the MX hosts to share a single certificate
> > with the destination domain (and not the MX hostname) as its DNS SAN.
> > If the policy lists that (shared) name as what's expected in the
> > certificate,
> > then authentication succeeds when the MX host's certificate matches one of
> > the allowed names.
> >
> 
> That's interesting. I think it's not actually that big a change--we just
> get rid of the MX host filtering and instead just apply the logic to
> validation.

This would make certificate validation differ from the way it's commonly
done, where the check is against the name used to connect to the server.

I think that would be a mistake.

Certificates are already non trivial to deploy and check, and making
validation work in an unusual way introduces complexity in coding in
some cases, (maybe not for postfix, of course, but most high level
libraries such as Python's or Go's make this more difficult) in a very
sensitive and delicate area.

It also makes deployment and checks more complex, as wildcard
certificates and mentions in the policy don't work in a somewhat
unexpected way (I don't think most folks expect wildcards to be matched
via string comparison).



If it's the filtering that is too much additional complexity, an
alternative would be to consider the "mx" field in the policy as an
alternative source for the mail servers list (no wildcards allowed in
that case, obviously).

This has, I think, the same security benefits of the list for filtering,
and may be easy to use in some cases. Deployment wise, it's probably not
as simple as the filtering, but not terribly more complex, and is easy
to understand and automate.

I'm not terribly convinced about it, but it could be an alternative to
filtering if it's an issue.


> > FWIW, I would have chosen something less fancy than JSON for
> > what is clearly a simple array of attribute/value pairs. ESMTP
> > already encodes such optional A/V pairs as space separated lists
> > of attr=value with xtext encoding as needed (it is not needed for
> > any plausible value of the above attributes).
> >
> 
> I seem to recall that we started with simple key-value pairs and moved to
> JSON because people variously seemed to think this was easier (since
> parsing libraries are common). I would also consider the vague possibility
> that in future iterations we wish to add fields.
> 
> De novo, I myself have no real opinion here, because certainly either work,
> but of course I'm loath to make changes again. I'd appreciate more feedback
> from more readers, though, as these style discussions are always a bit
> subjective.

There are lots of advantages of using JSON for this. It is well defined,
standard and there are lots of well tested and widely used
implementations.

It is used widely, it's familiar to many people, and its shortcomings
(which are not few, admittedly) are well understood and documented.

It support rich types (such as lists), and common libraries already
handle difficult situations like non-ascii content, long integers,
multi-line strings, malformed/malicious input, etc.


Defining an ad-hoc key-value pair format may seem simpler in the short
term, but I think it's not worth it, as many things will have to be
decided an carefully designed (e.g. multi-line lists). Then parsers have
to be implemented with support for a variety of things, and care for
malicious input which is usually not trivial.


Thanks!
		Alberto