Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Shumon Huque <> Thu, 01 March 2018 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE94612ECC4; Thu, 1 Mar 2018 11:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 2_fW3ypN2cZ6; Thu, 1 Mar 2018 11:13:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20F1B12ECEB; Thu, 1 Mar 2018 11:13:41 -0800 (PST)
Received: by with SMTP id c11so8864373ith.4; Thu, 01 Mar 2018 11:13:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=14HN2u+W5K9kUUG/UBEdhsTq/jBEKsCejIDRLTP/xvw=; b=JOeqmQSzNnjb2sDMBhcvjttEL7FzBZ7VM1KkV2/H+L0dSGXO7qQft5/tknLRbRa6f6 +fNo+Kx+JMoaTNr2k58sVcL10m+elTGiEtpYAxiUwHiurrLgzAxNOlyqY7P5AE1s8IPg MbJ0PtI7Mzpkdrh6zFjejmtGK7yaTlx3lKp7HVo8bzkBZLLFQKMkg0hKlJod+neNONLQ gvW4LXgNWmsNdEDwox4EPk1Kk/ryTk/19pTSU0WXcqZFDf7ziC82Lb49nukptmTmeNB+ PjnMH232Mb6oojgdc4g7yPjc7Gog+NIkj13EkoL9lvsv9OlnGl/hNc79O4ctHAFo4s83 YBbw==
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:cc; bh=14HN2u+W5K9kUUG/UBEdhsTq/jBEKsCejIDRLTP/xvw=; b=JWGFBiSoVqm1boIl5wKW56rxUIXDgmyBWVGAL/UqTmGr9Iq1w0z8HcIvwrKPSgRB0M ldMJpC1es3PRu6OZgKIBNPOkMcfJQIqORoxpMRf7PndPBx47jQj6WTLJp2WgkRvvvXPm qEW8wHAhVO3WKrzaYpmWqi/NkmpoXwZsehLJR9EZZpO8DrHISRg5+Oo9fK6Kt3iigE8H WB+W4pnELY+chxvgS/e22eNPRvMgEDsq+XgAgX0VGv9FQ4xhi0NSMww0h/7938MBQlut EwnswlQbiboqb5aerc+JY1CZQl1jEaXMrsgVJuaQsCaZhV/MCkYhhTGydr2c2DjsN/U2 2qPA==
X-Gm-Message-State: APf1xPABwwdMSc0EqaYJEh0HWFPS4fTOHKRo1eFZjUikQ/tPLDCFjcSs BKF6b9/NVSozGGXJ3RrpjvfFsYPVDAe2vUsaeWD4zg==
X-Google-Smtp-Source: AG47ELv7y9TsQeGFXbjNlpeQTRu5OBSVXcqgoD11XkU6VqDF0h8oYiTXTOiD4sijgBbBSFlb4SKENkipVui31kEv47s=
X-Received: by with SMTP id h77mr3910801ita.103.1519931620457; Thu, 01 Mar 2018 11:13:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Mar 2018 11:13:39 -0800 (PST)
In-Reply-To: <20180228200707.GF8921@localhost>
References: <> <> <> <> <> <> <> <> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> <20180228200707.GF8921@localhost>
From: Shumon Huque <>
Date: Thu, 01 Mar 2018 14:13:39 -0500
Message-ID: <>
To: Nico Williams <>
Cc: Viktor Dukhovni <>, The IESG <>,, TLS WG <>, tls-chairs <>
Content-Type: multipart/alternative; boundary="001a114741385201ce05665ea8fa"
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Thu, 01 Mar 2018 19:13:48 -0000

On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams <>

> IF there's an objection to modifying the extension in order to add a
> pin-to-DANE TTL field, I would propose the following instead:
>     Make the pin-to-DANE be "forever" but make it so it can easily be
>     cleared if DANE is undeployed for the service.

This option is already covered in the draft. It doesn't use the term
but does mention caching the existence of DANE on first contact and
requiring it subsequently (if clients want to do so).

I do not know if the draft authors and/or WG have an appetite to do the
more major change suggested by Viktor (i.e in-protocol pinning TTL
and requiring subsequent denial of existence proof if DANE is removed).