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

Dave Garrett <davemgarrett@gmail.com> Thu, 07 May 2015 18:35 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 F22541A87B2 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 11:35:23 -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 ueDvYFfPSMei for <tls@ietfa.amsl.com>; Thu, 7 May 2015 11:35:22 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 9204F1A1B51 for <tls@ietf.org>; Thu, 7 May 2015 11:35:18 -0700 (PDT)
Received: by qkx62 with SMTP id 62so33579014qkx.0 for <tls@ietf.org>; Thu, 07 May 2015 11:35:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=wQkXwtXg9UmvDAYR+WWVn8EuxFD5oy7nemBhNOjaxUE=; b=mfDy6mmksSo1hgyC1F0lP2wjQGAYtePUWs8w1kG8QPtrXtTDt+tZIC7Nxw1gzh3w3Q anWweSTgncWBws5TXzz5ARf1jPGn6Pd257lBcH6hJgmHNF+WDK6myxog5u5os/FwDo7h PJAUGEq9SPZsW/TUtsxcBTcBepeMFsnclAgNeM9Ah5muHAHh2jXTLtY3PhlSRXuCAFMx muTYK1aNzMKANq7F6oP6GlemQ39+puZ9m1yW/yzeVLU0tkIx2fS3isWdl/Ph8PNrVgcq IKCYkyqJcAGiG7q1B349jbIUC2Mu6ujGL9+5sB6uYKWmd6e854XAhaDdwkWAh+lUz0rG /xgw==
X-Received: by 10.140.17.50 with SMTP id 47mr539qgc.20.1431023717939; Thu, 07 May 2015 11:35:17 -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 o90sm1926749qkh.25.2015.05.07.11.35.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 11:35:17 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, ryan-ietftls@sleevi.com, Yoav Nir <ynir.ietf@gmail.com>, mrex@sap.com, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Viktor Dukhovni <ietf-dane@dukhovni.org>
Date: Thu, 7 May 2015 14:35:15 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <f06dfb0c50e3044f85a52ffa55089f2c.squirrel@webmail.dreamhost.com>
In-Reply-To: <f06dfb0c50e3044f85a52ffa55089f2c.squirrel@webmail.dreamhost.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505071435.15754.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SY67C0eRzjTviWhOJASBq1lKwn4>
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 18:35:24 -0000

On Thursday, May 07, 2015 01:51:35 pm Martin Rex wrote:
> Personally, I find it quite appalling how many broken TLS
> implementations out there fail to properly encode an ordered list
> of certificates into the Certificate handshake message.

or more concisely:

On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> Bleh.

I think we're in fair agreement that this is sloppy, but it's sloppiness that should've been fixed long ago if we still wanted to fight it.

I brought this issue up in response to a bug report for Firefox fully validating an EV cert list with an extra cert and things out of order. Mozilla and others seem to accept it just fine, so either the spec needs updating to reality or everyone should be adding new security errors to break it. The former makes more sense.

On Thursday, May 07, 2015 01:08:04 pm Ryan Sleevi wrote:
> The disconnect exists because the TLS and X.509 subsystems are
> disconnected (as they reasonably can be), with TLS opting for RFC 5246
> (and earlier), and X.509 clients needing to implement something like RFC
> 4158. In an RFC 4158 world, your inputs of intermediate CAs are unsorted (
> https://tools.ietf.org/html/rfc4158#section-2.7.2 ) - and may even be
> ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 )
[...]
> In an ideal world, I'd prefer the second MUST remain a MUST, because it
> makes implementing a TLS + RFC 5280 validator easier (e.g. without
> *requiring* an RFC 4158 discovery phase).
> 
> However, in a pragmatic world, because major clients implement RFC
> 4158-like behaviours, and because in the changing landscape of CA
> hierarchies (both through acquisitions, but also through the deprecation
> of weak crypto like SHA-1 or RSA-1024 bit keys and the adoption of
> stronger crypto, such as ECC), it's increasingly necessary to implement
> something like RFC 4158 to work on the Internet at large, changing the
> second MUST to a SHOULD seems imminently sensible and reflects the reality
> today and going forward.
> 
> The first MUST should remain - I can't see how any sane client would or
> could avoid that. The final MAY is also necessary/correct, judging by how
> the Web PKI actually works (plus the whole "self-issued for key rollover"
> captured in https://tools.ietf.org/html/rfc5280#section-6.1 that makes it
> problematic for a client to determine whether or not the 'root CA' is
> actually a 'self-issued for key rollover' intermediate)

Ok, so it looks like:
1) Fair bit of push-back against Peter's suggestion of relaxing the first MUST.
2) Begrudging agreement that the second MUST can be a SHOULD to match current realities.
3) The MAY shouldn't be a MUST, or SHOULD.

Current:  https://tools.ietf.org/html/rfc5246#section-7.4.2

certificate_list requirements draft 3a:
------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate MUST come first in the list.
     Additional certificates needed to construct a valid certificate
     chain SHOULD be ordered by increasing scope of authority.
     (e.g. sender, intermediate(s), certificate authority)
     Root certificate authority certificates MAY be omitted from
     this list under the assumption that the peer possesses it
     in its trust store.
------------------------------------------------------------

This gets the 2119-ing as desired, with rewording to cover the reasoning needed to follow or not follow the SHOULD.

certificate_list requirements draft 3b:
------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate MUST come first in the list.
     Additional certificates needed to construct a valid certificate
     chain SHOULD be ordered by increasing scope of authority.
     (e.g. sender, intermediate(s), certificate authority)
     It is NOT RECOMMENDED to include root certificates that
     peers must already possess in order to validate the
     given chain.
------------------------------------------------------------

This rewords the CA cert part into a more clear recommendation. (i.e. more than a MAY, but not quite a SHOULD)

Which, if either, of those two sounds good? Please also correct me if I've missed a subtlety here that needs to be taken into account. (or, or course, if I outright screwed something up ;)


Dave