[Cryptography-dev] Towards a new TLS API

[Christopher Armstrong]

Quick note: I’ve created a PR for this proposed document which should make it a lot easier to roundtrip on reviews:

https://github.com/radix/cryptography/pull/1

It’s against my own fork of cryptography just so there’s no risk of merging it to cryptography master. Please comment there, and I’ll update the document as needed.


-- 
Christopher Armstrong
http://twitter.com/radix
http://wordeology.com/

On April 17, 2014 at 9:37:33 AM, Christopher Armstrong (radix at twistedmatrix.com) wrote:

If you’re eager, the link is at the bottom of this email.

I’m not sure I have it in me to describe the context of this project from the beginning, so I will start in the middle: a bunch of people have agreed that designing a new high-level TLS API for Python is a good idea. At PyCon, I sprinted on designing this API with several other people, and got input from many people in the PyCA community:

- Ying Li
- Paul Kehrer
- Jean-Paul Calderone
- Laurens Van Houtven
- Alex Gaynor
- David Reid
- Hynek Schlawack
- Corbin Simpson
- Aaron Gallagher

And probably some other people that I missed.

It’s still in a very rough state, and certainly needs much more serious thought (as well as some bikeshedding). I’ll describe some of the basic tenets predicating the design:

- It will be be easy to use!
- It will be opinionated about which math and TLS versions to use, and not allow downgrading to weaker security
- It will have no IO (deal only with in-memory buffers)
- It will be implemented with multiple backends, such as OpenSSL, SecureTransport, PyTLS, etc.
- It will have no global state
- It will not allow disabling of security features such as basic security checks, chain validation and hostname validation.
- It will support both client and server operation.
- We may expose less safe and more flexible lower-level APIs, but they will be clearly delineated from the API that people *should* be using.

In addition, we may implement the protocol from scratch (of course using existing cryptography backends) in the future. Some of us feel strongly that protocol code should not be implemented in C (or any memory-unsafe language). I believe that the PyCA community has enough expertise to eventually produce a secure TLS implementation.

Right now the design is a sphinx-style .rst file in a branch of cryptography in my github account (mostly so I can run “make html” on it and get pretty output). Unfortunately this means I’m the only one who can commit to it or accept PRs, so if anyone has a suggestion to improve this situation I’d be happy to oblige.

The direct link to the file is: https://raw.githubusercontent.com/radix/cryptography/tls-api/docs/tls-api.rst

The branch is: https://github.com/radix/cryptography/tree/tls-api

Any input would be greatly appreciated. Make sure to check the “TODO” and “Future work” sections of the document at the end in case you’re reading through it and immediately think of something to shout about :)

PRs are appreciated. Thanks!

-- 
Christopher Armstrong
http://twitter.com/radix
http://wordeology.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140418/102d2b72/attachment.html>