Re: [TLS] TLS Fast-Track resurrected?

[Stefan Santesson <stefans at microsoft.com>]

Martin,

Thank you for taking the time and effort to provide a good and elaborate explanation of your concern.
You are making a valid point and I'm first in line to acknowledge the value of not only assuming the perfect world.

I do think that the problem you highlight could be auto-recovered in just the way you mention. That is, if a fast-track handshake fails due to failed server certificate validation, the client would automatically flush its cache and reconnect with a normal handshake. The cache would then be updated and functionality restored.

However, to provide a full hash of the complete set of omitted data is a very easy principle that could be worth it for just that reason.
I would not oppose adapting your proposal in this regard.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Martin Rex [mailto:Martin.Rex at sap.com]
> Sent: den 12 december 2008 17:03
> To: Stefan Santesson
> Cc: martin.rex at sap.com; jsalowey at cisco.com; tls at ietf.org
> Subject: Re: [TLS] TLS Fast-Track resurrected?
>
> Stefan Santesson wrote:
> > >
> > > > Well, the server certificate is in my proposal is hashed exactly
> > > > as I appears on the wire. There is no need to hash anything but
> the
> > > > server certificate.
> > >
> > > Nope, that is wrong.
> > >
> > > IF we talk about caching, then it is about not sending in a
> repeated
> > > handshake that was sent in a previous handshake.
> >
> > In the original fast-track yes, but that does not have to be so.
> > If we only cache the certificate, we would do a new handshake except
> > the server would not send its server certificate.
>
> I see potential pitfalls with that approach and therefore I don't like
> it.
> Only in case that the client would always and unconditionally ignore
> all
> chain certificates following the server certificate when performing
> certificate path validation, then this approach would reliably lead
> to the same behaviour for the initial and the fast-tracked handshake.
>
> However, this is unlikely to be generally true and much too easy to
> get wrong in an implementation (and will not show in the kind of
> interop tests that people normally do).
>
> I would really prefer if "fast-track" would be only about re-using
> (aka caching) information from a original full TLS handshake in order
> to cut down on the data traffic of repeated full handshakes (assuming
> that the much quicker&cheaper existing SSL/TLS session resumption
> is not an option).
>
> Using a hash about the exact representation of the data as an
> identifier
> for the data to be omitted from a fast-tracked full TLS handshake is
> the most reliable/robust approach.  If the hash doesn't match, the
> server will send the original data instead and the client can update
> his cache.
>
> If an identifier unrelated to the actual data on-the-wire is used,
> then client and server have no proof they're really refering to
> exactly the same data.  If the is/gets out-of-sync for whatever
> reason, the fast-tracked handshake using data-unrelated identifiers
> will fail, and the client will have to (a) retry and (b) apply
> heuristics whether a failure could be related to out-of-sync
> data references by the unrelated identifier and the client will
> have to OMIT the fast-track proposal from the next handshake in
> order to recover -- otherwise the client will be stuck in an
> endless error loop.
>
>
> Using a hash derived from the on-the-wire data as an identifier,
> the recovery will always be automatic, never cause any handshake
> failures and the client can blindly assert the fast-track
> identifiers in every client hello, this will never impair
> recovery from situations where the server's configuration was
> unexpectedly changed or the clients cache got corrupted.
> (well, the exact behaviour with respect to client cache corruption
>  depends on when the client computes the hash value over the cached
> data
>  that it sends in the fast-track hello extension).
>
>
> I *personally* don't have any scenarios where the "benefit" of a
> fast-track extension will actually be worthwile (worth the effort).
>
> In case that others have/know such scenarios and these do involve small
> pieces of hardware (instead of PC-style equipment), then having
> a quite reliable scheme of recovery after a blackout, power
> interruption,
> hard reset or factory-default-reset might be worth considering.
>
> >
> > > If the client would send only the hash of the server certificate
> > > and the server would omit the entire chain, then this would
> > > significantly change the entire handshake.
> >
> > Not at all, the client and server have all chances to resolve that
> situation.
>
> It DOES change the handshake.  It WILL change the result of the
> server certificate path validation if the client uses the chain
> certificates provided by a server during an original full SSL handshake.
>
> Picture this:
>
>     - original full SSL handshake, server sends inadequate, incorrect
> or
>       defective chain certificates.  The client caches all received
>       certs (server cert plus chain certs), but the clients certificate
>       path validation doesn't currently use the server-supplied chain
> certs
>       and succeeds the TLS handshake and caches *ALL* the received
> certs.
>     - all future full SSL handshakes are fast-tracked, but the client
>       sends only the hash/identifier of the servers certificate
>     - at some point, the servers chain certificates are fixed
>     - client doesn't realize that the servers chain certificates
>       have changed and can not update his cache because it is still
>       fast-tracking with the hash/identifier for the servers cert only
>     - something about the clients configuration is changed so that
>       for successful verification it will suddenly need the servers
>       chain certificates.  Because the inadequate/incorrect or
> defective
>       chain certs are still cached along with the correct server cert,
>       the verify now fails.
>
> However, since the servers certificate has not changed, the fast-track
> handshake will not be able to reocover automatically at this point.
> The client will either have to flush the CORRECT server cert from his
> cache or deliberately omit the fast-track extension from the handshake
> in order to recover.
>
>
> I strongly prefer to use reliable caching over hinting&assumptions
> for a fast-track TLS extension, with an high probability that an
> original full TLS handshake and a fast-tracked full handshake will
> result in the exact same behaviour.
>
> The use of hinting (using unrelated identifiers) instead of
> hashes derived from the on-the-wire data or the use of hashes
> over only a fraction of the data that is to be omitted can easily
> jeopardize the robustness of fast-track, so it should be avoided
> where possible.
>
>
> >
> > > If the motivation is to do caching of static information from
> > > the full SSL/TLS handshake, then one should focus on doing
> > > exactly that, and not do unnecessary other changes that will
> > > have subtle non-deterministic side effects.
> > >
> >
> > I don't believe we have any non-deterministic side effects.
>
> It is going to behave non-determinstic for the consumer of the
> technology, who is going to observe that after some change of
> his servers configuration, a fraction of the clients (from different
> vendors) are suddenly unable to connect while others don't seem
> to have problems, and reset/reboot of the clients fixes some
> and breaks others.
>
> Of course, it was a server configuration error, but diagnosing the
> cause is difficult if the clients show a seemingly random
> (aka non-deterministic) behaviour because the implementors didn't
> think about the consequences of their implementation stategies of
> a half-baked protocol that provides too many options.
>
>
> The purpose of standardizing a protocol is to provide an amount of
> certainty that most independent implementations are going to behave
> in a similar, robust and predictable fashion.
>
>
> So if we add the possibility for caching of static data from the
> original full TLS handshake, we should design it in a simple,
> generic and robust fashion so that it can be reused/extended
> for every piece of information in the full TLS hanshake, including
> any TLS extensions.  That is what good standards are about.  IMHO.
>
>
>
> >
> > > The existing fast-track document suggests a complex massive change
> > > of the entire handshake protocol and is therefore an all-or-nothing
> > > approach with a huge impact on every TLS implementation, it is
> > > not extensible to fast-track static information from other TLS
> > > extensions,
> > > and may, in fact be mutually exclusive with many other TLS
> extensions.
> > >
> >
> > Here we fully agree again.
> > I'm after something much simpler than the original fast-track.
>
>
> I really appreciate that you mention this.
>
> But it seems that I'm failing to convey my thoughts and concerns
> about the original and newly proposed design elements and features
> in a sufficiently comprehensible fashion.
>
>
> -Martin

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls