IETF Logo Mail Archive

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 16 May 2018 18:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAB412025C for <tls@ietfa.amsl.com>; Wed, 16 May 2018 11:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn-bkdgqR49X for <tls@ietfa.amsl.com>; Wed, 16 May 2018 11:14:05 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8421243F3 for <tls@ietf.org>; Wed, 16 May 2018 11:14:04 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 376227A3309 for <tls@ietf.org>; Wed, 16 May 2018 18:14:04 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <da6faf1b-f3fb-c119-41b0-017a2ea2a761@huitema.net>
Date: Wed, 16 May 2018 14:14:03 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <C22D39FA-00B4-47D0-A2C1-3289662B4FCD@dukhovni.org>
References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <CA+cU71=bOG=3TSDs7dfPLYWY96vSpxCm83=jTJB_1s29fVmnNQ@mail.gmail.com> <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org> <da6faf1b-f3fb-c119-41b0-017a2ea2a761@huitema.net>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/s93io6BycWB82-YGOq49Uh_kmoY>
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2018 18:14:07 -0000


> On May 16, 2018, at 1:59 PM, Christian Huitema <huitema@huitema.net> wrote:
> 
> The way I understand it, your proposal is not so much to "reserve 16
> bits" but rather to "include a 16 bit field defined as the pinning time
> in hours". Or maybe, "reserve 16 bits as set to zero on send and ignored
> on receive" in the current TLS DNSSEC draft, let it be published as RFC,
> and publish very soon a draft that defines the 16 bit field as the
> pinning time in hours, and presumably explains how to avoid the usual
> pitfalls of pinning. Do I understand correctly?

Yes, with the slightly more precise semantics you mention of
"set to zero on send and ignored on receive" and zero means "do
not pin".  This is we expect better then just reserving an undefined
field.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email