Subject: [dane] Delivery of email if MX is not signed

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 23 Aug 2015 19:29:50 +0200

Hi,

I have *not* followed this wg in detail, although I have talked with various people about how important it is to get DANE deployed. I am also strongly advocating use and deployment of DANE as I personally think the current CA/X.509 PKI structure is broken beyond ability to fix it.

I read a text by Jan Žorž:

<http://www.internetsociety.org/deploy360/blog/2015/08/even-more-danednssectls-email-testing-from-go6lab/>

That made me a bit confused as I interpreted the text as if mail was not delivered in one case where I think email should be delivered.

I have in Facebook had a long discussion with Jan, and the more I think about it, the more I think I am right ;-)

I have re-read the very very very long I-D (draft-ietf-dane-smtp-with-dane) that is now in RFC-Ed Queue and I think unfortunately the huge number of words, lack of flow chart (decision making tree) and lack of real world examples makes it hard to know what the document says. At least I can not say directly whether the draft really say anything at all about this example I am to bring up.

But all of this might imply I am wrong of course. If nothing else because I have not followed the discussions.

Ok, to the example:

Delivery of email consists of two steps:

1. Resolution of MX record. And if no MX exists, fallback to A/AAAA

In my example, we DO have an MX record. To me this is 100% normal DNSSEC. Question on whether the target of the MX is to be trusted is up to the policy we use for DNSSEC.

Also, in my example the RRSet the MX is in is _unsigned_:

example.com. IN MX 0 mail.example.net.

2. Delivery of the mail over TLS to mail.example.net.

This is where DANE comes in. For the cert to be trusted, there must be a TLSA record for _426._tcp.mail.example.net, and it must be DNSSEC signed, signatures validated etc etc.

This step 100% validates and is correct according to traditional DANE.

Ok, how then to put these pieces together?

I think these two steps are independent of each other. And DANE should be used, the cert be accepted, if step 2 is properly validated, TLSA record signed and validated etc. Regardless of whether the MX was signed.

That said, the sender CAN have a policy that say that "For me to base my trust on DNS (and not X.509 CA hierarchy), MX must be signed with DNSSEC and properly validated."

But, default must be to allow unsigned MX together with a properly setup with by DANE validated cert that is used in TLS.

If not, we will get absolutely zero deployment of DANE with SMTP as we will never get 100% DNSSEC deployment.

And if DANE is so good, which I think, and I hope all of us think, why should not a TLS connection that is properly secured with DANE not be accepted for SMTP?

No, I do not think the MiM attack vector is _worse_ with unsigned MX but properly validated TLSA than what we use today without TLS and unsigned MX. And no, I do not think todays X.509 CA use is very good at all. As some of you know.

    Best, Patrik

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Aug 2015 13:47:12 -0400 (EDT)

> 2. Delivery of the mail over TLS to mail.example.net.

so example.com is unsigned? and mail.example.net is signed, and the TLSA
record in example.net is signed.

In that case, I believe TLS will be used but the TLSA cannot be
verified, so while delivery happens over TLS, there is no way to
verify the identity of the receiver because the MX record could have
been spoofed.

I think you are arguing that it should deliver TLS only after validation
of the TLSA record for mail.example.net. That validation is a false
sense of security though.

I don't think mail delivery will be halted. since the example.com domain
is unsigned, anonymous TLS will be used when available, and no
verification will take place.

I'm not sure what you are proposing to change?

Paul

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 23 Aug 2015 19:59:37 +0200

> record in example.net is signed.

Correct.

> verify the identity of the receiver because the MX record could have

Excuse me for being slow here. What do you mean by "the TLSA cannot be verified"?

To be more precise:

Unsigned RRSET contain:

example.net. IN MX 0 mail.example.com.

Signed (and properly validated) RRSETs that contains these two records and a few more:

mail.example.com. IN A 192.168.1.1
_426._tcp.mail.example.om. IN TLSA ....

I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100% properly setup DANE "thing".

> I'm not sure what you are proposing to change?

I am not sure I am proposing a change. :-)

What seems to have happened in the tests that Jan did was that IF the MX was not signed, BUT the TLSA was signed and validated correctly, THEN postfix did _NOT_ deliver the email. At all.

I think that behaviour is wrong, and am unsure whether it is a bug in postfix or whether it is a bug in the spec.

   Patrik

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Aug 2015 14:18:39 -0400 (EDT)

> _426._tcp.mail.example.om. IN TLSA ....

so anyone can spoof:

pretending "mail.example.com." does not give you more security. What
would you do if you saw:

example.net. IN MX 0 evil.nohats.ca

with proper TLSA records for evil.nohats.ca?

> I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100% properly setup DANE "thing".

But nothing in that statement securely tells you anything about example.net.

> I think that behaviour is wrong, and am unsure whether it is a bug in postfix or whether it is a bug in the spec.

That would be a bug in postfix? The spec states:

    All
    "insecure" RRSets MUST be handled identically: in either case
    unvalidated data for the query domain is all that is and can be
    available, and authentication using the data is impossible.

It does not state to not deliver email, it just states there is no
authentication possible, so deliver without dane authentication.

Paul

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 23 Aug 2015 20:30:10 +0200

> example.net. IN MX 0 mail.example.com.

Yes, just like today.

> with proper TLSA records for evil.nohats.ca?

This is what we have today.

I would deliver over the TLS secured connection.

The only way to secure that is to DNSSEC sign mail.example.net.

Correct.

> authentication possible, so deliver without dane authentication.

Ok, I think what I have issues with is that I think "dane authentication" is not black or white.

We have at least:

1. Signed and validated MX, signed and validated TLSA

2. Unsigned MX, signed and validated TLSA

3. Unsigned MX, no TLSA, unsigned A/AAAA

Then we have all of the failed situations, which include:

4. Signed, but broken signatures, on MX, signed and validated TLSA

5. Signed, but broken signatures, on MX, signed but broken signatures on TLSA

6. Unsigned MX, signed but broken signatures on TLSA

Etc

So if you look at 1, 2 and 3, if I understand you correctly, [2] is not "DANE authenticated" even if the TLS connection has properly signed and validated TLSA record?

This is a bit confusing to me. I.e. the terminology is confusing. To me, [2] has proper DANE validated TLS available for the SMTP connection.

But I completely agree there is an MiM possible for the unsigned MX. Just like we have today. And why we want DNSSEC deployed.

   Patrik

---

From: [email-masked]
Date: Sun, 23 Aug 2015 20:39:23 +0200

Zitat von Patrik Fältström <[email-masked]>:

> I.e. if only looking at mail.example.com. and  
> _426._tcp.mail.example.com. that is a 100% properly setup DANE  
> "thing".
>
> What seems to have happened in the tests that Jan did was that IF  
> the MX was not signed, BUT the TLSA was signed and validated  
> correctly, THEN postfix did _NOT_ deliver the email. At all.
>
> I think that behaviour is wrong, and am unsure whether it is a bug  
> in postfix or whether it is a bug in the spec.

To my knowledge with Postfix this should lead to a "normal" TLS  
connection with no DANE at all for "dane" level:

"The Postfix SMTP client will not look for TLSA records associated  
with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS  
zone."

With dane-only the connection might fail.

Regards

Andreas

---

From: [email-masked]
Date: Sun, 23 Aug 2015 20:46:23 +0200

Zitat von Patrik Fältström <[email-masked]>:

> So if you look at 1, 2 and 3, if I understand you correctly, [2] is  
> not "DANE authenticated" even if the TLS connection has properly  
> signed and validated TLSA record?
>
> This is a bit confusing to me. I.e. the terminology is confusing. To  
> me, [2] has proper DANE validated TLS available for the SMTP  
> connection.
>
> But I completely agree there is an MiM possible for the unsigned MX.  
> Just like we have today. And why we want DNSSEC deployed.

You are https biased i guess. With an unsigned MX your secure chain is  
broken because the target you try to reach by an E-Mail address is  
directed to a target by an "unsecure" link. If the unsecure resolved  
target is then secured doesn't matter because you might be already on  
the wrong track.

Security is only as strong as the weakest point in the chain.

Regards

Andreas

---

From: Peter Koch <[email-masked]>
Date: Sun, 23 Aug 2015 20:50:57 +0200

> But I completely agree there is an MiM possible for the unsigned MX. Just like we have today. And why we want DNSSEC deployed.

If we'd only be worried about a passive attacker, we'd not
address the spoofed MX RR, but we'd want the SMTP connection
encrypted.  In that case (passive only), opportunistic (pre DANE)
STARTTLS would be sufficient.

If we'd worry enough about active attacks, we'd want the endpoint
identity verified (thus DANE[1]) as well as its capabilities
(thus DANE[2]), and at the same time we'd probably prefer (or
even demand) signed/validated MX RRs.

Apparently there are multiple potential attackers of different background,
motivation, and means. If your enemy is the helpful corporate
firewall that intercepts SMTP to 'optimize away' STARTTLS, maybe
its next version will 'enhance' MX responses?

-Peter

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 23 Aug 2015 21:07:10 +0200

> its next version will 'enhance' MX responses?

Agree.

What I think I see in the draft is that "DANE and SMTP" is either "on" or "off", and I want more shades of gray.

1. Unsigned MX, Unsigned A/AAAA, not using TLS at all

2. Unsigned MX, Unsigned A/AAAA, TLS used with self-signed cert

3. Unsigned MX, Unsigned A/AAAA, TLS used with cert signed by CA (i.e. trusted cert)

4. Unsigned MX, Signed A/AAAA, TLS used with cert signed by CA (i.e. trusted cert)

5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed TLSA (i.e. trusted cert)

6. Signed MX, Signed A/AAAA, TLS used with cert validated with signed TLSA

I think 4 and 5 are equivalent, both better than 3 (which is better than 1, 2 and 3).

And of course there are more permutations, specifically with signed MX, but the for me interesting alternatives are the ones above, where MX is unsigned.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 23 Aug 2015 21:10:54 +0200

On 23 Aug 2015, at 20:46, [email-masked] wrote:

> You are https biased i guess. With an unsigned MX your secure chain is broken because the target you try to reach by an E-Mail address is directed to a target by an "unsecure" link. If the unsecure resolved target is then secured doesn't matter because you might be already on the wrong track.
>

Agree, but I think the cert for the TLS can be trusted in two ways: Either by looking at TLSA record or by looking at CA X.509 chain. I think they are equivalent and both have exactly the same weakness if the MX is unsigned.

I do not see why one of these two mechanisms should be "invalid" just because the MX is unsigned.

   Patrik

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Aug 2015 15:33:53 -0400 (EDT)

> What I think I see in the draft is that "DANE and SMTP" is either "on" or "off", and I want more shades of gray.

Well yes. Because you either authenticate or fail to authenticate and
refuse to deliver. We cannot decide whether or not to deliver in shades
of grey.

So we have:

- unsigned domain -> deliver without authentication, allow any TLS credential
- signed domain with unsined mx target -> deliver without authentication, allow any TLS credential
- signed domain with signed mx target -> deliver only if authentication succeeded.

You seem to want something like:

- unsigned domain with signed mx target -> deliver if authentication
   succeeds - despite possible spoofed MX record

What is the result of the last one? "Verified TLS to potential rogue server" ? I don't think we
would call that verified.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Aug 2015 23:09:16 +0000

> >_426._tcp.mail.example.om. IN TLSA ....

_25._tcp for SMTP, no idea where _426 is from.

> >What seems to have happened in the tests that Jan did was that IF the MX
> > was not signed, BUT the TLSA was signed and validated correctly, THEN
> > postfix did _NOT_ deliver the email. At all.

The tests were badly executed or profoundly misinterpreted.

> >I think that behaviour is wrong, and am unsure whether it is a bug in
> > postfix or whether it is a bug in the spec.

Neither.

> > That would be a bug in postfix? The spec states:

Would be, but is not, because Postfix does not behave as claimed.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 23 Aug 2015 23:17:26 +0000

> 1. Unsigned MX, Unsigned A/AAAA, not using TLS at all

No, this correctly uses opportunistic *unauthenticated* TLS, and
the certificate is irrelevant.

> 4. Unsigned MX, Signed A/AAAA, TLS used with cert signed by CA (i.e. trusted cert)

This is useless, without per-destination static configuration.

> 5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed TLSA (i.e. trusted cert)

This does not provide adequate MiTM protection, but the draft does
not rule out clients that might do this, rather it does not specify
use of DANE for this case.  If enough users want this, such features
could be added to Postfix.  The delivery is not immune to active
attacks, but arguably somewhat stronger than ignoring such TLSA
RRs.

The primary use-case would be a provider that is MX hosting lots
of domains, many of which are not DNSSEC signed, but the MX hosts
are.

> 6. Signed MX, Signed A/AAAA, TLS used with cert validated with signed TLSA

The draft (soon to be RFC) is about case 6.

-- 
	Viktor.

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 24 Aug 2015 04:51:19 +0200

> succeeds - despite possible spoofed MX record

I more and more think I understand what I am asking for and what I want.

My apologies if what I now write seems to be different from what I wrote earlier.

I want the validation of the cert used for the TLS connection to use the same rules for trust regardless of whether DANE is used (i.e. signed and properly validated TLSA record for the peer) or if X.509 cert/PKI from some CA is in use.

What I read in the draft, and what I read in the paper Jan wrote after testing Postfix and what I read here in the responses I get is that DANE is trusted LESS than X.509 certs.

And I think that is wrong.

I.e. we have two cases:

1. X.509

1.1 Unsigned MX
1.2 cert validated from some CA that is trusted

2. DANE

2.1 Unsigned MX
2.2 cert validated via signed TLSA with DNSSEC chain of trust to some TA

I think they should be equivalent.

If they are, also in the implementation in postfix, then just tell me and I'll shut up.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 24 Aug 2015 04:53:52 +0200

> _25._tcp for SMTP, no idea where _426 is from.

Sorry, 465.

But we could as well use 25 in the example.

> Would be, but is not, because Postfix does not behave as claimed.

Ok, thanks!!!

   paf

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 24 Aug 2015 04:57:07 +0200

On 24 Aug 2015, at 1:17, Viktor Dukhovni wrote:

> use of DANE for this case.

Good, then I am not crazy! :-)

> If enough users want this, such features

Exactly.

I think it is important to be able to tell people they SHOULD ABSOLUTELY get DANE for their port 25/465 incoming SMTP servers, regardless of whether they have X.509 certs for them or not. When hosting providers have TLSA records, then it is only up to the domain holder in such hosting environments to sign their zone to get complete protection.

I think it would be unfortunate if we end up in a catch 22 here as well regarding DNSSEC deployment.

   Patrik

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 03:00:15 +0000

On Mon, Aug 24, 2015 at 04:51:19AM +0200, Patrik F?ltstr?m wrote:

> I want the validation of the cert used for the TLS connection to use the
> same rules for trust regardless of whether DANE is used (i.e. signed and
> properly validated TLSA record for the peer) or if X.509 cert/PKI from
> some CA is in use.

What rules would that be?  Without DANE or local configuration,
SMTP does no authentication of the peer, for reasons explained in
Section 1.3 of the draft, that we don't need to repeat.

> What I read in the draft, and what I read in the paper Jan wrote after
> testing Postfix and what I read here in the responses I get is that DANE
> is trusted LESS than X.509 certs.

This is a misapprehesion on your part.

> 1.2 cert validated from some CA that is trusted

No.  Non-DANE SMTP does unauthenticated TLS, and the cert is ignored,
whether its trust chain verifies or not.

> 2.2 cert validated via signed TLSA with DNSSEC chain of trust to some TA

In both cases no authentication is performed.

> I think they should be equivalent.

They are equivalent, you get no protection from active attacks.

> If they are, also in the implementation in postfix, then just tell me and I'll shut up.

With "smtp_tls_security_level = dane", the two cases are treated
identically, neither authenticate the peer, and both deliver the
mail regardless of the content of the peer certificate if any.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 03:06:04 +0000

> Good, then I am not crazy! :-)

Don't jump to hasty conclusions. :-)

> > of domains, many of which are not DNSSEC signed, but the MX hosts

It is not clear this is worthwhile, and the security properties
are rather questionable.  This might get implemented anyway, as an
optional mitigation against MiTM where for some reason the MiTM
chooses to not modify unsigned DNS.  The only visible sign of this
working would be deferred mail when verification of the MX host
fails.  There should be no claim of security in the success case.

> I think it is important to be able to tell people they SHOULD ABSOLUTELY
> get DANE for their port 25/465 incoming SMTP servers, regardless of whether
> they have X.509 certs for them or not. When hosting providers have TLSA
> records, then it is only up to the domain holder in such hosting
> environments to sign their zone to get complete protection.
> 

There is no catch-22.  For secure SMTP, sign your domain, and if
hosted by a provider, choose one that signs the provider domain
and publishes TLSA RRs.

--
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2015 03:19:26 +0000

> will never get 100% DNSSEC deployment.

We already have non-zero deployment, in fact ~2000 domains now, and
soon gmx.de and web.de as announced last week.

I think this thread needs to end, or else needs a more relevant
(to this WG) reboot.

If you want to propose an update that requires SMTP clients to
employ DANE TLSA verification of MX hosts in signed zones even when
the MX RRset was not "secure", read the previous discussion of this
question in the list archives (yes, it has come up before) and make
a clear-cut proposal with as solid a rationale as you can.  

I am not sure this can get enough support to reach "rough consensus",
but I'm open to the possibility.  If we don't misrepresent the
resulting security, it may be an acceptable deterrent to downgrade
attacks against the MX host when for some reason the attack is
unable or reluctant to tamper with DNS.

I'll survey the larger providers on this question at M3AAWG in
Atlanta in October.  In the mean-time we're making progress on
deploying DANE for SMTP as specified in the draft (upcoming RFC).

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Aug 2015 23:22:04 -0400 (EDT)

Exactly.

> whether its trust chain verifies or not.

I think what Patrik is asking for is that if the target mx hostname is
signed and has a TLSA record, why not validate that and do not use it
for mail delivery if the TLSA record fails? The logs would still NOT
say that the mail was delivered seucrely, because it was not as the MX
record itself was not secure.

I can't see a reason why not to do that, although I can also see why
implementations wouldn't care about this case and just skip all
certificate validation.

Paul

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 24 Aug 2015 08:22:27 +0200

> This is a misapprehesion on your part.

Thank you!

> No.  Non-DANE SMTP does unauthenticated TLS, and the cert is ignored, whether its trust chain verifies or not.
>
>> 2. DANE
>>
>> 2.1 Unsigned MX

Thanks!

> With "smtp_tls_security_level = dane", the two cases are treated identically, neither authenticate the peer, and both deliver the mail regardless of the content of the peer certificate if any.

Excellent!

That was what I was hoping.

Then I misunderstood the tests Jan did.

   Patrik