Subject: [dane] Discussion: New draft: DANE opportunistic TLS for SMTP

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 May 2013 14:09:51 +0000

https://tools.ietf.org/id/draft-dukhovni-smtp-opportunistic-tls-00.html

This proposed protocol supports opportunistic TLS with DANE
authentication resistant to MITM downgrade attacks.

Domains that publish DNSSEC signed MX records and corresponding
TLSA records support security via the DANE PKI when the sender
implements opportunistic DANE TLS.

Feedback welcome.  The goal is encourage interoperable implementations
that incrementally increase the security of the Internet SMTP
backbone as DNSSEC and DANE are adopted.

This protocol does not promise unconditional secure delivery, the
sender will send via unauthenticated TLS or even plain-text when
a destination does not publish secure TLSA records for secure MX
hosts.  However, it can be used for unconditional security with
sender-selected destinations by requiring a DANE authenticated
connection when the recipient domain is known/expected to publish
secure DANE TLSA RRs.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 May 2013 08:16:11 -0700

> authentication resistant to MITM downgrade attacks.

This seems like really important work. Lots of people turn on STARTTLS in SMTP with no actual certificate verification because the want better than nothing security but don't want the operational overhead of actually rejecting bad TLS. It seems like this proposal actually gets them better protection with the same lack of overhead if they don't want to reject. It also gives those who want to reject bad TLS a better basis to do so.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 May 2013 16:01:30 +0000

On Mon, May 20, 2013 at 08:16:11AM -0700, Paul Hoffman wrote:

> This seems like really important work. Lots of people turn on
> STARTTLS in SMTP with no actual certificate verification because
> the want better than nothing security but don't want the operational
> overhead of actually rejecting bad TLS. It seems like this proposal
> actually gets them better protection with the same lack of overhead
> if they don't want to reject. It also gives those who want to reject
> bad TLS a better basis to do so.

I should note that my draft substantively overlaps draft-ietf-dane-smtp-01.
Core differences:

    - The new draft includes a more expansive treatment of the semantics of the
      various TLSA RR types in the context of SMTP.

    - The new draft addresses SMTP submission with RFC 6409 SRV records.

    - The new draft specifies the target of a CNAME as the base name for TLSA
      lookups with MX hosts (and with non-MX domains).

Since https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3
also specifies opportunistic security, the core premise is common
to the two drafts.  Perhaps the two drafts can be merged.

-- 
	Viktor.