[dane] DNAMEs and TLSA name checks.

Viktor Dukhovni <viktor1dane@dukhovni.org> Tue, 18 February 2014 18:41 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2661A010A for <dane@ietfa.amsl.com>; Tue, 18 Feb 2014 10:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfhM2H-qzgfF for <dane@ietfa.amsl.com>; Tue, 18 Feb 2014 10:41:33 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 75B201A00F2 for <dane@ietf.org>; Tue, 18 Feb 2014 10:41:33 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F06642AB258; Tue, 18 Feb 2014 18:41:28 +0000 (UTC)
Date: Tue, 18 Feb 2014 18:41:28 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140218184128.GV278@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kL2wa0YiGsS2CkNNjrKE1TQpfRw
Subject: [dane] DNAMEs and TLSA name checks.
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 18:41:35 -0000

A comment Paul Wouters' OpenPGP drafts leads to an interesting
observation about the interaction of DNAME redirection and TLSA
name checks.

Suppose we have DNAME that designates "b.example" as an alternative
name for "a.example".

Suppose, in a hypothetical universe where browsers implement DANE,
a user browses to <https://www.b.example/>.  The DNSSEC query for the
address records of "www.b.example" will determine that this host
is an alias:

    b.example.	IN DNAME	a.example.
    www.b.example.	IN CNAME	www.a.example.
    ; + related RRSIGs proving the DNAME "secure"

In our hypothetical universe, there are TLSA records of the form:

    _443._tcp.www.a.example. IN TLSA DANE-TA Cert SHA2-256 {blob}
    ; + related RRSIGs proving the TLSA RRset "secure"

If the user's browser does not follow the advice of the DANE ops
draft, it will look for TLSA records at the original dns name,
that is not CNAME expanded:

    _443._tcp.www.b.example. IN TLSA ?

Because of the DNAME it will see the same TLSA RRset:

    b.example.	IN DNAME	a.example.
    _443._tcp.www.b.example. IN CNAME _443._tcp.www.a.example.
    ; + related RRSIGs proving the DNAME "secure"
    _443._tcp.www.a.example. IN TLSA DANE-TA Cert SHA2-256 {blob}
    ; + related RRSIGs proving the TLSA RRset "secure"

However, its "TLSA" base domain is "www.b.example", thus given a
CU of DANE-TA(2) it will expect the server certificate to include
"www.b.example".  This means that servers would need to carry all
DNAME variant DNS name forms in their certificates.

If, however, CNAME expansion is performed per the OPs draft, the
TLSA base domain will be "www.a.example", and server certificates
need only match the primary domain.

This issue should be rare with SRV and MX records, since the target
of the SRV or MX record is required to not be an alias and the TLSA
base domain is taken from the target of SRV or MX records.

The point of this post is to highlight the interaction of DNAME
records with certificate name checks and why (absent SRV or MX
redirection) TLSA RRs should be sought after CNAME expansion of
the target domain.

The SMTP draft requires similar logic when MTAs allow CNAMEs in
the MX hostname.  I don't recall whether the SRV draft says anything
about CNAME expansion for SRV targets (again not supposed to happen,
but if supported, should probably be CNAME expanded).

-- 
	Viktor.