Re: [TLS] Cached Info extension - Draft 01

[Martin Rex <Martin.Rex at sap.com>]

Simon Josefsson wrote:
> 
> Stefan Santesson <stefan at aaa-sec.com> writes:
> 
> > 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...
> 
> 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.


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