Subject: [Uta] "webby" STS and DANE/DNSSEC co-existence

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Apr 2016 21:45:06 +0100

Hiya,

With no hats, I'd like to argue that the WG should pursue
the "webby" STS proposal, but should also ensure that we
do not damage progress made by those who are deploying the
DANE/DNSSEC approach to securing MTA-MTA connections.

I think we can do that by requiring that outbound MTAs
that implement the "webby" approach MUST/SHOULD first test
for, and process, TLSA records for the next MX in the path.
In  other words the "webby" approach is tried 2nd.

In more detail, my reasoning is as follows:

- The DANE/DNSSEC approach works and when deployed does
  move MTA-MTA use of TLS beyond opportunistic security.
  And indeed some folks have deployed that and gotten the
  benefits.
- Deploying DANE/DNSSEC requires DNSSEC (fairly obviously;-)
  and the fact is that DNSSEC deployment is not something
  that everyone who wants to move beyond opportunistic
  security is currently willing to do.
- We can, and probably will, define a "webby" to achieve
  the same desired effect of getting beyond opportunistic
  security. Daniel and co's STS aprooach (as outlined for
  the next revision in B-A) is one such, and seems like
  it's one that can work.
- Any such webby approach will inherently involve us in
  re-inventing a lot of what we get from DANE/DNSSEC. That's
  a bit of a pain, but inevitable and not a reason to not
  do STS. (The goal here is not perfection but to enable
  folks to do better than opportunistic security after all.)
- My guess is that the webby approach will end up being
  a bit less secure/safe compared to the DANE/DNSSEC way
  of doing things, mostly due to it having to depend on
  some kind of TOFU step that gets repeated whenever DNS
  without DNSSEC is used (i.e. when something cached
  expires).
- We therefore end up with two ways to do one thing. One
  ("webby") likely to be deployed by some bigger mail
  processors who don't currently do DNSSEC, and another
  DANE/DNSSEC that will likely be better and that's where
  we'd (as in the IETF) really prefer us all to end up
  when/if possible.
- I think that saying one MUST first try DANE/DNSSEC is
  correct, but there may be cases where e.g. DNSSEC is
  just never going to visibly work for an MTA so it may
  be correct to say one SHOULD first try DANE/DNSSEC
  with the exception being cases where one knows at
  coding time that you'll never see an RRSIG or similar.

Anyway with two ways, I really hope the WG conclude that
we want both to be deployable without one damaging the
other. There are of course other ways to try ensure we can
sensibly live with both DANE/DNSSEC and webby STS and
yet help folks move beyond opportunistic security, but
I think the way outlined above is likely best if the folks
who develop MTAs can accept it.

Cheers,
S.

PS: Yes, this is entirely jumping the gun, and is only
something the WG would need to decide a bit down the road.
But since we had a good discussion of the topic in B-A,
I wanted to send this before I forget it all, as I'm quite
likely to do;-)

---

From: Jim Fenton <[email-masked]>
Date: Mon, 11 Apr 2016 14:18:14 -0700

>   the next revision in B-A) is one such, and seems like

As I remember, there were still some issues with how the lookup would
take place (what the URL would be): some sort of reserved hostname was
seen to be a non-starter, and I seem to remember that there was some
issue with .well-known as well, but can't remember the specifics.

Another issue I'm not sure we discussed is the handling of wildcard MX
records: if I send a message to [email-masked], and there is an MX
record for *.example.com, do I look for the policy at foo.example.com,
or do I notice that there was a wildcard MX and use the next higher
domain? I suppose that might work. But I'm still not 100% comfortable
that there's a good "webby" approach to finding the policy in all cases.
>   without DNSSEC is used (i.e. when something cached

The risk is that the sender won't find the policy at all if the web
address lookup fails. But can we agree that the long MTU approach
described in the current draft isn't an effective mitigation to that
problem? Several people pointed out in the meeting that caches don't
typically hold things for very long times; the MTU specifies how long
records MAY be cached, not how long they SHOULD be cached.

My concern here is that if it's possible for intermediaries (for
example, firewalls at the enterprise and national level that currently
interfere with STARTTLS negotiation) to interfere with STS lookups, all
we will have done is to ask them to implement a new blockage feature,
and we haven't actually improved security.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Apr 2016 21:21:28 +0000

> In  other words the "webby" approach is tried 2nd.

[ By the way both DANE and STS are still opportunistic security as
  defined in RFC 7435, the difference is that these are not just
  unauthenticated encryption. DANE and STS are used on the fly
  with peers that publish the relevant policy via some downgrade-
  resistant mechanism. ]

In Postfix, if and when we do implement client-side "webby" STS,
I expect that STS wil be trumped by any DANE policy on MTAs that
support both (when sending email to destinations that support both).
One key reason is that DANE downgrade-resistance is stronger (works
on first contact) and DANE is exposed to fewer trusted CAs.

-- 
	Viktor.

---

From: Mark Risher <[email-masked]>
Date: Mon, 11 Apr 2016 18:38:09 -0300

Hi, everyone:
Hope you all made it home safely.

> In  other words the "webby" approach is tried 2nd.

I agree that's the right order of operations for sending MTAs that *can* do
both, and I agree we don't want one approach to preclude the other. So it
actually sounds like MUST to me, in that if a sender does not have the
plumbing in place (yet) to validate TLSA records, then the SHOULD still
won't have any effect (you'd basically be saying that you SHOULD implement
DANE/DNSSEC, which I think we all agree with). Would that clarification be
better in the STS specification (because it will be published later), or in
a meta BCP that explains operational guidelines for people who can support
both?

> records MAY be cached, not how long they SHOULD be cached.

Yes, we have a known issue that, if you can never successfully retrieve a
policy, then you can never do better than status quo. The value of the long
MTU only kicks in once you've bootstrapped. The bootstrapping problem
against a persistent adversary could potentially be addressed with
preloading, e.g. the way that certain web browsers ship with pinned
certificates already in place.

Side update for the mailing list/working group: Based on feedback from the
in-person meeting, the authors are working on separating reporting and
clearing up the DNSSEC/policy issues as discussed, and hope to have a new
draft shortly. Thank you for all of your feedback and comments, both on
email and at the meeting.

Take care,
/m

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

On Mon, Apr 11, 2016 at 6:21 PM, Viktor Dukhovni <[email-masked]>
wrote:

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

---

From: Neil Cook <[email-masked]>
Date: Tue, 12 Apr 2016 10:39:52 +0100

> On 11 Apr 2016, at 22:38, Mark Risher <[email-masked]> wrote:
> 
> Hi, everyone:
> I agree that's the right order of operations for sending MTAs that *can* do both, and I agree we don't want one approach to preclude the other. So it actually sounds like MUST to me, in that if a sender does not have the plumbing in place (yet) to validate TLSA records, then the SHOULD still won't have any effect (you'd basically be saying that you SHOULD implement DANE/DNSSEC, which I think we all agree with). Would that clarification be better in the STS specification (because it will be published later), or in a meta BCP that explains operational guidelines for people who can support both?
> 

I’d rather see it specified in the STS specification (as a MUST), because there’s otherwise there’s a chance some implementors won’t read a separate meta BCP.

Neil

> Yes, we have a known issue that, if you can never successfully retrieve a policy, then you can never do better than status quo. The value of the long MTU only kicks in once you've bootstrapped. The bootstrapping problem against a persistent adversary could potentially be addressed with preloading, e.g. the way that certain web browsers ship with pinned certificates already in place. 
> 

> Side update for the mailing list/working group: Based on feedback from the in-person meeting, the authors are working on separating reporting and clearing up the DNSSEC/policy issues as discussed, and hope to have a new draft shortly. Thank you for all of your feedback and comments, both on email and at the meeting.
> 
> Take care,
> /m
> 
> 
> 
> 
> 
> 
> --
> Mark E. Risher |	 Group Product Manager |	 [email-masked] <mailto:[email-masked]> |	 650-253-3123 <>
> On Mon, Apr 11, 2016 at 6:21 PM, Viktor Dukhovni <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
>

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 12 Apr 2016 18:52:31 +0200

I'm not sure if I'm being stupid here, but what does it mean for STS to be
"trumped" by DANE (or the reverse)? Do you mean that if the recipient
domain/MX has both STS and DANE you will *only* validate the DANE policy?

If we instead said that senders who validate STS must honor STS and senders
who validate DANE must honor DANE, is there a conflict? I would presume
that if there is either a DANE failure or an STS failure senders who
validate both will treat it as a failure. Introducing a concept of priority
strikes me as unnecessary. What am I missing?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2016 01:43:04 +0000

> domain/MX has both STS and DANE you will *only* validate the DANE policy?

Correct.  Trying to enforce both is too complex, and needlessly
increases the risk of delivery problems.

> who validate DANE must honor DANE, is there a conflict?

That language is either tautological, or unreasonable, if intended
to imply that systems capable of both must be willing to apply both
concurrently.

> I would presume that if there is either a DANE failure or an STS failure
> senders who validate both will treat it as a failure. Introducing a concept
> of priority strikes me as unnecessary. What am I missing?

I have no plans to support concurrent evaluation of potentially
conflicting policies.  DANE is more robust than STS, given a DANE
policy I see no reason to also consider STS policy.

Of course an administrator will be able to choose which policy
applies to a given nexthop, but not enforcement of both.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 13 Apr 2016 09:48:13 +0200

What's the complexity you're worried about? Is it mainly that there's
another switch to flip incorrectly (i.e. inadvertent misconfiguration, at a
greater risk due to the presence of more configurations) or the risk of
malicious DoS?

I think Stephen laid out the trade-offs fairly well. I can see the argument
for telling recipients that if they already publish a DANE record they're
probably fine and shouldn't really need an STS policy as well. But a "must"
seems less helpful to me here; senders who have some external limitation
that prevents them from implementing DNSSEC then must not implement STS?
I'd be worried that some larger deployments might have trouble with that.

---

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

Hi,

> On 13 Apr 2016, at 14:48, Daniel Margolis <[email-masked]> wrote:
> 
> What's the complexity you're worried about? Is it mainly that there's another switch to flip incorrectly (i.e. inadvertent misconfiguration, at a greater risk due to the presence of more configurations) or the risk of malicious DoS?
> 
> I think Stephen laid out the trade-offs fairly well. I can see the argument for telling recipients that if they already publish a DANE record they're probably fine and shouldn't really need an STS policy as well. But a "must" seems less helpful to me here; senders who have some external limitation that prevents them from implementing DNSSEC then must not implement STS? I'd be worried that some larger deployments might have trouble with that.

I understood this as: First check for DNSSEC/DANE if there're no records available try STS. But do not do both. Which is entirely reasonable given the added complexity and attack vector. You really do not want to validate via two to three different protocols/solutions.

Aaron

---

From: Neil Cook <[email-masked]>
Date: Wed, 13 Apr 2016 09:40:45 +0100

> On 13 Apr 2016, at 08:48, Daniel Margolis <[email-masked]> wrote:
> 

Checking both is not a good idea. DANE support scenarios like self-signed certs, which STS does not.

> I think Stephen laid out the trade-offs fairly well. I can see the argument for telling recipients that if they already publish a DANE record they're probably fine and shouldn't really need an STS…

We’re only talking about what precedence to use for senders who support both, not saying that recipients must support both. If sender who supports both DANE/DNSSEC and STS encounters a TLSA record it MUST honour that, and not use STS. If a sender supporting both only sees one or the other, then it’s fine. Senders which only support one or the other are also fine.

Neil

> On Wed, Apr 13, 2016 at 3:43 AM, Viktor Dukhovni <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 13 Apr 2016 11:04:14 +0200

Ah, in that case, I totally misunderstood. Sorry about that.

I don't have a big problem with saying that *if* you support both you
should do DANE first. But I must admit, I still don't really understand the
value in specifying this explicitly: recipients still have to assume a
misconfiguration in either policy may result in dropped mail, so this isn't
a great mitigation for misconfigurations or deliberate DoS. My view (in
previous discussions of the same question) was that we would simply not
specify this--which infrastructure to trust seems like it's something that
the sender determines on their own; it's (obviously) impossible for the
recipient to dictate this ("Let me give you my CA-signed proof that I want
you to always trust CAs."), so a sender can reasonably say that they would
prefer DNSSEC to WebPKI or vice versa (or fail if either fails). But this
isn't a big point to me, so I'm flexible about it.

> certs, which STS does not.

Yes, but if you have a self-signed cert, you aren't going to have an STS
policy, so that's a different scenario than what we're discussing, no?

This is distinct from the first analogy that crossed my mind, which is Web
browsers who support DANE: in the web browser case, WebPKI is essentially
the default, so for DANE to work (with self-signed certs) we need to be
clear that DANE trumps WebPKI. But in the SMTP case the default is nothing,
so if someone explicitly requests STS or DANE, both policies must work
independently (or else they're going to be missing mail from senders who
validate only one or the other).

>
> I think Stephen laid out the trade-offs fairly well. I can see the
> argument for telling recipients that if they already publish a DANE record
> they're probably fine and shouldn't really need an STS policy as well. But
> a "must" seems less helpful to me here; senders who have some external
> limitation that prevents them from implementing DNSSEC then must not
> implement STS? I'd be worried that some larger deployments might have
> trouble with that.
>
>
> We’re only talking about what precedence to use for senders who support
> both, not saying that recipients must support both. If sender who supports
> both DANE/DNSSEC and STS encounters a TLSA record it MUST honour that, and
> not use STS. If a sender supporting both only sees one or the other, then
> it’s fine. Senders which only support one or the other are also fine.
>
> Neil
>

---

From: Neil Cook <[email-masked]>
Date: Wed, 13 Apr 2016 10:34:20 +0100

> On 13 Apr 2016, at 10:04, Daniel Margolis <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Wed, Apr 13, 2016 at 10:40 AM, Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 13 Apr 2016, at 08:48, Daniel Margolis <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Yes, but if you have a self-signed cert, you aren't going to have an STS policy, so that's a different scenario than what we're discussing, no?
> 

Well, both need to work independently as you say below. But I might still have an STS policy (using a different, CA-signed cert) where I have a self-signed cert for DANE, because I want to support clients who only support one or the other. Forcing clients to validate both doesn’t seem to be a good idea.

> This is distinct from the first analogy that crossed my mind, which is Web browsers who support DANE: in the web browser case, WebPKI is essentially the default, so for DANE to work (with self-signed certs) we need to be clear that DANE trumps WebPKI. But in the SMTP case the default is nothing, so if someone explicitly requests STS or DANE, both policies must work independently (or else they're going to be missing mail from senders who validate only one or the other).

Yes, but I might prefer that senders use one rather than the other. DANE is more flexible in terms of allowing things like self-signed certs, so from my point of view, if I’m running a mail server I want clients to use DANE if they support both. I don’t want the client to make that decision.

Neil

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 13 Apr 2016 11:38:35 +0200

On Wed, Apr 13, 2016 at 11:34 AM, Neil Cook <[email-masked]> wrote:

> Well, both need to work independently as you say below. But I might still
> have an STS policy (using a different, CA-signed cert) where I have a
> self-signed cert for DANE, because I want to support clients who only
> support one or the other. Forcing clients to validate both doesn’t seem to
> be a good idea.
>

I don't really understand how you would do this, though. Wouldn't this
necessitate having different MX records (some of which have matching TLSA
records and serve self-signed certs but aren't included in the STS policy,
and some of which are in the STS policy and have CA-signed certs) and
counting on sending MTAs falling back to the subset of (from their
perspective) valid MXs?

I'm just trying to understand the setup here a bit better.

---

From: Neil Cook <[email-masked]>
Date: Wed, 13 Apr 2016 10:59:06 +0100

> On 13 Apr 2016, at 10:38, Daniel Margolis <[email-masked]> wrote:
> 
> 
> On Wed, Apr 13, 2016 at 11:34 AM, Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> I don't really understand how you would do this, though. Wouldn't this necessitate having different MX records (some of which have matching TLSA records and serve self-signed certs but aren't included in the STS policy, and some of which are in the STS policy and have CA-signed certs) and counting on sending MTAs falling back to the subset of (from their perspective) valid MXs?
> 

Yeah, that would suck. I didn’t think enough about how you would make this work practically.

However this does bring up a good point - if I want to support STS *and* DANE as a receiver, and have a homogeneous MX/MTA setup, i.e. not something like the above, I would have to support the common subset of both specifications, at least as far as MTA configuration is concerned, e.g. no self-signed certs. That is a consequence we haven’t discussed before.

Neil

---

From: Chris Newman <[email-masked]>
Date: Wed, 13 Apr 2016 10:43:31 -0700

DANE is merely one method of validating a certificate, there can also be SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11” and “tls12” directives. Those specify a minimum acceptable version of TLS for future connections. Although we haven’t debated yet whether to include those in SMTP relay policy, I think it would make sense to include those directives, particularly given the problems we’ve seen with old versions of TLS causing real security problems. And there may be future policy directives we want that are even more compelling. So the question is where to put SMTP relay security policy that is orthogonal to DANE. Seems like wherever we choose to put the policy for SMTP relay STS (whether in a DNSSEC-protected DNS record, HTTPS well-known or SMTP+STARTTLS), that’s where we should always look for SMTP relay policy.

		- Chris
On April 12, 2016 at 17:48:25 , Daniel Margolis ([email-masked]) wrote:

On Wed, Apr 13, 2016 at 3:43 AM, Viktor Dukhovni <[email-masked]> wrote:

--
        Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2016 19:03:45 +0000

On Wed, Apr 13, 2016 at 10:34:20AM +0100, Neil Cook wrote:

> > Yes, but if you have a self-signed cert, you aren't going to have an
> > STS policy, so that's a different scenario than what we're discussing, no?

[ Response to up-thread comment ]

If a domain publishes both DANE and STS policy indeed both need to
be correct.  Which to use when both are published is perhaps just
local policy, but some guidance may be appropriate.

In particular because opportunistic authentication (please read
RFC7435, and then sections 1.3 and 3.1 of RFC7672) can be viewed
a policy of receiving system that the sending system is playing
along with, fragile policies are best avoided, lest senders throw
in the towel and disable SMTP transport security, because it is
more trouble than it is worth.

Now of DANE and STS have their separate pain points:

    * DANE: Cert rotation can be tricky, users may need to
      update DNS before replacing their certs.  Some will botch
      this from time to time.  

      However, with "3 X X" TLSA records certificate expiration and
      hostname matching are not relevant, so authentication works
      even with "expired" certs or certs that don't match the MX
      hostname, or for chains that lack otherwise required intermediate
      CA certs.

    * STS: Users will forget to renew certificates, and name checks
      need to work, and the CA needs to be trusted by the sender.
      Missing intermediate certs (often not added when renewing
      certs) are also a frequent problem.

      Certificate transparency may also enter the picture at some
      point, and provide more ways for WebPKI authentication to
      fail (missing SCTs in stapled OCSP, unsupported log servers,
      ...).

If we require *both* to work, there are just too many ways to lose.
The sender typically is willing to send in the clear, and is doing
TLS because *some* traffic deserves better and to thwart pervasive
monitoring.

Setting the bar too high is often counterproductive.

So my view is that for SMTP DANE is by far the more natural of the
two transport security mechanisms, and that STS is essentially a
medium-term work-around for the complexity of cost-justifying DNSSEC
in the face of internal organizational politics at the large
providers.

In that light, the more natural mechanism is used when available,
and the work-around is a secondary strategy.

> support one or the other. Forcing clients to validate both doesn�t seem
> to be a good idea.

This can't work.  An MTA will present the same certificate chain
to STS and DANE clients alike.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Apr 2016 19:14:06 +0000

On Wed, Apr 13, 2016 at 10:59:06AM +0100, Neil Cook wrote:

> However this does bring up a good point - if I want to support STS *and*
> DANE as a receiver, and have a homogeneous MX/MTA setup, i.e. not something
> like the above, I would have to support the common subset of both
> specifications, at least as far as MTA configuration is concerned, e.g.
> no self-signed certs. That is a consequence we haven�t discussed before.

STS is WebPKI.  If you want STS, you need a certificate from one
of the usual CAs.  With a self-signed certificate (some day just
a bare public key and no certificate at all) you can only use DANE.

Top 10 issuers of certs for DANE MX hosts:

     172 ; Issuer = CN=StartCom Class 1 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
     166 ; Issuer = CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
     165 ; Issuer = CN=Let's Encrypt Authority X1,O=Let's Encrypt,C=US
      91 ; Issuer = CN=StartCom Class 2 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
      90 ; Issuer = CN=Gandi Standard SSL CA 2,O=Gandi,L=Paris,ST=Paris,C=FR
      81 ; Issuer = CN=StartCom Class 1 DV Server CA,OU=StartCom Certification Authority,O=StartCom Ltd.,C=IL
      63 ; Issuer = CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
      62 ; Issuer = CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
      38 ; Issuer = CN=WoSign CA Free SSL Certificate G2,O=WoSign CA Limited,C=CN
      33 ; Issuer = CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc.

( Note some of the MX hosts support many hundreds of domains, the above counts
  the issuer just once for each issued certificate, not once per domain served. )

-- 
	Viktor.

---

From: Binu Ramakrishnan <[email-masked]>
Date: Wed, 13 Apr 2016 20:58:58 +0000 (UTC)

> a bare public key and no certificate at all) you can only use DANE.>--
Yes, the STS policy is served over WebPKI, but in the STS policy you may still specify/pin public key or certificate for MX server. Pinning is proposed as a future work for STS along with additional constraints like min TLS version, PFS etc. STS use WebPKI/Root CA as trust anchor for policy distribution and in the case of DANE, trust anchor is DNS root (through DNSSEC)

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Wednesday, 13 April 2016 12:14 PM
 Subject: Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Apr 2016 06:30:08 +0000

On Wed, Apr 13, 2016 at 10:43:31AM -0700, Chris Newman wrote:

> DANE is merely one method of validating a certificate, there can also be
> SMTP policy orthogonal to DANE.

Sure, but I don't see DEEP-style policy latches playing much of a
role, if any, in MTA-to-MTA opportunistic transport security.  No
plans to implement.  Sorry about that.

> Take for example, DEEP's 'tls11' and 'tls12' directives. Those specify a
> minimum acceptable version of TLS for future connections.

I don't see adding any support for this in Postfix.  Keep in mind
that MTA-to-MTA TLS is still opportunistic security even with DANE.
The client cannot be expected to jump through excessive hoops for
marginal gain.

Caching of TLS policy pins for every MX host ever contacted is not
a sensible requirement on the sending MTA.  Nor does this achieve
broad security, since secondary/tertiarry/... MX hosts are rarely
contacted, and MITM attackers can often block access to these, and
cause connections to use MX hosts that have not been used recently.
Caches with no size or TTL constraints are not viable.

The higher we set the bar for use of opportunistic TLS the less
useful it becomes.  We need to be reasonably modest in our goals,
so that they remain broadly achievable.

> So the question is where to put SMTP relay security policy
> that is orthogonal to DANE.

Opportunistic transport security for relays needs to avoid being
overly-prescriptive or require significant sender resources.

> Seems like wherever we choose to put the policy for SMTP relay STS (whether
> in a DNSSEC-protected DNS record, HTTPS well-known or SMTP+STARTTLS),
> that's where we should always look for SMTP relay policy.

DEEP is a fine hammer for MUAs, let's not make every SMTP-related
problem a DEEP nail.

DANE SMTP is deliberately minimally prescriptive.  The "floor"
security policy on acceptable ciphers and protocols will gradually
rise via adjustments to local policy and MTA software defaults as
older protocols and ciphers become increasingly rare.  Keeping the
design as simple as possible is a key feature.

If STS is to be a successful (be it perhaps in some sense secondary)
alternative it too needs to remain (or become) sufficiently simple.

Transparent interoperability is more important than dialing security
up to 11.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Apr 2016 06:38:07 +0000

On Wed, Apr 13, 2016 at 08:58:58PM +0000, Binu Ramakrishnan wrote:

> Yes, the STS policy is served over WebPKI, but in the STS policy you may
> still specify/pin public key or certificate for MX server. Pinning is
> proposed as a future work for STS along with additional constraints like
> min TLS version, PFS etc. STS use WebPKI/Root CA as trust anchor for policy
> distribution and in the case of DANE, trust anchor is DNS root (through
> DNSSEC)

See my response to Chris Newman.  The more prescriptive/ambitious
the STS design the less likely it is too see workable broad adoption.

If the STS spec is just for email between Yahoo and Gmail, sure,
go for it.  Less work for me, I won't need to implement yet another
transport security mechanism.

A more reasonably modest STS would stay well clear of prescribing
such fine details.  Once the policy lookup requires WebPKI support,
pinning MX host certs is fragile over-engineering.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 14 Apr 2016 10:58:32 +0200

> pinning MX host certs is fragile over-engineering.

To be clear, HPKP allows pinning a root or intermediate cert, not just the
host cert. I think pinning someone in the cert chain and not the host cert
is generally preferable (in terms of safety and ease of certificate
rollover).

But in terms of broader feedback, I think you're making a really important
point here (and up-thread) about (config) usability and security tradeoffs.
For now, simply getting CA *or* DNSSEC based signing of security policies
is a huge benefit for MTA-to-MTA SMTP. In a future where CA or registrar
malfeasance is the weakest link, we know the next steps--key pinning, cert
transparency, and similar. But that would be a future where we've already
vastly improved the state of the art from most deployments today. ;)

Dan

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 14 Apr 2016 19:19:32 +0700

> On 14 Apr 2016, at 15:58, Daniel Margolis <[email-masked]> wrote:
> 
> 
> On Thu, Apr 14, 2016 at 8:38 AM, Viktor Dukhovni <[email-masked]> wrote:
> 
> To be clear, HPKP allows pinning a root or intermediate cert, not just the host cert. I think pinning someone in the cert chain and not the host cert is generally preferable (in terms of safety and ease of certificate rollover).

The SMTP-STS draft mentions 'certificate pinning' as future work. Would you really want to go the way of HPKP? It's been an utter deployment and management disaster [0] [1]. While I agree that pinning to host-keys will mean more trouble for admins, I do feel that HPKP in general is a completely wrong approach. Adding this on top of STS will most surely make mails bounce at massive scale, at least in small deployments. Companies like the ones authoring the STS draft will have proper engineering teams and man-power available. Not every MX on the internet is Gmail or Yahoo, just to reiterate my concern about STS's complexity and out-of-band behaviour.

I've repeatedly suggested a better solution for pinning that works with WebPKI based trust anchors and would not need a webserver along with an MTA.

To be honest: this is getting a bit frustrating. I feel the STS authors look for a solution that works well within their domains and management cycles, but that's far from the rest of the internet community - they do not have the same man-power as said companies have. And even automating HPKP is doomed to fail, some tried, I haven't seen a good working solution.

Aaron

[0] http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html (current)
[1] https://www.internetsociety.org/sites/default/files/01_4_0.pdf (about a year old)

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 14 Apr 2016 19:44:30 +0700

Post-scriptum:

> On 14 Apr 2016, at 19:19, Aaron Zauner <[email-masked]> wrote:

These two studies outline something very well: while tech. invented and used at Google like HPKP works very well between their servers and client software they distribute, update and maintain themselves, it has been a failure for the broader internet community. I initially had big hopes for HPKP as it   effectively by-passed the TLS working group to become a standard. TACK had been the (earlier, far better) alternative, but got stuck in TLS-WG due to a more general discussion on the CA eco-system, mostly ignoring the superior features, some of which the HPKP authors re-used as I'm sure you're all aware. The end result after standardisation and people trying to write proper deployment automation scripts is just bad. HSTS had it's difficulties but it's a far better protocol if you ask me. I also feel the feedback mechanism in HPKP is rather poorly designed.

Aaron

---

From: Jim Fenton <[email-masked]>
Date: Thu, 14 Apr 2016 22:38:12 -0700

On 4/13/16 10:43 AM, Chris Newman wrote:
> DANE is merely one method of validating a certificate, there can also
> be SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11”
> and “tls12” directives. Those specify a minimum acceptable version of
> TLS for future connections. Although we haven’t debated yet whether to
> include those in SMTP relay policy, I think it would make sense to
> include those directives, particularly given the problems we’ve seen
> with old versions of TLS causing real security problems. And there may
> be future policy directives we want that are even more compelling. So
> the question is where to put SMTP relay security policy that is
> orthogonal to DANE. Seems like wherever we choose to put the policy
> for SMTP relay STS (whether in a DNSSEC-protected DNS record, HTTPS
> well-known or SMTP+STARTTLS), that’s where we should always look for
> SMTP relay policy.
>
>
When you're deciding whether to publish an encryption policy, it's
important to consider whether there's a downgrade attack. Fundamentally,
we're trying to deal with a situation where an intermediary can
interfere with the negotiation of encryption, or whether an impostor
server can claim not to support encryption in an effort to avoid a
requirement to authenticate itself as would happen when TLS is negotiated.

I don't know the details of what TLS 1.2 fixes in TLS 1.1, but I would
only include tls11 and tls12 directives if there is a downgrade attack
where the attacker can claim to only support TLS 1.1 and not 1.2 and
benefit from that. Unless there is something about certification
verification that can be exploited, the impostor server attack isn't
possible because the impostor would have to authenticate to negotiate
TLS 1.1 as well.  Similar situation for the intermediary/MITM.

Is there actually something in TLS 1.1 that can be exploited by these
sorts of attackers?  If not, I wouldn't include those directives.

-Jim

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 15 Apr 2016 16:36:23 +0700

Hi,

> On 15 Apr 2016, at 12:38, Jim Fenton <[email-masked]> wrote:
> 
> Is there actually something in TLS 1.1 that can be exploited by these sorts of attackers?  If not, I wouldn't include those directives.

I'm not sure if that answers your question w.r.t. downgrade attacks, but a quick comment on changes between the TLS versions: TLS 1.2 introduces AEAD (authenticated encryption with associated data), these modes are currently the only ones considered secure by academia. For example: 1.1 doesn't support GCM, CCM,.. - so you end up with CBC or RC4, both of which are at the very least broken in lab settings and these attacks have been improved by quite a bit over the last couple of years, so that might be something to consider. 1.2 also removed MD5 and SHA1 as PRFs and made them configurable in cipher-suites (e.g. SHA256).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 15 Apr 2016 16:40:26 +0700

> On 15 Apr 2016, at 16:36, Aaron Zauner <[email-masked]> wrote:by these sorts of attackers?  If not, I wouldn't include those directives.
> 

I think it's worth noting that these attacks are currently unfeasible for SMTP traffic to the best of my knowledge, but their use should be discouraged. And for e.g. RC4 an RFC exists prohibiting further use in standards.

Aaron

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Apr 2016 05:28:11 -0700

On Thu, Apr 14, 2016 at 10:38 PM, Jim Fenton <[email-masked]> wrote:

> SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11” and
> “tls12” directives. Those specify a minimum acceptable version of TLS for
> future connections. Although we haven’t debated yet whether to include
> those in SMTP relay policy, I think it would make sense to include those
> directives, particularly given the problems we’ve seen with old versions of
> TLS causing real security problems. And there may be future policy
> directives we want that are even more compelling. So the question is where
> to put SMTP relay security policy that is orthogonal to DANE. Seems like
> wherever we choose to put the policy for SMTP relay STS (whether in a
> DNSSEC-protected DNS record, HTTPS well-known or SMTP+STARTTLS), that’s
> where we should always look for SMTP relay policy.
>
>
> we're trying to deal with a situation where an intermediary can interfere
> with the negotiation of encryption, or whether an impostor server can claim
> not to support encryption in an effort to avoid a requirement to
> authenticate itself as would happen when TLS is negotiated.
>
> possible because the impostor would have to authenticate to negotiate TLS
> 1.1 as well.  Similar situation for the intermediary/MITM.
>

Jim,

TLS contains its own anti-downgrade measures. What's the reasoning for
adding ones here?

-Ekr

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Apr 2016 10:07:45 -0700

On 4/15/16 5:28 AM, Eric Rescorla wrote:
>
> On Thu, Apr 14, 2016 at 10:38 PM, Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     DANE is merely one method of validating a certificate, there can
>>     also be SMTP policy orthogonal to DANE. Take for example, DEEP’s
>>     “tls11” and “tls12” directives. Those specify a minimum
>>     acceptable version of TLS for future connections. Although we
>>     haven’t debated yet whether to include those in SMTP relay
>>     policy, I think it would make sense to include those directives,
>>     particularly given the problems we’ve seen with old versions of
>>     TLS causing real security problems. And there may be future
>>     policy directives we want that are even more compelling. So the
>>     question is where to put SMTP relay security policy that is
>>     orthogonal to DANE. Seems like wherever we choose to put the
>>     policy for SMTP relay STS (whether in a DNSSEC-protected DNS
>>     record, HTTPS well-known or SMTP+STARTTLS), that’s where we
>>     should always look for SMTP relay policy.
>>
>>
>     important to consider whether there's a downgrade attack.
>     Fundamentally, we're trying to deal with a situation where an
>     intermediary can interfere with the negotiation of encryption, or
>     whether an impostor server can claim not to support encryption in
>     an effort to avoid a requirement to authenticate itself as would
>     happen when TLS is negotiated.
>
>     I don't know the details of what TLS 1.2 fixes in TLS 1.1, but I
>     would only include tls11 and tls12 directives if there is a
>     downgrade attack where the attacker can claim to only support TLS
>     1.1 and not 1.2 and benefit from that. Unless there is something
>     about certification verification that can be exploited, the
>     impostor server attack isn't possible because the impostor would
>     have to authenticate to negotiate TLS 1.1 as well.  Similar
>     situation for the intermediary/MITM.
>
>     Is there actually something in TLS 1.1 that can be exploited by
>     these sorts of attackers?  If not, I wouldn't include those
>     directives.
>
>
> Jim,
>
That's exactly my point: I wouldn't include these directives.

-Jim

---

From: Chris Newman <[email-masked]>
Date: Sat, 16 Apr 2016 10:23:49 -0700

On April 14, 2016 at 22:38:23 , Jim Fenton ([email-masked](mailto:[email-masked])) wrote:
> When you're deciding whether to publish an encryption policy, it's important to consider whether there's a downgrade attack. Fundamentally, we're trying to deal with a situation where an intermediary can interfere with the negotiation of encryption, or whether an impostor server can claim not to support encryption in an effort to avoid a requirement to authenticate itself as would happen when TLS is negotiated.
>  
> I don't know the details of what TLS 1.2 fixes in TLS 1.1, but I would only include tls11 and tls12 directives if there is a downgrade attack where the attacker can claim to only support TLS 1.1 and not 1.2 and benefit from that. Unless there is something about certification verification that can be exploited, the impostor server attack isn't possible because the impostor would have to authenticate to negotiate TLS 1.1 as well. Similar situation for the intermediary/MITM.
>  

In SSL 3.0 and TLS 1.0 there are things attackers can exploit and those protocols are still in the wild and still required by many old MUAs that are still widely used. TLS 1.1 it’s less clear at the moment that it’s exploitable, but that’s likely to change.

While the TLS “live at the moment” version negotiation is not vulnerable to MITM, I view policy as setting the baseline for future security rather than stopping immediate MITMs. We can also do a threat analysis. The most common attacks outside passive eavesdropping and DNS are breaking into servers. Breaking into servers tends to get noticed if there’s an outbound stream of data or things stop working. But what if I break into a server and change it to prefer SSL 3.0 and TLS 1.0 over later versions during the negotiations? Now I can do external attacks on that domain that may not be detectable by the domain’s intrusion detection system. Meanwhile end-users are assured they’re secure by the “lock”.

So while Viktor made a compelling case that the TLS version directive is not appropriate for SMTP relay, I think it is appropriate for the MUA STS scenario where it’s simpler to implement, where very old MUAs are in wide use requiring permissive servers, and I’d really like to be sure my client is using the stronger versions of TLS as long as I don’t have to manually configure it.

Does this make sense?

Another reason I like the TLS version directive is I can give example code of how to implement it which helps explain the concepts. The other directives are too complicated for that.

		- Chris

---

From: Jim Fenton <[email-masked]>
Date: Sun, 17 Apr 2016 20:45:06 -0700

>>> So while Viktor made a compelling case that the TLS version directive is not appropriate for SMTP relay, I think it is appropriate for the MUA STS scenario where it’s simpler to implement, where…

I'm a little confused by the language in section 9.1 "All [client and
server] implementations MUST be configurable to support implicit TLS
using the TLS 1.2 protocol or later."  So why not insist in TLS 1.2 all
the time? There must be a deployment corner case that I'm not considering.

But, as you noted in section 6, the choice of TLS version isn't the only
thing that needs to be considered. Why does TLS version rise to the
level of importance of creating a directive, but cipher suite doesn't?

I don't see the complexity and interoperability risk associated with all
this to be warranted by the relatively low level of security risk.

Also, if we're talking about some unification of STS and DEEP (as
"MUA-STS" or something, if I recall correctly), and the STS policy is
retrieved in a "webby" manner, the policy record probably also needs to
adhere to its own standards for TLS version, cipher suite, etc. Which
could be problematic if an attacker can publish a record for a
known-vulnerable cipher suite or something.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Apr 2016 04:39:50 +0000

> level of importance of creating a directive, but cipher suite doesn't?

I agree that it may make more sense to set protocol floors in TLS
libraries and "die die die" RFCs that obsolete old protocol versions
than to do so via DEEP application latches.  The TLS protocol
version latches are likely too much work for too little gain.

-- 
	Viktor.

---

From: Chris Newman <[email-masked]>
Date: Mon, 18 Apr 2016 12:43:20 -0700

> the time? There must be a deployment corner case that I'm not considering.  

SSL appliance boxes tend to get updated slowly. Also the model has to cover two versions to explain how upgrading works.

> level of importance of creating a directive, but cipher suite doesn't?  

Cipher suites are necessarily fluid and it’s not always clear whether one will be better than another indefinitely. To the extent we can have TLS stack vendors be the only people who care about what cipher suites are enabled/preferred, we’re going to have better outcomes than if we expect non-security folks to control those knobs. The primary need is the ability to turn on/off old cipher suites as dictated by a site’s interoperability vs. security balance. Client policy is more likely to cause problems than to improve security in the cipher suite area.

The TLS version, on the other hand, is where the security community really ratchets up the minimum security for TLS. Minimum version is controllable in TLS APIs, and indeed a common TLS client design error is failure to expose that control knob. Thus when SSL3 & TLS1.0 vulnerabilities became well known, it required software updates to turn those versions off in many products (rather than a configuration or policy change). Having it in the standard might encourage implementers to pay attention to that important TLS stack control knob.

> this to be warranted by the relatively low level of security risk.  

For MUAs, this is not complex. It would be very straightforward to implement (a few lines of code) once the account confidentiality level model is implemented (which is the important part of MUA STS). I don’t see significant interoperability risk in the MUA space.

> known-vulnerable cipher suite or something.  

Unification is a non-goal. Protocol/model alignment where it makes sense is the goal. I believe a strong case has been made that STS policy is very application-specific. In SMTP relay STS, the default is deliver forward with zero security and there is communication with many badly behaved peers that all have to be tracked separately. The business motivation is: 1. never bounce legitimate mail to avoid support costs and 2. generate a reputation for confidentiality whether or not that reputation is reflected in reality. The ISPs with these two motivations control their SMTP relay clients & servers. Just getting the cert checked in the most barebones fashion is going to be a difficult ask for the infrastructure. The MUA world is different. Many MUAs already support an “SSL-required” mode that checks certs — they just have no way to move from the no-SSL to SSL-required mode and no indication of which mode is active. ISPs generally don’t control which MUA the customer uses, so the ISP motivation is to make the common MUAs work well. If (and only if) the MUA provides a visual indication of the account confidentiality level, the ISPs will change to get the label. There also tend to be a lot of very old MUAs in use in some countries, so ISPs often have very permissive server configurations (e.g., likely to support TLS1.0, RC4, SHA1, etc to interoperate with old MUAs). Ratcheting up the minimum TLS version is much easier to implement in MUA STS than SMTP relay STS, and it’s more likely to actually improve security.

	- Chris