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

mrex@sap.com (Martin Rex) Sat, 09 May 2015 03:20 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 5A7FC1A8A7E for <tls@ietfa.amsl.com>; Fri, 8 May 2015 20:20:40 -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 JozKKle1VHT0 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 20:20:38 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3415D1A8A67 for <tls@ietf.org>; Fri, 8 May 2015 20:20:38 -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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3645C2AF60; Sat, 9 May 2015 05:20:36 +0200 (CEST)
X-purgate-ID: 152705::1431141636-00005316-235CB2E8/0/0
X-purgate-size: 1741
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 11E1743E70; Sat, 9 May 2015 05:20:36 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 072AD1B2E2; Sat, 9 May 2015 05:20:36 +0200 (CEST)
In-Reply-To: <201505081935.13474.davemgarrett@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Date: Sat, 9 May 2015 05:20:35 +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: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wXGEYDLUbiyHvaOXEQ3mmbK9xwc>
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: Sat, 09 May 2015 03:20:40 -0000

Dave Garrett wrote:
> A PR with language based on this discussion:
> https://github.com/tlswg/tls13-spec/pull/169/files
> 
> The text is mostly the same or similar, with the second "MUST" changed
> to a "SHOULD", and the term "trust anchor" replacing references to root
> keys/CA.
> 
> Is this changeset acceptable?


I am violently opposed to this change.

It creates new ambiguities, makes bogus, backwards-incompatible
and interoperability-impairing behaviour appear less objectionable,
while providing _zero_ benefit.


The "original" requirements apply to the server's Certificate
handshake message, i.e. which certificates and in what order the
server is required to encode into the Server Certificate handshake
message.

The purpose of these requirements for the server is to facilitate
the the client's job to verify the server's certificate, improve
interoperability and create a predictable&deterministic client
behaviour that should be independent from the particular client
implementation as much as possible.

Clients that are willing to perform unsafe path discovery on
a Server's certificate handshake message will *NOT* be inconvenienced
if the server puts the certificates in correct order and optionally
omits only the self-signed rootCA certificate at the end.

Clients that do not perform any fancy unsafe path discovery, on the
other hand, may easily be non-interoperable with sloppy servers that
do not properly compose their Server Certificate handshake message,
and these Client are _not_ to blame for any resulting interop failure,
because it is clearly the server TLS implementation that goofed
when it produces a Server Certificate PDU that violates the MUSTs.


-Martin