Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Feb 10, 2017 at 11:22 AM, Cory Benfield  wrote:

>
> On 10 Feb 2017, at 17:20, Wes Turner  wrote:
>
> I learned about oscrypto:
>
> - oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption,
> signing, verification and KDFs using the OS crypto libraries. Does not
> require a compiler, and relies on the OS for patching. Works on Windows, OS
> X and Linux/BSD."
>   - src: https://github.com/wbond/oscrypto
>   - pypi: https://pypi.python.org/pypi/oscrypto
>   - docs: https://github.com/wbond/oscrypto/blob/master/
> docs/readme.md#modern-cryptography
>
> Is oscrypto useful or relevant to this effort?
>
>
> You’ll note that the PEP credits Will Bond with review and oversight.
> oscrypto could absolutely be a backend that supports these APIs if Will
> wants it to be. =)
>

thanks!

docs:

- https://github.com/wbond/oscrypto/blob/master/docs/tls.md

src:

- https://github.com/wbond/oscrypto/blob/master/oscrypto/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_tls.py
-
https://github.com/wbond/oscrypto/blob/master/oscrypto/_linux_bsd/trust_list.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_openssl/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_osx/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_win/tls.py

constants / enums

- _PROTOCOL_MAP
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_cipher_suites.py
- https://github.com/tiran/tlsdb/blob/master/tlsdb.py > tlsdb.json
  - see: [ ] SChannel, [ ] Secure Transport tasks brainstormed above
- [ ] @IETF @W3C are there / should there be  URIs / URNs for these?


>
> Cory
>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Cory Benfield]

> On 10 Feb 2017, at 17:20, Wes Turner  wrote:
> 
> I learned about oscrypto:
> 
> - oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption, 
> signing, verification and KDFs using the OS crypto libraries. Does not 
> require a compiler, and relies on the OS for patching. Works on Windows, OS X 
> and Linux/BSD."
>   - src: https://github.com/wbond/oscrypto 
>   - pypi: https://pypi.python.org/pypi/oscrypto 
> 
>   - docs: 
> https://github.com/wbond/oscrypto/blob/master/docs/readme.md#modern-cryptography
>  
> 
> 
> Is oscrypto useful or relevant to this effort?

You’ll note that the PEP credits Will Bond with review and oversight. oscrypto 
could absolutely be a backend that supports these APIs if Will wants it to be. 
=)

Cory

___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Jan 27, 2017 at 9:30 AM, Wes Turner  wrote:

>
>
> On Fri, Jan 27, 2017 at 3:10 AM, Cory Benfield  wrote:
>
>>
>> On 26 Jan 2017, at 21:17, Donald Stufft  wrote:
>>
>>
>> On Jan 26, 2017, at 4:18 AM, Cory Benfield  wrote:
>>
>> For this reason I’m inclined to lean towards the more verbose approach of
>> just writing down what all of the cipher suites are in an enum. That way,
>> it gets much easier to validate what’s going on. There’s still no
>> requirement to actually support them all: an implementation is allowed to
>> quietly ignore any cipher suites it doesn’t support. But that can no longer
>> happen due to typos, because typos now cause AttributeErrors at runtime in
>> a way that is very obvious and clear.
>>
>>
>>
>> I’d say additionally that given the verbose approach a third party
>> library could provide this OpenSSL like API and be responsible for
>> “compiling” it down to the actual list of ciphers for input into the
>> verbose API. If one of those got popular and seemed stable enough to add
>> it, we could always add it in later as a higher level API for cipher
>> selection without the backends needing to change anything since the output
>> of such a function would still be a list of all of the desired ciphers
>> which would be the input to the backends.
>>
>>
>> Yup, strongly agreed.
>>
>
> https://github.com/tiran/tlsdb/blob/master/tlsdb.py
>
> - [ ] ENH: tlsdb.py: add parsers/datasources for {SChannel,
> SecureTransport}
>
>   - [x] openssl-master
>   - [x] openssl-1.02
>   - [x] gnutls-master
>   - [x] nss-tip
>   - [x] mod_nss-master
>   - [x] **iana**
>   - [x] mozilla-server-side
>   - [ ] SChannel
>   - [ ] SecureTransport
>
> - [ ] ENH: tlsdb.py: add OpenSSL-workalike lookup method
> - [ ] BLD: tls.config.__: generate Enums?
>

To be clear, I don't have the resources necessary to complete these tasks.
Would these tasks be necessary/helpful?

Reading:
https://github.com/mathiasertl/django-ca/blob/master/requirements.txt

I learned about oscrypto:

- oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption,
signing, verification and KDFs using the OS crypto libraries. Does not
require a compiler, and relies on the OS for patching. Works on Windows, OS
X and Linux/BSD."
  - src: https://github.com/wbond/oscrypto
  - pypi: https://pypi.python.org/pypi/oscrypto
  - docs:
https://github.com/wbond/oscrypto/blob/master/docs/readme.md#modern-cryptography

Is oscrypto useful or relevant to this effort?


>
>>
>> Cory
>>
>> ___
>> Security-SIG mailing list
>> Security-SIG@python.org
>> https://mail.python.org/mailman/listinfo/security-sig
>>
>>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Jan 27, 2017 at 3:10 AM, Cory Benfield  wrote:

>
> On 26 Jan 2017, at 21:17, Donald Stufft  wrote:
>
>
> On Jan 26, 2017, at 4:18 AM, Cory Benfield  wrote:
>
> For this reason I’m inclined to lean towards the more verbose approach of
> just writing down what all of the cipher suites are in an enum. That way,
> it gets much easier to validate what’s going on. There’s still no
> requirement to actually support them all: an implementation is allowed to
> quietly ignore any cipher suites it doesn’t support. But that can no longer
> happen due to typos, because typos now cause AttributeErrors at runtime in
> a way that is very obvious and clear.
>
>
>
> I’d say additionally that given the verbose approach a third party library
> could provide this OpenSSL like API and be responsible for “compiling” it
> down to the actual list of ciphers for input into the verbose API. If one
> of those got popular and seemed stable enough to add it, we could always
> add it in later as a higher level API for cipher selection without the
> backends needing to change anything since the output of such a function
> would still be a list of all of the desired ciphers which would be the
> input to the backends.
>
>
> Yup, strongly agreed.
>

https://github.com/tiran/tlsdb/blob/master/tlsdb.py

- [ ] ENH: tlsdb.py: add parsers/datasources for {SChannel, SecureTransport}

  - [x] openssl-master
  - [x] openssl-1.02
  - [x] gnutls-master
  - [x] nss-tip
  - [x] mod_nss-master
  - [x] **iana**
  - [x] mozilla-server-side
  - [ ] SChannel
  - [ ] SecureTransport

- [ ] ENH: tlsdb.py: add OpenSSL-workalike lookup method
- [ ] BLD: tls.config.__: generate Enums?


>
> Cory
>
> ___
> Security-SIG mailing list
> Security-SIG@python.org
> https://mail.python.org/mailman/listinfo/security-sig
>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Cory Benfield]

> On 26 Jan 2017, at 21:17, Donald Stufft  wrote:
> 
> 
>> On Jan 26, 2017, at 4:18 AM, Cory Benfield > > wrote:
>> 
>> For this reason I’m inclined to lean towards the more verbose approach of 
>> just writing down what all of the cipher suites are in an enum. That way, it 
>> gets much easier to validate what’s going on. There’s still no requirement 
>> to actually support them all: an implementation is allowed to quietly ignore 
>> any cipher suites it doesn’t support. But that can no longer happen due to 
>> typos, because typos now cause AttributeErrors at runtime in a way that is 
>> very obvious and clear.
> 
> 
> I’d say additionally that given the verbose approach a third party library 
> could provide this OpenSSL like API and be responsible for “compiling” it 
> down to the actual list of ciphers for input into the verbose API. If one of 
> those got popular and seemed stable enough to add it, we could always add it 
> in later as a higher level API for cipher selection without the backends 
> needing to change anything since the output of such a function would still be 
> a list of all of the desired ciphers which would be the input to the backends.

Yup, strongly agreed.

Cory___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Donald Stufft]

> On Jan 26, 2017, at 4:18 AM, Cory Benfield  wrote:
> 
> For this reason I’m inclined to lean towards the more verbose approach of 
> just writing down what all of the cipher suites are in an enum. That way, it 
> gets much easier to validate what’s going on. There’s still no requirement to 
> actually support them all: an implementation is allowed to quietly ignore any 
> cipher suites it doesn’t support. But that can no longer happen due to typos, 
> because typos now cause AttributeErrors at runtime in a way that is very 
> obvious and clear.


I’d say additionally that given the verbose approach a third party library 
could provide this OpenSSL like API and be responsible for “compiling” it down 
to the actual list of ciphers for input into the verbose API. If one of those 
got popular and seemed stable enough to add it, we could always add it in later 
as a higher level API for cipher selection without the backends needing to 
change anything since the output of such a function would still be a list of 
all of the desired ciphers which would be the input to the backends.

—
Donald Stufft



___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig