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

Shumon Huque <> Tue, 27 February 2018 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B336412D969; Tue, 27 Feb 2018 07:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qmnct-ERK866; Tue, 27 Feb 2018 07:59:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0D2A1242F5; Tue, 27 Feb 2018 07:59:01 -0800 (PST)
Received: by with SMTP id w19so11657148ite.0; Tue, 27 Feb 2018 07:59:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z5pLJCuvDTppboAj/B1NcI8D3AYlYeiVvy4Kx7D+T/E=; b=iPe24s3HM5ofOQV6l5azLXMOGas3tkmbN1mBRdFaBmp3hIzhEqtrROqb/ZEW8BvSjb xOdpMRaHnNYLtSwit7oDUsjFl3Y2FnN114eGzhPq6rfyhiIG4M5By9NR4dTpwa/a5fNh wuSUM7O2XPi5CAvPBYUGZb84j9UnvLDwo7McD56WYQkyqB38k2eTfhaI/yk8Qm6GnSu+ y41KzymxKTz4TFgpllewe6uO4Hf0rz92bvpT3xk2lky28n0VP8vNvJqTujG4k/MMS7K1 UOoxPhnyXt/6kQeXajlSuaMdjkUkDJmd1XnzY7CaozA4wJIFH6kGsXG0o4XI/2Tbus1W foHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z5pLJCuvDTppboAj/B1NcI8D3AYlYeiVvy4Kx7D+T/E=; b=sbkCdIZRj+Hn9M4d0Cjo+FgigTEc0sUOoeQYwo4anLOqcNxKR3m/VVlf4yjHIrnVgu jaL5XhjSVEdh1b4UPtZyZqcO1YFNS7lIRbfV17g/jYMZBGfaymqXckxZUEKzIXFHpPn7 5neem5McSkvnILP8FW5Uv3w+JvnOfYhvl4nMBpqOTT32GSD9+b9+T399kSH6MRuVF6SL 1hUo0WO3xgTBgfjIX3wVQ9BZqgzrI5/X+gksm4v6bqDSoykPGdcMNl9I7PZTrNxXY1eu DiV9LhVBi+a1/9fwddCzuOt/ARtWTnRPyhludvntV3gchET54Zje9A9TZW2EJJcbqcy8 91dw==
X-Gm-Message-State: APf1xPANhnMqwOWuKd4i5xZDTZ1XiDZRrY1F59+qUbmzIOxXl6ucg1w1 PaCwKop9AUgPxDkrMVHqN1fYz8PxvDs2WwE4NC3F+3NV
X-Google-Smtp-Source: AG47ELszNPUBjGyv2Ailz0Jd2o5bm+rxBD+Yl+4oe/U2kPXilyOUP6KhFjedcAFo81FfwWZ4J1C+7sMOOkoYLJZIeco=
X-Received: by with SMTP id m195mr18057402ith.151.1519747140981; Tue, 27 Feb 2018 07:59:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Feb 2018 07:59:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Shumon Huque <>
Date: Tue, 27 Feb 2018 10:59:00 -0500
Message-ID: <>
To: Viktor Dukhovni <>
Cc: TLS WG <>, tls-chairs <>,, The IESG <>
Content-Type: multipart/alternative; boundary="94eb2c11ce6e7c973e056633b437"
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: Tue, 27 Feb 2018 15:59:05 -0000

On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni <>
> 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.


Is this a new realization you've recently arrived at? You've been
commenting on this draft for a number of years now, and I have
assumed that you were well aware of the lack of authenticated denial.
In fact, there is text in the Intro section that declares that
this protocol is unsuitable for SMTP/DANE precisely because it
requires confirmation of the existence or not of the TLSA record -
that text came about because of discussion with you.

Several of us were well aware of this during the early days of the
draft, but perhaps many folks did not fully appreciate the impacts
until I elaborated on them last year, and added text that described
the "adversary with fraudulently obtained PKIX credentials" attack.

It is certainly a limitation/flaw. Whether or not it is fatal is
debatable. What this means is that this protocol allows opportunistic
use of DANE authentication, but guarantee of use needs mechanisms
external to the protocol. Section 8 already describes several such
mechanisms that could be employed. So, I think this topic is covered.

This limitation also may not be applicable at all for green field
TLS/DNSSEC applications that can require the use of the extension

Having an authenticated denial mechanism would allow the TLS client
to have an inband way to enforce DANE authentication if available.
I suspect though that re-introducing a debate on this topic will
lead us into an argument about what it means for a server to publish
a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate
keys and certificates? Or is it also a policy signal that says DANE
must be used? I do not think the latter idea has any consensus in the
IETF currently.

> 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
> testing), the server MUST support the extension and respond with EITHER a
> valid TLSA RRset chain, or with a valid denial of existence.

This is a rather substantial change proposal. It's worth considering,
but I'd like to hear others chime in. But as I said, there are ways
to use this spec and address some of the limitations outside the
protocol today - you can cache and pin knowledge of TLSA existence,
even without an in-protocol commitment, although the latter would be
better. That may be good enough for the first iteration of the protocol.

Note that extending the protocol to incorporate authenticated denial
also means that the chain data would likey need a DNS response code.
That's a stronger argument to move to a full DNS message format (I'll
answer Paul Wouter's specific comments on that topic separately later).