On 11/12/17 10:48 AM, Viktor Dukhovni wrote: > >> 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. Yes -- I'm probably repeating repeating myself here, but thought it worth saying.
> >> - 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). So maybe the problem is the choice of the name "report" since it doesn't actually cause any reports to be generated. It's really a passive policy. I was thinking that expressing a policy along with "none" (along with a tlsrpt policy record) would accomplish this, but maybe the semantics of "none" are wrong given its role in removing MTA-STS (Section 7.3), but I don't see that it necessarily conflicts. Or maybe just change it to enforce: [yes/no]. > >> - 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. Without some guidance (perhaps a SHOULD), many implementations will never check the TXT record if they have a policy in their cache. Unless senders are going to be actually checking the TXT records for updates, it's not worthwhile for recipient domains to publish them. I also wonder how useful it is given that recipient domains are going to have to assume that their policies will be used until max-age anyway, and these policies aren't likely to change very often. > 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. A comment that I forgot to make is that, if this is a normative requirement (even a MAY or SHOULD), it should be in one of the earlier sections of the document, not in Security Considerations where it's likely to be overlooked by implementers. >> - 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. I'm wondering if the document should say that. > >> - 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. That's the way I would read and implement it too, but it would be good to say that in Section 4 so that it doesn't conflict with Section 2. > >> - 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. Agreed, so the text shouldn't unconditionally require SNI. >> 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. Please point me at text that says otherwise. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
