In comments on the previous post at the Identity Commons mailing list and comments at the session on deployment and usability of cryptographic credentials at the Internet Identity Workshop, people have questioned the advantages of running cryptographic protocols for issuing and presenting credentials inside TLS, and argued in favor of running them instead over HTTP. I believe running such protocols inside TLS removes several obstacles that have hindered the deployment of cryptographic credentials. So in this post I will try to answer those comments.
Here are three advantages of running issuance and presentation protocols inside TLS over running them outside TLS:
- TLS is ubiquitous. It is implemented by all browsers and all server middleware. If issuance and presentation protocols were implemented inside TLS, then users could use cryptographic credentials without having to install any applications or browser plugins, and developers of RPs and IdPs would not have to install and learn additional SDKs.
- The PRF facility of TLS is very useful for implementing cryptographic protocols. For example, in the U-Prove presentation protocol [1], when U-Prove is used for user authentication, the verifier must send a nonce to the prover; if the protocol were run inside TLS, that step could be avoided because the nonce could be independently generated by the prover and the verifier using the PRF. The PRF can also be used to provide common pseudo-random material for protocols based on the common reference string (CRS) model [2]. (Older cryptosystems such as U-Prove [1] and Idemix [3] rely on the Fiat-Shamir heuristic [4] to eliminate interactions, but more recent cryptosystems based on Groth-Sahai proofs [5] rely instead on the CRS model, which is more secure in some sense [6].)
- Inside TLS, an interactive cryptographic protocol can be run in a separate TLS layer, allowing the underlying TLS record layer to interleave protocol messages with application data (and possibly with messages of other protocol runs), thus mitigating the latency impact of protocol interactions.
And here are two advantages of running protocols either inside or directly on top of TLS, over running them on top of HTTP:
- Simplicity. Running a protocol over HTTP would require specifying how protocol messages are encapsulated inside HTTP requests and responses, i.e. it would require defining an HTTP-level protocol.
- Performance. Running a protocol over HTTP would add the overhead of sending HTTP headers, and, possibly, of establishing different TLS connections for different HTTP messages if TLS connections cannot be kept alive for some reason.
As always, comments are welcome.
References
| [1] |
Christian Paquin. U-Prove Cryptographic Specification V1.1 Draft
Revision 1, February 2011.
Downloadable from
http://www.microsoft.com/u-prove.
|
| [2] |
M. Blum, P. Feldman and S. Micali. Non-Interactive Zero-Knowledge
and Its Applications (Extended Abstract). In Proceedings of the
Twentieth Annual ACM Symposium on Theory of Computing (STOC 1988).
|
| [3] |
Jan Camenisch et al. Specification of the Identity Mixer
Cryptographic Library, Version 2.3.1. December 2010. Available at
http://www.zurich.ibm.com/~pbi/identityMixer_gettingStarted/ProtocolSpecification_2-3-2.pdf.
|
| [4] |
A. Fiat and A. Shamir. How to Prove Yourself: Practical Solutions
to Identification and Signature Problems. In Proceedings on Advances
in Cryptology (CRYPTO 86), Springer-Verlag.
|
| [5] |
J. Groth and A. Sahai. Efficient Non-Interactive Proof Systems
for Bilinear Groups. In Theory and Applications of Cryptographic
Techniques (EUROCRYPT 08), Springer-Verlag.
|
| [6] |
R. Canetti, O. Goldreich and S. Halevi. The Random Oracle
Methodology, Revisited. Journal of the ACM, vol. 51, no. 4, 2004.
|