Subject: Re: [dane] DANE for MX host via insecure MX RR?

From: Michael Ströder <[email-masked]>
Date: Thu, 10 Sep 2015 18:31:49 +0200

Viktor Dukhovni wrote:
> On Sun, Aug 23, 2015 at 07:29:50PM +0200, Patrik F?ltstr?m wrote:
> 
>> If not, we will get absolutely zero deployment of DANE with SMTP as we
>> 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.

Without a signed MX there's no cryptographically secured binding between the
recipient domain (right address part) and the public key used for TLS authc.

So I'm strictly against this possibility and the developers of a MTA I spoke
with today are also strongly against this.

@Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If you drop
the requirement for signed MX RRs DANE would not be worth the effort to be
implemented.

Ciao, Michael.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Sep 2015 16:53:37 +0000

> the requirement for signed MX RRs DANE would not be worth the effort to be

Note, the hypothetical proposal would not weaken DANE in any way,
nor would it "drop" the requirement to pay attention to the security
status of the MX RRset, in particular "bogus" replies or other DNS
errors in MX resolution would still result in deferral of mail.

All that would hypothetically happen, is that even when the MX
RRset is "insecure" (verifiably from an unsigned zone) but the
target MX host is in a signed zone and has "secure" TLSA records,
DANE authentication might be "SHOULD" or "MUST", rather than the
current "MAY".

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-2.2.1

       Since the protocol in this memo is an "opportunistic security"
       protocol ([RFC7435]) the SMTP client MAY elect to use DANE TLS (as
       described in Section 2.2.2 below) even with MX hosts obtained via an
       "insecure" MX RRSet.  For example, when a hosting provider has a
       signed DNS zone and publishes TLSA records for its SMTP servers,
       hosted domains that are not signed may still benefit from the
       provider's TLSA records.  Deliveries via the provider's SMTP servers
       will not be subject to active attacks when sending SMTP clients elect
       to make use of the provider's TLSA records (active attacks that
       tamper with the "insecure" MX RRSet are of course still possible in
       this case).

I think the current "MAY" is sufficient for now, but if that proves
to be a valuable feature of the protocol, an a short update BCP
RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible
in the future.

So long as such sessions are not reported as secure, and are not
accepted when DANE authentication is mandatory (e.g. Postfix
"dane-only" TLS security level), the proposal does not in any
way reduce the security of DANE as specified.

The main risk is with reliability.  Perhaps only those customers
of a service provider that operate DNSSEC signed domains are willing
to accept service availability risk in case of DANE authentication
failure, and the customers with unsigned zones want service
availability above all else.  If the proposal is formalized, then
all customer domains suffer if the TLSA records are ever wrong,
even those whose domains are unsigned.  

Of course service outages happen for operational reasons beyond
incorrect TLSA record updates (or failure to update).  And the
sending domains that elect the "MAY" policy will defer email even
for the unsigned domains.

So the proposal is not obviously damaging, just possibly premature.
We'll know more once there is more deployment and people either
learn (or don't learn) to operate their TLSA records correctly.

-- 
	Viktor.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 10 Sep 2015 19:52:34 +0200

> RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible

Hmm...I can understand why you wrote it like this. But some people are more
eager and want to push things into mandatory way. I wished DANE starts with
"MUST" from the very beginning. It's a new standard and a big invest anyway.

> way reduce the security of DANE as specified.

Postfix's "dane-only" requires successfully validated signed MX RRs?

> even those whose domains are unsigned.

Yes, service providers have opt-in mechs for such a distinction. And of course
they must have *different* right-hand parts in their MX RRs for both cases.

> learn (or don't learn) to operate their TLSA records correctly.

People should be prepared that some MTAs will require signed MX RRs.

Ciao, Michael.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Sep 2015 18:18:22 +0000

> "MUST" from the very beginning. It's a new standard and a big invest anyway.

It does start with MUST, when the MX RRset is "secure" *and* the
MX host address records are "secure" *and* "secure" TLSA records
are published.  When the first condition is false, and you don't
actually get MiTM protection, there's a MAY.  The MAY allows one
to get a secure-channel to possibly the wrong host (this is at
least tamper-evident if logs are read).

> Postfix's "dane-only" requires successfully validated signed MX RRs?

Requires all three conditions, and matching TLSA records for the
peer domain.  If you know a domain has committed to implement DANE
and keep it that way, you can set the policy for that domain to
"dane-only".

> People should be prepared that some MTAs will require signed MX RRs.

Not in the forseeable future.  Without signed MX RRs, many sites
will not take advantage of DANE TLSA RRs for the corresponding MX
hosts even if present.  That's different from requiring the MX
RRset to be signed in the first place.

-- 
	Viktor.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 10 Sep 2015 20:28:19 +0200

Viktor Dukhovni wrote:
> [..]  Without signed MX RRs, many sites will not take advantage of DANE
> TLSA RRs for the corresponding MX hosts even if present.

That's what I meant.

> That's different from requiring the MX

Yes.

Ciao, Michael.