[TLS] Comments on the cached-info draft

Stefan Santesson <stefan@aaa-sec.com> Wed, 07 November 2012 16:42 UTC

User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Wed, 07 Nov 2012 11:42:19 -0400
From: Stefan Santesson <stefan@aaa-sec.com>
To: tls@ietf.org
Message-ID: <CCBFF439.533CB%stefan@aaa-sec.com>
Thread-Topic: Comments on the cached-info draft
In-Reply-To: <312F1D0E-0C86-439E-A854-ADBBA0D7D23A@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [TLS] Comments on the cached-info draft
Precedence: list

It was quite a while since I wrote the first version of this draft.
Now that I bring it up to my attention I found a problem that I think
should be fixed.

After a close examination I'm convinced that the current spec breaks TLS.


The current approach is to exchange support for cached-info in client and
server hellos.
This includes hashes for cached objects (clients) and confirmation of
cached objects (server).

In addition to this, this protocol allows the cached data in handshake
messages to be swapped with cached object hashes.
This is a violation of the syntax of these handshake messages.

Take the Certificate handshake message for example. The spec suggest here
to replace the certificate_list vector to be replaced with a vector of
CachedObejct structured data.
This breaks the syntax of this handshake message. A strict processing of
the certificate_list vector will expect an ASN.1 encoded binary containing
a sequence of certificates, not a vector of data objects according to the
CachedObject structure.

My first thought was that we actually need a new handshake message.
However that is not helpful either.
The TLS spec require the Certificate handshake message to be sent in case
the chosen cipher suite demands it, so it MUST be sent.
It can't be replaced by another handshake message.

My current belief is that we simply should omit the cached data, and that
each cachedInfo type need to defined how to omit cached data.

In case of the certificate handshake message, the certificate list should
be replaced with an empty sequence.


There is actually no need to send the hash of the cached data in the
handshake message. Not if the confirmation of the cached info is exchanged
in the server hello. Sending the hash once more in the handshake message
is then redundant.


So I propose the following:

1) Clients send hashes of cached objects in client hello.
2) Server responds with one or zero hashes per cachedInfo type, that a)
matches a cached object sent by the client b) will be omitted by the
server in the corresponding handshake message.
3) How information is omitted from the handshake message is defined per
cached info type. For the current defined 2 types this is:
  A) cached certificate cahins in Certificate: replace the sequence of
certificates with an empty sequence.
  B) certificate_authorities in Certificate Request: Send an empty list of
DistinguishedName
4) Clients will act as if the cached objects (confirmed in server hello)
were sent in the handshake messages.
5) Everything else according to the current spec


The proposed approach will somewhat limit the functionality of the current
spec, but it ads value in simplicity.
I can't imagine a valid use case that would not be covered by this change,
but I might overlook something.

Re: [TLS] Comments on the cached-info draft Martin Rex
Re: [TLS] Comments on the cached-info draft Hannes Tschofenig
[TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Hannes Tschofenig
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Paul Hoffman
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Hannes Tschofenig
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Peter Sylvester
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Hannes Tschofenig
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Paul Wouters
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Peter Sylvester
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Hannes Tschofenig
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Hannes Tschofenig
[TLS] Comments on the cached-info draft Stefan Santesson
Re: [TLS] Comments on the cached-info draft Joseph Salowey (jsalowey)
Re: [TLS] Comments on the cached-info draft Stefan Santesson
Re: [TLS] Comments on the cached-info draft Piyush Jain
Re: [TLS] Comments on the cached-info draft Joseph Salowey (jsalowey)
Re: [TLS] Comments on the cached-info draft Joseph Salowey (jsalowey)
Re: [TLS] Comments on the cached-info draft Piyush Jain
Re: [TLS] Comments on the cached-info draft Piyush Jain
Re: [TLS] Comments on the cached-info draft Joseph Salowey (jsalowey)
Re: [TLS] Comments on the cached-info draft Piyush Jain
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Sean Turner
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Nikos Mavrogiannopoulos
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Joseph Salowey (jsalowey)
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Sean Turner
Re: [TLS] draft-ietf-tls-oob-pubkey-06 Sean Turner
Re: [TLS] Comments on the cached-info draft Joseph Salowey (jsalowey)
Re: [TLS] Comments on the cached-info draft Martin Rex
Re: [TLS] Comments on the cached-info draft Piyush Jain