Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

[Jim Fenton <[e-mail]>]

On 02/23/2017 01:01 PM, Daniel Margolis wrote:
> Hey, thanks for the feedback. Comments inline. 
>
> On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Below are comments from my recent reading of
>     draft-ietf-uta-mta-sts-03.
>
>     The biggest concern I have is the relationship between the DNS TXT
>     record and the HTTPS policy record. The policy is hosted in HTTPS
>     rather
>     directly in DNS in order to attempt to provide security without
>     DNSSEC.
>     But if attacks on DNS are in the threat model, one has to consider
>     that
>     an attacker might make it appear that there is not a DNS TXT record at
>     all, which causes the HTTPS record not to be retrieved at all (MTA STS
>     is presumed not to be deployed). This makes MTA STS too easy to
>     defeat.
>
>
> I don't believe I can speak to this with authority, but I feel
> somewhat comfortable excluding an /ever-present/ active MITM from our
> threat model. It's certainly trivial to defeat initial policy
> discovery, but an attacker must do this all the time. It's feasible,
> but there's some probability of discovery, of course.

It's not that the attack has to be ever-present, it's that client MTAs
that don't have a cached policy for the recipient domain will be showing
up all the time, and will need to retrieve the policy. To the extent
that they don't get the TXT record on the first try, they will infer
that there is no policy, and will continue to do so while the negative
response is cached by their responder (minimum TTL, typically only a few
minutes, but the SOA in the NXDOMAIN response could also be spoofed to
make this much longer). This waters down the effectiveness of MTA STS.

>     3.1. MTA-STS TXT records
>
>     There is no IANA registry for reserved hostnames, which is why
>     protocols
>     like SPF store their policies at the domain itself. Is there some
>     reason
>     this is not being done here? The version field can be used to
>     distinguish from SPF records and other TXT records at the domain
>     level.
>
>
> This is reasonable, but note that we still require the special
> hostname for the HTTPS host (necessary since some domains will not
> want to host the HTTPS endpoint at the top-level); reusing it for the
> TXT record seems reasonable, no? I'm not wedded to this, but I would
> avoid unnecessary changes unless there's a good reason at this point.
> Is the risks of collision with a pre-existing record high? I would
> think not. 
>
> (I'm lazy here because we already have various code that refers to
> this record name, and already changed it between version 2 and version
> 3 of the draft...)

It looks like the _ may be coming back as a result of the CNAME problem
noted on the other discussion thread. But the point is that IETF/IANA
have consistently declined to register specific hostnames for specific
purposes -- not even www. for the Web -- and I don't see why an
exception would be made now.

>  
>
>     "...are discarded" -> "...MUST be discarded"
>
>     3.2. MTA-STS Policies
>
>     "mx": Why is there an emphasis on providing confirmation of the
>     response
>     to the MX lookup, when it is just as easy to spoof the A/AAAA record
>     lookup that follows the MX and yet there is no publication of an
>     A/AAAA
>     policy?
>
>
> The "mx" constraint isn't really about the hostnames (though of course
> it is applied to them); it's about the subject of the server
> certificates presented by the MX. A different (albeit, I think,
> needlessly confusing!) design could allow for the MX hostnames to be
> arbitrary and not match the "mx" constraint in any way; all that
> matters is the certificate name, for exactly the reason you give.

Fair enough -- the certificate name addresses the A/AAAA issue.

>
>     3.3. HTTPS Policy Fetching
>
>     Why MUST 3xx redirects not be followed?
>
>
> This was an arbitrary choice to avoid confusion. If we allowed the
> following of redirects, is a policy behind an HTTPS redirect to a
> different domain valid? What about to a non-HTTPS endpoint? 
>
> On the flip side, redirects allow easy delegation of policy hosting
> without SNI--I could serve a 302 to "https://policy.myisp.net" on
> "mta-sts.mydomain.com <http://mta-sts.mydomain.com>". If people think
> the latter is compelling, I'm open to it, but we should have a good
> answer to the questions I posed above about which redirect targets are
> valid.

I was mostly asking that there be some explanation of the "no 3xx"
thing. Unless it introduces a definite security vulnerability, it's
worth considering whether there are email use cases that would be easier
to set up. You could potentially just prohibit redirect to non-HTTPS,
although a non-HTTPS policy might still be better than nothing.
>
>     "A suggested timeout is one minute..." This could quickly tie up SMTP
>     client resources. Is there any mitigation for that? It also seems
>     like a
>     long timeout.
>
>
> We discussed timeouts quite a bit here previously, I think. One minute
> seemed reasonable to me in the context
> of https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to
> it. That said, it seems to me from that RFC that a standards-compliant
> message delivery can (end-to-end) take substantially longer than 1
> minute, if I am reading correctly.

Rather than (or in addition to) a specific value, it might be better to
have some guidelines on choosing the proper value in various situations.

>  
>
>     4.2. MX Certificate Validation
>
>     Is there a way to allow either CA-based validation or DANE for a
>     certificate that is presented? This seems to conflict with the use of
>     DANE-based certificate validation, or at least there is no order of
>     precedence for certificate validation.
>
>
> As you probably remember, we did try to have an "either/or" kind of
> arrangement in the initial draft. It was a lot of extra complexity, I
> think, for little gain--MTA-STS with DANE certificate validation is
> sort of pointless, since DANE implies DNSSEC, which implies MX records
> are themselves signed.

So what takes precedence: if there is a DANE policy, is MTA-STS ignored?

>
>
>     5.0. Policy Application
>
>     "When a message fails to deliver...": How does the check for the
>     updated
>     policy occur, by looking for an updated TXT record or by re-retrieving
>     the HTTPS policy?
>
>
> By looking for an updated TXT record, as per section 3--but your
> question suggests we should clarify this. ;)

Yes, but Viktor's observation on the other thread (that TXT record
lookups are cheap) applies here so maybe just start all the flows with a
TXT record lookup.

>  
>
>     5.2. Policy Application Control Flow
>
>     In step 1, it is not clear whether the attempt to fetch a new policy
>     involves the TXT record or directly the HTTPS policy.
>
>
> Yep, as above, I think. 
>  
>
>     In step 2, should some sort of warning be generated if the retrieved
>     MXes differ from the current policy, or is this considered normal? It
>     might be a sign of spoofing or misconfiguration.
>
>
> See also David's comment and my reply under the thread "Updated drafts
> for MTA-STS & TLSRPT." 
>
> We could leverage TLSRPT to report such cases, or force a check for a
> new policy, or both, I think. Thoughts?

Will get into this once I have had a chance to review TLSRPT.

-Jim