Re: [Uta] New proposal: SMTP Strict Transport Security

[Viktor Dukhovni <[e-mail]>]

On Wed, Apr 06, 2016 at 10:52:14AM +0200, Daniel Margolis wrote:

> > While I see benefits to hosters, what I've seen from community projects
> > like bettercrypto(.org) is there's a lot of misunderstanding on how to
> > properly configure services, a lot of bad information sources around for
> > sysadmins and barely any tooling to automate. Let's Encrypt now does
> > automate on specific platforms and for specific daemons - we'll probably
> > extend this to some degree for mail daemons in the future but there's also
> > a lot of unwillingness among admins to use automation tools that require
> > e.g. root. I feel that a lot of admins will reject going via HTTPS services
> > just to serve mail in a secure fashion. I'm also not sure how willing
> > software implementers will be to go this direction, but we'd better ask
> > them.
> 
> One of my big questions to Viktor. :)

In Postfix, finding a way to query an HTTPS server for transport
security policy is relatively simple.  Postfix supports policy
lookup via a variety of key/value lookup interfaces one of which
happens to be "socketmap" which is IPC over unix-domain or inet
sockets.

So the lookup can be out of process, via some sort of socketmap
talking STS-agent.

The difficult bits are:

    * Cold start: Validation of the policy on first use.  STS wants
      to only cache policies that work, so the policy lookup layer
      needs to find out whether the policy "worked".

      When an unvalidated policy fails, delivery needs proceed
      despite the policy failure, so we need to perform certificate
      verification, proceed despite verification failure, but report
      the verification failure to the STS-agent.  Currently when
      authentication is not required we don't bother checking
      certificates.

    * Error recovery:  STS (draft) suggests refreshing the
      policy when deliveries fail.  This again requires 
      post-delivery data reporting back to the policy
      lookup service.

Both of the above are complicated by the fact that "success" and
"failure" are not well defined when a destination has multiple MX
hosts.  

 * Is it enough for delivery via just the first MX tried to succeed?
   Or does the initial delivery need to confirm more than one MX host?

 * Is delivery to a second MX host after failing the first a "success"?

 * How about a site only some of whose MX hosts match the STS policy constraints?

 * What about MX hosts whose certificate chain is fine, but the TLS handshake
   fails for other reasons?  Is the policy "validated"?

 * What if the handshake completes, but the connection breaks during data
   transfer (possibly due to a TLS interoperability error)?

The draft is not particularly detailed in defining what "validation"
means, and there is not at present in Postfix a mechanism to report
SMTP delivery status to external agents.

What should a success or failure report to the STS policy lookup
agent include?   Should this agent also manage the failure reporting?
As STS evolves the requirements may change, but we'd want to nail
down the delivery-agent to STS-agent protocol, so that STS-agents
can be add-ons that evolve largely separately from Postfix, without
requiring new C-code in new Postfix releases to stay current with
the protocol.

It may also be helpful to explain that the "domain" for which the
STS client is doing policy lookup is not necessarily the domain
part of the recipient address(es) in the message envelope.  While
these are typically the same, in some cases the nexthop domain may
be a "smarthost" relay or a manually configured nexthop for a set
of designated recipient domains.

Another one of the things that DANE "gets right", is that TLSA
records are service-endpoint-specific.  MTAs may at times be
configured to relay some or all mail via nexthop:port with a port
other than 25.

The certificate on port 587 (or whatever) may be different than
the one on port 25 and the desired TLS policies may be different
for the different (by port) SMTP services.

We'd probably avoid linking-in libcurl, we'd very much want to
avoid synchronous HTTP lookups inside the delivery agent.

To avoid deliver pipeline stalls we'd expect the out-of-process
STS delivery agent to reply immediately with no policy when it does
not already have at least an embryonic unvalidated policy cached,
and to schedule a policy fetch in the background.  The policy would
only be used and validated on the first delivery *after* it was
already cached locally (as an unvalidated policy).

    * Cold start:
      Trigger STS background policy fetch, proceed without STS
      policy.

    * Luke warm start:
      Validate as-yet not validated policy.  Deliver either way,
      but enable on "success" (carefully defined, TBD).

    * Warm start:
      Enforce policy, "failure" (definition TBD) defers mail and
      triggers background policy refresh.  Need a mechanism to
      securely "repudiate" the policy (return an HTTPS validated
      empty policy, or one that just supplies a reporting address).

So, this is not going to be easy.  I don't expect to see a stable
specification for STS this year.  But early 2017 may be possible.
Work to integrate this into Postfix may begin in the Spring of
2017, and the first stable release that supports it might then
appear in Jan/Feb 2018.  Distros will take 2-5 years to bundle that
release, and users another 2-5 years to deploy said distros.  So
no significant deployment much before 2020 at the earliest.

-- 
	Viktor.