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

mrex@sap.com (Martin Rex) Fri, 08 May 2015 14:19 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 E4F111A1B84 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 07:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.951
X-Spam-Level:
X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, 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 n3Hn6zX_c4Uy for <tls@ietfa.amsl.com>; Fri, 8 May 2015 07:19:28 -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 62B871A1B86 for <tls@ietf.org>; Fri, 8 May 2015 07:19:28 -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 4834D44C19; Fri, 8 May 2015 16:19:26 +0200 (CEST)
X-purgate-ID: 152705::1431094766-00000B48-9273206D/0/0
X-purgate-size: 2366
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 284D443EC7; Fri, 8 May 2015 16:19:26 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1C16A1B2DE; Fri, 8 May 2015 16:19:26 +0200 (CEST)
In-Reply-To: <201505071435.15754.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Fri, 08 May 2015 16:19:26 +0200
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: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/crygTHL0liXXGbK1qQBRyF7J0LY>
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: Fri, 08 May 2015 14:19:31 -0000

Dave Garrett wrote:
> 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.


No, the former is clearly detrimental.


Browsers, which haved added fancy colors and stuff to address bars
for EV certs, really ought to punish servers sending bogus Certificate
handshake messages by reducing the color feedback to mere black&white
and not attributes (_not_ produce a warning!  I believe the Google
Chrome 42 behaviour for sha1-Signatures is totally wrong, because
hardly anyone understands what the real issue is, and Chrome will
not tell you which signature algorithms in which certs it is unsatisfied
with).

I believe that one of the causes why the problem exists at all
is a lack of sensible PKI credential management on the server side.

Properly done, the PKI software on the server side will refuse
installation of a server certificate with an incomplete certification
path directly to the administrator who is trying to install the certificate.
The only person who can "fix" such a configuration error is the server
admin, so the admin (a) should get to see that error and (b) get to 
see it upfront, even before starting a server with a bogus configuration.

After successful server certificate chain verification (normally on
maintenance operations on a server's PKI credential, or for servers
lacking PKI credentials management, at least once on server start)
the correct ordering of certificates is known, and that known ordering
can then be used for thousands/millions of TLS handshakes without
wasting any further CPU cycles.


-Martin