Re: [Uta] MTA-STS-03 review

[Daniel Margolis <[e-mail]>]

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


To rathole very slightly on this--and not looking at the Postfix code
specifically, say--I don't really understand this point.

In hypothetical pseudocode, your MX is going to be doing something like
this:

for candidate in mx_list:
  if try_to_send(candidate):
    success = True
    break

And in the cert validation (or DANE validation or anything else) step, we
modify "try_to_send()" to close the connection and return False if the cert
validation fails, no?

So your point seems to be that the MX selection logic must be modified to
support the MX matching approach:

for candidate in filter_mx_list(mx_list):
   # etc

Right? But why would you not simply modify "try_to_send()" to check the
hostname against the policy (same as it would check the cert SANs or CN
against the policy)?

I'm not trying to get too into the pseudocode since this is a vast
oversimplification, but I'm afraid I don't understand the distinction you
are drawing between modifying candidate selection and modifying cert
validation. Can you explain a little more?

Thanks.


On Mon, Apr 3, 2017 at 9:35 PM, Viktor Dukhovni <[e-mail]>
wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>