On Thu, Mar 30, 2017 at 11:55:56AM +0100, Alberto Bertogli wrote:
> > 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.
Well, the prior practice, since at least 2007 in Exchange, and 2005
in Postfix, is to match the destination domain, rather than the MX
hostname (which obtained from DNS MX lookup was not secure).
This is used for bilaterally coordinated "secure-channel" TLS
"tunnels" between partner sites.
> 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.
Well, RFC7672 did not create this feature from thin air. The reason
it appears in RFC7672 is to support existing practice. It is true
that non-opportunistic TLS was not especially common in SMTP (due
to lack of scalability), but it was used.
A site that has the destination domain in the certificate can
support both DANE and secure-channel mandatory TLS.
> Bringing SMTP certificate validation in line with how HTTPS
Analogies between HTTPS and TLS for SMTP are often misleading if
not outright damaging. So having differences is somewhat of a
feature.
> 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 :)
That, unfortunately, means modifying the complex MX host selection
code in the MTA, which up till now has been quite separate from
TLS authentication. I would really like to avoid touching the MX
processing loop, and implement TLS policy strictly in the TLS
handshake layer.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
