> On Apr 19, 2018, at 5:35 AM, Ben Campbell <b...@nostrum.com> wrote:
>
> ยง1.1, Policy Domain: The definition is partially circular. Please define what
> is meant by "domain". I assume that means domain in the DNS sense, but the
> word
> "domain" is commonly uses in other senses as well. Please be explicit.
Thanks, this is a good catch! The policy domain does need a clear definition.
While it is the domain for which either a DANE or STS policy mandates secure
TLS delivery, and will be a DNS domain, a more precise definition is probably
helpful.
In the case of STS it is usually the envelope recipient domain, but
may be the domain name of an explicitly configured "next-hop" gateway for email
delivery to the envelope recipient.
In the case of DANE, security policy is specified for each "MX Host'
separately, with the TLSA records obtained via the "TLSA base domain"
for that host. And yet, it is *perhaps* not the intention here to
publish the reporting address separately for each MX host. It is
more "economical" to publish it just once for the envelope recipient
domain or override next-domain just as with STS.
On the other hand, when email is hosted by a third-party,
obtaining the reporting address for the MX host is more
likely to get the report to the responsible party.
With either DANE or STS the most likely reason for policy
failure is operator error, and so there's some appeal to
notifying the the MX host provider (if "_smtp-tlsrpt.<mx-host>"
is found). Perhaps with the envelope recipient domain or
locally configured next-hop domain as a fallback policy domain.
If, however, the failure results from a botched MiTM, with the
MX RRset modified by the attacker, then one would perhaps want
to notify the (email) destination domain, not the operators of
the fake MX host. With DANE, the MX RRset is more likely to
be DNSSEC-validated, and so tamper-evident, but DANE may also
be apply to the DNSSEC-signed MX hosts of an "insecure" (unsigned)
domain.
Thus, I must admit to have overlooked some of the subtlety
involved in figuring out which "example.com" is the right
input to "_smtp-tlsrpt.example.com". Don't know whether
the authors have thought this through more thoroughly.
It is likely that the present intent is to use the same
location for both DANE and STS, and for that to be
the envelope recipient domain or configured next-hop
if set, but I'd guess that use of the MX host domain as
a primary (or fallback) base for the "_smtp-tlsrpt" lookup
likely has not been considered.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
