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

Viktor Dukhovni <> Thu, 05 July 2018 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6498D130E60 for <>; Wed, 4 Jul 2018 19:33:12 -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 KldhiuZUpRPL for <>; Wed, 4 Jul 2018 19:33:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 031FD130E1D for <>; Wed, 4 Jul 2018 19:33:11 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 61ADA29A1EA; Wed, 4 Jul 2018 22:33:10 -0400 (EDT)
Date: Wed, 4 Jul 2018 22:33:10 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
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 02:33:12 -0000

On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:

> > 1.  Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
> Unsure. I'd like to see some real evidence that it will be widely consumed.
> Do we have a count of major implementors who say they will do so?

Well, what is a "major implementation"?  TLS is not just browsers,
and adoption does not always begin the day the RFC is published.
DANE adoption only started 2+ years after RFC6698, and is still
ramping up.  The important thing here is to not *preclude* adoption
by needlessly limiting the scope to just "greenfield" applications.

It is rather clear that the present draft is only compatible with
applications that mandate the extension.  Some form of "STS-lite"
pinning is needed to support incremental adoption by existing

> 2.  Do you support the reserved bytes in the revision for a future pinning
> > mechanism?
> No. I'm undecided on whether we should have an extension point here, but
> I'm strongly against having it just be opaque reserved bytes. Everywhere
> else we have decided to put extension points, we've had them as Extensions,
> not just "here are some bytes".  Aside from this being general TLS
> practice, it is good futureproofing because one can grease Extensions,
> whereas you cannot grease opaque bytes.

It is far from clear why "grease" is applicable here, or what "grease
barriers" either proposed form of the reserved field presents.

    * With the 16-bit field, servers set it to zero until non-zero
      values are specified.

    * With the <0..255> byte value, servers send an empty value
      until non-empty values are specified.

    * In either case clients ignore either non-zero or non-empty
      values, until they implement the specification, and must not
      employ pinning until such time.

I thought the authors wanted this done quickly, but lately they
seem to be in no rush to get the document finished.  If we're no
longer in a hurry to get this out the door before all the issues
are sorted out, we can specify the downgrade protection now, in
which case there's no need for reserved fields, we can define the
pinning approach now.