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

Eric Rescorla <> Thu, 05 July 2018 03:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 605C7130E87 for <>; Wed, 4 Jul 2018 20:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pYn5vfadj6Yd for <>; Wed, 4 Jul 2018 20:43:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46E67130E7B for <>; Wed, 4 Jul 2018 20:43:20 -0700 (PDT)
Received: by with SMTP id l189-v6so2492329ywb.10 for <>; Wed, 04 Jul 2018 20:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mMaOt6a+8gJjY81yNtxbnW0r1n2uE8kXwlqEKjHoNLA=; b=Jql6HwkzyKFv8j+9Si9FpN+z9eZpfH1RWpJIWC2w1HTEMkNFhxSiOySpug77FR8xRp GZHq7HGXa9DH+yfB45hqzbV0WCfEbar4VLXGd3P5XZNoFgQlYw2m2Are91gu3Ls30NxZ Pm8NBA9lqy3BAHJNqPJDWBKrvQ4I6w1Mbrh/rf9uaZrQhgTv8TkeAvUKcyY1OlNqUtex Lj21iC52fe6vPugHgbaOwiPs1/a4wV4xh9MmF9+zYTEWLVq8/9AZoG7oEkiiJyIETyaZ 3TbI2GQdpPGpcGf3UVIlEKmrjpGg3rfv2pna/YNJOOacO6aBPSNfIwFsDhIr7f2c5a1Z 03Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mMaOt6a+8gJjY81yNtxbnW0r1n2uE8kXwlqEKjHoNLA=; b=nnKG48BlAdFDOGYbyueAeM4LR7QCNwVBKtyobLjnstkhTcHe2uz4cjb3xuqrmIBJT3 Jq8iKg5wQefizsul9QehCc1bNykb23xdR8OC2FUgdFp1QexIo0vJgIAhm88ojCNm+RUH ykZZNpcZnKtAJmaG0O4c49MsP8js+P6anqwKUo/aryf3qbRDJt/5D53Acvok2gUspCoH Ys7bb69bmRvMTDgPcltn5m9GyVz/D3iRsCIML9om+vgBIM+ePm0CyXMye62lpI4QPUhb n3HQBDTWx3vQfR5qLDes1iT2wN1mjk9kDuRGJu/N46ju2FpNXTqH5H3hW8jQ0YfdTxaY TqhQ==
X-Gm-Message-State: APt69E042yBS+GWPWkMhLK4lY4zUmb9k4xAqkrhpbf4uzxYH7NJGgryp sVkUOhdovOtTPL5FeeHFjCfx+H41WMFDlfRnnmESM797
X-Google-Smtp-Source: AAOMgpdTDtx/qOgvqXDJk8iW/+tBwXWVx4DiAip6ZhIM5pCqmfwE02m3qdBQJH7WvYW4CULd1Qd0YiJ6MKhYNY6qDsE=
X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr2137892ywa.381.1530762199282; Wed, 04 Jul 2018 20:43:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 20:42:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Wed, 4 Jul 2018 20:42:38 -0700
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000001fd1ee057038595e"
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:43:23 -0000

On Wed, Jul 4, 2018 at 8:16 PM, Viktor Dukhovni <>

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

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

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

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

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

Yes, I appreciate that this is your opinion.