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

Nelson B Bolyard <nelson@bolyard.me> Sat, 11 October 2008 21:40 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 B3E273A68CE; Sat, 11 Oct 2008 14:40:09 -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 AFABC3A68CE for <tls@core3.amsl.com>; Sat, 11 Oct 2008 14:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 aiKVzjeBFycg for <tls@core3.amsl.com>; Sat, 11 Oct 2008 14:40:07 -0700 (PDT)
Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id 882233A690D for <tls@ietf.org>; Sat, 11 Oct 2008 14:40:06 -0700 (PDT)
Received: (qmail 6772 invoked from network); 11 Oct 2008 21:40:55 -0000
Received: from unknown (64.202.165.47) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 11 Oct 2008 21:40:55 -0000
Message-ID: <48F11D66.6040900@bolyard.me>
Date: Sat, 11 Oct 2008 14:40:54 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20080930003201 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: IETF TLS Working Group <tls@ietf.org>
References: <E1KnXuC-00044h-Qp@wintermute01.cs.auckland.ac.nz>
In-Reply-To: <E1KnXuC-00044h-Qp@wintermute01.cs.auckland.ac.nz>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Peter Gutmann wrote, On 2008-10-08 05:12 PDT:
> Martin Rex <Martin.Rex@sap.com> writes:
> 
>> But I really dislike the idea of expecting an empty DName (i.e. one
>> that contains no RDName elements in the ASN.1 SEQUENCE) should have the
>> same meaning as _NO_ DName at all!  Are you sure that this notion is 
>> interoperable with other implementations?
> 
> Because TLS client certs are so rarely used it's hard to say, the best I
> can say is "I haven't run into problems so far", but that doesn't mean
> much given the very small sample size.

Since I work on TLS for Mozilla products, I can offer some perspective
on the issue of the frequency or rarity of client authentication requests.

Mozilla's products (browsers and email MUAs) have always implemented client
cert authentication.  They offer the users a choice of what to do when
a server requests client certs, and the choices include:

- Automatic selection.  The product selects a cert automatically based on
issuer name matching the server's list of CA names, (empty list of CA names
treated like a wildcard).  Basically, the first cert with matching issuer
name and appropriate KU and EKU is used. If the user has no cert from an
appropriate issuer, send no_certificate response.  This is all silent (no
user interaction) unless the user's private key requires authentication for
every use.

- manual selection.  If the user has any cert(s) whose issuer matches the
server's list of CA names, with appropriate KU and EKU, the product presents
the user with a list of such certs, and lets the user choose one.
An empty list of CA names from the server is treated like a wildcard.
Certs with no EKU extension are presumed to be valid for all EKUs.
Even if the user has only one cert that matches, he is prompted to choose.
He can also choose not to send any cert, but to send a no_certificate
response.  If the user has NO certs that match, then the user is not
presented with any list, and a no_certificate response is silently sent.

(Pre-configured per-server selection of client cert (including "none")
is in development.)

Until recently, the default for both browsers and MUAs was automatic
selection.  But this was recently changed in both types of clients,
for separate reasons.

For browsers, there arose a concern that automatic and silent client cert
authentication allows a web site to request cert authentication even when
the user has no business relationship with the site, and could be used for
user tracking, defeating anonymity of browsing.  So the default setting in
browsers was changed to manual selection to avoid silent user tracking.

This change caused a LOT of users to begin to have a very different user
experience with their browsers and MUAs.  Requests for client certs were
apparently MUCH more common and wide spread than we had previously known.
Users who had their own certs for email purposes, certs whose KU and EKU
also permitted them to be used for TLS client authentication, suddenly
found themselves being inundated with requests to select a cert for
client authentication.

For MUAs, the reason for making manual selection the default was different.
A number of popular free email server products that offer SMTP and IMAP
(or POP) over TLS have recently begun to exhibit the following behaviors:

- No TLS session cache.  A full handshake is done on every connection.
- Client certs are requested in EVERY handshake.
- The list of CA names in the server's cert request is empty, with no
  way for the server admin to change that.
- If the server receives a client certificate that it does not recognize
  as being authorized to authenticate any user, instead of ignoring the
  cert, and going on to request authentication using one of the other
  methods (e.g. user name and password), it drops the connection, usually
  without sending any alert.

MUA users who possessed their own email certs found themselves unable to
successfully connect to their mail servers because their MUAs would
automatically send their email cert to the server for client authentication,
and the server then dropped the connection.  The immediate workaround for
them was to configure their MUA for manual selection of certs for TLS
client authentication, and then choose to send a no-certificate response
when prompted.  However, this was not entirely satisfactory because they
found themselves having to manually choose to send no certificate on
EVERY connection.  For IMAPS users, this meant encountering the cert
selection dialog every time they change to view a different IMAP folder.
It also meant encountering the dialog on every message sent.

The MTA administrators are generally unaware of client authentication.
They are unaware that they have the ability to associate a certificate
with each user account, thereby allowing the cert to be used in lieu of
name and password Identification and authentication.  They have no way
to change the behavior of their MTA server product.  Therefore, they
perceive the unfortunate MUA user experience to be an MUA bug, not an
MTA server bug.

ANY of the following changes would mitigate these problems:
- servers implementing TLS session caches, and then not performing FULL
handshakes on every connection.
- servers sending non-empty lists of CA names.
- CAs issuing email certs with EKU extensions that disallow use for client
authentication.  However, this dual use is considered a feature by CAs.

In trying to persuade MTA administrators to enable TLS session caching in
their servers, we found that there is widespread misunderstanding and fear
that TLS session caching somehow allows clients to have access to accounts
on servers without having authenticated to the servers.  They seem to
believe that with a TLS server session cache enabled, any client can reuse
a previously cached TLS session without authentication.  They are fearful
to the session caches, and see the session caches as part of the problem,
not as part of the solution.

Believing that these problems will not be quickly solved, Mozilla is working
on implementing the ability for the client to remember the
association of a user-chosen cert with a server, so that it can repeat
that choice thereafter without bothering the user again.  However, this
will certainly mask the issues of servers not reusing TLS sessions.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls