Re: [Uta] MTA-STS-03 review

[Daniel Margolis <[e-mail]>]

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


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.

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

>
> > On Apr 3, 2017, at 4:53 PM, Daniel Margolis <[e-mail]>
> wrote:
> >
> > 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
>
> 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):
> >    # etc
>
> 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
> > validation. Can you explain a little more?
>
> 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.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>