Extending TLS to Meet Protocol Developers’ Requirements

1. Extending TLS to Meet Protocol Developers’ Requirements July 23, 2007 Tim Polk

2. Why Am I Up Here? • Protocol developers are increasingly drawn to TLS to provision security services • As they should, it is a great protocol • Strong KDF that incorporates TLS context into derived key material • We want to encourage this, because inventing new mechanisms is always risky • Review is time consuming • Fixing errors is even more time consuming!

3. Why Am I Up Here? • TLS provisioned security services focus on the TLS endpoints, not on the calling protocols • Applications do not have an opportunity to contribute context to the TLS KDF • Applications needing additional key material need to run another KDF

4. Building on Channel Bindings • Channel bindings are an important step in the right direction • Incorporating the TLS finished messages into the authentication process binds the TLS key material to the authenticated identity at the application level • But we really want a mechanism that allows the application or protocol to contribute to the KDF, strongly binding the upper level context to the key material

5. Opaque Objects • draft-rescorla-tls-opaque-prf-input-00.txt • “it is desirable to have some material with the following properties”: • It is contributed both by client and server. • It is arbitrary-length. • It is mixed into the eventual keying material. • It is structured and decodable by the receiving party.

6. What Does That Get You? • Client and server can each assert their view of the application context • Client and server can verify application context is consistent at the endpoints • Key material that protects this application is strongly bound to that context, in addition to the context of the TLS session. • (If the client is authenticated,) the identities of both parties are bound to the key material.

7. TLS Extractors Draft • Endpoints request creation of additional key material for use by the application • http://tools.ietf.org/html/draft-rescorla-tls-extractor-00 • This is a very powerful tool, but we can augment this and make it stronger • Cryptographers’ rule of thumb: applications should contribute something to the derivation of their own keys… • So opaque objects and extractors in concert would provide a much stronger solution

8. Providing a tool • From the context of TLS, this mechanism does not have any negative impacts • From the context of the application, this mechanism can • Bind the app context to the session key material • Amplify channel bindings • Bind the app context to any additional TLS-derived application layer key material • We can and should provide these tools to application developers • Lets avoid those tricky protocol design problems!

9. Proposal • TLS should adopt opaque objects as a wg document • TLS should adopt the extractors draft as a wg document