Re: [TLS] draft-shore-tks-dnssec-chains-extension

Viktor Dukhovni <> Wed, 29 July 2015 02:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A6E51A1B59 for <>; Tue, 28 Jul 2015 19:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPOOF_COM2OTH=2.723] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-30jy83ifdK for <>; Tue, 28 Jul 2015 19:05:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 154061A1B40 for <>; Tue, 28 Jul 2015 19:05:39 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 3048B284D5A; Wed, 29 Jul 2015 02:05:38 +0000 (UTC)
Date: Wed, 29 Jul 2015 02:05:38 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jul 2015 02:05:40 -0000

On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:

> For the following hypothetical example:
>   IN   CNAME
>              IN   TLSA     2 0 1 <cadata_blob>

This is simpler than the general case, everything is still "linear",
because there's only a CNAME chain leading to the TLSA RRset.

More generally, there's also a CNAME chain leading to the TLSA base
domain: IN CNAME IN CNAME IN A IN CNAME IN TLSA 2 0 1 <cadata_blob>

Here, we have CNAME (perhaps via a DNAME) indirection from the SNI
name ( to the actual TLSA base domain (

And then more CNAME records from there to the CDN provider's TLSA

This is no longer the DNS response to a single query (iterative
resolvers generally chase CNAMEs), since one first CNAME expands
the original target hostname to obtain the TLSA base domain (provided
the CNAME chain is validated end-to-end) and then CNAME expands
the _443._tcp. prefixed base domain to find the TLSA RRset.

> the getdns library's validation chain function currently returns (RRSIGs
> omitted for brevity):
> TLSA <set>
> DNSKEY <set>
> DS <set>
>   com. DNSKEY <set>
>   com. DS <set>
>   . DNSKEY
> DNSKEY <set>
> DS <set>
>   net. DNSKEY <set>
>   net. DS <set>

The getdns library is unlikely to handle the fully general case,
because first the TLSA base domain has to be found.

> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the future incorporate SCT RRs in
> the chain. However do we really need to? The TLS server is the one doing
> the DNS queries, so it could perform the SCT checks against the logs it
> trusts, while querying the chain records, and then build the validated
> chain. I'm not sure there is a need for the TLS client to additionally do
> these log checks, so it doesn't need to have that info delivered in the
> chain.

The TLS server is not trusted, the whole point is detect malfeasance,
where the DNS operator and TLS server conspire to lie (to selected

> > This really can't go in the certificate, because then certificates
> > would have to be updated as often as RRSIGS are regenerated.  That
> > seems exceedingly unlikely to be deployable.
> >
> I believe Eric's question was about why this couldn't be done via a new
> 'Certificate Type' (and not about embedding the chain in the X.509 cert). I
> presume the idea being the new certificate type would allow both the
> server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
> be delivered in the server's Certificate Message. I believe the argument
> for doing it via a new TLS extension was that it would allow us to mandate
> the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> Extension.

I see.  I think the question of whether "must staple DANE" is
supported or not is quite orthogonal to the question of how DANE
stapled data is encoded.

The disadvantage of this being a new certificate type is that AFAIK
it would then not be orthogonal to the choice between X.509 chains
and raw public keys.  We might then have a (small) combinatorial mess:
	traditional X.509 chain
	X.509 chain with stapled DANE evidence
	raw public key
	raw public key with stapled DANE evidence

I think the extension is a more logical separation of duties, but
I am willing to hear contrary arguments.