On Sun, Dec 06, 2015 at 04:24:53AM +0100, Aaron Zauner wrote:
> > MTA-to-MTA SMTP (relay) establishes connections to wherever the MX records
> > point. The MX records are in DNS. Therefore, if active attacks are in
> > scope, and DNS is not protected from active attack, you cannot protect
> > of MTA-to-MTA SMTP from active attack. None of the proposals you suggest
> > both scale and work if DNS is subject to MITM.
>
> Yes but verification will fail if you MITM DNS and redirect to an
> previously unpinned server.
I don't think domain-level pinning, rather than per-server pinning
is workable. Pins expire, domains change hands, and MTAs unlike
MUAs and browsers don't have users to "click OK" when stuff breaks.
> A Postmaster operating the MX
> needs to be in control of the issued WebPKI certificate (which means:
> ideally the certificate supports Certificate Transparency and HPKP
> headers are set on the Web-server). This might be impractical for many
> operators:
With STS (which I am not currently endorsing as a universal approach
beyond the small club of the largest providers behind this design)
the destination domain owner publishes the policy which essentially
pins the MX RRset and specifies authenticaiton of same. The
webserver that authenticates the policy is at a well-known URI
associated with the destination domain. The MX operator just has
to maintain valid WebPKI certificates from some widely trusted CA,
that are associated with the MX hostname. I don't see why CT
support or lack thereof is pertinent here.
> Currently more than 60% of SMTP MTAs do _not_ have signed certificates,
> far less even provide valid CN or SAN X.509 information.
Because why pay for bits everyone is going to ignore anyway. The
sysadmins are behaving rationally.
> TACK does not
> require certificates to be CA-signed, this is completely optional. TACK
> also makes revocation and key-rollover a bit easier than this proposal.
I'd considered TACK for SMTP, but gave up once it became clear that
TACK (per-server key pinning) is of no use given MX indirection.
> Again; that might work fine for the companies the authors of smtp-sts
> work for and their large hosting infrastructures, it will not work for
> the common SMTP instance somewhere below a desk in an office. I don't
> see that this proposal would be widely deployed by mail operators.
FWIW, I don't think that STS is universally applicable either, ...
That said I'm going to contribute some cycles and text to making
it as good as it can be, and then time will tell. Worst case it
will help the large providers secure their inter-organizational
connections and protect a large fraction of mail by volume, rather
than domain diversity.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
