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

Shumon Huque <> Wed, 29 July 2015 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACE971B3367 for <>; Tue, 28 Jul 2015 18:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8XxxPBwzurB5 for <>; Tue, 28 Jul 2015 18:44:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61B291B3364 for <>; Tue, 28 Jul 2015 18:44:35 -0700 (PDT)
Received: by qkfc129 with SMTP id c129so59919959qkf.1 for <>; Tue, 28 Jul 2015 18:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+kslX0bOs/CoBEzT80hDoRDkarrYh7EDbAnmx3z1yIQ=; b=fVQqpLIFE6da/fMPG4nFimBceDy6YLTwNPKjwZ2mtnlXRYUnIRr4dSVmXncu1GWJuf e8gjs9ytXgqx5ydfsxrJgblwY+I7KTlnnQ7M4MewpDa/ipVpQ5EIeyoAEKFI1ZcN6qKn HGmaUrA5NtSTDBgaMl/+ncDqk0yE+oNRc7Vsti6nN1sLNeNIWt2BwJ2jsF9+6sebgHjD 3YqHOaEHa1y7NVklzIEMBklNacr6o6+wsRXATrIbXj+Ilw4IPQu4Ijmp91jWxtAR2m4I O1jaCY1or40tENkQJXD39fsbYdfM0+rt0az//0RZOxa0J27XdvvDcita/XHyb/tlt6FY AMtQ==
MIME-Version: 1.0
X-Received: by with SMTP id f80mr54057583qkf.2.1438134274658; Tue, 28 Jul 2015 18:44:34 -0700 (PDT)
Received: by with HTTP; Tue, 28 Jul 2015 18:44:34 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 28 Jul 2015 21:44:34 -0400
Message-ID: <>
From: Shumon Huque <>
Content-Type: multipart/alternative; boundary="001a1147b55c949709051bf9baf0"
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 01:44:37 -0000

On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni <>

> 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 A
> 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):
> 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.

There are a number of possibilities here, including more complicated data
structures. But I think we can use the current linear chain structure and
have it composed of multiple sequences corresponding to intersecting
branches of the DNS tree.

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

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

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'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more
before considering DNSSEC key transparency issues.

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

> > 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.

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

Shumon Huque