On Thu, May 3, 2018 at 10:19 PM, Viktor Dukhovni <[email protected]> wrote:
> On Thu, May 03, 2018 at 06:14:44PM -0700, Eric Rescorla wrote: > > > S 10.2. > > > mode, to allow clean MTA-STS removal, as described in Section > 8.3.) > > > > > > Resistance to downgrade attacks of this nature--due to the > ability to > > > authoritatively determine "lack of a record" even for non- > > > participating recipients--is a feature of DANE, due to its use of > > > DNSSEC for policy discovery. > > > > I'm surprised that you don't note that if you use DNSSEC (and the > > client validates), you are in general resistant to this form of > > attack. > > With MTA-STS, hardening the DNS is not enough, the policy does not > take effect until it is first verified to work. First-contact > lookup failures for the TXT record do not cause email to be deferred. > > Indeed with MTA-STS, some MTAs may do *background* policy retrieval, > and the first few messages to a destination may go out unprotected. > > For a downgrade-resistant mechanism, a domain can use DANE SMTP > (RFC7672). If the destination domain is signed, the first step in > that direction is already taken. > > > > 2. That at least one of the policy's "mx" patterns matches at > least > > > one of the identities presented in the MX's X.509 > certificate, as > > > described in "MX Certificate Validation". > > > > IMPORTANT: This doesn't seem like quite what you want. Consider > > the case where the STS policy has: > > > > mx: mx1.example.com > > mx: mx2.example.com > > > > And I then attempt to send to mx1.example.com, send SNI=mx1.example.com, > > and get a cert that is only valid for mx2.example.com. > > [ This was discussed extensively in the WG. This part of the design > is substantially my doing... ] > > An MiTM attacker can direct the traffic to any MX host of his choice > by blocking TCP SYNs, or generating RST packets for traffic to all > the other MXs, causing the desired MX host to be the only one the > client can reach. Also, for a large fraction of domains a wildcard > certificate, or a certificate with all the names is used. For > example, below are the SANs from the certificate for gmail.com: > > DNS:mx.google.com > DNS:alt1.aspmx.l.google.com > DNS:alt1.gmail-smtp-in.l.google.com > DNS:alt1.gmr-smtp-in.l.google.com > DNS:alt2.aspmx.l.google.com > DNS:alt2.gmail-smtp-in.l.google.com > DNS:alt2.gmr-smtp-in.l.google.com > DNS:alt3.aspmx.l.google.com > DNS:alt3.gmail-smtp-in.l.google.com > DNS:alt3.gmr-smtp-in.l.google.com > DNS:alt4.aspmx.l.google.com > DNS:alt4.gmail-smtp-in.l.google.com > DNS:alt4.gmr-smtp-in.l.google.com > DNS:aspmx.l.google.com > DNS:aspmx2.googlemail.com > DNS:aspmx3.googlemail.com > DNS:aspmx4.googlemail.com > DNS:aspmx5.googlemail.com > DNS:gmail-smtp-in.l.google.com > DNS:gmr-mx.google.com > DNS:gmr-smtp-in.l.google.com > > So trying to make sure that you're reaching the MX host > you think you're reaching and not one of the others is > largely pointless and often a lost cause. > But not everyone is configured this way. > > This seems like it's extremely undesirable and might be the basis for > some kind of attack. > > See above. If the MX host has a certificate that matches the > client's SNI, it'll may return it, even if that's one of the other > MX hosts. If it does not return a matching certificate, the "attack" > fails. > This might be true, but this kind of informal reasoning is notoriously prone to error. We have a general pattern for TLS certificate verification, which you are deviating from, and we then need to analyze in detail. I'm not seeing any good reason for that. > > I think the rule you want is: > > > > You look up the MXes in the DNS. > > You select one that must match one of the things in the mx list in the > STS > > Preemptive removal of non-matching MX hosts is liable (in sloppy > implementations, and I expect enough to be sloppy) to cause routing > loops, when a backup MX host, not after removing itself early from > the list, fails to eliminate worse priority MX hosts. I don't understand this claim. It also > requires all sites to duplicate MX host updates from DNS into the > STS policy, disallowing the "low-maintenance" ".example.com" form. > I don't see why this would be true. You publish .example.com and then you modify the MX requires at will. provided that they all end in .example.com. > > The certificate MAY be checked for revocation via the Online > > > Certificate Status Protocol (OCSP) [RFC6960], certificate > revocation > > > lists (CRLs), or some other mechanism. > > > > Why is revocation only MAY? > > Looking at e.g. the X.509 certificate for Gmail, I don't see a > "must staple OCSP" extension. So we get no meaningful security > from OCSP stapling, an attacker who misappropriates the private > key will not staple OCSP responses. > > I have no intention of building an HTTP client into the Postfix > SMTP client to download CRLs from various CAs that remote peers > might use. Full CRLs might at least be cached on a per-CA basis, > while per-certificate OCSP requires a connection to the CA for each > new certificate. > > I'm afraid I see too little value in CRLs to consider CRL support > in Postfix. The OS platforms that Postfix runs on don't deliver > a full intermediate CA store with regular updates of the associated > CRLs. Doing CRL management in each application is IMHO impractical. > > In short, I have not implemented and don't expect to implement CRL > support in Postfix. > You seem to be omitting the obvious answer: regular OCSP. -Ekr
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
