Re: [Uta] MTA-STS-03 review

[Daniel Margolis <[e-mail]>]

Very fair points. I may be overstating the significance of being able to
use a non-matching certificate (and I don't think it's awful to force
implementors to have a cert that matches their hostname, either; this seems
to me to not be a terribly painful prerequisite).

But I think the cost of doing custom matching is low, too. You're right
that there's some cognitive load in having it match in a non-standard way,
but in fact in practice it will almost always be the same: because most
people will use certs that have a SAN that matches the hostname, writing an
'mx' pattern to match the hostname will inherently match the cert, too! So
for deployers this is not all that easy to get wrong, and for MTA
developers they should just read the pseudocode in the appendix of the RFC,
I think.

What I said at the UTA meeting in person was that we seem to be haggling
over things (this, the JSON-vs-key-value-pair thing) which, while not
insignificant, are somewhat less critical than major architectural or
fundamental questions, which makes me think we should just decide
these--some of them perhaps somewhat arbitrarily--and move ahead.

I don't have strong opinions on either of these points, but the consensus
seemed to be mostly in favor of the SAN approach at UTA.



On Thu, Mar 30, 2017 at 12:55 PM, Alberto Bertogli <[e-mail]
> wrote:

> 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).
>