Subject: [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19)

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:07:15 +0200

On 1. 5. 2012, at 8:05, Jakob Schlyter wrote:

> On 30 apr 2012, at 15:53, Martin Rex wrote:
> 
>> When trying to deliver mail to @toad.com, the only secure
>> question to ask is whether the server is authorized to process
>> Email for @toad.com.  For certificates issued from the traditional
>> PKIX world, that would require a "toad.com" DNSName SAN.
> 
> That would require large hosting provider, e.g. Google Apps, to update their SMTP TLS certificates each and every time they added or removed a customer. In my book, that would not scale. I believe we should focus on securing the transport, not building a TLS-based application authorization system.

And I would add this is out of the scope of the DANE protocol...

If you want MX fixed, do it.  But it is currently broken even just for TLS.  Either there will be some other document which fixes interaction of SMTP and TLS and throws DANE on top of it, or the MTAs will just cope ;), but we cannot specify anything which is broken right now.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 3 May 2012 11:25:40 -0400

> If you want MX fixed, do it.  But it is currently broken even just for TLS.  Either there will be some other document which fixes interaction of SMTP and TLS and throws DANE on top of it, or the MT…

Oh, this discussion again.  If you want real assurance that an outsourced mail server is authorized to operate a mail server, then you need:
1. DNSSEC on the MX record (in which case the hosting provider can use his own cert)
2. Certificate reissuance whenever the set of customers changes (as Jakob notes)
This was raised earlier, e.g.:
<http://www.ietf.org/mail-archive/web/dane/current/msg04023.html>

I relented on that discussion only because people seemed to think that the MX world were comfortable with the spoofing risk, and communities that were worried about spoofing (e.g., XMPP) could write their own independent specs.  

--Richard

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 May 2012 16:32:09 +0100

Richard L. Barnes <[email-masked]> wrote:
>
> Oh, this discussion again.  If you want real assurance that an
> outsourced mail server is authorized to operate a mail server, then you
> need:

> 2. Certificate reissuance whenever the set of customers changes (as Jakob notes)

You don't need both of these. If you do (1) then the server certificate
identifies the MX target host name, so (2) is not necessary. (2) is only
necessary if you put the mail domain (MX owner) in the cert, but if you do
that then DNSSEC for the MX lookup isn't necessary.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Northeast 4 or 5. Slight. Occasional rain, fog patches. Moderate or
good, occasionally very poor.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:58:54 +0200

On 3. 5. 2012, at 17:25, Richard L. Barnes wrote:
> Oh, this discussion again.

No, it's _not_ that discussion again.  I wanted to say that we
don't _want_ to discuss and fix it in the DANE WG.  Somebody fix
it elsewhere and come back.

O.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 May 2012 10:02:19 +1000

In message <[email-masked]>, =?utf-8?Q?Ond=C5=99ej
> it elsewhere and come back.

While this isn't be a issue for DANE, DANE actually *removes* the
last known threat, downgrade by filtering/not offering STARTTLS
from the EHLO response, to making MX and STARTTLS work globally as
it provides a method to signal that TLS should be available and as
a consequence you should see a STARTTLS.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 03:43:26 +0200 (MEST)

Mark Andrews wrote:
> O. writes:

100 ack.

> a consequence you should see a STARTTLS.

Please do not confuse DANE with DNSSEC.

example:

    foo.x.         IN MX     10  mx.bar.y.
    mx.bar.y.      IN CNAME      tweety.baz.z.
    tweety.baz.z.  IN A          0.1.2.3

plus:
    foo.x. is a DNS-Zone with DNSSEC enabled
    bar.y. is a DNS-Zone without DNSSEC
    baz.z. is a DNS-Zone with DNSSEC enabled

The DNS software module does not know about MX records and will
not look at any of the above.

To _me_ this looks like opening a can of worms, not like closing one,
and the apps protocols that want such scenarios secured by DNSSEC,
will have to design and discuss their desired security architecture,
how to perform&implement the various lookups and possible indirections,
how to compute the desired result/outcome from the various possibilities
leveraged by the DNS magic machinery and describe:

   - to implementers of the apps protocol how to implement this
   - to admins of the machines how to configure the various possible
     scenarios

and provide a security considerations about all the potential and
non-obvious pitfalls.

Btw. in the example above, "mx.bar.y. IN CNAME tweety.baz.z."
could have been a DNS reply spoofed by an attacker.

I have significant doubts, that DANE is the right forum to discuss any
of these very apps-specific characteristics and requirements.
And DANE-protocol LC is definitely the wrong time for it
(IIRC, the DANE WG tabled this discussion before it got deeply ratholed
 over it).

*I* really do not want to discuss this any further.

-Martin