> On Oct 12, 2017, at 5:01 AM, Ivan Ristic <ivan.ris...@gmail.com> wrote:
>
> But should a MTA-STS-aware client fail a server with a non-public certificate
> that's DANE-validated?
I would expect a sending MTA to figure out which of DANE or STS applies to a
given
delivery, and apply just that mechanism, and not some hybrid. When DANE applies
(secure MX records and secure TLSA records for the MX host) then DANE is used
and
STS is out of scope. Otherwise, if an STS policy applies to the domain, then go
with that. So that, by the time STS policy is being used, non-public
certificates
would fail absent DANE.
> This is also an area where the current hostname matching might interfere with
> DANE,
> because DANE is validated for the specific hostname that you're connecting to,
1. DANE for SMTP also requires support for multiple names, where the names are:
* The nexthop domain (the recipient domain or explicitly configured
gateway)
* CNAME expansion of the nexthop domain
* The TLSA base domain (either MX hostname full CNAME expansion or
the original MX hostname, whichever yields the first secure TLSA
RRset)
2. The STS policy name matching is out of scope when DANE is in use.
You seem to be looking for STS policy to harden MX lookup, for use with DANE.
Such a mixed model is unlikely to be useful. We could arguably *require*
STS clients to support DANE outbound, and then allow STS policies to express
"use DANE for my MX hosts" [ and that would be cool with me :-) ], but without
that, the domain in question would be broken for STS clients that don't support
DANE unless all the MX hosts had valid Web PKI certs, so just go with that...
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
