[TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

Eric Rescorla <ekr@rtfm.com> Mon, 25 July 2011 17:19 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D100721F8BC5 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 10:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gRv13KGN07lD for <tls@ietfa.amsl.com>; Mon, 25 Jul 2011 10:19:02 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id E498721F8BC3 for <tls@ietf.org>; Mon, 25 Jul 2011 10:19:01 -0700 (PDT)
Received: by wwe5 with SMTP id 5so2896720wwe.13 for <tls@ietf.org>; Mon, 25 Jul 2011 10:19:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id c8mr4102341wbd.7.1311614340969; Mon, 25 Jul 2011 10:19:00 -0700 (PDT)
Received: by with HTTP; Mon, 25 Jul 2011 10:19:00 -0700 (PDT)
Date: Mon, 25 Jul 2011 13:19:00 -0400
Message-ID: <CABcZeBOVWtTgRcCQ_C8jq_E=LW5nKtUYFrTYyaDcb6-WtdtLWQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/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: Mon, 25 Jul 2011 17:19:02 -0000

This document describes a mechanism for allowing the client to
indicate to the server that he has cached the server's TLS
public key. The server then omits the key from the handshake
and the client relies on the cached value.

Section 1.1 appears to describe two primary motivations for this

- It saves the cost of transmitting the certificate over the network
  to the client.
- It potentially conflicts with other validation mechanisms which
  the client may have for checking the server cert.

In support of these motivations it lists the following use cases
(numbered by me):

   1. The TLS server public key is obtained from a [PKIX] certificate
      chain from an [LDAP] server

   2. The TLS server public key is obtained from a DNSSEC secured RRset
      using [DANE]

   3. The TLS server public key is provisioned by the operating system
      and updated via software updates

   4. A TLS client has connected to the TLS server before and has cached
      the TLS server certificate chain or TLS server public key for re-

The second motivation does not apply to use cases (1) and (4): The
server's credentials are already phrased as PKIX credentials and
client can validatte them however it wishes, the only need is for the
server and client to assure themselves that they have the same set of
validated credentials. Thus, the only issue here is bandwidth; the TLS
WG already has a (dormant) work item on caching certificate messages,
draft-ietf-tls-cached-info. That item is dormant due primarily to lack
of energy. To the extent to which we are dealing with certs phrased as
PKIX credentials, then energy should be applied to that document.

The second motivation is more convincing for cases (2) and (3) [though
in truth it is IMO still more likely that in case 3 the credential
will be phrased as a cert.] However, it's not really that convincing
to me: TLS stacks already have X.509 parsing, and pulling the public
key out is a fairly straightforward task. I don't see any reason
why it's troublesome to ignore the rest of the certificate; indeed
this is a quite common practice when self-signed certs are in use.
So, I don't see this as that troublesome. As above, the bandwidth
issue can be dealt with by draft-ietf-tls-cached-info.

In summary, I don't see a lot of use for this extension. However,
if there is real demand for it, the right approach would be to
resurrect draft-ietf-tls-cached-info and add a new cache type
for the EE public key.

What's the reason why you would want to send the server the
SPKI instead of the hash?

         opaque SHA256Hash<32>;

You probably want [32] here.