Subject: [Uta] Updated MTA-STS & TLSRPT

From: "Brotman, Alexander" <[email-masked]>
Date: Fri, 10 Nov 2017 13:47:58 +0000

Hello folks,

These two drafts were uploaded last night, and we'd like any feedback.  For the MTA-STS, there are changes relating to SNI, minimum TLS version, and reverse proxy language.  There are also some minor nits that were resolved.  For TLSRPT, we added some language about DoS attacks, omitting report TLS failures from reporting, and allow reporting on more than one policy type per report.  We look forward to hearing from the group.  Thank you.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

---

From: "Maarten Aertsen (NCSC-NL)" <[email-masked]>
Date: Fri, 17 Nov 2017 17:31:35 +0100

Hi,

On 10-11-2017 14:47, Brotman, Alexander wrote:
> These two drafts were uploaded last night, and we'd like any 
> feedback. [..] We look forward to hearing from the group. Thank you.
I have feedback on the current draft from the perspective of smaller
e-mail providers.

MTA-STS competes with DANE TLSA for the achievement of similar security
goals of e-mail providers. As such, e-mail providers will be faced with
the choice of which protocols to support and enable: DANE TLSA, MTA-STS
or both. E-mail providers will be limited by their vendors (i.e. 
implementors) in their freedom of choice. Implementors partially choose 
support based on the guidance in this (later) spec.

I have quoted the relevant parts of the draft that treat considerations 
for such choices below:

> 2. Related Technologies
> 
> The DANE TLSA record [RFC7672] is similar, [..]; the mechanism
> described here instead relies on certificate authorities (CAs) and
> does not require DNSSEC, at a cost of risking malicious downgrades.
> For a thorough discussion of this trade-off, see Section 9, "Security
> Considerations".
Section 9 _does_ include the security considerations relating to 
downgrades. It _does not_ make explicit the considerations for choice, 
which is what I expected to find after reading this paragraph. On the 
other hand, these are partly, and /implicitly/ covered two paragraphs 
later in Section 2:

> The primary motivation of MTA-STS is to provide a mechanism for 
> domains to upgrade their transport security even when deploying 
> DNSSEC is undesirable or impractical. However, MTA-STS is designed 
> not to interfere with DANE deployments when the two overlap; in 
> particular, senders who implement MTA-STS validation MUST NOT allow 
> "valid" or "report-only" MTA-STS validation to override a failing 
> DANE validation.
This paragraph seems to imply that DANE TLSA takes priority over 
MTA-STS. This assumption is never explicitly stated in the document.

I would argue to explicitly include guidance on the choice implementors 
face. This is important in a world where it is likely that large 
receivers will only support MTA-STS due to their preference not to 
implement DNSSEC. The tendency to go along with large organisations 
should be offset by being crystal clear about the differences between 
DANE TLSA and MTA-STS with respect to their ability to meet stated 
security goals.

To this end, I would propose adding: "and are therefor RECOMMENDED to 
perform this validation prior to MTA-STS validation. To avoid risking 
malicious downgrades, receivers that deploy DNSSEC are RECOMMENDED to 
maintain DANE TLSA records for MX hosts."

Relevant inspiration for this proposal came from earlier conversation 
between Jim Fenton and Viktor Dukhovni quoted below. For brevity, I have 
not included the "local policy" angle", but this may well be worth doing.

best regards, Maarten

On 12-11-2017 19:48, Viktor Dukhovni wrote:
> On Nov 12, 2017, at 6:01 AM, Jim Fenton <[email-masked]>
> wrote: >> - Section 4 "enforce" prohibits delivering when things fail
>> mta-sts, but Section 2 says, "MTA-STS is designed not to interfere
>> with DANE deployments where the two overlap". Doesn't this
>> requirement constitute that sort of interference? >
> I would read that as "STS is entirely out of scope when DANE policy 
> is in effect". Of course sending machines get to decide whether DANE
> policy is in effect or not, by choosing to enable DANE or STS in the
> first place, and potentially choose one or the other explicitly for
> some domains.
> 
> Thus, for example, while DANE policy is generally driven by the 
> remote domain's publishing of TLSA records, a sending Postfix MTA can
> be configured to *require* DANE for some set of destinations, in
> which case delivery will only happen when the destinations publish 
> ("secure" DNSSEC) DANE TLSA records, and not otherwise.
> 
> Similarly, a sending system might *require* STS for some set of 
> destinations, and refuse to send in the absence of a cached policy.
> 
> So, the way I would read and implement this would be to prefer DANE
> over STS barring local policy that prefers one over the other for
> some destinations or perhaps suppressed both.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 20 Nov 2017 16:47:46 +0000

As Viktor said, this is mostly up to sending MTAs. I may be wrong--and
welcome feedback about what's commonly done on similar RFCs--but I see the
scope of the MTA-STS RFC as being outlining the protocol itself, not
guidelines on when to deploy it versus other protocols.

As such, I don't really want to be recommending to implementors whether or
when to prefer STS to TLSA, or vice versa. What we define is what a
compliant MTA who validates STS does--and the TLSA RFC does similarly for
that protocol. I should think that someone who checks both should fail a
message if either fails, but if someone wants to check only one or the
other--or only one if the other is missing--they are of course free to do
so.

Obviously a recipient cannot expect that a valid TLSA record will override
an invalid STS policy, or vice versa, since they are not guaranteed senders
will check both, so there's no real need to specify this behavior anyway, I
think.

My impression is that recommendations of when to deploy which would make
more sense in a separate BCP than as part of the STS draft, but I may be
mistaken. What's the common convention here?

On Fri, Nov 17, 2017 at 5:31 PM Maarten Aertsen (NCSC-NL) <
[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>