Re: [TLS] Update spec to match current practices for certificate chain order

Dave Garrett <davemgarrett@gmail.com> Fri, 08 May 2015 21:34 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13711A19F0 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:34:51 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 wp5jWs66Z6Pj for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:34:50 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (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 334471A0A6A for <tls@ietf.org>; Fri, 8 May 2015 14:34:50 -0700 (PDT)
Received: by qgdy78 with SMTP id y78so42984535qgd.0 for <tls@ietf.org>; Fri, 08 May 2015 14:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=keoi3ONH5e/NENsBD7J16cDYsJeDTLqXqMHWqUKYl4w=; b=uNJ4gA6JNJTdKUdmxvPO/IZJWa5a0pciC0xs4hwna7a1A2WpATmy9Zz+8mnpHeguVR WEdUowHP7OdD3ojF0Rc8U5TE7CCLyx409lEZYFewtwAgDlgtRk2U/sfZAaMY6tgw511a AvwPzCWyIMFDOx9mIjyjmt4tzBnS2RELuwd7SUf0HYY6JKXQ+CZt525nmdgOd0A8w+5R DShph4IqbLKSVJPt5FbcMQptze5YRh8SbwdOdi8Q3rhRHhxutBDqZpl8ZnvMvpdNQ8tT puGuc9E/12Q9nY2qxIkpXwchkAsI9Fw8ax9l/jK+8EowcqGXy7ikaYnknILSKEDDq+7M Ar+Q==
X-Received: by 10.140.100.200 with SMTP id s66mr58840qge.1.1431120889327; Fri, 08 May 2015 14:34:49 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f131sm4446564qhc.47.2015.05.08.14.34.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 14:34:48 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: ryan-ietftls@sleevi.com
Date: Fri, 08 May 2015 17:34:47 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com> <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com>
In-Reply-To: <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505081734.47783.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BFPwPBosXyh3QpiZgF9IJUtYoVQ>
Cc: tls@ietf.org
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
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: Fri, 08 May 2015 21:34:51 -0000

On Friday, May 08, 2015 05:10:19 pm Ryan Sleevi wrote:
> On Fri, May 8, 2015 8:29 am, Dave Garrett wrote:
> >  Let me be clear: I don't fundamentally disagree with you.
> 
> While I have great respect for Martin, I do disagree and think he's
> fundamentally wrong here, for the reasons I already explained in my first
> message as to why what he's asking is not only *wrong*, but *unwise* and
> an unnecessary coupling of two intentionally-independent layers.

This is a two decade old set of security standards. If you want any strict
separation of layers, you're going to need to start from scratch. (which we're
hopefully doing soon with something QUIC based) Anything other than
acknowledging this current situation as a mess and doing what you can
where you can (e.g. HPKP) is not really practical.

Wise as it may be to try to keep things decoupled, it's not the current reality.

> And of course, coloring is the unquestionably wrong answer here from a
> usability study.

It's wrong just from a biological perspective, seeing how colorblindness of
various forms is not uncommon.


Dave