Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, May 3, 2018 at 10:19 PM, Viktor Dukhovni <[e-mail]>
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