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

Nico Williams <> Mon, 16 April 2018 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26A2D12704A for <>; Mon, 16 Apr 2018 14:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IwVmqOO7ops9 for <>; Mon, 16 Apr 2018 14:26:09 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82F2A124234 for <>; Mon, 16 Apr 2018 14:26:09 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id CA5CB2004CA12; Mon, 16 Apr 2018 14:26:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=9oHDPZ5rDaubqq BiRw+AqYzQ5js=; b=rU10ERLfINP7hgjM3hsC86UoEfPDqfAoghz3qc8i5GgNpc a4pmx9OTKbXFufvXSNt7zcV6hd/e12aR+h/sMPch49f2QsyGW5Jd+C7yP9EZwI4d xNUrRkZblKvegfngtfmrUGQoz0PpE9t9rQ6IZA+PDxOtQqeszTaAQmxsGRyOo=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 8F9392004CA0E; Mon, 16 Apr 2018 14:26:08 -0700 (PDT)
Date: Mon, 16 Apr 2018 16:16:29 -0500
From: Nico Williams <>
To: Paul Wouters <>
Cc: TLS WG <>
Message-ID: <20180416211628.GC25259@localhost>
References: <> <> <20180416163123.GZ25259@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
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: Mon, 16 Apr 2018 21:26:11 -0000

On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote:
> On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
> >>* We might want to say that if the TTL is zero then the clients MUST NOT
> >> pin and must clear any pin.  And we might do this in spite of not
> >> describing any pinning semantics -- explicitly leaving pinning
> >> semantics to a future document.
> >
> >Exactly.  I'd like to suggest that this is the most reasonable
> >common ground, and would urge the WG and authors to get behind
> >this as a consensus position.
> This seems dangerous. If an attacker can re-route and get a rogue
> cert, they can set TTL to 0, negating a previously set TTL, without
> requiring proof by presenting the denial-of-existence of the TLSA
> record. That is also a downgrade attack.

The extension would have to be present and contain either the TLSA RRs
and chain, OR the denial of existence chain, in order to even to carry
any TTL value.

Only in the denial of existence case could an impersonator set a TTL
value of the impersonator's choice, and in this case the client must
treat it as zero in order to avoid a DoS.  In the other case, the
impersonator could *not* set a TTL of their choice without compromising

> How to go from TTL != 0 to TTL == 0 should be specified carefully,
> either in this document or its own document.

If the server sends a denial of existence, then the TTL can't be fully
trusted, and there is a DoS if the client uses non-zero TTL values.  If
the server sends TLSA RRs and chain then all TTL values can be trusted
and should be used, though we might specify how in a later document.

> The only known save way of going to TTL == 0 is by presenting DoE of
> TLSA records (but it does bind using the TLS extension to the existence
> of TLSA records)

The TTL will be coerced zero on DoE, but it can be set to zero in the
TLSA case as well.