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

Shumon Huque <> Wed, 29 July 2015 02:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 361A11B352D for <>; Tue, 28 Jul 2015 19:43:32 -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 CzJJMOVgGVe7 for <>; Tue, 28 Jul 2015 19:43:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 049BE1B3524 for <>; Tue, 28 Jul 2015 19:43:30 -0700 (PDT)
Received: by qgii95 with SMTP id i95so85651337qgi.2 for <>; Tue, 28 Jul 2015 19:43:29 -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=VsfyhEn7xDiwPYm0tvK/0YB1TGT3dyUtJ47PSLuZtdk=; b=rf/+mmOmqJptazPxAm3K+vnsXU/jofTygOqmLvcE+ONBCgWTN5zgRChqpbvQNBHUZP dEdF9SxxPZZlGlik2I0yik5ap/4v/2GGrHsnVxPPRvr84FfIBmgH/pXeL4AR3N2sKwqP Os4WXOZ8PP5/4NlMElL9+fnT1zdzNGCGkoPhJ+C9EL8QTVVhepaEj2IbIYaas6binHXD HFGIBonVkYrezwmo/3ki6/X3wA/Qf5JqROl+jOdzJqTa9cEsIM8Lm7w0QilFoFBgQ9xq v94PhbyGF+j/A8TSE5j25e7reIsTAw3L12u6I2IrTZ6CZS59y5P+EyXfkmLjb4x1rP7W sPHQ==
MIME-Version: 1.0
X-Received: by with SMTP id s21mr41004044qgs.10.1438137809306; Tue, 28 Jul 2015 19:43:29 -0700 (PDT)
Received: by with HTTP; Tue, 28 Jul 2015 19:43:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 28 Jul 2015 22:43:29 -0400
Message-ID: <>
From: Shumon Huque <>
Content-Type: multipart/alternative; boundary="001a11c12c4043125a051bfa8d84"
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:43:32 -0000

On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni <>

> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
> 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.

Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
target rather than the owner name. This doesn't seem to be how many early
HTTPS sites are deploying TLSA records though, e.g.

> 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 probably doesn't today. I'll check into this.

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

Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
threat we should take into account.

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

Encoded yes, but not necessarily on what protocol element carries the
encoding. It depends on what mechanism is being used for the must-staple
assertion. The X.509 TLS feature extension mechanism requires a list of TLS
extension values to be specified. Using a new TLS certificate type would
not be compatible with that.

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.

Yes, I agree.

Shumon Huque.