Subject: [Uta] review of draft-ietf-uta-mta-sts-14

From: "Chris Newman" <[email-masked]>
Date: Wed, 21 Mar 2018 20:10:59 +0000

Overall, this is in much better shape than the last time I reviewed the 
document (-07). I agree with several of Alexey's issues but won't repeat 
them. I have some minor concerns with the level of requirement for SNI, 
and I think the security considerations should be improved.

When I reviewed -07, I suggested a security consideration. Here's a 
slightly edited version of the same consideration:

---
This mechanism causes an MTA (an automated system) to adopt the role of 
an HTTPS client in a scenario where the HTTPS server may be hostile to 
operation of the MTA. A full HTTP stack is a large amount of code that 
may contain coding errors that expose the MTA to new implementation 
vulnerabilities due to the increased attack surface. This threat can be 
partially mitigated by using a hardened HTTPS client library that has 
been tested against a fuzzing HTTPS test server. This threat can also be 
partially mitigated by isolating the HTTPS code into a separate process 
that does not have access to the normal MTA machinery and making sure 
the MTA machinery gracefully handles a wedged HTTPS co-process.
---

I think this text would be good to include in the security 
considerations section.

Section 3.3:

>   proactivecly refresh cached policies before they expire; a suggested

proactivecly => proactively

Section 7.1:

> To ensure that the server sends the right certificate chain, the SMTP 
> client MUST have support for
> the TLS SNI extension [RFC6066].

I'm ok with this statement, but I'd like to hear from other server 
implementers on this list about SNI support in their SSL stack.

Oracle's messaging server uses Mozilla NSS so it implements and uses 
client-side SNI on all connections. However, the Mozilla NSS API to 
consume server-side SNI is difficult to use, so server-side SNI is not 
presently an implementation priority for us.

> When connecting to an SMTP server, the SNI extension MUST contain the 
> MX hostname.

I find this problematic in several ways. I don't believe the term "MX 
hostname" is either defined anywhere or clearly understood. Do you mean 
one of the hostnames in the MX record? Or do you mean the DNS name of 
the MX record itself (which is normally not a hostname)?

Second, it should be clearly stated that this rule only applies to SMTP 
clients implementing the SMTP-STS specification. Legacy SMTP clients 
will often use an SNI matching the hostname that appears in the MX 
record and is used to look up the A/AAAA record for the connection.

>   HTTP servers used to deliver MTA-STS policies MUST have support for

I don't see a reason for this to be "MUST". SHOULD seems more pragmatic, 
or just drop this implementation requirement and leave the MAY (so it's 
a quality of implementation issue).

>   SMTP servers MUST have support for the TLS SNI extension and MAY 
> rely
>   on SNI to determine which certificate chain to present to the 
> client.

Same comment as for HTTP servers. Also, I'd prefer this be SHOULD given 
we're unlikely to implement server-side-SNI for SMTP in the near future 
regardless of what's said here.

Section 8.2

This policy delegation model is insecure absent DNSSEC. The attack is 
not mentioned in the security considerations. Suppose I want to monitor 
all traffic between domain A and domain B (lhs.example.com). And suppose 
domain A is a mail service provider. There are three steps to a fairly 
nasty attack here:
1. set up an "evil mail hosting" environment that has correct mta-sts 
policy & PKIX certificates to be a hosting provider for domain B.
2. plan to attack two DNS lookups from domain A, producing two CNAMEs 
for the _mta-sts.lhs.example.com and lhs.example.com domains that point 
to the evil hosting environment.
3. Use a throwaway account on domain A to send email to 
[email-masked]. Do this during the CNAME attack.

If the attacker does this when domain A does not have policy for domain 
B cached, the attacker can intercept the mail flow for the duration of 
the policy refresh period (and the attacker controls the STS record and 
value of max_age). Although the presence of the "evil mail hosting" 
domain is detectable in the logs of domain A & B, it's difficult to 
distinguish the "evil mail hosting" domain from a valid mail hosting 
domain unless domain A advertises DKIM/DMARC and domain B enforces 
DKIM/DMARC.

There's an existing IETF standard for secure policy delegation that 
could stop this attack: POSH (RFC 7711). I'm pointing out that is a way 
to stop the attack, not suggesting it's a good idea to add that 
complexity to this system.

>   ...  This can be done either by setting the
>   "mta-sts" record to an IP address or CNAME specified by the hosting
>   organization and by giving the hosting organization a TLS 
> certificate
>   which is valid for that host, or by setting up a "reverse proxy"
>   (also known as a "gateway") server that serves as the Policy 
> Domain's
>   policy the policy currently served by the hosting organization.

This sentence is garbled.

		- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Mar 2018 20:44:16 -0400

> On Mar 21, 2018, at 4:10 PM, Chris Newman <[email-masked]> wrote:
> 
>> To ensure that the server sends the right certificate chain, the SMTP client MUST have support for
> I'm ok with this statement, but I'd like to hear from other server implementers on this list about SNI support in their SSL stack.

The same requirement exists in DANE (rfc7672) and is implemented in Postfix, Exim, CloudMark, ...
It has caused no issues.  Exim uses either OpenSSL or GnuTLS, Postfix and CloudMark just OpenSSL.

> Oracle's messaging server uses Mozilla NSS so it implements and uses client-side SNI on all connections. However, the Mozilla NSS API to consume server-side SNI is difficult to use, so server-side SNI is not presently an implementation priority for us.

There is NO requirement for server-side SNI support stated or implied in this draft.
The client MUST give the server the opportunity to support SNI, but the server can
simply ignore the SNI extension.  The DANE RFC explains that a server that supports
SNI, but does not recognize the requested name, MUST NOT abort the connection, it
MUST instead continue with some default chain, the client may support additional
names it could not send in a single SNI request.

>> When connecting to an SMTP server, the SNI extension MUST contain the MX hostname.
> 
> I find this problematic in several ways. I don't believe the term "MX hostname" is either
> defined anywhere or clearly understood. Do you mean one of the hostnames in the MX record?
> Or do you mean the DNS name of the MX record itself (which is normally not a hostname)?

Obviously, the former and not the latter.  That is, the "exchange" field
of the MX RRData:

	qname. ttl IN MX preference exchange.

> Second, it should be clearly stated that this rule only applies to SMTP clients
> implementing the SMTP-STS specification.

Of course, since this is the STS specification.

> Legacy SMTP clients will often use an SNI matching the hostname that appears
> in the MX record and is used to look up the A/AAAA record for the connection.

That's the same value, but if pre-DANE Postfix is a legacy SMTP client MTA,
then it simply sends no SNI at all when DANE is not used.  Don't know about
widely used MTAs.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 22 Mar 2018 09:59:34 +0000

> then it simply sends no SNI at all when DANE is not used.  Don't know about

For Exim, as a client, sending SNI and the value used is a configuration
option.
-- 
Cheers,
  Jeremy

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 22 Mar 2018 13:34:54 +0000

> Section 8.2

My analysis of section 8.2 is wrong and I withdraw the comment. Serves 
me right for trying to do a quick security analysis during the plenary 
while jet lagged. :-)

I'm going to continue to think about the relationship between POSH (RFC 
7711) and SMTP-STS. I don't think it will result in proposals but I want 
to make sure we didn't miss an important security case that POSH 
handled.

		- Chris