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

Viktor Dukhovni <> Thu, 05 July 2018 04:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0FEC1310A7 for <>; Wed, 4 Jul 2018 21:01:26 -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 W9-hptnPZQE2 for <>; Wed, 4 Jul 2018 21:01:24 -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 D87761310B1 for <>; Wed, 4 Jul 2018 21:01:24 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 4461E29A25D; Thu, 5 Jul 2018 00:01:24 -0400 (EDT)
Date: Thu, 5 Jul 2018 00:01:24 -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 04:01:29 -0000

On Wed, Jul 04, 2018 at 08:42:38PM -0700, Eric Rescorla wrote:

> It would be nice to hear from those maintainers, as well as from some of
> the bigger email senders (e.g., GMail, Yahoo Mail, etc.)

The question is premature, some implementations are not candidate
early adopters.  Once library support is there, and there are
some early adopters deployed, then the others follow.

Postfix implemented DANE in 2014, a bunch additional MTAs added
support in 2017 and 2018, and I expect more in 2019.

> > 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.
> It has not been my experience or, I think, that of the WG, that this is the
> case.

Yes, that's true with major TLS revisions.  This extension, however,
will not see such rapid uptake that sloppy early versions will need
to be revised.  You're on the one hand questioning whether any
adoption will take place at all, and on the other concerned that
early adopters will be intolerant of non-sentinel values of the
proposed reserved field.  Your first concern is closer to the mark.

While I'd like to have the second problem, the reality is that for
the first couple of years the number of implementations will be
rather small, and the specification of the reserved field can and
should predate the bulk of the follow-up implementations.

> Rather, once there is a significant fielded population of intolerant
> endpoints, generating the offending PDU causes too much breakage and
> instead you have to send something which doesn't break those endpoints. cf.
> the padding extension, supported_versions, and the CCS hack.

Sure, but "significan fielded population" is not a problem we'll
be having here for some time.  This is a space where uptake will
be slow, and the early adopters will be well aware of the requirements.
By the time the late adopters arrive, we'll have the downgrade
protection fully specified.