SMTP STS and policy delegation for smtp *client* ?

[David Schweikert]

Hi,

I wonder what the Postfix community thinks or plans to do according to
this standard that is being written:
https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1

I personally find this quite interesting. What I wonder is, if maybe
we have now reached a similar point of complexity for policy decisions
when delivering mails, as it was the case for incoming mails when policy
delegation for the SMTP server was introduced.

Could a similar policy lookup protocol be implemented for the SMTP
client and things like SMTP STS be implemented as a policy daemon?
The policy lookup could take place right after the SMTP handshake.

Cheers
David

[Wietse Venema]

David Schweikert:

I will read the draft in the coming days. I am all in favor of
outsourcing complex policies (for example, I do not expect to see
an XML processor in the Postfix trusted code base).

In the case of SMTP server policy, that was relatively easy to
implement (reuse the code that implements access map support), but
there is nothing to reuse, yet, on the SMTP client side.

Wietse

[Viktor Dukhovni]

> On Mar 21, 2016, at 12:18 PM, David Schweikert <da...@schweikert.ch> wrote:
>
> I wonder what the Postfix community thinks or plans to do according to
> this standard that is being written:
> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1

My take on the draft is that it is a hack to get the large email providers
doing SMTP TLS with authentication amongst themselves while they take multiple
years to ponder DNSSEC, which can be tricky to retrofit onto their complex
deployments. The draft still has warts to iron out, I'll help them with those.

I am not convinced this scales down at all well, but there will likely be demand
for securing outbound email traffic sent to the large providers. I am not a big
fan of code to support the centralized email storage model of the large providers,
but that battle is lost for now.

--
Viktor.

[Per Thorsheim]

Alex Stamos at Facebook has publicly & repeatedly stated that DNSSEC is
"dead". I guess that means no RFC 7672 at Facebook. With him making that
statement I already know others taking the same position. There seems to
be a strong anti-dnssec crowd, complaining primarily on these issues:

1) Government access / possible interference with dnssec
2) Weak encryption (1024 bit keys)
3) Complexity of configuration & maintenance
4) "only 1 bit to tell you if things are ok or not"
5) DoS capabilities (ppl forget there are other & easier ways)

Google public DNS supports DNSSEC, but afaik no other part of Google
uses it. Although this proposal can live with or without DNSSEC, I am
wondering if Google, Microsoft, Linkedin & other major companies has any
plans to deploy DNSSEC and RFC7672. Or will this proposal be a shorter &
easier step forward, eventually delaying or simply ignoring RFC7672 for
the foreseeable future?

Regards,
Per

[Michael Storz]

Am 2016-03-21 17:18, schrieb David Schweikert:
> Hi,

>
> I wonder what the Postfix community thinks or plans to do according to
> this standard that is being written:
> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1
>

> I personally find this quite interesting. What I wonder is, if maybe
> we have now reached a similar point of complexity for policy decisions
> when delivering mails, as it was the case for incoming mails when
> policy
> delegation for the SMTP server was introduced.
>
> Could a similar policy lookup protocol be implemented for the SMTP
> client and things like SMTP STS be implemented as a policy daemon?
> The policy lookup could take place right after the SMTP handshake.
>

> Cheers
> David

Hi David,

since Postfix already implements a tls policy mechanism via
smtp_tls_policy_maps you could use the tcp_table protocol to explore the
integration of STS into Postfix. This would allow a comparison of the
possibilities of STS with all the good stuff Viktor implemented for
smtp_tls_policy_maps.

Regards,
Michael

[Viktor Dukhovni]

> On Mar 21, 2016, at 3:17 PM, Michael Storz <Michae...@lrz.de> wrote:
>
> since Postfix already implements a tls policy mechanism via smtp_tls_policy_maps you could use the tcp_table protocol to explore the integration of STS into Postfix. This would allow a comparison of the possibilities of STS with all the good stuff Viktor implemented for smtp_tls_policy_maps.

I recommend socketmap over tcp_table.

--
Viktor.

[Viktor Dukhovni]

> On Mar 21, 2016, at 3:27 PM, Viktor Dukhovni <postfi...@dukhovni.org> wrote:
>
> I recommend socketmap over tcp_table.

http://www.postfix.org/socketmap_table.5.html

--
Viktor.

[Michael Storz]

Am 2016-03-21 20:09, schrieb Per Thorsheim:
> Den 21.03.2016 18.47, skrev Viktor Dukhovni:
>>
>>> On Mar 21, 2016, at 12:18 PM, David Schweikert <da...@schweikert.ch>
>>> wrote:
>>>

>>> I wonder what the Postfix community thinks or plans to do according
>>> to
>>> this standard that is being written:
>>> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1
>>

I do not think the big ISPs will implement DANE in the foreseeable
future as you can see from the authors of this draft. They will
implement STS, a SMTP variant of HSTS with a flavor of DMARC. And a
variant of HPKP (certificate pinning) will follow very fast. And the big
providers will use a STS preload list to circumvene TOFU for their mail
servers. I do not hope they will use a variant of IMPT
(https://tools.ietf.org/html/draft-laber-smtp-impt-00) which is now used
by the big German ISPs with their "E-Mail made in Germany (EmiG)".

Therefore the only thing we can do is to see that STS will smoothly work
with installations of DANE.

Regards,
Michael

[Viktor Dukhovni]

> On Mar 21, 2016, at 4:04 PM, Michael Storz <Michae...@lrz.de> wrote:
>
> I do not think the big ISPs will implement DANE in the foreseeable future as you can see from the authors of this draft. They will implement STS, a SMTP variant of HSTS with a flavor of DMARC. And a variant of HPKP (certificate pinning) will follow very fast. And the big providers will use a STS preload list to circumvene TOFU for their mail servers. I do not hope they will use a variant of IMPT (https://tools.ietf.org/html/draft-laber-smtp-impt-00) which is now used by the big German ISPs with their "E-Mail made in Germany (EmiG)".
>
> Therefore the only thing we can do is to see that STS will smoothly work with installations of DANE.

While it is difficult for them to sign their own zones, it would not
nearly be quite that difficult to deploy validating resolvers and
implement the client role of DANE. Zealous objections aside, I expect
a few of them will in time support client-side DANE, and some have or
will publish DANE TLSA RRs.

--
Viktor.

[David Schweikert]

Hi Michael,

On Mon, Mar 21, 2016 at 20:17:02 +0100, Michael Storz wrote:
> since Postfix already implements a tls policy mechanism via
> smtp_tls_policy_maps you could use the tcp_table protocol to explore
> the integration of STS into Postfix. This would allow a comparison
> of the possibilities of STS with all the good stuff Viktor
> implemented for smtp_tls_policy_maps.

Indeed, thanks for the hint!

Cheers
David