Re: [TLS] First TLS cached information draft posted

[Martin Rex <Martin.Rex@xxxxxxx>]

Simon Josefsson wrote:
> 
> > 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)
> 
> I understand Martin's concern, but how would a client know whether data
> was replaced or not?  How would the client know which hash algorithm is
> used?

The Server can reliably signal in the ServerHello extension whether
it supports Caching for an object for which the Client asserted
a Hash value in the ClientHello extension, and the Server ought
to be able to decide upfront which Hash algorithms it supports.

Allowing the client to supply different hashes for different
incarnations of the same tls handshake data would significantly
increase the protocol complexity.  Suddenly, the hash values
of different algorithms might refer to different cached data.

I would suggest to limit the client to announce only one cached
value (possibly with different hash algorithms, but then the server
should not have to check each hash value for a mach, but only the
hash algorithm selected by the server).

It might be sensible for the client to manage cache entries based
on several attributes, and in particular distuigish also by the
"server name" as used in the TLS extension "Server name indication"
in order to support TLS-compatible virtual hosting.


> 
> > 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.
> 
> I think we need to include the hash algorithm too.  You cannot infer
> which hash algorithm is used based on the length only.
> 
> I don't think it is reliable to optionally replace data.  Hash values
> can be made to look like valid ASN.1, and the client would have to guess
> whether the server replaced the value or not.

The Server Hello Extension should indicate whether the server will
try to use the caching extension, and which hash algorithm it is
going to use (from those proposed by the client).

So the "heuristic" of the client is to match the potentially cached
data (length first, then data) against the one hash value that the
client originally proposed in the ClientHelloExtension and that the server
agreed to support in the ServerHelloExtension.

Personally, I'm not concerned about a potential collision of the
clients proposed hash with the real data that the server is going
to send.  Such a collision would not affect the data that the server
is going to send, it could only affect how the client would
interpret it (using the cached data instead of parsing the
real data that looks like its proposed hash).

What are possible alternatives?
- Send other data that could be ambiguous in other scenarios
- Send data in a specifically invalid fashion, i.e. a maximum-value
  length field that exceeds the outer container size.


-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls