IETF Logo Mail Archive

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.

v2.23.0 | Report a Bug | By Email