Reporting: No discussion of caching of reporting configuration

[davidillsley]

While the Security Considerations section says

SMTP TLS Reporting provides transparency into misconfigurations or attempts to intercept or tamper with mail between hosts who support STARTTLS.

There's nothing dealing with an attacker attempting to suppress reporting to prevent detection of "attempts to intercept or tamper". Specifically, there's no mention of caching of reporting configuration, allowing an attacker to use DNS spoofing to hide attempts to bypass MTA-STS, reducing the usefulness of the reporting.

One option would be to move this config into the mta-sts policy file, but I guess there are good reasons that's not already the case (possibly for DANE reuse).

[danmarg]

Exactly; we want this to work for DANE as well.

You're certainly right that an attacker could suppress the TLSRPT record resolution and thus hide tampering. A long-lived cache would help prevent this, but I personally think that may be more trouble than it's worth. In particular, for the DNSSEC/DANE case, it's not necessary (since DNSSEC secures the resolution) and potentially harmful (in the sense that DANE, unlike STS, does not mandate that senders have any sort of "cache" for this kind of thing to begin with, so this may impose an additional constraint on implementors).

I think it's an interesting suggestion that maybe TLSRPT could have an optional caching scheme, either via a really long DNS TTL or via a ttl explicitly in the TXT record, to allow paranoid implementations to cache the record. But even then I'm not sure it's worth the complexity; a long DNS TTL may naturally suffice, right?

@abrotman Thoughts? David, any ideas?

[davidillsley]

Gotcha. I do think there's a bunch of value in increasing the likelihood that for non-DANE cases (the vast majority now, and in the near future) that an attacker gets noticed. I think there's a deterrent effect and a benefit to domain owners knowing they're been targeted.

In terms of options, things that spring to mind:

• an extension to the mta-sts policy could be defined which has the same semantics as the DNS record, retaining semantic compatibility, but being more robust in non-DANE scenarios
• the reporting document could encourage long TTLs and caching
• add a security consideration noting that in the absence of DNSSEC, this mechanism can only be relied on to detect misconfigurations

[danmarg]

I think option 2 and 3 are best. Option 1 seems not worth the complexity it introduces. WDYT?

#195

Please review?

[davidillsley]

I think that's a reasonable compromise - I'm conscious that for what should be a simple spec it's taking a long time, and wouldn't want to worsen that. Can always define an extension later if required.

[danmarg]

Agreed. And I appreciate your awareness of the process issue. ;)

Will merge this in. Thanks again.