> On Apr 3, 2017, at 4:53 PM, Daniel Margolis <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
