[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 [] (unknown []) (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.