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

[David Schweikert <[e-mail]>]

Hi Viktor,

On Wed, Apr 06, 2016 at 22:40:40 +0000, Viktor Dukhovni wrote:
>  * 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 considering STS to be a mechanism that verifies something
that should always be true, and just generating a permanent failure if
you encounter something that doesn't match that policy? Like a sort of
"assertion check" on what you see following the normal processing path.

> 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.

You could design a protocol that is very similar to the postfix access
policy delegation protocol:

- Postfix SMTP connects to the chosen next hop and does the handshake
- It gives via policy protocol all information that it has about the
  connection (hostname, IP, TLS information, etc.)
- In case something is bad, the policy demon can return "REJECT" with a
  reason (and initiate reporting by registering the failure in some
  database).

> 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.

I don't understand this: why would the STS client do a policy lookup not
on the recipient address? I understand that you can have a different
nexthop specified in your transport map, but why look that up instead of
the recipient address domain?

> 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.

Maybe you should be able to disable the STS check in those cases where
you do some local override?

> 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).

Yes, that's really a problem in the policy-delegation idea. I guess you
could return a "DEFER" and thus force the mail to be back in the queue,
waiting for the fetching of a current policy to finish? But then you
have the problem that postfix is going to retry with another hop...

Cheers
David