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
u...@lhs.example.com. 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
