[TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169))

Dave Garrett <davemgarrett@gmail.com> Mon, 18 May 2015 23:00 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3A5D31ACDFE for <tls@ietfa.amsl.com>; Mon, 18 May 2015 16:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dCbqtWht_I3T for <tls@ietfa.amsl.com>; Mon, 18 May 2015 16:00:13 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5563E1ACDFD for <tls@ietf.org>; Mon, 18 May 2015 16:00:13 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so119750888qkg.1 for <tls@ietf.org>; Mon, 18 May 2015 16:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=LP2zp15JX1D6yLwn1m3mysfCOeNAIBqTXh8T886VzYs=; b=eyiJmhe+RiEPIsQwH9gqMur7VJFfFp2Gkk6LpSXYSuDU3Zjyz6s0CPxjPA3jVuCVtG T6Ps/pHfp02s3Nb5GtPU0TnQpz0kkkwYkVWCZrzSeJHhVrCpY+ad+v9IVHG9yX8iwzbY Gz5tbRShx0ZJeY7xRY5JZ0CuCZV4eTbb/K44N/ISLKlLISPFFuldbaXGwHW8ZrpVbhGV Yh+PGBZ7tqIPO86+jFnufOskgMQpwaqrQfwgpwq/3gZ+6il4hikcjKH68nv8Sjeq8D2S fS9d1mDaAcrAt18Y82pJamfLyM8zK0azoUuXshobsycfUMCV76JqSD6cHgR9xybjVY4b 5ETA==
X-Received: by with SMTP id 82mr33811952qhr.32.1431990012519; Mon, 18 May 2015 16:00:12 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id 139sm7884238qhb.26.2015. for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 May 2015 16:00:11 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 18 May 2015 19:00:09 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201505181900.10185.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hO_fPkqZvOsz9z-rNJXhGBPFBt8>
Subject: [TLS] relax certificate_list requirements - opinion call (was Re: [tls13-spec] relax certificate_list ordering requirements to match current practice (#169))
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 18 May 2015 23:00:15 -0000


Of note, see also:

The discussion on this list got quite long and at least one person changed their opinion on the topic. I'd like to figure out where we stand on this now.

The primary people advocating for this are myself and Ryan Sleevi.
The primary person advocating against this is Martin Rex.

Who else is in favor or against, at the moment?

Regardless of your opinion, is there anything else that needs to be added to the changeset?
(If you think this is problematic, what needs to be added to reduce that?)

Also, the topic of AIA cert fetching came up, with people both arguing for and against. Personally, I don't think cert chain verification should be triggering any network activity unless explicitly approved beforehand. Do we need to add a note of some kind with regard to this topic? Could we make OCSP stapling a requirement in some way to at least address that? In an ideal world, I'd prefer either the server sends 100% of what's needed to verify, or the handshake should fail. (this is beginning to get off-topic from the main issue, though)

Don't interpret this as a full vote or consensus call just yet. I'm just trying to assess what needs to be discussed to move forward on the topic in some way.