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

Viktor Dukhovni <> Wed, 22 July 2015 17:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 307ED1B2BC3 for <>; Wed, 22 Jul 2015 10:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qAsNNXyHkQW7 for <>; Wed, 22 Jul 2015 10:16:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FA861A8711 for <>; Wed, 22 Jul 2015 10:16:24 -0700 (PDT)
Received: by (Postfix, from userid 1034) id AEE7C284B55; Wed, 22 Jul 2015 17:16:22 +0000 (UTC)
Date: Wed, 22 Jul 2015 17:16:22 +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, 22 Jul 2015 17:16:26 -0000

On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:

> I think the server should stick to one chain, from the root to itself,
> so it does not have to deal with variable chain blobs per client.
> That will allow server code to stick to something like hourly
> regenerating the blob for use with all clients.

>From the root to its own TLSA RRset, however, this can be complicated
in the presence of CNAMEs: IN CNAME IN A IN CNAME IN TLSA 2 0 1 <trust-anchor-digest>

In this example, three leaf RRsets need to be verified back to the
root (with notable overlaps in the chains): IN CNAME <RDATA> IN CNAME <RDATA> IN TLSA <RDATA>

How should these be organized?  It seems to me that the immediate
answer that gets the client going in the right direction is the
first CNAME, which enables to construct the TLSA base domain,
and then to follow the second CNAME to the ultimate TLSA RRset.

Should everything other than the first CNAME be in additional
records?  Should all the above (with their RRSIGs) be in the answer
section, with the union of the supporting DNSKEY/RRSIG/DS records
as additional?

I tried to ask a related question during the meeting, but bandwidth
to explain the context was limited:  Should proofs of non-delegation
be included, to keep gTLDs and ccTLDs honest for some future CT for
DNS?  Specifically, suppose you see: IN TLSA <rrdata>

with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
records that demonstrate that "" (and
are not delegated?  (Such records might then be subject to "gossip"
or related "transparency" counter-measures).

> I do strongly prefer the binary blob to be in raw dns format. That
> will make parsing easier with existing code, and over time we will
> not run into issues where dns libraries support newer algorithms
> but this specific dnssec parsing code isn't updated.

I'm not sure what "algorithms" you have in mind?  We should perhaps
allow (even encourage) "compression" to reduce the payload size,
this would require the client to "uncompress" (canonicalize) all
the RRs before checking the RRsigs.  Once canonicalized, DNSSEC
signature checks don't care how the canonical forms of each RRset
were constructed, and the wire form (which is not canonical) is
not more compatible with new signature algorithms than any other

> As for ekr's question on why not stuff this inside X.509, that would not
> be compatible with tls raw pulic keys that only contain a SBKI, and drag
> back into the protocol more ASN.1 parsing and containers.

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.