Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

Viktor Dukhovni <> Wed, 16 May 2018 05:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AE2F127867 for <>; Tue, 15 May 2018 22:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 ql_k_Jcj5GLf for <>; Tue, 15 May 2018 22:34:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B353A124234 for <>; Tue, 15 May 2018 22:34:04 -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 AF3A67A3309 for <>; Wed, 16 May 2018 05:34:02 +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: Wed, 16 May 2018 01:34:01 -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] TLS DNSSEC chain consensus text, please speak up...
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: Wed, 16 May 2018 05:34:06 -0000

> On May 16, 2018, at 1:18 AM, Melinda Shore <> wrote:
> Your proposal has been discussed
> at length on the list, it's been discussed at length off the list,
> and there is still no consensus to modify the extension to support
> your use case.

You say that, but there are ~5 people on each side
woh've expressed an opinion on pinning one way or the other.
And the original consensus call did not even esk the question
at hand.  Rather it was whether to specify pinning or not.
Not whether to reserve space to do so later.  Subsequent
discussion has been the same echo chamber of Eric, Rirhard
and you on the one hand, and Paul, Nico and I on the other.
Perhaps at this point we might actually hear from some others.

> And as a reminder, "Rough consensus is achieved
> when all issues are addressed, but not necessarily accommodated."

Here I agree, but things like unaddressed downgrade attacks are
also a factor that is supposed to tilt the scales.

> On 5/15/18 8:22 PM, Viktor Dukhovni wrote:
>> It just leaves
>> the door open going forward, at negligible cost (two bytes on the
>> wire in bandwidth, and zero in implementation).
> I would be grateful if you would have a consistent story on this.
> Clearly, it's not just two bytes, or there wouldn't be a perceived
> need for them.  It's two bytes plus the associated semantics and
> processing algorithms.  In the event that anybody has an interest
> in implementing something along these lines the offer to work on
> an extension to support it still stands.

The story is quite consistent.  Applications that have no need
for pinning pay no cost as claimed.  Applications that need it,
can't use the present specification at all, but would be able
to at the cost of storing the pins, and requiring the extension
when pinned.  Nobody pays an extra cost they could otherwise