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

Viktor Dukhovni <> Mon, 16 April 2018 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0CB127869 for <>; Mon, 16 Apr 2018 10:06:48 -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 tb6g3p0Fdbir for <>; Mon, 16 Apr 2018 10:06:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7B86120721 for <>; Mon, 16 Apr 2018 10:06:46 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9783A7A3309 for <>; Mon, 16 Apr 2018 17:06:45 +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: <20180416163123.GZ25259@localhost>
Date: Mon, 16 Apr 2018 13:06:44 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <20180416163123.GZ25259@localhost>
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: Mon, 16 Apr 2018 17:06:48 -0000

> On Apr 16, 2018, at 12:31 PM, Nico Williams <> wrote:
> I wouldn't mind a (C'): a variant of (C) where we get denial of
> existence and a one- or two-byte TTL (one by count of weeks or two-byte
> count of hours) with de minimis text about it, leaving pinning semantics
> to a separate document.  In such a (C') we'd elide all pinning (or most*)
> in this document.

Specifically, this actually would help the cause of those who don't
want pinning, because in (C') we can specify:

  * Client's MUST NOT employ any pinning for downgrade protection
    when the extension support TTL sent by the server is ZERO.
    Only a-priori local policy that mandates DANE TLSA records
    for particular domains can require the extension, in all other
    cases the extension MUST be optional in future connections
    when an authenticated server returns a ZERO extension TTL.

  * Pending future specifications, the server MUST set the extension
    support TTL to ZERO.

With this, we get to explicitly specify that clients MUST NOT pin,
rather than removing text and leaving the option up to the implementors
imagination.  And implementors will want downgrade protection, and the
current list of half-baked downgrade protection measures in Section 8
was in place at the time of the WG LC consensus for moving the draft
forward, and these were added in lieu of tackling downgrades in a more
systematic way, so ripping it all out does not seem like a minor tweak.

If we add a two byte extension support TTL field, that servers will
set to ZERO, and tell clients to not attempt downgrade protection
when it is so set, we leave room for future downgrade protection
without having to change the extension wire format.

With the TTL always returned as ZERO in the recent past, the server
is equally free to return denial of existence or just not present the
extension.  Operator's choice.

This way, the draft retains the option of future downgrade protection,
thus not completely abandoning its promised scope, while deferring any
pinning for now, and indeed making it very clear to clients that they
MUST NOT (yet) do any TOFU or similar pinning.

> * 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.