Subject: [TLS] Cached Info extension - Draft 01

From: Stefan Santesson <[email-masked]>
Date: Tue, 16 Jun 2009 19:13:36 +0200

I decided it was easier to explain my suggestions by incorporating it into a
new draft and submit it.

Draft 01 is currently in staging at:
http://www.ietf.org/proceedings/staging/draft-ietf-tls-cached-info-01.txt

This indicates by no means that I think we have reached an agreement on this
issue, but it at least we have a version that represents a better starting
point for change discussions.

I did however include Simon¹s suggested wording amendment in the beginning
of section 4.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 24 Jun 2009 12:43:53 +0200

It was not my intention to kill off this discussion with this new draft.

I¹m wandering whether the silence is a sign of agreement, vacation or just a
giving up that the author will ever listen to reasonable arguments...

/Stefan

On 09-06-16 7:13 PM, "Stefan Santesson" <[email-masked]> wrote:

> I did however include Simon¹s suggested wording amendment in the beginning of
> section 4.
> 
> /Stefan
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Jun 2009 14:24:13 +0200

> giving up that the author will ever listen to reasonable arguments...

I still prefer Martin's proposal to add framing, but could live with
your approach.

A mild problem that I don't think is fully covered yet is the complexity
in transition to new hashes -- clients will forever need to send SHA-1
hashes to the server, it seems, to ensure interoperability?  Or should
the document contain some text that explains that servers should pick
the "preferred" hash it supports, and that clients should cache that
choice for future use?  Additional text would then be needed to explain
that if clients try the new hash later on, and it doesn't work, it
should revert back to SHA-1 in case the server software was changed to
not support the other hash.  This aspects doesn't feel completely baked
yet to me.

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Jun 2009 14:41:28 +0200 (MEST)

> not support the other hash.  This aspects doesn't feel completely baked

How about extending the ClientHello and ServerHello extension
with a pure negotiation of the supported Hash algorithms?

So that in the first request, when the client does not have any cached
data (and no hash values to propose), only the hash algorithm is
"negotiated", plus the data elements for which the server supports
caching in principle?

This way, the client can learn which hash algorithm the server
supports before filling his cache, and the client can also abstain
from caching for servers that do not support the extension at all
and abstain from caching particular handshake data, for which the
server does not support caching.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Jul 2009 03:12:30 +0200

I might be missing something, but I'm not sure I get the problem.

One difficulty I have is that I don't see, and never have seen, the reason
to provide different levels of hash algorithms for a usage that does not
require a strong hash.

But even if the client decides to do this, the server can pick any of the
hashes as the return value. That hash is long and random enough to work as a
perfectly unambiguous identifier of a successfully replaced cached object,
and is long and random enough to reduce the chance of accidental collisions
of any kind to totally negligible probabilities.

Maybe we should sit down in Stockholm and come up with a solution that
hopefully makes everyone happy.

/Stefan