Subject: Re: [Uta] MTA-STS-03 review

From: Daniel Margolis <[email-masked]>
Date: Mon, 3 Apr 2017 21:00:45 +0200

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 <[email-masked]
> 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).
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Apr 2017 19:35:31 +0000

On Thu, Mar 30, 2017 at 11:55:56AM +0100, Alberto Bertogli wrote:

> > nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I

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.

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

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

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 3 Apr 2017 22:53:00 +0200

> processing loop, and implement TLS policy strictly in the TLS

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 <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Apr 2017 17:05:15 -0400

> On Apr 3, 2017, at 4:53 PM, Daniel Margolis <[email-masked]> wrote:
> 
> In hypothetical pseudocode, your MX is going to be doing something like this:
> 

Yes, but with an initial step to prune the MX list when the sending host
is a member of that list...  And of course dealing with multi-recipient
messages, ...

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

When authentication is required and fails, all recipients tempfail, and
the next candidate MX is tried (ignoring details of what "next host" means
when MX hosts have multiple IP addresses).

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

The draft suggests filtering the MX host list first, and then looping
over the remaining hosts.

> for candidate in filter_mx_list(mx_list):

As above.

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

One could defer the hostname validation, but if it is really
just an MX hostname filter, and not a certificate filter,
then there would be a futile connection to the host, and
a TLS handshake, before the TLS layer discovers that the
MX hostname is a priori forbidden by the STS policy.

> I'm afraid I don't understand the distinction you are drawing
> between modifying candidate selection and modifying cert

If the policy restricts the acceptable content of the MX RRset
in DNS, then one ought to avoid connections to "forged" MX hosts,
which requires changes to the MX selection loop.

If the policy restricts the acceptable names in the MX host
certificate, then MX selection remains unaffected, and one
tempfails connections where the peer certificate fails to
validate (for any of a set of reasons, including name check
failure).

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 4 Apr 2017 09:24:05 +0200

> which requires changes to the MX selection loop.

Pseudocode in the draft notwithstanding, a compliant implementation
*may* connect
to the "wrong" MX hosts if it wants to. That was my only point.

The draft suggests pre-filtering for efficiency's sake only--when MX host
validation is used, hosts can be determined to be invalid before the
connection, so we can avoid the slightly wasteful step of connecting. But
of course they can be invalid only after connection, too (if they have a
valid hostname but an invalid cert), so obviously we cannot consider
connecting to the "wrong" host to be some kind of security issue (and it is
not).

Like I said, this is mostly a digression, since we've already adopted the
SAN-validation approach in the Github (and it should be in the next draft,
unless I hear major objections, per the seeming consensus at the UTA
meeting). But I believe this pro/con is largely a red herring.