Re: [TLS] Cached-info substitution

[Adam Langley <[e-mail]>]

On Fri, Feb 19, 2010 at 10:01 AM, Stefan Santesson <[e-mail]> wrote:
> 1) To define a format for the handshake message which include the hash
> substitution using a syntax that alters the defined syntax of the handshake
> message. (current draft approach)
>
> 2) To define a format which preserves the original handshake message syntax.

I'm afraid that I'm still not clear what you mean here.

In the current draft:

"Following a successful exchange of "cached_information" extensions,
the server may replace data objects identified through the client
extension with any of the CachedInformationHash values received from
the client, which matches the replaced object."

My understanding is that this is a "memcmp for magic values" scheme.
Given the size of the hashes, this isn't unreasonable, I just feel
that we should be more explicit if possible.

Given that, we could

1) define new handshake messages, although you're correct that the
namespace is small.

2) Redefine the structure of the existing handshake messages for the
case when this extension is in effect. The new structures would have
an explicit field for substituted hashes, in addition to the old
fields. Hosts would choice one or the other to be non-zero length.
(Based on my knowledge of NSS and OpenSSL's code, this wouldn't be too
bad to implement.)

3) Wedge the cached values into the current structures somehow. Brian
suggests using zero lengths as a magic marker. However, the hash value
would still need to follow because the client could have predicted one
of several values. I think this is a poor man's version of option two.


AGL