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

Martin Rex <Martin.Rex@sap.com> Mon, 06 October 2008 18:45 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 052083A67F4; Mon, 6 Oct 2008 11:45:44 -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 91F193A63D2 for <tls@core3.amsl.com>; Mon, 6 Oct 2008 11:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level:
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 gVl-bWDNzDPI for <tls@core3.amsl.com>; Mon, 6 Oct 2008 11:45:40 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 62CE93A686A for <tls@ietf.org>; Mon, 6 Oct 2008 11:45:35 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m96IjffC010679; Mon, 6 Oct 2008 20:45:41 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200810061845.m96IjcBV009717@fs4113.wdf.sap.corp>
To: smb@cs.columbia.edu (Steven M. Bellovin)
Date: Mon, 6 Oct 2008 20:45:38 +0200 (MEST)
In-Reply-To: <20081006113354.69029a62@cs.columbia.edu> from "Steven M. Bellovin" at Oct 6, 8 11:33:54 am
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: simon@josefsson.org, 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
Reply-To: martin.rex@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/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Steven M. Bellovin wrote:
> 
> On Mon, 06 Oct 2008 07:41:52 -0700
> Eric Rescorla <ekr@networkresonance.com>; wrote:
> 
> > I think there are two separate issues here:
> > 
> > (1) Whether implementations should be required to send certificates
> >     in a specific order.
> > (2) Whether implementations should generate an error if they are
> >     received in another order.
> 
> "Be conservative in what you send; be liberal in what you accept."

That was my first thought, too.  :)

However, the really interesting question for a customer/consumer
of a technology is actually this variant of (2):

(2a) if interoperability of two independent implementations of TLS
     fail because one side aborts with a fatal error if it receives
     an unordered certificate_list, who is to blame?

Maybe it should be reworded to say

  "You MUST fix your implementation if you fail to interoperate
   with peers that report an error when receiving an unordered list


I recently had a customer complain because he would have liked to
use SSL client cert authentication with a particular kind of
middle box from a router vendor, but found himself unable to
configure that, because that middle box did not offer a possibility
to configure an certificate_authorities list to be sent in
the CertificateRequest message.

Looking at the official protocol spec, the possibility to send an
empty list of certificate_authorities in the CertificateRequest
message was introduced as a purely optional feature with TLS v1.1.
It was _NOT_ previously allowed to send an empty list in
the SSL v3 and TLS v1.0 specifications!

I'm aware that some implementations have been violating this
requirement in the SSLv3 and TLSv1.0 spec (instead of failing on
an incomplete configuration), but I think it is a pretty dumb
engineering decision to create an implementation of SSL/TLS
where it is possible to configure the Server to request a
client Certificate and NO MEANS to configure the list of
certificate_authorities for the ClientRequest message,
because this list MUST be sent to SSLv3 and TLS v1.0 client, and
it will also be required for interoperability with TLS v1.1+
clients that do not implement support for an empty list.


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