Re: [TLS] Precluding bilateral opt-in for downgrade protection.

Paul Wouters <paul@nohats.ca> Sat, 28 April 2018 19:08 UTC

Return-Path: <paul@nohats.ca>
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 5B64A127342 for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 12:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 oEVH5ZKDLB-P for <tls@ietfa.amsl.com>; Sat, 28 Apr 2018 12:08:15 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FC41275AB for <tls@ietf.org>; Sat, 28 Apr 2018 12:08:14 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40YL193Hn4zCq8; Sat, 28 Apr 2018 21:08:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1524942493; bh=96dnN2GaQewBrGI2Pgy+Lki9AMk0hqTw9eS7AiS6wrQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=W8hWw66DJK9F7KwHi/hFdMQfwiLQe5OnLDqJrokQNRn8hOaCCBZEwY2IOxrri9aAm Qt6ish41v9VL/88jmOLxLIuB51BX5OhJ6+kNSGExoQbm0/M5eS1DoDCvUhVR1T6M90 /uSAa7Hdhrep2Gjeglik4Q4Lom31nBdI+YgeKQ78=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KqhJ3lMmFt36; Sat, 28 Apr 2018 21:08:12 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 28 Apr 2018 21:08:12 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 74DDB61CD5; Sat, 28 Apr 2018 15:08:11 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 74DDB61CD5
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C16640C1031; Sat, 28 Apr 2018 15:08:11 -0400 (EDT)
Date: Sat, 28 Apr 2018 15:08:11 -0400
From: Paul Wouters <paul@nohats.ca>
To: Shumon Huque <shuque@gmail.com>
cc: tls@ietf.org
In-Reply-To: <CAHPuVdXMSe8bNzeqoNTjb814zaeDZP8kPSfbaU9WBQb+V6EGLg@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1804281502470.11560@bofh.nohats.ca>
References: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org> <CAHPuVdV+qhC=jS-JEoS6ig6ofRXV__VLOmSL=6c=3_vJK-zCpQ@mail.gmail.com> <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> <CAHPuVdXMSe8bNzeqoNTjb814zaeDZP8kPSfbaU9WBQb+V6EGLg@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/npkDkytjed7GGY3hF6FkI09t5UM>
Subject: Re: [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: Sat, 28 Apr 2018 19:08:16 -0000

On Sat, 28 Apr 2018, Shumon Huque wrote:

>       I wish I could be confident that such a specification would
>       be allowed to move forward.  My fear is that the same visceral
>       opposition to DANE and DNSSEC would play out, and so I may as
>       well try to get past these now.
> 
> I would like to explore this. Is there anyone in the working group
> who would oppose such a new spec moving forward? 
> 
> (Maybe the WG chairs need to ask this question officially).

There is not much point in doing this, as everyone can "change their
mind" later when this document's process has completed.

In other words, it won't make me feel any better if no one objects now,
unless the chairs would make it a discussion to update the TLS charter
to add this work item.

And even then, the more inevitable this new work item becomes, the
more sense it makes to add the two bytes now to avoid more "designed by
committee" weirdness like one extention mandating another extension and
figuring out what it means if the mandating-extension itself vanishes.

Our two byte proposal is technically sound.

Paul