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

Viktor Dukhovni <> Fri, 20 April 2018 05:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B6AD127871 for <>; Thu, 19 Apr 2018 22:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yr86cl6xwmWo for <>; Thu, 19 Apr 2018 22:33:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E27C127775 for <>; Thu, 19 Apr 2018 22:33:26 -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 074F97A3309 for <>; Fri, 20 Apr 2018 05:33:24 +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: Fri, 20 Apr 2018 01:33:23 -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] 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: Fri, 20 Apr 2018 05:33:28 -0000

> On Apr 20, 2018, at 12:09 AM, Joseph Salowey <> wrote:
> [Joe] This can also be done with a new extension code point that defines a replacement extension that adds the pinning policy.  This seems like viable possibility, we are not running short on extension code points.  

This looks like the lose-lose version.

  * The present extension loses all downgrade from original LC,
    and gets a reduced scope, all without a clear consensus to
    limit the scope or lose all downgrade protection, with the
    path forward on restoring it more uncertain.

  * No explicit do not pin signal in the present extension.

  * Should a second extension be defined later, clients have
    to signal two separate extensions, and servers have to
    respond with two separate extensions. Complicating
    implementation, all to save two bytes in the present
    extension, with those two bytes providing a clear do
    not pin signal, not pinning at this time does have

  * With the extra two bytes the next specification merely
    needs to allow new interpretations of non-zero values,
    with no new wire formats for anyone to implement.
    THe upgrade path for both clients and servers becomes
    simple, just extend the capabilities of an extension
    they may already support, or which existing code can
    be found.

The requested 2-bytes carry no implementation burden for
parties that would implement the extension without those
bytes.  Worst-case they'll never be used, but they do
signal good-will on the part of those who want a minimal
extension now to allow the follow-on specification to be

The close attention to the content of this document that
resulted from the disparate views of its proper scope has
found important issues that were missed, and corrected an
unnecessary limitation (prohibition of denial of existence).

Though some delay has resulted, the document is better off
for it.  I think it is fair to ask for good faith in return,
at a negligible cost of 16 bits that might if things don't
go to plan forever remain zero, but will at least explicitly
signal to the client that pinning based on prior observation
of the extension should not take place.

Refusing to make a trivial concession to gain a broader
base of support for the document, just to save two bytes
does not look like an inclusive process to me.