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

From: Daniel Margolis <[email-masked]>
Date: Fri, 1 Apr 2016 21:44:03 +0200

Viktor et al,

Two things:

First, I've taken a stab at a "design reasoning FAQ" document:
https://github.com/mrisher/smtp-sts/wiki/FAQ. I think most of the contents
of this were already discussed on this list, but hopefully it provides a
useful reference.

Second, I've tried to write up the reasoning you expressed here about "why
DNSSEC?" (for lack of a better term) here:
https://github.com/mrisher/smtp-sts/wiki/Why-DNSSEC-at-all%3F. (Not that my
writing is necessarily more clear than yours, but rather to extract it for
handy reference in preparation for hopefully a bit more feedback from other
people here.)

Feedback welcome.

Dan

On Tue, Mar 22, 2016 at 8:58 AM, Daniel Margolis <[email-masked]>
wrote:

> Hi Viktor,
>
> Thanks for all the thoughtful comments. I'll respond to what (at a glance)
> seems to be the most significant three first.
>
> On Tue, Mar 22, 2016 at 7:35 AM, Viktor Dukhovni <[email-masked]>
> wrote:
>
>>     A significant obstacle to a successful roll-out of WebPKI with
>>     SMTP is not such much that obtaining and deploying CA certs is
>>     onerous (enabling DNSSEC is likely more difficult at present),
>>     but rather that there is no single set of CAs that sending and
>>     receiving systems can (or perhaps should) reasonably agree on.
>>     On the one hand, because MTAs employing STS are non-interactive
>>     background processes with no human-operator in the loop to
>>     "click OK" for each exception, the set of CAs a sending system
>>     that employs STS would need to trust would need to be "comprehensive
>>     enough" to include all the CAs used by all the domains one
>>     might need to send email to.
>
>
> This is of course a big topic, but I don't think we should assume that in
> common deployment web browsers *do* rely upon a user to make some sound
> human decision about whether to trust a CA. For example, here's the
> multi-stage process to get Chrome to accept an untrusted certificate:
> https://docs.oracle.com/cd/E24628_01/install.121/e39876/img/scrnshot_advanced.gif.
> It's not insignificant to me that Oracle felt the need to document this
> process for the users with screenshots: we *don't* expect the common
> browser user to make a personal determination of what CAs to accept, so the
> "background process" argument is, I think, based on a false premise.
>
> In truth, we expect browser users to defer to their platform vendors to
> make sane decisions for them, and we expect the owners of large websites to
> be able to pick a CA that is widely trusted. With the rise of Let's Encrypt
> and other free CAs, this doesn't seem overly burdensome.
>
>
>     This requires domains that publish STS records to duplicate
>>     their MX records in the STS RRset.  It is not clear why that's
>>     useful.  If the STS record itself is not DNSSEC-validated, the
>>     payload is not more secure than the MX RRset.  If the payload
>>     is DNSSEC-validated, then the MX RRset in the same zone would
>>     (barring unexpected zone cuts) be equally secure.  I posit that
>>     this field is both onerous and superfluous.
>
>
> There are two differences with the MX records here:
>
> 1. A (most likely) longer TTL on the STS policy versus the MX record
> 2. The option for wildcard's or broader patterns than merely a list of
> valid hosts
>
> This permits the publishing domain to declare that "for the next year, I
> plan to always host my mail at example.com" without publishing specific
> MX records that have a 1-year TTL (which of course could be brittle).
>
>
>     It would be expensive for MTAs to attempt repeated HTTPS
>>     connections that timeout trying to connect to port 443 at
>>     the majority of domains which have not deployed STS.
>>
>>     All that's needed in DNS to support a pure WebPKI STS is a
>>     boolean value to signal the existence of the STS resource URI.
>>     This data can be obtained efficiently.  If the "_smtp-sts" RR
>>     exists (pick a suitable RRtype and fixed short payload) then
>>     the HTTPS URI should be consulted, otherwise the HTTPS URI is
>>     not consulted (at first contact), or is consulted asynchronously,
>>     in parallel with the first mail delivery (with appropriate spacing
>>     between probes, ...).
>>
>>     Thus some MTAs might compress the STS DNS record to zero bits,
>>     and just use asynchronous suitably spaced HTTPS probes to the
>>     domains for which no policy is presently known.  However the
>>     1-bit encoding is likely better.
>>
>
> I also dislike the copying of the policy into two places, for the reasons
> Dave noted here:
> https://mailarchive.ietf.org/arch/msg/ietf-smtp/nqWeUTe03mxJLltC-wHOsVvfbKo
> .
>
> The only real reason to do this is to allow MTAs to cheaply see if the
> policy has been updated. This seems like a silly thing, since in normal
> usage they never need to check as long as they have a cached policy, but
> it's exactly that asymmetry that worries me: Since in normal usage the
> traffic to the HTTPS endpoint will be minuscule compared to the SMTP
> traffic to the domain, hosts are likely to dramatically underprovision the
> former versus the latter. Unfortunately, then, in the case of a validation
> *failure*, the HTTPS endpoint would (absent some other policy TTL separate,
> and shorter from, the expiration lifetime) be bombarded with an HTTP GET
> *once* *per* email.
>
> So all we're really doing here (in the webpki case) is leveraging DNS as a
> sort of caching layer. An alternative solution would be what I hinted at
> above: to simply embed a short "TTL" in the policy. Or to say we don't care
> and encourage the use of HEAD.
>
> If we are willing to force the webpki validation method (as you assumed, I
> think, above) and don't mind making senders handle this short-term TTL
> logic,  I think we could make the publishing process simpler, with the
> advantage Dave noted in the above-linked thread (i.e. an easier deployment
> for customers of hosted mail services).
>
> I'm somewhat on the fence about this trade-off myself, but I don't think
> it's unreasonable. Thoughts?
>

---

From: Chris Newman <[email-masked]>
Date: Fri, 01 Apr 2016 18:48:00 -0300

I’m unconvinced by these two design reasoning documents.

They start with the assumption that signed routing information, security policy and reporting should be conflated. I consider those separate functions. The only relationship between signed routing and security policy is that security policy might require that routing be signed.

I am not convinced it is desirable to allow sites with strong security to downgrade to weak security. Since allowing that adds so much complexity and security risk to the proposal, it seems you need a much stronger justification to include that complexity than the claim that it’s a form of “customer lock-in”. Assuming we do simplify the proposal, then once a domain advertises SMTP STS, they will subsequently require their hosting provider to offer STS. As domain owners usually pay their hosting providers, this creates a financial incentive for hosting providers to offer STS and thus there is no “customer lock-in” problem as long as this is standardized properly. Indeed, I’d argue that removing the timeout and security downgrade mechanisms from the security policy part of the proposal make it simpler, more secure and likely to deploy faster due to financial incentives. Seems like a win-win-win to me.

I feel very strongly that policy for SMTP relay should be advertised by SMTP and protected by SMTP TLS. Doing anything else creates a much larger attack surface on the policy information and is both more complex and less secure. The preferred mechanism to sign SMTP relay routing (DNS MX) is DNSSEC. I’m open to proposals for alternate mechanisms to sign MX record information due to the difficulty of deploying DNSSEC, but such mechanisms should not be confused with security policy.

I’m open to proposals to advertise reporting information separately from (or together with) SMTP security policy and to provide a mechanism to report SMTP security without requiring SMTP security policy to be present. Given the interest in reporting for a broad range of SMTP relay security features, we might want to split the reporting function into a separate document.

		- Chris
On April 1, 2016 at 16:44:20 , Daniel Margolis ([email-masked]) wrote:

Viktor et al,

Two things:

First, I've taken a stab at a "design reasoning FAQ" document: https://github.com/mrisher/smtp-sts/wiki/FAQ. I think most of the contents of this were already discussed on this list, but hopefully it provides a useful reference. 

Second, I've tried to write up the reasoning you expressed here about "why DNSSEC?" (for lack of a better term) here: https://github.com/mrisher/smtp-sts/wiki/Why-DNSSEC-at-all%3F. (Not that my writing is necessarily more clear than yours, but rather to extract it for handy reference in preparation for hopefully a bit more feedback from other people here.)

Feedback welcome. 

Dan

On Tue, Mar 22, 2016 at 8:58 AM, Daniel Margolis <[email-masked]> wrote:
Hi Viktor, 

Thanks for all the thoughtful comments. I'll respond to what (at a glance) seems to be the most significant three first. 

On Tue, Mar 22, 2016 at 7:35 AM, Viktor Dukhovni <[email-masked]> wrote:
 
This is of course a big topic, but I don't think we should assume that in common deployment web browsers *do* rely upon a user to make some sound human decision about whether to trust a CA. For example, here's the multi-stage process to get Chrome to accept an untrusted certificate: https://docs.oracle.com/cd/E24628_01/install.121/e39876/img/scrnshot_advanced.gif. It's not insignificant to me that Oracle felt the need to document this process for the users with screenshots: we *don't* expect the common browser user to make a personal determination of what CAs to accept, so the "background process" argument is, I think, based on a false premise. 

In truth, we expect browser users to defer to their platform vendors to make sane decisions for them, and we expect the owners of large websites to be able to pick a CA that is widely trusted. With the rise of Let's Encrypt and other free CAs, this doesn't seem overly burdensome. 

1. A (most likely) longer TTL on the STS policy versus the MX record
2. The option for wildcard's or broader patterns than merely a list of valid hosts

This permits the publishing domain to declare that "for the next year, I plan to always host my mail at example.com" without publishing specific MX records that have a 1-year TTL (which of course could be brittle). 

I also dislike the copying of the policy into two places, for the reasons Dave noted here: https://mailarchive.ietf.org/arch/msg/ietf-smtp/nqWeUTe03mxJLltC-wHOsVvfbKo. 

The only real reason to do this is to allow MTAs to cheaply see if the policy has been updated. This seems like a silly thing, since in normal usage they never need to check as long as they have a cached policy, but it's exactly that asymmetry that worries me: Since in normal usage the traffic to the HTTPS endpoint will be minuscule compared to the SMTP traffic to the domain, hosts are likely to dramatically underprovision the former versus the latter. Unfortunately, then, in the case of a validation *failure*, the HTTPS endpoint would (absent some other policy TTL separate, and shorter from, the expiration lifetime) be bombarded with an HTTP GET *once* *per* email. 

So all we're really doing here (in the webpki case) is leveraging DNS as a sort of caching layer. An alternative solution would be what I hinted at above: to simply embed a short "TTL" in the policy. Or to say we don't care and encourage the use of HEAD. 

If we are willing to force the webpki validation method (as you assumed, I think, above) and don't mind making senders handle this short-term TTL logic,  I think we could make the publishing process simpler, with the advantage Dave noted in the above-linked thread (i.e. an easier deployment for customers of hosted mail services). 

I'm somewhat on the fence about this trade-off myself, but I don't think it's unreasonable. Thoughts?

_______________________________________________  
Uta mailing list  
[email-masked]  
https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 1 Apr 2016 22:18:15 +0000

On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote:

> I feel very strongly that policy for SMTP relay should be advertised by
> SMTP and protected by SMTP TLS. Doing anything else creates a much larger
> attack surface on the policy information and is both more complex and less
> secure. The preferred mechanism to sign SMTP relay routing (DNS MX) is
> DNSSEC. I'm open to proposals for alternate mechanisms to sign MX record
> information due to the difficulty of deploying DNSSEC, but such mechanisms
> should not be confused with security policy.

Unfortunately, in MTA-to-MTA SMTP, the receiving SMTP server has
no idea what domain the sending SMTP client wants to deliver mail
to at the time that it advertises its ESMTP extensions in the EHLO
response.

For this (and other related) reasons, in-band SMTP security policy
can only be communicated for the given SMTP server, and not the
recipient domain.

A relay MTA MUST NOT make any conclusions about recipient domain
security based on security policy advertised by a particular MX
host.  An individual MX host cannot advertise security policy
(implicitly) for every single domain it happens to receive mail
for, except for future relaying via that *same* MX host.

To secure SMTP relay traffic to a recipient domain, the routing
needs to be secured by some means.  STS (with sensible modifications)
proposes doing so via an HTTPS well-known URI associated with the
recipient domain.  This is achieved via DNS-based signalling of
the existence of the STS well-known URI, and likely DNS-based
signalling that a cached policy is stale and should be refreshed. 

Your suggestion, in that light, should be interpreted to say that
the STS URI should be used to only secure the routing information
(security for MX records via HTTPS rather than DNSSEC), and that
once the routing information is secured, security policy for the
given relay be in-band via SMTP and modeled on DEEP.

Note that consequently, a domain would be able to downgrade to a
non-TLS provider, by serving a routing-only policy that references
new MX hosts that don't support a new relay-MTA flavour of DEEP.

Also, when a sending relay sees new MX RRs incompatible with a
cached routing policy, it would be able to refresh that policy,
(provided the well-known STS URI is still up and running) and
deliver via the subset of MX hosts that match the refreshed policy.

[ MX hosts that don't match the policy MUST NOT be ignored when
  doing relay loop elimination.  They would have to be treated
  as though connections to them are failing, not as though they
  weren't part of the MX RRset. ]

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 2 Apr 2016 15:46:25 +0100

> On 1 Apr 2016, at 22:48, Chris Newman <[email-masked]> wrote:
> 

I think having reporting in a separate document makes sense.

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 3 Apr 2016 15:53:02 +0200

Alexey,

If we adopt the changes suggested by Viktor (which I described here:
https://github.com/mrisher/smtp-sts/wiki/Why-DNSSEC-at-all%3F), splitting
the reporting information ("rua") into its own DNS record has the advantage
that domains that support DANE today could request reporting without
deploying an STS record. So I think that makes sense (and naturally
suggests reporting should be a separate document as well). I don't think
this should be very contentious.

Regarding Chris and Viktor's discussion:

Chris, just to ensure I understand you properly, you're suggesting that the
MX information (which MX servers are expected) and the policy ("require TLS
with a valid cert") be split, with the former served as described (HTTPS)
and the latter served by the MX itself?

As far as I can see, the implications of this are:

1. As Viktor said, the policy information can only be per-MX. That's not a
problem (DANE works this way), but I'm not sure it's a benefit, either. One
implication is that it could be harder to determine (say, at the time
someone is composing an email) if the recipient domain will support secure
delivery, since the policy is not per-domain (unless the sender refuses to
use some MXs...).

2. It seems like it increases the deployment requirements for inbound mail,
since currently to achieve "always use TLS" as a *receiver* no MTA changes
are necessarily. (This is similar to DANE.) To support the SMTP extension
recipient MTAs would have to advertise it.

It's also not clear to me how this really simplifies things, since it seems
like two components are needed now instead of one: one method to get
routing information (either DNSSEC or HTTPS) and one to get policy
information (something in the SMTP exchange). With either DANE or
STS-as-proposed, there's only a single channel, which I think is a virtue.

Finally, I think the pros and cons of allowing users of hosted mail
providers to downgrade their security are in fact not strongly relevant
here, since in any version in which a domain can update routing information
and the policy information is per-host they can in fact downgrade anyway,
as Viktor said.

So I guess I'm still unsure of the primary motivation for making such a
change. If we have to get routing information securely, why not use
whatever channel to also get policy information? The one is useless without
the other, after all. Requiring a change to participating MTAs may seem to
make it easier (since those of us implementing this probably know the MTA
code better), but it doesn't eliminate the prerequisite for that other
secure channel, does it?

Thanks again,
Dan

On Sat, Apr 2, 2016 at 4:46 PM, Alexey Melnikov <[email-masked]>
wrote:

> > I’m open to proposals to advertise reporting information separately from
> (or together with) SMTP security policy and to provide a mechanism to
> report SMTP security without requiring SMTP security policy to be present.
> Given the interest in reporting for a broad range of SMTP relay security
> features, we might want to split the reporting function into a separate
> document.
>

---

From: Chris Newman <[email-masked]>
Date: Mon, 04 Apr 2016 01:27:37 -0300

On April 1, 2016 at 19:18:31 , Viktor Dukhovni ([email-masked]) wrote:

Unfortunately, in MTA-to-MTA SMTP, the receiving SMTP server has 
no idea what domain the sending SMTP client wants to deliver mail 
to at the time that it advertises its ESMTP extensions in the EHLO 
response. 
This correctly identifies a key difference between SMTP relay and SMTP submission. I had missed this, thank you for raising it!

For SMTP submission, there’s an early-indication of domain ownership from the mandatory user authentication (multi-domain hosting services tend to use email address as user name to get this benefit). For SMTP relay we have no mechanism to indicate the intended domain so to handle the case of a multi-domain hosting service that offers different policies for different domains we’d need to add a way to communicate intended domain early. This can be done with an SMTP verb (adding a round trip) or by using TLS ALPN or something similar (no new round trip).

For this (and other related) reasons, in-band SMTP security policy 
can only be communicated for the given SMTP server, and not the 
recipient domain. 
I’m not convinced this is true. I’d like to hear those other reasons.

If the MX-from-DNS isn’t trusted, then no policy can be trusted. But STS-from-DNS has the same issue.

Mostly yes. I’d also want to consider an optimization to skip the HTTPS step for self-hosted domains just to reduce overall new traffic.

Note that consequently, a domain would be able to downgrade to a 
non-TLS provider, by serving a routing-only policy that references 
new MX hosts that don't support a new relay-MTA flavour of DEEP. 
We decide in the specification whether the policy attaches to the domain or the SMTP hostname. This is a design choice.

This all follows from a conclusion I don’t agree with.

Once policy is latched for a domain, any SMTP relay not complying with the policy is a failure. We’ll want to make sure we get the 4xx vs. 5xx rules right in the spec for this.

		- Chris

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 4 Apr 2016 10:42:07 +0200

Thanks for the clarification.

Sounds like a feature to me. Having MUAs do insecure DNS lookups (which is
> what they’d probably do) and make misleading assertions about relay
> security (which couldn’t be made even if DNSSEC/HTTPS was employed to trust
> the STS information, given that forwarding is in the infrastructure and all
> that). If you want to have MUAs make assertions, you’re moving in the
> direction of the SMTP extension draft, and as Victor pointed out, the
> infrastructure is going to ignore even those assertions under some
> circumstances if that were to deploy.

I am (perhaps parochially) thinking mostly about webmail systems where the
MUA and the sending MTA are mostly the same piece of infrastructure. So my
real goal is for the MTA to be able to tell the MUA at compose time that it
has a policy for the recipient domain and can guarantee certain behavior.

In this context, I think having policies be per-domain is important, but as
you note, you could have a policy semantic which allows a single MX to
communicate a domain-wide policy even with an in-band channel.

> Mostly yes. I’d also want to consider an optimization to skip the HTTPS
> step for self-hosted domains just to reduce overall new traffic.

To clarify a bit the individual steps needed, then, it seems like you're
proposing that given the following stages:

1. Routing information: What MX hostnames are expected
2. Authenticating the MX: Determining that the server TLS cert matches
3. Policy: Ensuring the minimum level of transport-layer encryption

You propose to put #1 in either DNSSEC or HTTPS (with an optimization to
use in-channel in place of HTTPS if the MX domain matches the email domain)
and #2 and #3 in the SMTP exchange?

But this doesn't necessarily eliminate the extra DNS or HTTPS lookup (at
least in the case where the MX domain does not match the email domain),
right? You still need to get the routing information somehow, and we're
still trying to make this viable for domains that can't yet deploy DNSSEC.
So in that light, you're proposing that all domains would need at least the
SMTP in-band exchange and that some domains would also need step #1 to be
done over HTTPS--meaning that sending domains would have to still support
both options, right?

I can see the appeal of doing much of this in-band given that it's
consistent with what DEEP proposes, but I'm still concerned that if we need
*also* support out-of-band, we're just increasing complexity. What do you
think?

Dan

On Mon, Apr 4, 2016 at 6:27 AM, Chris Newman <[email-masked]>
wrote:

> This correctly identifies a key difference between SMTP relay and SMTP
> submission. I had missed this, thank you for raising it!
>
> For SMTP submission, there’s an early-indication of domain ownership from
> the mandatory user authentication (multi-domain hosting services tend to
> use email address as user name to get this benefit). For SMTP relay we have
> no mechanism to indicate the intended domain so to handle the case of a
> multi-domain hosting service that offers different policies for different
> domains we’d need to add a way to communicate intended domain early. This
> can be done with an SMTP verb (adding a round trip) or by using TLS ALPN or
> something similar (no new round trip).
>
> Mostly yes. I’d also want to consider an optimization to skip the HTTPS
> step for self-hosted domains just to reduce overall new traffic.
>
> We decide in the specification whether the policy attaches to the domain
> or the SMTP hostname. This is a design choice.
>
> Once policy is latched for a domain, any SMTP relay not complying with the
> policy is a failure. We’ll want to make sure we get the 4xx vs. 5xx rules
> right in the spec for this.
> - Chris
>
>

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 4 Apr 2016 11:14:43 +0100

On 01/04/16 23:18, Viktor Dukhovni wrote:
>> SMTP and protected by SMTP TLS.

> to at the time that it advertises its ESMTP extensions in the EHLO

Why must it be done then?  Why not at RCPT TO time, via some suitable
response?

> in-band SMTP security policy

Why should a response from one MX not be authoritative for
security policy?  It is taken to be for a message acceptance, or message
hard-rejection.

-- 
Cheers,
  Jeremy

---

From: Jim Fenton <[email-masked]>
Date: Mon, 4 Apr 2016 05:01:14 -0700

> Why must it be done then?  Why not at RCPT TO time, via some suitable

It's not even possible at RCPT TO time, for example if the message is
being forwarded.

-Jim

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 4 Apr 2016 13:45:24 +0100

> It's not even possible at RCPT TO time, for example if the message is

Has been forwarded, and the RCPT is post-forwarding?  Rules for the
current recipient apply.

Is about to be forwarded, and the RCPT is pre-forwarding?  Rules
for the current recipient apply.

I don't see your point; please elucidate?
-- 
Cheers,
  Jeremy

---

From: Jim Fenton <[email-masked]>
Date: Mon, 4 Apr 2016 05:54:49 -0700

> can only be communicated for the given SMTP server, and not the

I'm pointing out one of the other related reasons that isn't addressed
by doing the response at RCPT TO time.

-Jim

---

From: Chris Newman <[email-masked]>
Date: Mon, 04 Apr 2016 10:43:06 -0300

On April 4, 2016 at 2:42:15 , Daniel Margolis ([email-masked]) wrote:
Thanks for the clarification. 

Sounds like a feature to me. Having MUAs do insecure DNS lookups (which is what they’d probably do) and make misleading assertions about relay security (which couldn’t be made even if DNSSEC/HTTPS was employed to trust the STS information, given that forwarding is in the infrastructure and all that). If you want to have MUAs make assertions, you’re moving in the direction of the SMTP extension draft, and as Victor pointed out, the infrastructure is going to ignore even those assertions under some circumstances if that were to deploy.
I am (perhaps parochially) thinking mostly about webmail systems where the MUA and the sending MTA are mostly the same piece of infrastructure. So my real goal is for the MTA to be able to tell the MUA at compose time that it has a policy for the recipient domain and can guarantee certain behavior. 
Do you really think an end-user can understand what it means if the MTA will transport encrypt the next hop of mail relay but can say nothing about relay hops after that or how the mail is handled by either service provider? Perhaps I’m missing the motivation for doing this, can you explain why this is useful?

In this context, I think having policies be per-domain is important, but as you note, you could have a policy semantic which allows a single MX to communicate a domain-wide policy even with an in-band channel. 

To clarify a bit the individual steps needed, then, it seems like you're proposing that given the following stages:

You propose to put #1 in either DNSSEC or HTTPS (with an optimization to use in-channel in place of HTTPS if the MX domain matches the email domain) and #2 and #3 in the SMTP exchange? 
Basically right.

But this doesn't necessarily eliminate the extra DNS or HTTPS lookup (at least in the case where the MX domain does not match the email domain), right? You still need to get the routing information somehow, and we're still trying to make this viable for domains that can't yet deploy DNSSEC. So in that light, you're proposing that all domains would need at least the SMTP in-band exchange and that some domains would also need step #1 to be done over HTTPS--meaning that sending domains would have to still support both options, right? 
Presuming there is WG rough consensus that use of HTTPS meets the cost/benefit cutoff when compared to DNSSEC, then yes that is correct.

I can see the appeal of doing much of this in-band given that it's consistent with what DEEP proposes, but I'm still concerned that if we need also support out-of-band, we're just increasing complexity. What do you think?
As long as the only out-of-band is verification of routing information and not policy, then I don’t see it as increasing complexity. Indeed it’s a somewhat more conservative approach to architectural cost (trying to minimize use of extra packets and protocols when performing the core SMTP relay operation).

But I’ll admit I have some experiential bias in that I’ve seen few DNS additions deploy effectively, and I’ve seen a bunch of SMTP extensions deploy effectively.

		- Chris

On Mon, Apr 4, 2016 at 6:27 AM, Chris Newman <[email-masked]> wrote:
On April 1, 2016 at 19:18:31 , Viktor Dukhovni ([email-masked]) wrote:

---

From: Mark Risher <[email-masked]>
Date: Mon, 4 Apr 2016 07:03:19 -0700

>> Do you really think an end-user can understand what it means if the MTA
will transport encrypt the next hop of mail relay but can say nothing about
relay hops after that or how the mail is handled by either service
provider? Perhaps I’m missing the motivation for doing this, can you
explain why this is useful?

The intent of this proposal itself is to resist downgrades and frontage
mis-routing of messages. I agree users will not understand this, and any
effort for communicating encryption status covering the entirety of the
journey from user to user would require additional work beyond STS (such as
DEEP, REQUIRETLS, and other proposals).

>> I’ve seen few DNS additions deploy effectively, and I’ve seen a bunch of
SMTP extensions deploy effectively.

Can you share examples of each? We chose DNS over the new verb for ease of
deployment; one example is the rates of adoption of SPF (which only
requires DNS updates) versus DKIM.

Thanks for the feedback. Looking forward to the face to face in a few hours,
/m

---
Mark Risher | Google | 650-253-3123
On Apr 4, 2016 10:44 AM, "Chris Newman" <[email-masked]> wrote:

> Do you really think an end-user can understand what it means if the MTA
> will transport encrypt the next hop of mail relay but can say nothing about
> relay hops after that or how the mail is handled by either service
> provider? Perhaps I’m missing the motivation for doing this, can you
> explain why this is useful?
>
> In this context, I think having policies be per-domain is important, but
> as you note, you could have a policy semantic which allows a single MX to
> Presuming there is WG rough consensus that use of HTTPS meets the
> cost/benefit cutoff when compared to DNSSEC, then yes that is correct.
>
> As long as the only out-of-band is verification of routing information and
> not policy, then I don’t see it as increasing complexity. Indeed it’s a
> somewhat more conservative approach to architectural cost (trying to
> minimize use of extra packets and protocols when performing the core SMTP
> relay operation).
>
> But I’ll admit I have some experiential bias in that I’ve seen few DNS
> additions deploy effectively, and I’ve seen a bunch of SMTP extensions
> deploy effectively.
> - Chris
>
>> Once policy is latched for a domain, any SMTP relay not complying with
>> the policy is a failure. We’ll want to make sure we get the 4xx vs. 5xx
>> rules right in the spec for this.
>>

---

From: Mark Risher <[email-masked]>
Date: Mon, 4 Apr 2016 07:05:36 -0700

(Sorry, "frontage" was a Swype typo. I meant "deliberate")

The intent of this proposal itself is to resist downgrades and *deliberate*
mis-routing of messages

/m

---
Mark Risher | Google | 650-253-3123
On Apr 4, 2016 11:03 AM, "Mark Risher" <[email-masked]> wrote:

> >> I’ve seen few DNS additions deploy effectively, and I’ve seen a bunch
> of SMTP extensions deploy effectively.
>
>> Sounds like a feature to me. Having MUAs do insecure DNS lookups (which
>>> is what they’d probably do) and make misleading assertions about relay
>> I am (perhaps parochially) thinking mostly about webmail systems where
>> the MUA and the sending MTA are mostly the same piece of infrastructure. So
>> my real goal is for the MTA to be able to tell the MUA at compose time that
>> it has a policy for the recipient domain and can guarantee certain
>> behavior.
>>
>> *also* support out-of-band, we're just increasing complexity. What do
>> you think?
>>
>> As long as the only out-of-band is verification of routing information
>> and not policy, then I don’t see it as increasing complexity. Indeed it’s a
>>> For SMTP submission, there’s an early-indication of domain ownership
>>> from the mandatory user authentication (multi-domain hosting services tend
>>> to use email address as user name to get this benefit). For SMTP relay we
>>> have no mechanism to indicate the intended domain so to handle the case of
>>> a multi-domain hosting service that offers different policies for different

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 4 Apr 2016 16:59:33 +0200

> additions deploy effectively, and I’ve seen a bunch of SMTP extensions

Hmm, like what?

In terms of the extra round-trips or protocols, I think:

1. The HTTPS request is probably unavoidable here (since if we assume we
can require DNSSEC in all cases, why wouldn't we just use DANE?), but
fortunately it's rare (once per recipient domain per policy lifetime). So I
think the round trip cost here is minimal, but the infrastructure cost is
worth noting, as you say (even if the HTTPS GET isn't in the sending path;
it can of course be done by some offline process that populates the policy
cache asynchronously.)
2. If we adopt Viktor's suggested edits, there's only a single additional
DNS lookup in the sending path (to check the policy nonce).

I don't think #2 is a huge problem; after all, DMARC, DKIM, and SPF each
result in a DNS lookup per *inbound* message (and many servers also do
rDNS). These should be cheap and highly cache-able, so if we're counting
bytes, I would say they're probably cheaper than an extra round trip on the
SMTP protocol itself (if it happens on every message).

That said, I also don't think that an extra round trip on the SMTP protocol
is a huge deal, so I don't think this is the deciding factor either way. At
heart, the question to me is whether a) it's more elegant to built the
policy stuff into the SMTP exchange and b) whether it's more deployable to
build these changes into the MTA or loosely coupled infrastructure.

My concern remains that we would end up having to *both* stand up an HTTPS
endpoint (or client, for senders) for the routing information *and* change
the MTA to serve and retrieve policy information. That said, I have only
one MTA I'd have to change, and I can probably manage either option; I'm
curious to hear from you and from people like Viktor about what options
they would consider easier to implement in MTAs they work on.

Dan

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 4 Apr 2016 17:24:59 +0200

Hi,

> On 19 Mar 2016, at 11:20, Mark Risher <[email-masked]> wrote:
> 
> Dear UTA:
> We have just submitted a proposal entitled SMTP Strict Transport Security, which details a mechanism for protecting MTA-to-MTA email traffic against TLS downgrade attacks and interception.
> 
> The initial draft is at https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/ and we hope to discuss this at the Buenos Aires meeting next month. While we have deployed a prototype/reference implementation among the authors, we are very open to feedback and suggestions from the broader group and look forward to your input.

As already mentioned in two previous threads to this mailing list and a GitHub issue: I see a big problem with deployment of the webpki authentication part outside of big hosting environments. But I really do like the idea of getting feedback from/to MTAs. Can you guys think of a way we can get in-band reporting within e.g. SMTP (an extension)?

EFF is currently picking up STARTTLS-Everywhere again (mind: it's been idle since before Let's Encrypt, a lot of new proposals like this one for mail came out - so the project, scope and even it's name are subject to change in the near future). One idea I had was to provide anonymised log information regarding TLS-failures / MITM attempts to distributed monitoring servers and the receiving party. If there were a more general document for error-reporting (as some suggested) - we could maybe make use of that as well. If it requires every small mail-OP to set up a webserver on the same machine, it's unlikely that we can push for that, and adoption number might turn out low.

As for authentication/TOFU: I see no better proposal than TACK around. HPKP was an utter failure [0] and I fear that, for the very same reasons, SMTP-STS might not see a lot of deployment nor use in single-domain-setups. And there're quite a few around. While it's important to secure the majority of mail traffic between large providers - they're already doing well - we should not forget that there's still a lot of self-hosted MXs on the Internet.  I could imagine an updated (e.g. using EdDSA over ECDSA etc) version of TACK fitted to SMTP. One of the original authors might be interested in working on that he told me earlier this year, unfortunately I did not have any time to pursue this idea further.

Thanks,
Aaron

[0] http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 4 Apr 2016 18:01:43 +0200

* Aaron Zauner <[email-masked]> [04/04/2016 17:24:37] wrote:
> As for authentication/TOFU: I see no better proposal than TACK
> around. HPKP was an utter failure [0] and I fear that, for the
> very same reasons, SMTP-STS might not see a lot of deployment nor
> use in single-domain-setups. And there're quite a few around.
> While it's important to secure the majority of mail traffic
> between large providers - they're already doing well - we should
> not forget that there's still a lot of self-hosted MXs on the
> Internet.  I could imagine an updated (e.g. using EdDSA over ECDSA
> etc) version of TACK fitted to SMTP. One of the original authors
> might be interested in working on that he told me earlier this
> year, unfortunately I did not have any time to pursue this idea
> further.

Could work like that: the MTA announces an additional extension
(e.g. NOSTRIP), once the other side sees that, it requires that the
MTA support STARTTLS and the TLS TACK extension [0]. An in-band
upgrade
is performed and TACK/policy information retrieved and stored. These
pins can be used on follow-up connections, and the way TACK handles
key-rollover it's very unlikely that operators have to take a lot of
care regarding their pins (this is why HPKP fails and isn't widely
deployed). For implementors this doesn't change much either; as with
the original SMTP-STS proposal the MTA needs to be aware of policy
information. This information is now provided by TACK. TACK is a TLS
extension, so functionality only needs to be provided from the
library
(TLS stack - there's already TACK code available for e.g. OpenSSL).

The beauty really is TACK's pin lifecycle and rollover. It being an
extension, it's also rather easy to deploy (eg. an admin would just
need to upgrade their system TLS stack to a current release), and
deployment is usually the biggest barrier, especially in
small/single-domain setups as we've seen from our scans.

Reporting could be handeled entirely seperate or as a SHOULD.

Aaron

[0] http://tack.io/draft.html

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 4 Apr 2016 19:56:27 +0200

It's been a long time since I looked at TACK, but if I remember right,
doesn't this only help with the CA/trust issue?

To me the big question with STS as is is how to exchange policy/routing
information, which I believe is mostly unrelated to TACK, right? In fact
STS is quite agnostic about how to determine if you trust the HTTPS
certificate presented--I think TACK is potentially applicable there (as is
Cert Transparency, though we also considered CT as a future option for
publishing or discovering policy presence).

Or am I totally misremembering what TACK does?

Dan

---

From: Chris Newman <[email-masked]>
Date: Mon, 04 Apr 2016 17:24:27 -0300

>> Do you really think an end-user can understand what it means if the MTA will transport encrypt the next hop of mail relay but can say nothing about relay hops after that or how the mail is handled…

The intent of this proposal itself is to resist downgrades and frontage mis-routing of messages. I agree users will not understand this, and any effort for communicating encryption status covering the entirety of the journey from user to user would require additional work beyond STS (such as DEEP, REQUIRETLS, and other proposals).

I guess I mis-stated my question. Here’s another attempt: Why is it useful for the MUA to know if a domain has STS policy at mail composition time?

>> I’ve seen few DNS additions deploy effectively, and I’ve seen a bunch of SMTP extensions deploy effectively.

Can you share examples of each? We chose DNS over the new verb for ease of deployment; one example is the rates of adoption of SPF (which only requires DNS updates) versus DKIM.

For standards, I’ve seen SMTP AUTH, SMTP CHUNKING, SMTP BINARYMIME, SMTP STARTTLS deploy rather successfully (although the latter has issues we’ve all seen). I understand SMTP X-CLIENT (for a non-standard extension) is quite common now. I’m not sure how successful SPF is in practice — our server implements it but I don’t hear much customer traffic about it.

		- Chris

---

- Chris

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 4 Apr 2016 22:40:43 +0200

Hi Daniel,

> On 04 Apr 2016, at 19:56, Daniel Margolis <[email-masked]> wrote:
> 
> It's been a long time since I looked at TACK, but if I remember right, doesn't this only help with the CA/trust issue?
> 
> To me the big question with STS as is is how to exchange policy/routing information, which I believe is mostly unrelated to TACK, right? In fact STS is quite agnostic about how to determine if you trust the HTTPS certificate presented--I think TACK is potentially applicable there (as is Cert Transparency, though we also considered CT as a future option for publishing or discovering policy presence).
> 

TACK is a pinning proposal primarily focused on HTTPS (but also considers other application layer protocols) client/server interaction. It's also almost three years old, uses old signature schemes et cetera. - It's not what I'd want to use right away. It's neither a standard nor has it been updated since it's inception back then. It needs considerable love, but would also work for server<->server transmissions. My thinking in the past revolved around an SMTP extension that indicates (updated, SMTP-)TACK use and may, additionally, contain arbitrary security information (similar to your policies) once authenticated.

The main properties that make building on TACK interesting for me are:
- Lifecycle-management / Key-rollover (no accidental lock-out as you may get with HPKP)
- No need for CA-signed certificates (fits well into the SMTPS domain)
- Ease of deployment
- Ease of maintenance (a good, automated implementation may do everything on it's own)

Given there're now multiple proposals for mail security, I think it would not be very constructive to write/publish a competing I-D for this.

Hmm. I haven't given any thought on how to best incorporate that into your STS proposal. Could you use it instead of the webpki authentication method and distribute TACK fingerprints via DNS?

w.r.t. Certificate Transparency: how do you see CT working for SMTP mail certificates? It's currently EV-only and more than 60% of MTAs are unsigned. Do you mean building on technology/hash-trees like CT?

Thanks for the feedback,
Aaron

---

From: Mark Risher <[email-masked]>
Date: Mon, 4 Apr 2016 18:49:54 -0300

>> EFF is currently picking up STARTTLS-Everywhere again (mind: it's been
idle since before Let's Encrypt, a lot of new proposals like this one for
mail came out - so the project, scope and even it's name are subject to
change in the near future).

This is cool. How far along is it? One issue we ran into with
STARTTLS-Everywhere was where it would be hosted.

>> One idea I had was to provide anonymised log information regarding
TLS-failures / MITM attempts to distributed monitoring servers and the
receiving party. If there were a more general document for error-reporting
(as some suggested) - we could maybe make use of that as well. If it
requires every small mail-OP to set up a webserver on the same machine,
it's unlikely that we can push for that, and adoption number might turn out
low.

This is similar to what we were discussing with Certificate Transparency,
i.e. some sort of append-only log for policies published and policies
discovered.

>> w.r.t. Certificate Transparency: how do you see CT working for SMTP mail
certificates? It's currently EV-only and more than 60% of MTAs are
unsigned. Do you mean building on technology/hash-trees like CT?

More like the latter. We've been discussing with the CT folks how it could
be extended for DV certs, what extensions would be needed, and whether to
allow self-signed. We moved that to "Future Work" so as not to derail the
short-term, and because someone recommended against writing a draft that
depends on another draft, but it remains an interesting alternative
solution to the cryptographically-secure distributed hashtable problem.

/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

On Mon, Apr 4, 2016 at 5:40 PM, Aaron Zauner <[email-masked]> wrote:

> TACK is a pinning proposal primarily focused on HTTPS (but also considers
> other application layer protocols) client/server interaction. It's also
> almost three years old, uses old signature schemes et cetera. - It's not
> what I'd want to use right away. It's neither a standard nor has it been
> updated since it's inception back then. It needs considerable love, but
> would also work for server<->server transmissions. My thinking in the past
> revolved around an SMTP extension that indicates (updated, SMTP-)TACK use
> and may, additionally, contain arbitrary security information (similar to
> your policies) once authenticated.
>
> Given there're now multiple proposals for mail security, I think it would
> not be very constructive to write/publish a competing I-D for this.
>
> Hmm. I haven't given any thought on how to best incorporate that into your
> STS proposal. Could you use it instead of the webpki authentication method
> and distribute TACK fingerprints via DNS?
>
> w.r.t. Certificate Transparency: how do you see CT working for SMTP mail
> certificates? It's currently EV-only and more than 60% of MTAs are
> unsigned. Do you mean building on technology/hash-trees like CT?
>
> Thanks for the feedback,
> Aaron
>

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 5 Apr 2016 00:25:21 +0200

Hey Mark,

> STARTTLS-Everywhere was where it would be hosted.

We're just starting (April). We've had a few video-calls that were a
mix of organizing and hackathon fixing trivial open issues, PRs and
reading up/documenting on what's changed TLS-wise in mail daemon
software over the years. I'll start working considerably more on the
project this month, hopefully we'll have more to show in the near
future.

> i.e. some sort of append-only log for policies published and

I was actually also thinking of distributed append-only logs. I'm
open to collaborate on that, would be very useful to us. git has
been suggested as a (maybe temporary) distribution platform, but
I'd prefer a solid design with distributed append-only logs.

> solution to the cryptographically-secure distributed hashtable

Yes, very interesting. Please keep me in the loop if that's OK with
you guys, might also be something that should (for now) be discussed
off-list?

The STS suggested error-reporting feature is something that makes
sense as a seperate draft, as others could use it for different/
augmented data as well if spec'd in the right way. I'm open to
collaborate and will have (finally!) more time for all that email
related stuff now.

Thanks,
Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 4 Apr 2016 23:35:18 +0000

On Mon, Apr 04, 2016 at 05:24:59PM +0200, Aaron Zauner wrote:

> As for authentication/TOFU: I see no better proposal than TACK around.

I was briefly interested in TACK for SMTP before I started work on
DANE 2 years ago, but gave up after realizing that TACK cannot
protect the MX records.  Without protecting the MX records you get
no active attack protection.

STS proposes to validate MX records (MX host patterns) via HTTPS,
at which point one can consider various mechanisms for authenticating
the credentials of the validated MX hosts.  

Are you proposing TACK without WebPKI for the STS HTTPS URL or
WebPKI + TACK pins?  Note also that secondary MX hosts are rarely
used so senders will often lack prior contact with these, but an
attacker can block access to the primary MX, at which point you
get cold-start with a secondary MX (reducing TACK to WebPKI).

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 5 Apr 2016 02:06:37 +0200

Hi,

> On 05 Apr 2016, at 01:44, Binu Ramakrishnan <[email-masked]> wrote:
> 
> Aaron,
> 
> Whether we use Git to distribute policies or use CT append logs, we still need to pull policies using HTTPS (or something similar). From that perspective, STS's webpki model is not different. If you are talking about TACK, based on my understanding it is not suitable for SMTP MTAs. The fundamental issue is that a secure in-band policy distribution is difficult in such environments because of MX indirection.

Could you go a bit into what you consider "mx indirection" and where you see problems there? e.g. a specific problem statement. I'm not sure I follow.

> This may not even a differentiator.

I don't follow?

> How the trust is establised without DNSSEC or PKIX?

It's a TOFU model. So you establish trust on first use / flight. From thereon you have pins. See above w.r.t. roll-over.

> 
> > - Ease of deployment
> I would have agreed with "ease of deployment" if openssl changes serve as a drop-in replacement that magically enforce policy, but that is not the case. Just updating openssl alone is not going enable this feature. In addition to TLS library upgrade, we need to make changes to MTA to make it work with STARTTLS flow. On top of that TACK draft also mentions about fetching pins from a 3rd party, even that also may require HTTPS.

Yes, but the same is very much true with STS as well, or did I misunderstand something entirely? Ideally it might be as easy as an `sudo apt-get upgrade  openssl exim -y`. If the upstream distribution packages well and provides proper tooling, this can be *very* smooth. If there's zero tooling it's a burden for admins, but that's the same issue with any proposal of that kind.

TACK only mentions as a note that pins _could_ be also fetched from servers. This is probably not something I'd incorporate. This is entirely optional and I'm not sure it's implemented anywhere.  In the UTA meeting today something similar was mentioned for pre-fetching policies with SMTP-STS: cronjobs and fetch from HTTPS.

> STS provides lot of flexibility with deployment; for instance, we can deploy separate outbound MTAs for valid STS domains without even touching outbound MTAs at all (STS check happens before queuing it to outbound MTAs).

I already mentioned that small-mail shops probably won't go through all of the difficulties of deploying a proper SMTP-STS setup. Added to that, most dont have DNSSEC.

>HTTPS is current medium of policy distribution, but it can be replaced with anything better in the future.

Right, so why not ponder over better solutions? Someone might come up with something good after all!

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 5 Apr 2016 02:11:00 +0200

Hi Viktor,

> On 05 Apr 2016, at 01:35, Viktor Dukhovni <[email-masked]> wrote:
> 

But if I use a TOFU model like TACK then if an attack on any MX record I try to resolve happens and I get redirected I end up with a TLS alert instead of a classic MITM because the attacker does not control my keys. DOS can happen in any case.

> get cold-start with a secondary MX (reducing TACK to WebPKI).

WebPKI + TACK essentially (plus an SMTP extension). And again; the TACK draft would have to be updated and retrofitted.

Thanks,
Aaron

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 5 Apr 2016 11:16:06 +0200

On Tue, Apr 5, 2016 at 2:06 AM, Aaron Zauner <[email-masked]> wrote:

> > Whether we use Git to distribute policies or use CT append logs, we
> still need to pull policies using HTTPS (or something similar). From that
> perspective, STS's webpki model is not different. If you are talking about
> TACK, based on my understanding it is not suitable for SMTP MTAs. The
> fundamental issue is that a secure in-band policy distribution is difficult
> in such environments because of MX indirection.
>
> Could you go a bit into what you consider "mx indirection" and where you
> see problems there? e.g. a specific problem statement. I'm not sure I
> follow.
>

To slightly paraphrase Binu's reply, I think one of the (if not the) key
challenges with SMTP STS is allowing the email domain to specify a routing
policy (and maybe also a security policy, as discussed with Chris
up-thread) regardless of whether it's also the email hosting domain.

I'm not clear on how TACK can be used here.

One idea on how to use a CT-style append-only log is that you could use the
log itself as the source of policies, and the log server can sort of do
whatever it wants to for the log inclusion criteria (e.g. with CT the
inclusion criteria are "must be an EV cert", but that's very arbitrary; a
different log could include any policy served over validated HTTPS for any
domain, or you could have a log that includes policies seen by EFF's
outbound MTA--since the log is observable and append-only, it still feels a
lot safer to me to do this than to use Github for policy distribution).

> It's a TOFU model. So you establish trust on first use / flight. From
> thereon you have pins. See above w.r.t. roll-over.
>
> >
> > > - Ease of deployment
> > I would have agreed with "ease of deployment" if openssl changes serve
> as a drop-in replacement that magically enforce policy, but that is not the
> case. Just updating openssl alone is not going enable this feature. In
> addition to TLS library upgrade, we need to make changes to MTA to make it
> work with STARTTLS flow. On top of that TACK draft also mentions about
> fetching pins from a 3rd party, even that also may require HTTPS.
>
> Yes, but the same is very much true with STS as well, or did I
> misunderstand something entirely? Ideally it might be as easy as an `sudo
> apt-get upgrade  openssl exim -y`. If the upstream distribution packages
> well and provides proper tooling, this can be *very* smooth. If there's
> zero tooling it's a burden for admins, but that's the same issue with any
> proposal of that kind.
>
> TACK only mentions as a note that pins _could_ be also fetched from
> servers. This is probably not something I'd incorporate. This is entirely
> optional and I'm not sure it's implemented anywhere.  In the UTA meeting
> today something similar was mentioned for pre-fetching policies with
> SMTP-STS: cronjobs and fetch from HTTPS.
>

What I meant about a cron that fetches policies was that any given server
can fetch policies directly from the policy domain asynchronously from the
send path--I was merely answering the question of whether it's a big
problem to have an MTA that speaks HTTPS. (My point being that you don't
need that; you can have an MTA with a cron job that runs the moral
equivalent of "for line in `grep sts_policy_missing postfix.log`; do
curl_policy $line; done".)

I do separately think it makes sense to pre-ship common bundles, but I'm
not sure that we should focus on that as the main method of policy
distribution. In particular, today, if I'm a Debian user, Debian is already
part of my trusted computing base, so having a Debian policy bundle doesn't
really scare me. But if some upstream github repo were the *only* source of
truth for policies, it seems a bit scarier to me--a much more brittle
distribution mechanism, and somewhat overly centarlized.

> > STS provides lot of flexibility with deployment; for instance, we can
> deploy separate outbound MTAs for valid STS domains without even touching
> outbound MTAs at all (STS check happens before queuing it to outbound MTAs).
>
> I already mentioned that small-mail shops probably won't go through all of
> the difficulties of deploying a proper SMTP-STS setup. Added to that, most
> dont have DNSSEC.
>

I'm not sure about this intuition, though I only have a counter intuition.
For the hosted scenario, a provider could simply set up an HTTPS endpoint
for their client domains, use SNI, and fetch SSL certs for the client as
part of a hosting package. For the self-hosted scenario, is it considerably
harder? I'm not sure, but given how easy it is to set up a personal HTTPS
endpoint with Let's Encrypt, I don't really see why. Am I far off base?

> something good after all!

Agreed!

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 6 Apr 2016 00:26:31 +0200

Hi,

> On 05 Apr 2016, at 03:13, Binu Ramakrishnan <[email-masked]> wrote:
> 1. TACK TOFU model promotes trusting self-signed certificates. It is similar to SSH and it is less trusted than PKIX.

You can use TACK with self-signed or with CA signed certificates. I'm not sure I agree that there is less trust than with just PKIX.

> 2. What is the process followed when you change your MX from abc.com to xyz.com ? Basically explain how to differentiate a legitimate MX redirection with an attacker diverting the traffic, especially in short notice?

A TACK pin is bound to a hostname and TACK signing key (TSK). While ordinarily you'd probably just publish a new TACK for a new hostname it's possible to have multiple hostnames signed by the same TSK and this could be used to manage hostname-rollover if I'm not mistaken (the original draft does of course not consider this scenario).

You do have a similar problem with STS: You'd need DNSSEC to ensure that an attacker can't divert traffic on the first connection attempt. You already mention this in the "Future Work" section of your document under "certificate pinning" (I think it's supposed to say "public key pinning"). One of the main issues currently is that most MTA-MTA traffic is over connections established without a CA signed certificate. You're now requiring them to use one anyhow, just in a different place.

> 3. (repeating) Whether you use Git or append logs or "pins" from 3rd party, you still need to fetch policies from a remote location possibly over HTTPS.

Sorry I think that wasn't clear: my discussion on git/CT/reporting and interest in your CT-related work had nothing to do with TACK or authentication.

> Why to use TOFU, when there are better options? STS directly fetches policies over HTTPS and the trust is established over PKIX

Again; you may use PKIX with TACK.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 6 Apr 2016 00:36:14 +0200

Hi,

> On 05 Apr 2016, at 11:16, Daniel Margolis <[email-masked]> wrote:
> To slightly paraphrase Binu's reply, I think one of the (if not the) key challenges with SMTP STS is allowing the email domain to specify a routing policy (and maybe also a security policy, as discussed with Chris up-thread) regardless of whether it's also the email hosting domain.
> 

TACK isn't the right place to distribute information from. It's a TLS extension, it should be terse. My original idea was to use a SMTP extension along with required TACK-like authentication. The extension could send arbitrary information. As mentioned earlier, I'm not sure what the best way is to integrate this with STS.

> 
> One idea on how to use a CT-style append-only log is that you could use the log itself as the source of policies, and the log server can sort of do whatever it wants to for the log inclusion criteria (e.g. with CT the inclusion criteria are "must be an EV cert", but that's very arbitrary; a different log could include any policy served over validated HTTPS for any domain, or you could have a log that includes policies seen by EFF's outbound MTA--since the log is observable and append-only, it still feels a lot safer to me to do this than to use Github for policy distribution).

Yes, I totally agree there. git was brought up in a discussion, we're not currently implementing anything in that direction. When we come back to this we'll see what's available from UTA etc. for us to use.

> I'm not sure about this intuition, though I only have a counter intuition. For the hosted scenario, a provider could simply set up an HTTPS endpoint for their client domains, use SNI, and fetch SSL certs for the client as part of a hosting package. For the self-hosted scenario, is it considerably harder? I'm not sure, but given how easy it is to set up a personal HTTPS endpoint with Let's Encrypt, I don't really see why. Am I far off base?

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.

Thanks,
Aaron

---

From: Binu Ramakrishnan <[email-masked]>
Date: Wed, 6 Apr 2016 01:42:08 +0000 (UTC)

Aaron, I think the important point here is when you say TOFU (Trust On First Use) - that means no trust anchor is involved at least during the initial step. In the case of STS, the policy is served over webpki. In fact sender can possibly skip DNS indicator flag and directly fetch policies from recipient's well known HTTPS endpoint. Note that DNS STS record is a convenience, not a must to have component.
> One of the main issues currently is that most MTA-MTA traffic is over connections established without a CA signed certificate. You're now requiring them to use one anyhow, just in a different place.Using untrusted cert is not a feature, but an important security issue that needs to be fixed either through DANE or PKIX.
thanks,-binu
      From: Aaron Zauner <[email-masked]>
 To: Binu Ramakrishnan <[email-masked]> 
Cc: Mark Risher <[email-masked]>; "[email-masked]" <[email-masked]>; Orit Levin (CELA) <[email-masked]>; Daniel Margolis <[email-masked]>
 Sent: Tuesday, 5 April 2016 3:26 PM
 Subject: Re: [Uta] New proposal: SMTP Strict Transport Security
   
Hi,

Aaron

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 6 Apr 2016 10:52:14 +0200

On Wed, Apr 6, 2016 at 12:36 AM, Aaron Zauner <[email-masked]> wrote:

> TACK isn't the right place to distribute information from. It's a TLS
> extension, it should be terse. My original idea was to use a SMTP extension
> along with required TACK-like authentication. The extension could send
> arbitrary information. As mentioned earlier, I'm not sure what the best way
> is to integrate this with STS.
>

Ah, I misunderstood. You weren't talking about policy bootstrapping--you
were talking about how to do cert auth. But even if we'd prefer TACK (which
isn't unreasonable by itself), do we really want to deviate from the
well-trodden path of webPKI? I think not--browser-to-webmail HTTPS is
already an existing piece of attack surface for most users, so reusing it
here is somewhat sensible. And convincing people to do something
new--especially if we have to design it from scratch--is biting off more
than I'd want to chew.

>
> >
> > One idea on how to use a CT-style append-only log is that you could use
> the log itself as the source of policies, and the log server can sort of do
> Yes, I totally agree there. git was brought up in a discussion, we're not
> currently implementing anything in that direction. When we come back to
> this we'll see what's available from UTA etc. for us to use.
>

I think we should break this into a separate thread, but I'd be very
interested to continue this discussion. I think with this kind of
verifiable log infrastructure in place you could potentially solve the
policy bootstrap issues as well. This isn't something we'd want to gate a
v1 on, I don't think, but it's a worthwhile discussion.

>
> > I'm not sure about this intuition, though I only have a counter
> intuition. For the hosted scenario, a provider could simply set up an HTTPS
> endpoint for their client domains, use SNI, and fetch SSL certs for the
> client as part of a hosting package. For the self-hosted scenario, is it
> considerably harder? I'm not sure, but given how easy it is to set up a
> personal HTTPS endpoint with Let's Encrypt, I don't really see why. Am I
> far off base?
>
> 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. :)

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 6 Apr 2016 10:24:22 +0100

On 06/04/16 09:52, Daniel Margolis wrote:
>  But even if we'd prefer TACK (which
> here is somewhat sensible.

Speaking as the maintainer of an MTA, no it is not.  Having to add
support for another protocol to an application which deals in SMTP,
and knows how to use a library to get DNS, just feels wrong.  I'd
feel an extreme lack of enthusiasm for ever getting around to
implementing such.
-- 
Jeremy                                  [email-masked]

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 6 Apr 2016 11:49:21 +0200

The discussion about TACK doesn't address the question of how to get
policies out of band--Aaron, as far as I read it, is merely suggesting to
use TACK for cert authentication. Not to disregard the issue you raise, but
it's unrelated to the one I was discussing. My point was that it's
reasonable to mimic the HTTPS trust model, not that it's desirable to bring
in an HTTPS dependency in the MTA.

Regarding your point:

I do agree that an SMTP dependency on HTTPS doesn't feel great, but what
are the concrete issues? Is libcurl that much worse than libresolv? In
reality, you're delegating to some client library in both cases. DNS is
better in the common case, in that it has a more robust caching
infrastructure, but since we rely (by necessity, to ensure the security
model works) on policy caching explicitly, that's irrelevant to our usage.

I can think of a few cases that may be problematic--in a big deployment,
the MTAs might be unable to talk to the outside world over port 443, for
example. That's a real issue, though I think a solvable one (e.g. by
delegating policy updating to a different process or machine).

(For some at least somewhat interesting context,
https://www.ietf.org/mail-archive/web/dnsop/current/msg15195.html,
https://developers.google.com/speed/public-dns/docs/dns-over-https.)

That said, "extreme lack of enthusiasm" is of course not what I want to
hear. Aside from "don't do that", do you have any suggestions? What are the
concrete issues that make this particularly unappealing?

Dan

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 6 Apr 2016 11:12:39 +0100

On 06/04/16 10:49, Daniel Margolis wrote:
> are the concrete issues? Is libcurl that much worse than libresolv?

Nothing concrete.  However, you are not swapping libresolv for libcurl,
you're adding libcurl to the assemblage.  Bloat, in runtime memory
footprint, in exec linkage cpu time, in maintainer/developer load.
-- 
Cheers,
  Jeremy

---

From: [email-masked]
Date: Wed, 06 Apr 2016 06:34:58 -0700 (PDT)

> and knows how to use a library to get DNS, just feels wrong.

As I indicated in the Jabber chat session the other day, I'm 100% with Jeremy
on this. This expands the attack surface of the MTA considerably, and like it
or not that has to be considered as part of the security tradeoffs we're making
here.

Nor did the suggestion that prefetching, caching, and similar techniques
somehow ameliorate this impress me. While it may be possible to perform some or
even all of these http operations outside of critical SMTP client code, the MTA
has to perform them somewhere, somehow.

I briefly considered calling for a limited profile of https for this purpose,
but I don't see how that can possibly work. Just as we know that the way some
people are going to implement the client side of this is by throwing an
existing, hugely  complex https library into their SMTP client, it's even more
certain that the way people are going to implement the server part of this is
by throwing up a web server using whatever existing web server technology they
have lying around, with all that implies.

> I'd

FWIW, if this comes to pass given our customer base we won't really have an
option not to implement it. But I think the way I'm going to handle it is by
building on top of an existing minimal https client we already have, and adding
additional capabilties as the need arises. And if that causes ongoing
interoperability issues, that's just too bad.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2016 14:52:55 -0000

>> and knows how to use a library to get DNS, just feels wrong.

At the dinner a few nights ago we spent a lot of time thinking about
this, and I believe there was a general sense that asking MTAs to
become https clients isn't going to work.  But in the absence
of DNSSEC, we didn't have any better ideas.

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 6 Apr 2016 17:34:01 +0200

That's a pretty depressing conclusion, but yes, I think this is a
compromise solution.

To be mildly contrarian, though, I would consider HTTP's pervasiveness to
be a feature rather than a bug, and the idea that someone could implement
the server-side component by using "whatever existing technology they have
lying around" to be a benefit rather than a cost. I'd prefer to require
people to use robust, well-tested common libraries rather than implement
something custom to support a protocol we had designed de novo.

I am making no claims that this is anything other than pragmatism at
work--we haven't invented the most elegant protocol ever! But if we need
out-of-band communication (which we do, given the assumed constraints),
HTTPS seems as good as anything *because* there are many implementations of
clients and servers and *because* it's well-understood and widely
supported.

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Apr 2016 22:40:40 +0000

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

---

From: David Schweikert <[email-masked]>
Date: Fri, 8 Apr 2016 17:16:00 +0200

Hi Viktor,

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

> requiring new C-code in new Postfix releases to stay current with

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

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

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

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 8 Apr 2016 19:06:16 +0000

> the recipient address domain?

Because STS is *transport* policy.  Not end-to-end policy.  Given
that you expected otherwise, this definitely needs to be explained.

Just because email is ultimately going to say Gmail, if my nexthop
relay is some corporate outbound smarthost, the relevant STS policy
is for that relay, not the destination domain.

-- 
	Viktor.

---

From: David Schweikert <[email-masked]>
Date: Sun, 10 Apr 2016 00:00:07 +0200

> is for that relay, not the destination domain.

OK, got it. But this is going to work only for nexthops / relays
specified as a mail domain (and not as hosts), right?

I am not so sure about the usefulness of this, though. I mean: in case
you are modifying the routing for a mail domain, I would have thought
that you also need to disable the STS check (like you need to disable
certificate pinning when using SSL web proxies).

Or said differently: are you going to enforce TLS encryption to your
outbound smarthosts using STS?

Cheers
David

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 10 Apr 2016 16:19:03 +0200

Right, I was thinking of it the same was as you. If you're using
smarthosts, you're already not using the email domain's MX, so of course
you can't use its STS policy, either.

What we didn't define is whether the STS policy mechanism should be used in
this case. But does this even make sense? STS is fairly closely coupled to
the notion of a valid set of MXs; in the case of a smarthost setup where
you've manually configured a relay server, it's a bit hard to see how a
"per domain, validate MXs this way" kind of policy could be applied. Is it
the domain of the smarthost?

Obviously you could craft a policy semantic to support this (perhaps by
making per-host policies explicit), but is it worth the complexity? In the
static relay case you could conceivably manually encode security policies,
though maybe that doesn't scale well to some complex setups?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 10 Apr 2016 20:36:42 +0000

> specified as a mail domain (and not as hosts), right?

Either.  For example, DANE works regardless of whether routing is
via MX records or directly to the nexthop as a hostname.  A domain
with no MX records, or a administrator-specified route in which
the nexthop is not subject to MX lookups (a [nexthop.example] in
square brackets with Sendmail and Postfix) is implicitly equivalent
to:

	nexhop.example. IN MX 0 nexthop.example.

So if a Postfix transport table contains:

	examle.com	smtp:example.net

then we deliver example.com's mail via the MX hosts of example.net
with whatever policy pertains to other mail sent via example.net.
If, on the other hand, the transport table contains:

	examle.org	smtp:[smtp.example.name]

then mail is sent via the smtp.example.name relay, and the TLS
policy is that for "smtp.example.name" as a domain with no MX
records.

> I am not so sure about the usefulness of this, though.

It is quite useful, because a smarthost is not the only case,
sometimes one explicitly redirects mail for remote domains to other
domains and not infrequently MX lookups are not disabled for such a
"redirect".

> I mean: in case

Well, we don't disable DANE checks in such a case.  It both economy
of mechanism and useful to apply the relevant policy for the nexthop
domain regardless of the reason the domain is selected.

And it would certainly be wrong to use the policy for the recipient
domain.

> outbound smarthosts using STS?

Yes.  STS is a transport policy, not an end-to-end policy.  Therefore
it applies to the logical transport nexthop.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 10 Apr 2016 20:44:58 +0000

> you can't use its STS policy, either.

Postfix need not know or care which transport overrides are
"smarthosts" and which are alternate nexhtops negotiated with a
remote peer.  The same security mechanisms apply in both cases.

> this case. But does this even make sense?

Yes, it does.  You're securing a delivery channel between a sending
relay and a set receiving relays with possible MX indirection.

> STS is fairly closely coupled to

RFC5321 explains how mail is routed in the absence of MX hosts.
Delivery to a non-MX destination is equivalent to delivery to a
destination with a single preference 0 MX record where owner-domain
an the MX exchange are the same.

If MX records are out of scope (non-MX smarthost, then the MX
pinning of STS is not needed, and the policy only specifies the
use of PKI and reporting addresses).  If MX records are used
to select the actual relay, then transport security policy is
the same as with mail that is addressed to the relay domain.

> though maybe that doesn't scale well to some complex setups?

Absense of the STS DNS record that triggers policy acquisition via
HTTPS suffices to cover cases where no policy is desired or published.

However the nexthop is determined, STS and DANE should apply to
secure SMTP traffic to the nexthop.  In most case the nexthop
domain and the recipient domain are the same, but this is not
always so.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 11 Apr 2016 10:07:14 +0200

I see your point. But I think one thing still needs to be specified. In the
smarthost case, what domain is used to validate the server certificate
during the HTTPS policy fetch? Presumably it's now the domain of the
smarthost, not the domain of the recipient domain (for obvious reasons).
But this is mildly funny; absent smarthosting, it's the email domain that
signs the policy (for obvious reasons); with smarthosting, it's the MX
domain?

I guess this is why Chris was saying it makes sense to separate routing
policy and security policy, but I don't love the complexity that that adds.
I think instead it makes sense to simply say that in the smarthosting case
the policy domain is the smarthost domain.

Dan

---

From: David Schweikert <[email-masked]>
Date: Mon, 11 Apr 2016 22:20:25 +0200

Hi Viktor,

On Sun, Apr 10, 2016 at 20:36:42 +0000, Viktor Dukhovni wrote:
> via MX records or directly to the nexthop as a hostname.

I am not sure that the analogy with DANE is appropriate. DANE has TLSA
records for hosts, and not for mail domains (and can of course map
securely mail domains to hosts with DNSSEC MX lookups), whereas STS
focuses on the policy for mail domains, right?

> A domain with no MX records, or a administrator-specified route in
> which the nexthop is not subject to MX lookups (a [nexthop.example] in

In the case of STS, I have the feeling that it is important not to mix
up mail domains and hostnames. So if you have:

   examle.org	smtp:[example.name]

Then "example.name" is a hostname, and the MTA shouldn't lookup the policy
for "example.name", because that is actually the policy for the mail
domain "example.name".

Cheers
David

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Apr 2016 20:30:47 +0000

On Mon, Apr 11, 2016 at 10:07:14AM +0200, Daniel Margolis wrote:

> during the HTTPS policy fetch?

The nexthop domain.  It may, or may not, be subject to further MX
indirection depending on local policy:

    1.  # Forward example.com email via example.net's MX hosts
	# whatever they may be
	#
	example.com	smtp:example.net

    2.  # Forward example.name email via the smtp.example.org
	# relay host.
	#
	example.name	smtp:[smtp.example.org]

In case "1" the STS policy DNS lookup (signal of support) would be
at "example.net" and the well-known URI would be https://example.com/...

In case "2" the STS policy DNS lookup would at "smtp.example.org",
and if that happens to indicate STS support, the well known URI
would be https://smtp.example.org/...

> Presumably it's now the domain of the

Yes, always the domain of the SMTP nexthop, which may or not be
subject to further MX indirection, but recall that (RFC 5321) relay
hosts are just (implicitly) MX domains with:

	smtp.example.com. IN MX 0 smtp.example.com

So the two cases are the same, the STS policy is always associated
with the owner-domain domain on the (possibly implicit) MX RRset.

> signs the policy (for obvious reasons); with smarthosting, it's the MX

Nothing funny at all, and not it is always the transport nexthop
domain that signs the policy.  Do not confuse the nexthop domain
with its MX exchange host, even when they are necessarily the same
(example 2).

> policy and security policy, but I don't love the complexity that that adds.

Yes, these are related.  With DANE routing is protected by DNSSEC
alone, and TLSA records then provide security policy for the target
MX.  Since TLSA records are cleanly separated from routing they
protect the traffic for that MX regardless of whether MX indirection
was used or not.

In Postfix 3.1 (released in Feb 2016) we by default also make use
of DANE TLSA records even when the MX RRset is not signed, provided
the MX host's TLSA records are.  We don't log that as being as
secure as having signed MX RRs, but it does protect against active
attacks when the DNS records are not compromised.

> the policy domain is the smarthost domain.

Not sure where "instead" comes from, that's the only plausible
interpretation for transport security, but note that when the
nexthop domain (smarthost is a special case of nexthop based on
local policy) is subject to further MX lookups (example 1), the
STS policy is associated with the nexthop domain, not the target
MX hosts.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 11 Apr 2016 22:53:51 +0200

> STS policy is associated with the nexthop domain, not the target

Yes, agreed. I was saying "instead" as in "as opposed to truly separating
routing and per-host policies". In that solution (either separating the
policies into separate records on possibly separate domains--somewhat
mimicking the relationship between the DNSSEC-signed MX and the TLSA
records in the DANE case--or moving the per-host policy in-band) you get
more complexity to handle the case in the same way as we just described
here (an STS policy for the next-hop, regardless of what it is), which
seems a losing trade.

Anyway, tl;dr: agreed that it needs to be specified as you suggest.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 13 Apr 2016 15:15:48 +0700

Hi Binu,

First off: sorry for the very late reply, I've been moving to another continent temporarily.

> On 06 Apr 2016, at 08:42, Binu Ramakrishnan <[email-masked]> wrote:
> 

I think your misconception is that I'm an opponent to WebPKI. I'm not - I'm merely trying to deal with realities..

Currently the majority of MXs (i.e. 90+%) on the internet do not have properly signed certificates, and even the signed ones often contain wrong CNs or SANs. I've even seen invalid characters in different places in certs during scans [0] - no idea how they got signed by a CA in the first place. A lot of them are a few years old and expired long ago. This is the reason why MTAs do not properly validate certificates in the first place. The move you're suggesting just puts verification in a different (out-of-band, HTTPS) place.

As noted earlier to Viktor: I'd like to see WebPKI + TACK. Meaning: we could probably achieve fast roll-out on MTAs that do not have properly signed certs and move to properly signed certificates in the long run. TACK would effectively mitigate MITM attacks due to pinning. Once a MTA switches to a valid cert (or something like Let's Encrypt to automate) you get pinning plus a trust-chain/anchor. I'm not suggesting we move away from the CA system - it's currently the only thing that works at scale. I'm still quite pessimistic about DNSSEC, though I hear about big rollouts to happen during this year - let's see.

Then there's another problem, it's probably what Dan meant with 'bootstrapping': If I'm not mistaken, a sending MTA on the first connection to a new MTA will need to resolve DNS - MX records, without DNSSEC any attacker can manipulate these queries. One idea is to pre-populate with pins as STARTTLS-Everywhere tried in the past and some of you have suggested for STS. TACK Pinning would also work very effectively in this case, with the nice property that TACK allows for very efficient key-rollover - no out-of-band communication needed at all.

Of course this doesn't solve the matter of policy distribution, while I'd like to see something in-band (i.e. an SMTP extension as mentioned earlier) the STS suggested way is via out-of-band HTTPS verification where i.e. policies get compared and verified. I'm not a fan of this solution as you can probably guess - if it ends up this way, I'll probably need to implement support for that in STARTTLS-Everywhere/LE anyhow.

> > One of the main issues currently is that most MTA-MTA traffic is over connections established without a CA signed certificate. You're now requiring them to use one anyhow, just in a different place.
> Using untrusted cert is not a feature, but an important security issue that needs to be fixed either through DANE or PKIX.

..as mentioned in the sentence you quote; I strongly feel this is one of the major issues in MTA security today, not a feature.

It's probably a good idea to split this into several threads as Dan suggested: policies and their distribution, feedback mechanisms and authentication (pinning, PKIX et cetera).

Thanks,
Aaron

[0] http://arxiv.org/abs/1510.08646