Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-09.txt

From: [email-masked]
Date: Mon, 05 May 2014 22:15:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

        Title           : SMTP security via opportunistic DANE TLS
        Authors         : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-smtp-with-dane-09.txt
	Pages           : 34
	Date            : 2014-05-05

Abstract:
   This memo describes a downgrade-resistant protocol for SMTP transport
   security between Mail Transfer Agents (MTAs) based on the DNS-Based
   Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of
   this protocol enables an incremental transition of the Internet email
   backbone to one using encrypted and authenticated Transport Layer
   Security (TLS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 May 2014 05:33:38 +0000

> 	Filename        : draft-ietf-dane-smtp-with-dane-09.txt

Changes from -08:

    - Document organization feedback from Olafur.  Some long sections
      broken up into smaller pieces, and some sub-sections promoted to
      top-level sections.

    - SMTP clients MAY elect to make use of TLSA records after "insecure"
      MX redirection, but MUST NOT misrepresent this as secure delivery.

    - Server logs SHOULD show the original (not CNAME expanded) MX hostname
      when the MX RRset is "insecure".  Otherwise, redirection leading
      to downgrades may not be "tamper-evident".

    - SMTP clients MAY elect to make use of "insecure" TLSA records (typically
      resulting from "insecure" CNAME indirection from
      _port._tcp.<servername>, as the zone containing <servername> is
      always signed when TLSA records are requested).  Again, MUST NOT
      misrepresent resulting security.

    - Routine corrections already discussed, based on Tom Ritter's feedback.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 6 May 2014 11:42:55 -0400

Dear colleagues, 

The mail exchanges on this draft and conversations with Victor have brought up a new issue that we want to 
highlight. (this message uses vocabulary from the dane-vocabulary draft) 

Question: Are there more than one security models possible for applications/protocols that use DANE ? 

The original DANE/TLSA model in effect says "all records used for DANE must be DNSSEC protected, both 
actual records and DNS records used to get to those records." 
The protocol we designed for HTTPS, unlike many other protocols uses Address records as Service specification. 
Protocols that use a different record (like MX or SRV) as a service specification record now have 2 places to put 
Authentication (TLSA) records. 
SRV draft and SMTP drafts both say put Authentication records with Address records, as that is better for operators. 

The SRV and Vocabulary drafts both assume that both Service records and Address records are secured if the 
Authentication records are stored with Address records, (requiring DNSSEC for all sets).

The SMTP draft is proposing that it is ok to use TLSA records that are stored with Address records even if the
Service (MX) records are not signed. 

Attempts to answer the question as what kind of security models can we have with DANE? 
	Full: All records used to find service, address and authentication are DNSSEC protected 
	Server only: Address and Authentication records are DNSSEC protected 
	Service only: Service and Authentication records are protected but not Address records

Questions that need answers: 
- What are the security implications of each model? 
- What types of security does each model provide ? 
- What is not possible with each model?
- What threats does each model handle? 
- any others? 

Do we (as a WG) want to document these models formally and the implications of each model operationally ? 

	Olafur & Warren 

On May 6, 2014, at 1:33 AM, Viktor Dukhovni <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 May 2014 16:44:38 +0000

On Tue, May 06, 2014 at 11:42:55AM -0400, Olafur Gudmundsson wrote:

> The SMTP draft is proposing that it is ok to use TLSA records that are
> stored with Address records even if the Service (MX) records are not
> signed.

Note, this is predicated on the assumption that the client's security
policy is "opportunistic", and that it is OK to send email in the
clear or with unauthenticated TLS, when DANE is not employed.

The draft also briefly touches on "mandatory DANE TLS", in which
the sender demands strong transport protection for some destination
domains.  In that case, only "Full" below is acceptable.

> - What threats does each model handle? 

So for me, the context in which this questions is set is whether
the application security policy is mandatory (security expected)
or opportunistic (no security expected, but opportunities for
security on a peer-by-peer basis are not missed).

Thus, I would suggest that the above 3-way choice is not at the
right layer of the problem.  The model is mandatory protection or
opportunistic security, or ...  which then leads one to make the
appropriate choices.

There are variations on the models:

    - Mandatory protection with DANE when available and PKIX as a fallback.
      (Works poorly with protocols that employ DNS SSRs, but is viable for
      protocols ala HTTPS).

    - Opportunistic DANE, with key-continuity protocols (authenticated
      pinning e.g. TACK, this also runs into difficulties with SSRs).

    - ...

That said, the key dichotomy is I believe "mandatory" vs.
"opportunistic" security.  The discussion about "discovery" in
London was in disguise a discussion about the admissibility of
"opportunistic" uses of DANE, which need to "discover" peers that
support DANE.  We seem to have crossed that bridge without falling
off, so now we can pay attention to each relevant model as
further specifications are developed.

> Do we (as a WG) want to document these models formally and the
> implications of each model operationally ?

I believe that opportunistic security models are going to be more
important in IETF protocols (some of you may be keeping track of
the lively discussion on the saag list).  And thus it is not
unreasonable to define "opportunistic DANE TLS" more broadly, with
the SMTP draft a first step in that direction (a test case if you
like).

-- 
	Viktor.