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

Dave Garrett <davemgarrett@gmail.com> Thu, 07 May 2015 07: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889411B29A2 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 00:00:09 -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 68EmZ8Xhj3G9 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 00:00:07 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 852DC1B29A3 for <tls@ietf.org>; Thu, 7 May 2015 00:00:07 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so16565331qgf.1 for <tls@ietf.org>; Thu, 07 May 2015 00:00:06 -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=+hRZA9O7czf4gzYyUbdkw+YbVs00GRlwLg7Y954PFLo=; b=bj8oRn1giqkydDmskULC7sJCnZuUYxIDXbUep1em9zvqlJjzMBtVOPQ0CGsUsy9AGM RpAqWtPpwHoqdvBqroamdVO7PJZt0GFkmleSClraOLiZy+2Ihw+YTObaJEBHMGsn55Lv sx+qtj0z8mWp06nzHPC/aHmzWdbNpRIzW9wTYCRPcRmaxE6g9Oq7TigzeJWByJZskhVe gAIhJdhRSiHXJhFvaVhb1JJQsRBMVPhGGVXPM/OB4wjkEOQt+ELKfmIsmB7SArhaSCQT 5XMPGelTvAp1n5U7ZkSloCfY55BVZQXjBj4A+LXEIwejlIO+j6wEDL9R/6xkRux7RWXP i5tg==
X-Received: by 10.55.24.158 with SMTP id 30mr5147404qky.83.1430982006823; Thu, 07 May 2015 00:00:06 -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 z198sm844667qhd.44.2015.05.07.00.00.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 00:00:06 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Thu, 7 May 2015 03:00:04 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com>
In-Reply-To: <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201505070300.05183.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7MgeKJczctz2tB6iz-yvaG5BoTM>
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: Thu, 07 May 2015 07:00:09 -0000

On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> > On May 7, 2015, at 6:13 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > It seems that in practice, nobody cares about that second "MUST”.
> 
> It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing code anyway.

By "nobody cares" I mean that clients seem to be fine handling this now, even if they'd rather not have had to. I don't see vendors evangelizing the proper ordering of certs as a high priority.

> People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.

Well, we don't get anything from telling people to panic and abort the connection if it's wrong. Handling the possibility of out-of-order certs is already a thing that has to be done in practice, so stating that up front would improve real-world interop for any clients that might've done otherwise.

In any case, there's not much point in having a "MUST" in the spec that doesn't really help and won't be enforced.

>  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

With Mozilla's phase out of 1024-bit roots, some sites followed recommendations to have two intermediates as a transitional measure. This may be useful for future transitions as well. (not clear on the details here; please correct me if I'm wrong)

> > I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth)
> 
> SHOULD is OK, MUST would imply perfect knowledge of how the other side is configured. The root of trust may or may not be the self-signed certificate. But it’s probably always fine to omit the self-signed certificate.
> 
> > Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.
> 
> None that I can think of
> 
> Yoav

On Thursday, May 07, 2015 01:50:18 am Peter Gutmann wrote:
> I suspect the first MUST can go as well, particularly if you're using code
> that handles cert chains in other formats like CMS/PKCS #7, where the "chain"
> can contain any old rubbish and the chain-assembly code has to build the path.
> For example my code looks for a cert containing the site name 
> ("www.whatever.com") and then builds a chain up via the parent links until it
> can't find any more useful certs.  That just works no matter what the other
> side sends.
> 
> Peter.

We might just want to SHOULD-ify the whole thing, then.

Here's a stab at a rewrite with SHOULDs and generalized language:
----------------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate SHOULD come first in the list, followed
     by additional certificates ordered by increasing authority.
     (e.g. sender, intermediate(s), certificate authority)
     Root certificate authority certificates SHOULD NOT be provided
     in this list, as validation generally requires the root keys be
     distributed independently.
----------------------------------------------------------------------

That may need some tweaking, but I think it clearly outlines the expectations and reasoning.

How does that sound?


Dave