> On Nov 12, 2017, at 6:01 AM, Jim Fenton <[email protected]> wrote:
>
> An attacker that is positioned between mail servers to be
> able to block the negotiation of STARTTLS probably is also positioned to
> be able to block the _mta-sts TXT record response, making it look like
> there's no policy.
This is an unavoidable feature of STS. It is vulnerable to "cold start"
downgrade attacks, that is to downgrades when the sending system has
no cached policy.
> - Section 3.2 "mode" key/value pair: What does "report" do now that
> tlsrpt is separate? It seems like the modes now ought to be "enforce"
> and "none".
It does exactly what it says, delivery proceeds despite lack of STARTTLS
or authentication failure, but such failures to establish a secure channel
for delivery are reported. There are no such reports to domains with no
policy. Perhaps the receiving domain is unsure how interoperable its
TLS stack or certificate chain would be if enforced. Though to be honest
I am not convinced that support for reporting will be universal, I expect
that some systems will treat "report" and "none" as synonymous (by never
sending reports).
> - max_age: Does expiration of max_age trigger a refresh or does it
> simply age out of the cache?
A sensible implementation of STS will make (multiple if necessary)
refresh attempts long *before* the cached policy expires, provided
there is sufficient ongoing traffic to the destination domain.
Such refresh would happen after a delivery of a message after 1/2
max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before
expiration. So with a 180 day max_age, and steady message flow to
a domain with a poorly available HTTPS service, the refreshes would
happen (rounded):
* shortly after 90 days, but failing that
* shortly after 135 days, but failing that
* shortly after 157 days, but failing that
* shortly after 168 days, but failing that
* shortly after 173 days, but failing that
* shortly after 177 days, but failing that
* shortly after 178 days, but failing that
* shortly after 179 days, but failing that
* shortly after 12 hours to go, but failing that
* shortly after 6 hours to go, but failing that
* shortly after 3 hours to go, but failing that
* shortly after 90 minutes to go, but failing that
* shortly after 45 minutes to to, but failing that
* shortly after 22 minutes to go, but failing that
* shortly after 11 minutes to go, but failing that
* shortly after 5 minutes to go, but failing that
... policy expires ...
* periodic lookup after each message delivery, but
not more often than once every (say) 5 minutes.
The details of the refresh policy, and frequency of probes
for domains with no cached policy would be implementation
dependent. I think that based in part on my feedback the
text in Section 9.2 says (somewhat less prescriptively):
https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2
9.2. Preventing Policy Discovery
...
Because this attack is also possible upon refresh of a cached policy,
we suggest implementers do not wait until a cached policy has expired
before checking for an update; if senders attempt to refresh the
cache regularly (for instance, by checking their cached version
string against the TXT record on each successful send, or in a
background task that runs daily or weekly), an attacker would have to
foil policy discovery consistently over the lifetime of a cached
policy to prevent a successful refresh.
> I had thought that TXT record suppresion
> attacks were mitigated by only requiring the TXT record initially, but
> this makes it sound like it ages out and has to be rediscovered the next
> time a message is sent to the domain.
See above, refresh should happen long before expiration. An ongoing
MiTM attack can defeat this, but the attack has to be ongoing for the
lifetime of the policy. It may be easier to get a forged certificate
from some DV CA (via MiTM of the traffic between the CA and the target
domain).
> Just to be clear, I do not consider use of long cache times to be an
> effective security measure.
If that's the case, then STS is not for you. DANE has stronger
downgrade resistance, please join the existing > 173000 domains
that have DNSSEC and DANE-enabled MX hosts. I'd especially like
to see some US-based hosting providers emulate domeneshop.no,
transip.nl, udmedia.de and bhosted.nl by enabling DANE on the
SMTP servers used for their hosted domains. If anyone reading
this knows the right people at Godaddy, Dreamhost, ... please
let them know I'm available to answer any questions they may
have and suggest key rotation strategies.
> - Section 3.3: Does certificate expiration constrain the max_age of a
> cached policy? (if the certificate expires very soon)
No. Neither the mta-sts HTTPS server certificate, nor even more so
the expirations of MX host certificates affect the policy expiration
time.
> - 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.
> - Section 4 "report": delete? (because this is in tlsrpt)
Sorry, the "report" mode is not superseded by "tlsrpt", which
does not provide any downgrade protected signalling.
> - Section 6.1: Why is SNI always required? Can't a small MTA that only
> ever serves one domain get by without it?
SNI is required from the *sending* MTA and HTTPS policy lookup client.
It is not (should not be) required at receiving systems, except when they
in fact have multiple certificate chains and need to use the SNI signal
from the client to choose the right one. Even then, at the MX host
it is required that when the client's SNI does not match any name
known to the server, it should continue and send its default chain.
The HTTPS server can do whatever it is that HTTPS servers do with
SNI, it is not for this specification to redefine HTTPS.
> - Section 7.1 leads me to question the benefit of having a policy ID in
> the TXT record as opposed to just a hint whether might be a MTA-STS
> policy.
This was subject to considerable earlier discussion, and is in fact
needed.
> Apparently the only time the a sender i. required to check the
> TXT record is when they don't have a policy (first message or it has
> expired).
There's your confusion. This is not the case.
> Of course senders could check TXT more often but I don't see
> any guidance for that.
Section 9.2.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
