Subject: Re: [TLS] Comments on cached info at TLS meeting

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 Aug 2009 11:21:19 +0200

I guess the main thing to discuss after the IETF meeting is whether the
server need to signal in its server hello exactly what data it will replace
in the server hello OR if the server can return an empty cached info
extension and decide later what to replace.

Both models should work IMO but they have different pros and cons.

Does anyone have any strong arguments?

/Stefan

On 09-07-31 1:46 PM, "Stefan Santesson" <[email-masked]> wrote:

> Recap of comments on cached info during the IETF meeting in Stockholm.
> 
> Simon thought that it would be OK to send just the hash as replacement for the
> cached data if the client treats the hash as an index that identifies the
> replaced data. Doing so avoids guessing by the client. A clarification should
> be made in the draft.
> 
> Eric made a comment on Jabber that ³now that I see this problem suggested,
> this seems pretty gross from an implementation perspective. I think I'd prefer
> that the cache hits be returned explicitly in the extension²
> 
> I interpret this to mean that Eric wants the server to acknowledge exactly
> what data it will replace when it sends its server hello.
> This means that we have different opinions on the list whether the server have
> to know what data it will replace at server hello exchange.
> I¹m personally pretty agnostic about this, but we need to agree on one
> approach.
> 
> Other than that it was suggested that other objects could be of interest to
> define in the draft. We may see proposals on the list.
> 
> /Stefan
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

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

> extension and decide later what to replace.

What I would really like to see is a possibility to
negotiate the use of this extension on the first contact to a
new server, so that the client can learn right away whether
the server supports the extension, and which hash algorithm server
and client share.

With this knowledge, the client does not need to populate his
cache with data that will never get used at all (because the
server does not support caching for this information or does
not support caching at all).

And the client will not have to ever propose more than one hash
value for a piece of information, because the client then will
already know the common hash algorithm (if any) when it adds
the information to its cache.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 Aug 2009 19:45:20 +0200

> not support caching at all).

This sounds like a good idea to me.

> the information to its cache.

There is a concern if the server migrates to another system or software,
and the cached information becomes stale.  There needs to be some
discussion in the document around that, and it isn't exactly clear to me
how it could be worded.  For example, how does the client detect this?

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Aug 2009 14:34:50 +0200

> This sounds like a good idea to me.

I wander if this is a worthwhile optimization. We are not talking about a
huge amount of data here.

But I don't mind either way. I just wanted Eric to say why he want the
cached data to be selected, accepted and negotiated at client/server hello
time.

> how it could be worded.  For example, how does the client detect this?

I think the simple answer is that the client will know that the caching
proposal failed if the server rejects the offer to replace cached data with
a hash provided by the client.

The client response to such situation may vary. I can see several options,
all valid.

1) The client updates its cache with the data sent by the server and upon
next connection will send multiple hashes to the server (assuming that the
server may have been updated).

2) Upon multiple failures by the server to accept information caching, the
client may set the caching on hold for that server and may apply different
logic for when and how to retry caching to that server.

3) The client may decide to always send caching info to all servers at all
times except for those where the result is repeated unexpected failures.

I have no objection to clarify this in the draft.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 11 Aug 2009 20:32:46 +0200 (MEST)

> how it could be worded.  For example, how does the client detect this?

If the hash value sent by the client does no longer match the
hash value over the new/changed data on the server, the server
is going to send the new/full handshake data.  So the handshake
should always automatically fallback to the full handshake, unless
there is a hash value collision.

What is it exactly that you're asking for?

Guidance about when the client should update his cache entries?

The client should probably drop/replace cache entries whenever
the server sends new/full data instead of using cached values.

The more interesting question might be to "key" the cache entries.

The key into the cache should probably distinguish the server
name from the URL / connection-info in order to support the
TLS extension "Server Name Indication",

The server certificate will probably depend on the public key type
used for the key exchange algorithm (RSA,DH,DSA,ECDSA,...) of the
negotiated TLS ciphersuite.

The list of trusted CAs, on the other hand, may vary with the
server name, but should be fairly independent from the public
key type used by the key exchange algorithm of the negotiated
TLS ciphersuite.

-Martin