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

Viktor Dukhovni <> Thu, 26 April 2018 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D302612DA17 for <>; Thu, 26 Apr 2018 08:05:36 -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 L27dqcJlw5_V for <>; Thu, 26 Apr 2018 08:05:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F1D3127241 for <>; Thu, 26 Apr 2018 08:05:35 -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 00ABE7A3309 for <>; Thu, 26 Apr 2018 15:05:33 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 26 Apr 2018 11:05:32 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
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:05:37 -0000

> On Apr 26, 2018, at 10:50 AM, Eric Rescorla <> wrote:
>> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
>> find:
>>   * a lifetime field
>>   * enforce vs. test
>>   * a report URI
>> 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.

We should observe that "enforce vs. test" is already moot, this document
implies enforce.  If you wanted a test mode and a reporting URI, these
would have to be part of the present extension.  When the server presents
is DANE TLSA records, the client will enforce them (for just one session,
but we should assume that downgrade attacks, while evermore common are not
the norm).

The signal to do DANE (by virtue of delivering TLSA records) is the primary
change, and it is delivered via the present extension, the "pinning" we're
proposing is NOT "pinning" to deliver TLSA records and do DANE, it is merely
downgrade protection for the signalling channel!  The "pin" can be satisfied
with a denial of existence response.  Compliant servers merely need a software
capability (to send the signal), the "pin" does not enforce new security

Downgrade protection for DANE signalling DOES NOT need any of those other
bells and whistles.  They would, if needed, belong in this specification,
not in a tweak to harden the signalling.