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

Viktor Dukhovni <> Thu, 05 July 2018 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57240130E8B for <>; Wed, 4 Jul 2018 20:16:18 -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 piJc48n_VMHV for <>; Wed, 4 Jul 2018 20:16:17 -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 112DF130E87 for <>; Wed, 4 Jul 2018 20:16:16 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 1BBE729A228; Wed, 4 Jul 2018 23:16:16 -0400 (EDT)
Date: Wed, 4 Jul 2018 23:16:16 -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 03:16:19 -0000

On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:

> > > Do we have a count of major implementors who say they will do so?
> >
> > Well, what is a "major implementation"?
> Well, we could start with "what implementations are going to do this"?

Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT,
and I am a maintainer of both the TLS features in Postfix, and the
X.509 code in OpenSSL, I expect to add support for DANE chain in
OpenSSL and Postfix in 2019.  Next on the list would be Dovecot and
mutt, but it'd be nice if that was done by one of the primary
maintainers of those packages.

> Yes, and this is where grease comes in. Specifically, if implementations
> are required to send empty values (or zero) until something is specified,
> then implementations which *require* those values and choke otherwise go
> undetected.

Any broken clients will get fixed.  The client that motivated this
draft is purported to require the extension, and the others will
take some time to appear, highly likely not until the follow-on
spec is written.  The odds of real problems here are negligible.

> By contrast, if we have a structured Extension code point with
> requirements to ignore unknown extensions, then implementations can send
> grease extension values and verify that the peer properly ignores them.

There's no need for nested extensions, they serve no purpose.  If DANE
chain STS is in a separate extension, it may as well be top-level.

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

At much too much complexity, unless we fork-lift this extension
plus the additional payload, and largely obsolete this draft.  Using
one extension to pin itself and another is much too cumbersome.

> > 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.
> That would first require there being consensus to do pinning.

That is, to address the security gap highlighted in the upcoming
more complete security considerations.  s/pinning/DANE chain STS/