Subject: [Dtls-iot] TLS Cached Info: Input from this group

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Jan 2015 11:23:44 +0100

Hi all,

after making progress with the profile document I am trying to finalize
the work on the TLS cached info document (which is also referenced in
the profile document, btw).

Let me start with a short reminder about the purpose of the TLS cached
info document. The TLS cached info document introduces an extension that
allows the two parties to cache information from earlier exchanges with
the benefit of saving bandwidth in future exchanges. This works well
with information that is fairly static, such as information inside the
Certificate and the CertificateRequest message.

I have gotten good review comments last year from the TLS working group
and I have subsequently updated the draft again. Here is the most recent
version of the document:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-18.txt

Version -18 of the document allows omitting of the Certificate,
CertificateRequest, and the CertificateStatus message. As the example in
Appendix A shows this provides good optimization capabilities even for
the most basic case (where only the Certificate and the
CertificateRequest messages are omitted, ECC-keys are used, and no
intermediate CA certificates are exchanged, i.e., only end-entity
certificates are exchanged between the two parties).

The exchange works roughly as follows:

* Client computes a fingerprint of the Certificate message provided by
the server in an earlier exchange by computing a SHA-256 hash over the
entire Certificate message.

* Client conveys this fingerprint in the ClientHello message (within the
cached-info extension).

* Server looks at it and compares it with hash of the Certificate
message it would send. If they match, then the client has the most
recent version and the server omits sending that Certificate message to
the client.

Although OCSP isn't used in the constrained client-to-cloud interaction
it serves as a future extensibility option. Hence, it is included in the
document now as well.

Some review comments, however, raised the question whether transmission
of the client certificate could also be omitted (when it is cached by
the server). With the initial focus on the constrained client-to-server
use case in mind this was not really necessary since another extension,
the Certificate URL extension, allows the server to find the client
certificate via the indicated URL.

However, in the meanwhile we have expanded the document to also include
the peer-to-peer case and the use of Certificate URLs is not such a
great idea when you are dealing with constrained servers.

Hence, I wanted to introduce the ability to cache client certificates as
well. Here is how this could work.

* Client indicates support of server-side caching of certificates via a
new type in the cached-info extension.

It conveys the fingerprint of the Certificate message it would send. The
client may have more than one certificate but in the IoT case this is
rather rare. So, we are talking about a single fingerprint for the
entire Certificate message.

* Server knows whether client authentication is needed and, if so, looks
at the cache. It puts the fingerprint in the cached-info extension (to
indicate to the client what certificate to select). It also sends a
CertificateRequest message (unless that message is omitted due to the
use of another cached-info type).

* Client omits sending the Certificate message based on the message from
the server.

In an alternative design one could send one fingerprint for reach
certificate (rather than for the entire certificate message altogether).
This would be more flexible but leads to a more complex specification.

Any thoughts?

Ciao
Hannes