[TLS] Precluding bilateral opt-in for downgrade protection.
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 27 April 2018 20:17 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 781D9127873 for <tls@ietfa.amsl.com>; Fri, 27 Apr 2018 13:17:19 -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 lJ2821f9qUAX for <tls@ietfa.amsl.com>; Fri, 27 Apr 2018 13:17:17 -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 1B9FB127869 for <tls@ietf.org>; Fri, 27 Apr 2018 13:17:16 -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 9C93A7A3309 for <tls@ietf.org>; Fri, 27 Apr 2018 20:17:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org>
Date: Fri, 27 Apr 2018 16:17:14 -0400
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P5h5C9uTI-j4ibf4j1ODshd_DsM>
Subject: [TLS] Precluding bilateral opt-in for downgrade protection.
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: Fri, 27 Apr 2018 20:17:19 -0000
Over the past too many weeks we have struggled to arrive at a rough consensus on downgrade protection for the dnssec-chain extension. Originally, and largely unnoticed by all, the specification described an all too fragile approach that involved unilateral extension pinning by the client. After I pointed this out, there was no controversy around removing this, and I am not sad to see it go. We've also reached consensus on adding denial of existence support, the authors have started work on that, and perhaps some of the additional text I'm proposing in that direction will be helpful. The remaining issue is how to repair the gash in the specification created by ripping out its original downgrade protection mechanism. Though the original text was flawed the problem it attempted to address does not go away just because we're not solving it yet. Only applications where the extension is mandatory get by as-is. There is in front of us a proposal to reserve 16-bits at the front of the extension, that can later be used as part of a future downgrade protection mechanism. The DNSSEC payload of the extension will be multiple kilobytes, holding a signed TLSA RRset, and DNSKEY and DS RRsets for multiple domains. It is hard to argue that prepending 16 zero bits is a burden on anyone, unless one is opposed not only to implementing downgrade protection for this extension in one's own applications at present, but is in fact opposed to ever implementing it, and indeed opposed to giving others that same option (offering a non-zero extension support lifetime is of course optional, as is acting on such an offer). Any negotiated (non-unilateral) downgrade protection will have finite duration, and will include such a field. A principled stand against 16-bits of "wasted" payload, compared to the size of the included DNSSEC chains, to block reaching a compromise on this draft suggests a deeper opposition to any variant of downgrade protection one might propose in a separate draft. It would be helpful to know where opponents stand on negotiating continued use of the extension in general and in the future. We are confused by their statements so far, and wonder if they are not just generally in opposition to any negotiation of continued support for the extension (in all applications), and whether that might be driving their opposition to the 16 bits, whether consciously or not. -- Viktor. -- Viktor.
- [TLS] Precluding bilateral opt-in for downgrade p… Viktor Dukhovni
- Re: [TLS] Precluding bilateral opt-in for downgra… Shumon Huque
- Re: [TLS] Precluding bilateral opt-in for downgra… Viktor Dukhovni
- Re: [TLS] Precluding bilateral opt-in for downgra… Shumon Huque
- Re: [TLS] Precluding bilateral opt-in for downgra… Paul Wouters
- Re: [TLS] Precluding bilateral opt-in for downgra… Paul Wouters
- Re: [TLS] Precluding bilateral opt-in for downgra… Shumon Huque
- Re: [TLS] Precluding bilateral opt-in for downgra… Viktor Dukhovni
- Re: [TLS] Precluding bilateral opt-in for downgra… Shumon Huque
- Re: [TLS] Precluding bilateral opt-in for downgra… Viktor Dukhovni
- Re: [TLS] Precluding bilateral opt-in for downgra… Benjamin Kaduk
- Re: [TLS] Precluding bilateral opt-in for downgra… Benjamin Kaduk
- Re: [TLS] Precluding bilateral opt-in for downgra… Viktor Dukhovni