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

[Eric Rescorla <[e-mail]>]

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.

OVERALL
Section 1.1 appears to describe two primary motivations for this
extension:

- 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-
      use

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.


OTHER COMMENTS
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.