[Security-sig] Unified TLS API for Python

[Christian Heimes]

On 2017-01-12 09:45, Cory Benfield wrote:
> 
>> 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.

Do we need to support both? I thought that wrap_buffers() is the
preferred way for non-blocking TLS with an event loop. You are the
expert, do SChannel and SecureTransport work with non-blocking sockets
and WantRead/WantWrite?

> 
>> * 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.

Not really, just add it to the ToDo pile :)

>> 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?

I see some merit to either have a formal encoding hook on the context or
to limit server_hostname to punycode.

But before we decide, we need to study TLS implementations. OpenSSL
requires IDN A-labels. NSS' CERT_VerifyCertName() consumes IDNA, too.
InitializeSecurityContext() pszTargetName has no encoding specification.
I'm not familiar with SecureTransport.

Christian