[Security-sig] Unified TLS API for Python

[Cory Benfield]

> On 11 Jan 2017, at 21:23, Christian Heimes <christian at cheimes.de> wrote:
> 
> * Do we need to define blocking / non blocking state of the socket?

I think we want to support both. I’m not sure we need to expose it in the API: the implementation can check by asking the socket directly if it cares.

> * What about STARTTLS support, do we need to define how to deal with
> data that has been transmitted before?

Hrm. I’m inclined to want to hold off on that to begin with, though you’re welcome to propose an API extension if you have a concrete idea of how to do it.

> Maybe we can get away without any extension to the API. SRV-ID uses
> underline to signal a service identifier, e.g. _http.www.example.org. In
> the future an application could pass down a service identifier as
> server_hostname argument and let the TLS library deal with it like this:
> 
> if server_hostname.startswith('_'):
>    srvid = server_hostname
>    service, hostname = server_hostname.split('.', 1)
>    service = service[1:]
> else:
>   service = srvid = None
>   hostname = server_hostname

Yup. That could well work. Another good argument for “wait and see” ;).

> OpenSSL's hostname verification code accept IDN A-labels. SubjecAltNames
> are encoded as IA5String containing IDN A-labels, too. For most
> flexibility the wrap functions should accept server_hostnames as both
> U-label and A-label. If you add an encode_hostname() method to the
> context, than users can easily override the method to switch between
> IDNA 2003, 2008 or perform custom checks to prevent homoglyphic
> confusion attacks.

My question here is: do we need to pursue this in the abstract API? Or can it be left up to concrete implementations to worry about?

Cory