Re: [TLS] Update spec to match current practices for certificate chain order
"Ryan Sleevi" <ryan-ietftls@sleevi.com> Sat, 09 May 2015 03:51 UTC
Return-Path: <ryan-ietftls@sleevi.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 597881A8BC0 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 20:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 Rz1VOv4GTnVC for <tls@ietfa.amsl.com>; Fri, 8 May 2015 20:51:51 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6C1A8BB1 for <tls@ietf.org>; Fri, 8 May 2015 20:51:51 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E40952F4071; Fri, 8 May 2015 20:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=7jP8b6OGr6I+Amue4St0wKjCSo4=; b=j7S7ePyk3sitBE2LZ v64auxTOxvMowxNzE3DZNZwVGGO51Q4yl/PNemEnzNttZsqrbG+AEDAFdmwkukei R7fy5UB+qX9dCycrCOR0XRPvDeg+S+NsuTWWMtjLgK+KJ3AW8MZgmnjR/fwTZVcK Ppa9GUE5KtXXg4P88ucFwtPhf0=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id B9A552F4065; Fri, 8 May 2015 20:51:50 -0700 (PDT)
Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 8 May 2015 20:51:49 -0700
Message-ID: <a46388945a43eb199f843e505fcea6d9.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp>
References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp>
Date: Fri, 08 May 2015 20:51:49 -0700
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
To: mrex@sap.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rYXeCFWLYZe6v9JM7YSwKCcY02g>
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: ryan-ietftls@sleevi.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:51:52 -0000
On Fri, May 8, 2015 8:20 pm, Martin Rex wrote: > 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. Of course, none of this has happened because the X.500 directory doesn't exist, each client's job also has to maintain an appropriate trust store, the server cannot know apriori what that trust store is unless it knows the client, and if it does know the client, it can know whether or not it supports a given behaviour. > 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. I know nothing I say will dissuade you from calling it "unsafe path discovery", even though I rather vehemently disagree with you. I will simply point out, however, that were it not for this "unsafe path discovery", we would not finally be moving to a place where we might be able to turn off 1024-bit RSA keys used in intermediate and root certificates, because the PKI is hard and the Internet involves multiple stakeholders. > > 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. If you're going to write a client that works on the Internet at large and is capable of moving at the speed of the Internet, the best I can say is "Cheer up and deal with it". Clients doing what you propose, rather than the thing you hate, hold Internet security back, so I'm not terribly sympathetic (e.g. https://access.redhat.com/articles/1413643 for the most recent example) While I realize it's just my opinion, in my role, any client that does what you state above I consider bugged and recommend against deploying. Because it either won't work on the Internet or, far more commonly, it will hold the people trying to secure it back, and in the process, hold the whole Internet hostage to their broken security. But c'est la vie.
- [TLS] Update spec to match current practices for … Dave Garrett
- Re: [TLS] Update spec to match current practices … Yoav Nir
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Fabrice Gautier
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Geoffrey Keating
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Geoff Keating
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Salz, Rich
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ilari Liusvaara
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Watson Ladd
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi