Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Paul Wouters <> Thu, 05 July 2018 03:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC751130DEA for <>; Wed, 4 Jul 2018 20:59:51 -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] 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 gJ-MjHSIlVBj for <>; Wed, 4 Jul 2018 20:59:48 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFC22130DDA for <>; Wed, 4 Jul 2018 20:59:47 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 41LkdZ0jH2z39k; Thu, 5 Jul 2018 05:59:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1530763186; bh=h4CYIx67s7b5wNew5zEuuhWOo9+QpisTh9xqaeIipHM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SesQUbbYosr446YtYnFybDwGhXMEXZFdWP0xzdbLnZX6f8uap7mD9Gvfi2eBYIA1m Ib4xPqZJMIrlbnBAvnSRh3NyFC56JrBkNYTElGCc/7GSZolg21wnPObx7/nK0MvfP+ cL2ciLcc6RUGEAnYObJiRlhovZPJouNE1JvLrP9c=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OZNSTBONYUBG; Thu, 5 Jul 2018 05:59:43 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 5 Jul 2018 05:59:41 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 3A1EB79AAE; Wed, 4 Jul 2018 23:59:40 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 3A1EB79AAE
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FAF1407821F; Wed, 4 Jul 2018 23:59:40 -0400 (EDT)
Date: Wed, 4 Jul 2018 23:59:40 -0400 (EDT)
From: Paul Wouters <>
To: Eric Rescorla <>
cc: "<>" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-Mailman-Version: 2.1.26
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, 05 Jul 2018 03:59:52 -0000

On Wed, 4 Jul 2018, Eric Rescorla wrote:

> In any case, as Martin Thomson says, we have a perfectly good
> extension mechanism which can be used to add pinning later without creating any placeholder here.

The IETF should not publish security protocols that are trivially downgraded.

The work _should_ really be completed within this document to address
all downgrade attacks. As a _compromise_ there have been suggestions
done to let this document be published while commiting to a method for
downgrade protection. That was not an invitation to punt it to infinity
or an invitation to have a bis replace this entire document just to be
ignored because some people only care about the DOH case. Besides, we
would end up with identical specs apart from two bytes and the same
discussion about these two bytes would happen about whether the new
document Obsoletes: this one. It won't resolve the issue at all and
meanwhile some people have implemented and deployed a protocol that can
be trivially downgraded, or bothered to just not implement because it
offers no real security benefit.

If you don't like TLS extension pinning, come up with another mechanism
that resolves the downgrade attack. But note that none of the comments
against using two bytes for hour scale extension pinning withstood
scrutiny and half of them were appeals to authority or based on people's
gut feelings.

So far, I've only heard incorrect comparisons with other pinning mechanism
problems that ignore the fact that the source of this extension material
is in DNSSEC and that the extension data is a "live snapshot" of active
DNSSEC data and thus never stale/old/bad/brokeb.

> That would first require there being consensus to do pinning.

Again, why do you think it would be even valid to have consensus to
deploy a trivially downgradable security mechanism? I would certainly
expect the IESG to send this back to the drawing board, even if they
missed it on their first evaluation round.