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

[Paul Wouters <[e-mail]>]

On Mon, 25 Jul 2011, Eric Rescorla wrote:

Thank you for your review Eric.

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

Not entirely.

The TLS server never omits sending its public key. It only omits sending
it in a PKIX container.

The TLS client indicates that it has authenticated the key out of band,
not neccessarilly only when it cached it from a previous session. In
fact, the primary use case intended here is out of band public key
validation.  Reusing a cached key is just a bonus effect of the more
modular authentication mechanism.

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

Perhaps we were not clear enough in section 1.1. The primary motivation
is to allow decoupling of TLS server public key authentication from PKIX
validation, allowing TLS clients to determine their own authentication
scheme to apply for talking to the TLS Server.

> 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

This is part of the current problem we are trying to solve. Currently,
there is no choice but to wrap the TLS Server public key into a PKIX
container that necessitates specifying certain information that can
be problematic for some reasons:

- Conflicts with the actual TLS client authentication scheme
- PKIX mandated data that cannot be processed by the TLS client for non-PKIX
   authentication.

One example given were the conflicts of TLSA/HASTLS data with PKIX data
when using DANE.

Another one we did not mention is, and which we should probably add,
is that some applications (eg browsers) cannot store PKIX received
information for non-PKIX authentication methods. In other words, a browser
cannot store a certificate used as packaging container for a DANE TLS
server public key, because it contains a made up, unvalidatable, CN=
which cannot be left out of a PKIX cert. Think of my DANE certificate
specifying CN=paypal.com for the host dane.xelerance.com. The browser is
forced to maintain an internal list of what information inside the PKIX
container has been properly validated with a non-PKIX method (eg DANE)

> client can validatte them however it wishes

While that is true, it is a weak argument for necessitating sending cruft
in the TLS protocol forever after.

I would say especially so, since this TLS extension is a pretty trivial change,
both in specification and implementation. Especially on the TLS server side.

Additionally, asking to send PKIX freeform data inside a crypto protocol does
make me nervous from a security point of view. We've seen issues in the past of
PKIX certificates with mangled data and pre-image attacks by using various PKIX
fields.

TLS clients that would only need to support something like DANE, would not even
need an ASN.1 parser anymore if the TLS server supports this new TLS extension.

> TLS stacks already have X.509 parsing,

That might be considered a security problem instead of an asset.

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

And what did that ignoring get us? Massive amounts of popups and security
warnings to click away. The idea is that we cannot receive a TLS public
key for "dane.xelerance.com" that pretends to be "paypal.com". Saying
that it is easy to ignore is not a strong argument for trying to ensure
no one has to make the ignore/not ignore decision by a proper design.

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

Originally, we put it in as SPKI because we were envisioning that the TLS
server could just respond with the extension containing an empty list, as
the client already has knows (and authenticated) the public key out of band,
and we wanted at least one full copy of the TLS server key covered by the
Finished Message. In response to talking to some people, it was deemed more
orthogonal to the current TLS protocol to have the TLS server send a copy
of its public key (as it does so in the regular PKIX case inside the container)

With the TLS server sending the full public key, we can indeed remove it from
the TLS client side.

>         opaque SHA256Hash<32>;
>
> You probably want [32] here.

Thanks. I've updated it in my copy.

Paul