Re: [Uta] MTA-STS-03 review

[Alberto Bertogli <[e-mail]>]

On Mon, Mar 27, 2017 at 10:55:06PM +0200, Daniel Margolis wrote:
> To the matching point, I share the concern about people having to write
> their own cert matching code, but I think there are a few arguments for it:
> 
> 1. I believe if we restrict wildcards to the "full" leftmost label (i.e. *.
> example.com is valid, but mail*.example.com or mail.*.example.com are not)
> and we do the same in the certs (which RFC6125 seems to allow us to
> define), wildcard matching is a simple "x ends with y or y ends with x"
> comparison, so is in fact trivial to implement.

Agreed, but it still carries some hidden complexity.

For example, how does this interact with SNI? e.g what name would the
client pick to give to the server in the TLS negotiation?


> 2. It seems (and I suspect this was part of Viktor's motivation) to match
> nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I
> read it correctly leaves the door open to a certificate matching the
> nexthop domain rather than the MX hostname; by requiring MX hostname
> matches in STS we would break that behavior.

Yes, my reading from that reference is that the nexthop domain can be
used to match as well.


> I think #2 is a pretty compelling point.

It is definitely a point, but I'm not sure it's that compelling (sorry
Viktor!).

There's, AFAIK, no very clear and well defined way to do certificate
matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix
that.

For better or worse, HTTPS is the most widely deployed TLS usage in the
world, and has gone through years of all kinds of production exposure.
The certificates are validated has been thoroughly reviewed and is well
documented and understood.

Differring from that, and adding complexity to how SMTP does TLS
validation based on a particular section of RFC 7672 which, as far as I
know (and please correct me if I'm wrong) is not widely deployed and
hasn't got nearly as much production exposure, seems to me to be risky,
and is IMHO not worth it.

Bringing SMTP certificate validation in line with how HTTPS does it
would not only simplify (some) implementations, but make deployments
easier, reduce the cognitive load and learning curve for folks running
their own servers, and benefit from all the existing analysis and also
the future improvements in the area (e.g. certificate revocation,
certificate transparency improvements, etc.).

Very few existing deployments would be affected, as I don't think many
are relying on using [DANE+certificate for the next hop but not the MX
name].


Note, in case it's not clear, that I'm not advocating for the removal of
the MX list from the policy, but to keep it as in the current draft
(i.e. use it as a filter mechanism, and then do TLS validation on the
resulting MX name).

All this said, I don't want to drag my point along or interfere with the
normal flow of things. I much appreciate your thoughtful replies, and if
you don't find my arguments convicing, I understand :)

Thanks a lot!
		Alberto


PS: As an example of a related RFC that is AFAIK not widely deployed,
and which I think most popular deployments violate, is RFC 7817 "Updated
TLS Server Identity Check Procedure for Email-Related Protocols".

It applies to POP3, IMAP and SMTP submission (excludes MTA-to-MTA), and
specifies that servers must have certificates not only for the host name
used to access them (e.g. imap.example.net) but also to the top level
domain used for email addresses (example.net in this case):
https://tools.ietf.org/html/rfc7817#section-6

Neither gmail.com, yahoo.com, live.com or outlook.com imap, pop3 or smtp
submission do this (but in fairness, hotmail.com does).