On 11/06/2018 11:24 AM, Viktor Dukhovni wrote:
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?
Yes. If I understand MTA-STS correctly, the purpose of the https
component is to mitigate fraudulent MX records, policy mode, and time to
live. Using DNSSEC to mitigate shouldn't be required, I respect the
right for some system administrators to choose not to trust it, but I
think it simplifies MTA-STS for system administrators who do trust it.
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.
I think caching may still be a good idea in case a the records are
modified resulting in validation error.
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.
Yes, AFAIK google doesn't publish TLSA records (gmail anyway shows as
untrusted in postfix log unless I specify a smtp_tls_CApath) and
provides MX for a lot of companies.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
