Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <> Thu, 05 April 2018 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4508D127599 for <>; Thu, 5 Apr 2018 07:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vD1N7FPbc1mT for <>; Thu, 5 Apr 2018 07:08:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 500F012D890 for <>; Thu, 5 Apr 2018 07:08:09 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2D2987A330D for <>; Thu, 5 Apr 2018 14:08:08 +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: Thu, 05 Apr 2018 10:08:07 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <> <> <20180405022007.GG25259@localhost> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Thu, 05 Apr 2018 14:08:28 -0000

> On Apr 5, 2018, at 9:33 AM, Eric Rescorla <> wrote:
> However, that doesn't mean that hijacking isn't a problem (though I agree a less
> serious one). If I have no provisions for DNSSEC at all and the attacker does
> pin hijacking I could be offline for hours to days while I figure out how to get
> and serve them.

Perhaps you did not see my explanation of why the pin imposes no obligation beyond
supporting the extension in the server software.  A server for an unsigned domain
can just serve denial of existence of the domain's (or a parent's) DS record.

So you don't need to "get and serve them", you just need to forward whatever is
the true data in DNS about the server's domain.  Only the capability to present
the actual DNS chain is required.

	* If server's zone is not DNSSEC-signed, forward NSEC records showing
          existence of NS and non-existence of DS at or above the requested:


          domain and the requisite signatures up to the root.

        * If server's zone is DNSSEC-signed, but no TLSA records are present, serve
          NSEC records proving non-existence (or NODATA) of the requested

		_443._tcp.server-fqdn.example IN TLSA ?

	  records and the requisite signatures up to the root.

        * If the server's zone is DNSSEC-signed, and TLSA records are present, serve
          the requested TLSA records along with the requisite signatures up to the root.

All three of these would be obtained and cached (up to most of the advertised TTL) in
the same way from a suitable resolver that supports chain queries, it is up to that
resolver to return the appropriate response each of the above cases, the server can
treat the data as opaque, modulo determining the time for which it may cache the
response so that the chain need not be re-fetched for each client connection.

If one is worried about hijack by someone who can cause the domain to be signed
with TLSA records published (so as to set a non-zero pin), then one might be
motivated to have server software that is capable of returning the extension.
Just as with STS one might need software that supports TLS if the hijacker
deployed STS.  I don't think that such hijacking is a major risk, but if that
risks drives adoption of the extension (without any other changes in tbe
domain's practices wrt. DNSSEC or DANE adoption) all the better. :-)
The domain might need the extension some day for more than just hijack recovery,
and it will already be available.