On Thu, May 05, 2016 at 05:18:17PM +0000, Binu Ramakrishnan wrote:
> DMARC is a mechanism to fight against mail related abuse (eg. spam emails).
I agree that DMARC is a rather distant analogy, for the reasons
you mention, because the flow is along the reverse path from
receiving systeme back to purported origin systems, where-as with
STS the flow is along the forward-path.
In the absence of a specification for reporting addresses for DANE,
I've been sending some notices to WHOIS and similar contacts to
domains whose TLSA records have issues.
As my MTA is DANE-enabled, I've configured a specific sender address
to bypass DANE policy when sending email, and send notices from
that address (using Postfix sender_dependent_default_transport_maps).
It seems clear that being able to send email despite authentication
failure would be useful not only for sending problem reports but
also to allow users who have urgent non-sensitive messages to get
those delivered in a timely manner.
Therefore, as a converse to the proposed REQUIRETLS proposed earlier
on this list we should consider standardizing an explicit MAYTLS
signal that travels via suitable header (so it can tunnel through
hops that dont explicitly support the new feature).
Given a "User-TLS-Policy: MAY" or similar header, a compliant
sending MTA would then do traditional opportunistic TLS bypassing
any attempt to do DANE or STS, ...
This would then in the vast majority of cases allow both the reports
under discussion and urgent non-sensitive traffic (Lunch invites,
...) to reach destinations that have DoSed themselves by botching
their certificate chains and/or corresponding DANE/STS policies.
Given a reasonable way to overide mandatory TLS on the forward
path, I think an email-only reporting spec should suffice. If a
destination cannot be reached at all by ordinary insecure SMTP,
then they probably don't need a flood of reports to compound the
problem. SMTP has gotten along without automated "your site is
down" reports for ~40 years.
So bottom line, don't preemptively specify both HTTP and SMTP report
delivery, choose one, so that every sending and receiving system
will implement just one. If HTTPS is required, specify just HTTPS.
If SMTP is required, specify just SMTP. Don't force all sending
systems to support two reporting formats. Either alone should be
sufficient.
For email reports, some sort of DoS mitigation should be considered.
In particular, since such reports should not transit public mailing
lists or other forwarding services, it is reasonable to insist on
origin authentication (DKIM or similar) and suggest that any given
sending domain rate limit its reports to something like at most
one an hour per reporting email address (not target domain as the
same reporting address might support a great number of hosted
domains).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
