Re: [TLS] Proposed text for dnsssec chain extension draft

Nico Williams <> Thu, 26 April 2018 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FB6512DA21 for <>; Thu, 26 Apr 2018 08:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.611
X-Spam-Level: *
X-Spam-Status: No, score=1.611 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=3.6, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mauz2PUYBVtu for <>; Thu, 26 Apr 2018 08:28:50 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27F06126B7E for <>; Thu, 26 Apr 2018 08:28:50 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A73ACA004B85; Thu, 26 Apr 2018 08:28:49 -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=OeswSNFe4y85yf K5U5v7xGfVUnM=; b=GEeZR6qfPqF0yjdq15V8Sp9pt5mAA+nNHOw2/QH8GpCCgE lIK4/8yXRtHPN7KSGx9iRYfrl9D1meY0drr8qYSXogoqIsB6U/rETavvHH8313Ui By4vHRTsn3ECH6lEyRYhLySiJ1TbS1dFP2dT5tJ4zHY+H8qVrX1EwJTaagV+A=
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 4F533A004B82; Thu, 26 Apr 2018 08:28:49 -0700 (PDT)
Date: Thu, 26 Apr 2018 10:22:07 -0500
From: Nico Williams <>
To: Eric Rescorla <>
Cc: TLS WG <>
Message-ID: <20180426152206.GM25259@localhost>
References: <> <> <> <>
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] Proposed text for dnsssec chain extension draft
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, 26 Apr 2018 15:28:51 -0000

On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <>
> wrote:
> > On Apr 26, 2018, Eric Rescorla <> wrote:
> >
> >   * a lifetime field
> >   * enforce vs. test
> >   * a report URI

We will need only the TTL.  We will not need anything else.  This is NOT
like HPKP.  This will pin only the use of the extension, and NOT EVEN
the use of DANE since you can send a denial of existence and you can
*always*[*] do that if you stop wanting DANE.

[*] unless you're operating in an alternate DNS universe where no zone
    is signed, not even the root zone, but then you wouldn't have used
    this extension ever, and you'd not have pinned it).

Because we'd pin only to the use of this extension, the TTL is

> > This specification is always "enforce" (though my pull request
> > changes a MUST use DANE to a SHOULD with some necessary added
> > conditions) and since the report URI is in good measure to
> > support non-enforce mode, we're back to just max-age.

> But this reinforces my point. I think we ought to have an enforce vs
> test flag and a report URI (and I I don't find your arguments above
> about why we shouldn't do this persuasive.)  Standardizing this
> functionality would require resolving these issues.

Strawman.  These are make-believe issues.  Is it just to give the
appearance that we couldn't possibly reach consensus on just two bytes?