Subject: Re: [TLS] First TLS cached information draft posted

From: Min Huang <[email-masked]>
Date: Wed, 10 Jun 2009 14:56:57 +0800

Hi, Stefan

You said:
"1) Is it allowed to send over multiple CachedObject elements
containing the same type identifier?
Proposed answer = No (you can already include multiple hashes 
for each type)"

It means that the number of the cached certificate is one or 
it means the hash values of all cached certificates are contained 
in one CachedObject of the same type?

regards,
Min

I think I have to try to clarify this

The client send a cached_information extension which contains a list of
CachedObject structures.

Each ChachedObject element contains:

- type identifier (CachedInformationType type)
- a list of hash values (CachedInformationHash hashes)

Each CachedInformationHash contains:

- Algorithm identifier (HashAlgorithm hash)
- Hash value (opaque hash_value)

There are a number of issues that need to be specified or clarified in the
draft:

1) Is it allowed to send over multiple CachedObject elements containing the
same type identifier?

Proposed answer = No (you can already include multiple hashes for each type)

2) What should the server return in its server hello message for each
acceptable CachedObject?

Alternative 1 = The CachedObject element, exactly as it was received by the
client (with all hashes)

Alternative 2 = The CachedObject element, but only containing the
CachedInformationHash elements that is recognize and support.

Proposed answer = Alternative 1 (This allows the server to say YES in
principle without analyzing the hash values at the time of Hello exchange)

3) Is the server REQUIRED to honor its support of a CachedObject by
replacing the identified handshake data with a received hash?

Proposed answer = NO (for reasons raised by Martin)

4) What does the server send as replacement for the replaced handshake data?

Proposed answer = One opaque hash_value (without hash type identifier) that
was received by the client, which MUST contain a valid hash over the
replaced data.

Do you agree?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 17:09:52 +0200

Ming and Simon,

As you both seems to have misunderstood what I intended to say here.

What I currently think is the correct way is to include just one
CachedObject structure for each cached information type (e.g. One for
certificate data and one for CA names).

This CachedObject stucture may contain any number of hashes. This might be
hashes using different algorithms over the same object or it may be hashes
of the same kind over different objects (e.g. multiple acceptble certs). It
is just an unordered list of hashes.

The server now takes the data it intended to send. And compute the hash over
that data with as many algorithms it can out of the algorithms used by the
client. If one of the received hashes matches one of the generated hashes,
the match is accepted and the server will return one of the matching hashes
as acceptance of the cache (data replacement).

This is at least how it was intended in the current draft.

This is to me still the simplest, cleanest and easiest approach.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Jun 2009 17:29:00 +0200 (MEST)

> as acceptance of the cache (data replacement).

To me, this sounds more complex that I think it should be.

I think the server should neither have to compute and neither have
to check the hash values for all hash algorithms for which the client
sent hashes. (which implies that the client has to send hash
values consistently for all items and all hash algorithms that
it wants to offer.

The server should reply in the ServerHello extension for which items
and which hash algorithm (of those poposed by the client) it supports
substituting the real data with the replacement (the hash
value in the current proposal).

The server should not have to compute and compare multiple hash
values over the real value when composing the handshake message
affected by the diet, and neither should the client have to
compare the substituted value to the hash values of more than
one hash algorithm (when the client proposed multiple values
for the same item with different hash algs.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 18:01:25 +0200

Sorry, but I just have to disagree with myself.

It's just messy and non-logical to include hashes of multiple objects in one
and the same CachedOject structure.

I propose the following text:

   The client MUST NOT include hashes for multiple objects in the same
   CachedObject structure. If more than one hash is present in the
   CachedObject structure, they MUST be hashes over the same information
   object using different hash algorithms.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 17:40:15 +0200

Martin,

It may be that I misunderstand you because it is not clear to me what you
would like to do instead.

If you would spell out the ideal protocol flow exactly as you would prefer
it, what would it be like?

/Stefan