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

mrex@sap.com (Martin Rex) Thu, 07 May 2015 13:52 UTC

Return-Path: <mrex@sap.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 678FC1A7034 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 06:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 JMzz9jsmoozK for <tls@ietfa.amsl.com>; Thu, 7 May 2015 06:52:17 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028E31A6FF6 for <tls@ietf.org>; Thu, 7 May 2015 06:52:16 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 6EE8C44A45; Thu, 7 May 2015 15:52:14 +0200 (CEST)
X-purgate-ID: 152705::1431006734-00005316-41B50EBA/0/0
X-purgate-size: 1568
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 5F44743976; Thu, 7 May 2015 15:52:14 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 500811B2D9; Thu, 7 May 2015 15:52:14 +0200 (CEST)
In-Reply-To: <201505062313.06092.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 7 May 2015 15:52:14 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150507135214.500811B2D9@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yODBvH5bNx84bH_vElIUwskof_w>
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
Reply-To: mrex@sap.com
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 13:52:19 -0000

Dave Garrett wrote:
> https://tools.ietf.org/html/rfc5246#section-7.4.2
> ----------------------------------------------------------------------
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> ----------------------------------------------------------------------
> 
> It seems that in practice, nobody cares about that second "MUST".

That isn't quite accurate.

Up to 2013 our SSL implementation has been hard failing TLS handshakes
with TLS peers that are sending garbled or incomplete chains.

In 2013, I added a _simple_ reordering before certficate path validation.
Missing certificates or alien certificates are still going to result
in a fatal handshake failure.
 
The one thing that I fail to understand: why did SSL implementations
add sorting into the recipient side processing of the TLS Certificate
handshake message, but *NOT* at the same time fix their sender-side
processing of that handshake message to *NOT* send bogus certificat_lists
in the first place.  One of the most notorious offenders is OpenSSL.

-Martin