> On Nov 6, 2018, at 10:51 AM, Alice Wonder <[email protected]> wrote:
>
> However when the zone is protected by DNSSEC there could be an improvement.
I think you're trying to say that the presence of a DNSSEC-validated
_mta-sts.example.com TXT record all by itself could obviate the need
for an MTA-STS policy, because the MX RRset at "example.com" will
then also be DNSSEC-validated, and does not require out-of-band
HTTPS security, and the TXT record can signal a commitment to
WebPKI-verifiable certificates at the MX hosts.
Is that right?
If so, I don't recall this being discussed, it is of course too late
to add this to the already published RFC. If this idea has support,
it could become a separate draft. The main obstacle is that "testing"
in the HTTPS policy would no longer be seen. If that remains important
to publishers, we'd need an additional (otherwise optional)
"mode=testing|enforce" in the TXT record too, that would be used only
if the TXT record is DNSSEC-validated, but otherwise ignored.
Basically, this would move the substance of the policy from HTTPS
to DNSSEC, and caching, ... become unnecessary, because DNSSEC reliably
delivers fresh data.
For DNSSEC-signed domains that self-host mail, publishing DANE TLSA
records is an even better option, but many DNSSEC-signed domains
have third-party MX hosts in unsigned domains.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
