Re: [TLS] Verifying X.509 Certificate Chains out of order

pgut001@cs.auckland.ac.nz (Peter Gutmann) Tue, 07 October 2008 12:25 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4192F3A6B5F; Tue, 7 Oct 2008 05:25:02 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E693A6861 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 05:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOVvMsgQgde8 for <tls@core3.amsl.com>; Tue, 7 Oct 2008 05:24:59 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 16D793A689A for <tls@ietf.org>; Tue, 7 Oct 2008 05:24:58 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 81085481C03; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWAZwMcSXtx5; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 662E9481BAC; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2F9D619EC0BA; Wed, 8 Oct 2008 01:25:22 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1KnBcw-0000hC-1u; Wed, 08 Oct 2008 01:25:22 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: martin.rex@sap.com
In-Reply-To: <200810071049.m97An3Gt010285@fs4113.wdf.sap.corp>
Message-Id: <E1KnBcw-0000hC-1u@wintermute01.cs.auckland.ac.nz>
Date: Wed, 08 Oct 2008 01:25:22 +1300
Cc: tls@ietf.org
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

[Replying to two messages at once]

Axel.Heider@gi-de.com writes:

>> I'd say modify it, in fact I'm not sure what the rationale for requiring
>> ordering was in the original spec, "it's tidier that way" doesn't strike me as
>> a good argument :-).
>
>Consider TLS on low-end or embeddede devices with limited ressources. Walking
>through the chain becomes difficult or even impossible if there is no order.

Again, how can you create an implementation that can run the entire SSL
protocol but can't manage a few 32-bit pointers across three or four certs?
This seems like a total red herring, it's difficult to think of an
implementation that can perform the necessary cert verification but somehow
can't manage an extra pointer swap.

(Well, I'm sure I can come up with some pathological case where you can do one
and not the other, but I'd have to apply some pretty creative thinking :-).

>The situation that you describe as "unlikely" is the situation that is going
>to be the norm when SSL client certs start getting used in a serious fashion.

Oh, in that case there's nothing to worry about, if I can wait until PKI
starts working before I need to address it then I'm OK.

>You walk up to a restaurant for a dinner.  The guard at the door tells you
>that you need a membership card in order to enter and hands you a form to
>fill in and prove your membership    however he refuses to tell you which
>membership he will consider acceptable. Actually    he promises you that if
>you happen to pick one that is not acceptable, he will send you away with a
>painful kick in the butt.

What a marvellously nonsensical example.  If I go to http://www.amazon.com I
enter the password I use for Amazon.  If I need to provide a cert, I provide
the cert I use for Amazon.  End of story.  This procedure has worked just fine
for more than ten years now for SSH, which I'm sure has a much larger and more
diverse user base than client-side SSL certs ever will.

>Another serious problem of the "server sends nothing" approach is that it
>requires the client to blindly perform an expensive public key operation and
>this may incur the overhead/incovenience of prompting the user to insert a
>hardware token and/or enter a PIN to authorize a private key operation --
>which can be entirely avoided if the server announces what CAs it trusts and
>there is no match to the credentials available to the client.

Sure, I'll admit that one's a real issue in the special situation where this
specific case applies.  OTOH I'm happy to leave things as they are until
client certs take off before I look at it further, I've got way too much other
stuff to work on that's more pressing than this.

And that's the real killer for this I think: If you're going to go with these
niche variations that almost no-one uses, you sort of have to accept that
you're going to be in a world of pain.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls