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

[Jim Fenton <[e-mail]>]

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.

=====

Abstract

Introduces the acronym for the specification as SMTP STS. Should
probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent.

1.0 Introduction

"...delete parts of the SMTP session..." -> "...delete or corrupt parts
of the SMTP session..." (in view of common firewall behavior to change
STARTTLS to XXXXXXXX).

"...downgrade or interception attacks..." -> "...downgrade or MITM
attacks..." (interception is the motive or result, not the attack).

2.0. Related Technologies

"In addition, SMTP STS provides..." -> "In addition, MTA STS
provides..." (and elsewhere in the document)

3.0. Policy Discovery

If an attacker is able to spoof an NXDOMAIN response to the TXT record
request, MTA STS is ignored. This seems like a pretty serious problem in
the absence of DNSSEC, the use of which is of course not being assumed.

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.

"...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?

"A lenient parser SHOULD accept...": For the protocol to be extensible,
this has to be "Parsers MUST accept..."

"...SHALL be ignored" -> "...MUST be ignored"

3.3. HTTPS Policy Fetching

Why MUST 3xx redirects not be followed?

"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.

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.

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?

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.

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.

6.1. Policy Updates

"...HTTPS endpoint has been updated but the TXT record has not yet
been...": Throughout this specification, no mention is made of DNS
caching of the TXT records. Should the records be published with
relatively short TTL, or relatively long TTL? It definitely has an
effect on how dynamic the domain's policy can be.

8. Security Considerations

Item 2, falsification of A/AAAA responses can also be used to redirect
client connections to a rogue server.

"Sender policy cache": It's not clear how this resists the blockage of
the TXT record. If the record is consistently blocked, the policy will
never be discovered to be cached. Also, caches are of finite size and
can not be expected to be kept consistently. If a client discovers a
policy with serial number "xxx", and then subsequently doesn't discover
a policy through the TXT record, what does it do?

Malicious MTA-STS TXT record: This seems to assume that the motive of
the attacker is to create a rogue MX server, but suppose the motive of
the attacker is instead to foil reception of email by the domain. Could
they accomplish this by publishing a bogus STS policy that makes all the
MX records look bad? This relates to the problem of not having an IANA
host name registry.