Re: [TLS] First TLS cached information draft posted

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

Stefan,

Stefan Santesson wrote:
> 
> I don't like the extra complexity of the proposed structure and I fail to
> see the problem of recognizing the hash as replacement of data.
> 
> First of all, the worse case scenario if everything fails miserably and
> client mistake a hash for real data or the other way around, is a failed
> handshake.
> 
> This is followed by a normal handshake where the client will reset it's cash
> for that server.
> 
> This safe fallback allows us to accept reasonable risk of failure.
> 
> Now, how hard is it to recognize a hash as replacement for cashed data and
> what is the risk of collision?

I agree that probability of an accidental exact match (length and value)
between a hash value over previous real data and the representation
of new real data after a config change of the server is EXTREMELY low.
Personally, I it consider it negligable.


I do not agree with the reasoning about the recovery -- a requirement
to close a communcation channel entirely and restart from scratch
is something that is likely going to break a lot of apps (I wish
it did not, but unfortunately, it does).  Designing the protocol
in a robust fashion so that there is no abiguitiy, and unnecessary
risks of failure are avoided, is usually a sensible thing to do.
I personally do not think we have such a risk here, it is more
about clean architecture and avoiding heuristics in a protocol parser.


Since I am no real TLS implementor myself, I do not have any
personal preference on whether or not to use an extra framing, and
want to leave the discussion and in particular the decision to the author
and those implementors who intend to implement this extension and those
that are familiar with the requirement of small/constrained clients
or low-bandwidth connections that expect a benefit from using this
extension.


-Martin