Re: [TLS] draft-shore-tls-dnssec-chain-extension-00

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 19 July 2015 19:49 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6D1A8A48 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 12:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Vn9LtsiKpBmS for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 12:49:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC981A8A3A for <tls@ietf.org>; Sun, 19 Jul 2015 12:49:44 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CB138284D6F; Sun, 19 Jul 2015 19:49:43 +0000 (UTC)
Date: Sun, 19 Jul 2015 19:49:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150719194943.GO28047@mournblade.imrryr.org>
References: <55922571.8080605@nomountain.net> <alpine.LFD.2.11.1506302319510.29441@bofh.nohats.ca> <CAHPuVdVc01v4EKM5A9OEQ2Y78b=zZeQjKHigP3NR5nAT=y7FwQ@mail.gmail.com> <20150701035820.GJ14121@mournblade.imrryr.org> <87k2twm2ol.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87k2twm2ol.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vCaUn3TiNnnCA_YYA7_lcOEJesA>
Subject: Re: [TLS] draft-shore-tls-dnssec-chain-extension-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2015 19:49:46 -0000

On Sun, Jul 19, 2015 at 08:18:18PM +0200, Daniel Kahn Gillmor wrote:

> On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> > Instead, there would need to be in various cases:
> >
> >     * A validated chain of CNAMEs (possibly synthesized via validated
> >       DNAME RRs) leading from the client's requested SNI name to
> >       a final TLSA base domain.  (0 or more CNAME/DNAME indirection
> >       records and all the DNSKEY/DS/RRSIG records to validate
> >       these).
> >
> >     * A validated chain of CNAMES from _port._proto.<base-domain> to
> >       an actual validated TLSA RRset (and ...).
> >
> >     * The final TLSA RRset with all the requisite validation records.
> >
> >     * Also a potential change in the client's notion of the reference
> >       identifier to match in certificates, to the final TLSA base domain.
> 
> Complicating this further, there could be a chain to an SRV or MX
> record, which then needs to chain to the TLSA, in think (possibly with
> CNAMEs in the mix).  This is potentially a pretty long chain.  also: how
> does a multi-tenanted server know what SRV or MX chain to include in the
> chain?

My reading of the draft is that it is primary aimed at making DANE
practical for HTTPS,  where last-mile considerations on the client
end are a significant part of the adoption barrier.

For HTTP, MX and SRV records are out of scope.  Clients that depend
on DNS to the extent of determining the server identity based on
MX or SRV records, already need DNSSEC to avoid MiTM issues, and
at least in the case of SMTP and XMPP are expected to handle DANE
without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains).

-- 
	Viktor.