Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Viktor Dukhovni <> Mon, 26 February 2018 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 331B1124BFA; Mon, 26 Feb 2018 09:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2NyZk_sJzLuy; Mon, 26 Feb 2018 09:20:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A73BA12025C; Mon, 26 Feb 2018 09:20:43 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E9CF67A3309; Mon, 26 Feb 2018 17:20:36 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Mon, 26 Feb 2018 12:20:36 -0500
Cc: tls-chairs <>,, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
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: Mon, 26 Feb 2018 17:20:45 -0000

> On Feb 26, 2018, at 9:26 AM, Paul Wouters <> wrote:
> So it was decided to not use a full DNS packet format? And then since you
> miss the structure of the Answer Section and Additional/Authority
> Section, you require the "answer RR's" come first where you basically
> emulate an Answer Section?
> Isn't that an indication that we should really use the wireformat of an
> entire DNS message here? Maybe some DNS library/tools people can chime
> in here to tell us if this matters much to them (assuming they are
> adding support for creating/consuming these chains of RRsets in wire
> format.
> I am personally a little sad we cannot have a dig +chainquery command
> where we write out the entire answer packet format to a blob, to be loaded by
> the TLS server. And where a TLS client cannot just hand over the blob
> "as if it came in as a reply from a DNS server" to its DNS/cache
> receiving code path.

The latter would require compression support on the receiving side, which
has been specifically excluded so far.  I am not against making the data
more compact, though it is rather late in the process, but I have a more
pressing issue.

I think that as it stands, lack of authenticated denial of existence is
a *fatal* flaw in the protocol.  I just don't see a sufficiently practical
scenario in which this extension confers a useful security benefit.

Perhaps this draft should go back to the working group, to consider a new
protocol element, by which the server commits to support the extension for
a time that is substantially longer than the underlying DNS TTLs.  During
this time (suggested to be weeks or months, when in production after initial
testing), the server MUST support the extension and respond with EITHER a
valid TLSA RRset chain, or with a valid denial of existence.

The protocol, thus extended, can then be seen as a more robust form of key
pinning, in which pins are stored server-side, and only the fact that
pinning is expected is stored client-side (for any length of time, the
client may still do short-term caching of TLSA RRs based on the DNS TTL).

The protocol is still subject to downgrade (to PKIX) on first contact,
but is this a common element of all protocols that bootstrap security
on first use.  Indeed the WebPKI itself is largely TOFU as most certs
(which are predominantly DV certs) are issued by CAs based on rather
weak initial evidence.