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

Paul Wouters <> Thu, 30 July 2015 10:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4A811A89AB for <>; Thu, 30 Jul 2015 03:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9lud74Kd2yD for <>; Thu, 30 Jul 2015 03:30:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C3D21B29B2 for <>; Thu, 30 Jul 2015 03:28:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3mhnyM2Wdnz3Hd; Thu, 30 Jul 2015 12:28:27 +0200 (CEST)
Authentication-Results:; dkim=pass (1024-bit key) header.b=M2LSThC6
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id n2Xan6f7rVBO; Thu, 30 Jul 2015 12:28:26 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 30 Jul 2015 12:28:26 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 85D8A80042; Thu, 30 Jul 2015 06:28:25 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1438252105; bh=xUQvl9+N1fzGzvBmrTbzMSIC9yPzDxfrzwlieMuNZSI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M2LSThC67rlDXXzVwmEzDLGgEK6qXiVc6yzYiUZQ1ucodkNOZQzgJY4256DrQiEyj +y1cG3pDRGH+auPStbqUhJp3yTjTtKu4ZHbCt1gF76q97u3HJ70pB6NE8YcRaX0l78 cALO4fa5xwQb4SwlQpciBtvahnt7ryESm2XwrW2w=
Received: from localhost (paul@localhost) by (8.15.1/8.15.1/Submit) with ESMTP id t6UASO0g001584; Thu, 30 Jul 2015 06:28:24 -0400
X-Authentication-Warning: paul owned process doing -bs
Date: Thu, 30 Jul 2015 06:28:24 -0400
From: Paul Wouters <>
To: Melinda Shore <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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: Thu, 30 Jul 2015 10:30:38 -0000

On Tue, 28 Jul 2015, Melinda Shore wrote:

> On 7/28/15 5:44 PM, Shumon Huque wrote:
>> 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.
> That draft really is pretty immature and at this point it's not
> clear whether and how it's going to progress.  Paul Wouters can
> speak for himself about where he thinks the draft needs to go

The current draft focussed on the container format of the data, but
after some discussion in the dns and trans groups, it became clear
that the more important question to answer first is what to log.
Especially when you want to protect against a rogue parent, it becomes
important to log zone cuts along with the keys so that consumers of
the log can see the key/parent responsible for publishing the data.

There are also issues with preventing spam/ddos attacks against the
logs, similar but different from certificates.

> Well, sort of.  We did talk about creating a new certificate
> extension rather than a TLS extension but opted not to.  The
> one advantage of an X.509 extension would have been that it wouldn't
> require protocol changes, but it still would have required modifying
> both the server and the endpoint.

The TLS extension would be easier to configure than requiring the system
administrator to regenerate (and re-sign?) certificates. Or mark certain
data (the dnssec blob) as not covered by the certificate signature.
People will end up putting the wrong certificate signatures in TLSA
records, etc. The TLS extension separates this more cleanly, and only
the TLS servers supporting the new extension need to know about how
to generate and serve the dnssec blob. Aind finally, with raw public
keys there is no way to embed the dnssec blob into the "certificate"
payload, as it is defined (on purpose) to only contain the SPKI.