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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Feb 2015 19:05:18 +0100

It would be great to get some feedback on this topic...

On 01/26/2015 11:23 AM, Hannes Tschofenig wrote:
> 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
> 
> 
> 
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>