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

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 co

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

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

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

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 a

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

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

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

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

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

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

Re: [Security-sig] Unified TLS API for Python: Round 2

On 26 January 2017 at 16:22, Cory Benfield wrote: > > On 26 Jan 2017, at 14:23, Nick Coghlan wrote: > > In an ideal world, that could be handled just by having the ssl module > import the new tls module and alias the exceptions accordingly. > Talking to Christian about it, things might be a littl

Re: [Security-sig] Unified TLS API for Python: Round 2

On 2017-01-26 15:23, Nick Coghlan wrote: > On 26 January 2017 at 10:50, Cory Benfield wrote: >> >>> On 26 Jan 2017, at 07:49, Nick Coghlan wrote: >>> >>> Option 4: tls.TLSError, tls.WantReadError, tls.WantWriteError are >>> defined as inheriting from ssl.SSLError, ssl.SSLWantReadError, and >>> ss

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 26 Jan 2017, at 14:23, Nick Coghlan wrote: > > In an ideal world, that could be handled just by having the ssl module > import the new tls module and alias the exceptions accordingly. > Talking to Christian about it, things might be a little messier in > practice due to the way the _ssl/ssl

Re: [Security-sig] Unified TLS API for Python: Round 2

On 26 January 2017 at 10:50, Cory Benfield wrote: > >> On 26 Jan 2017, at 07:49, Nick Coghlan wrote: >> >> Option 4: tls.TLSError, tls.WantReadError, tls.WantWriteError are >> defined as inheriting from ssl.SSLError, ssl.SSLWantReadError, and >> ssl.SSLWantWriteError *if* the latter are defined >

Re: [Security-sig] Unified TLS API for Python: Round 2

On Thu, Jan 26, 2017 at 1:50 AM, Cory Benfield wrote: > >> On 26 Jan 2017, at 07:49, Nick Coghlan wrote: >> >> Option 4: tls.TLSError, tls.WantReadError, tls.WantWriteError are >> defined as inheriting from ssl.SSLError, ssl.SSLWantReadError, and >> ssl.SSLWantWriteError *if* the latter are defin

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 26 Jan 2017, at 07:49, Nick Coghlan wrote: > > Option 4: tls.TLSError, tls.WantReadError, tls.WantWriteError are > defined as inheriting from ssl.SSLError, ssl.SSLWantReadError, and > ssl.SSLWantWriteError *if* the latter are defined > > Option 5: as with Option 4, but the "ssl" module is

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

> On 26 Jan 2017, at 01:33, Steve Dower wrote: > > Looks good to me, but I wonder why we need to define all the algorithms in > the PEP (by reference)? Could they also use a similar model to certificates, > where the implementation provides a constructor that takes a string (in a > format def

Re: [Security-sig] Unified TLS API for Python: Round 2

On 2017-01-26 08:49, Nick Coghlan wrote: [...] > Option 5: as with Option 4, but the "ssl" module is also changed such > that it *always* defines at least ssl.SSLError, ssl.SSLWantReadError, > and ssl.SSLWantWriteError (and perhaps some of the other APIs that can > be emulated atop the new tls abst

Re: [Security-sig] Unified TLS API for Python: Round 2

On 22 January 2017 at 17:34, Cory Benfield wrote: > This module should be entirely unattached to the ssl module, IMO. This is > most important because the ssl module doesn’t exist when Python is not > linked against OpenSSL: being unable to define the exceptions in a “you > don’t need OpenSSL modu

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

Originally from Steve Dower (with my apologies): --- Looks good to me, but I wonder why we need to define all the algorithms in the PEP (by reference)? Could they also use a similar model to certificates, where the implementation provides a constructo

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 24 Jan 2017, at 01:59, Nathaniel Smith wrote: > > I've just been used to using bytearrays everywhere for things like > socket receive buffers. I find them much more convenient to work with > than BytesIO b/c you can do things like pass them directly to > send/recv/parsing functions, and the

Re: [Security-sig] Unified TLS API for Python: Round 2

On 01/23/2017 05:59 PM, Nathaniel Smith wrote: On Sun, Jan 22, 2017 at 4:01 AM, Cory Benfield wrote: On 20 Jan 2017, at 23:00, Nathaniel Smith wrote: - given that for next protocol negotiation we have to accept arbitrary bytestrings and the primary value of the NextProtocol class is to protec

Re: [Security-sig] Unified TLS API for Python: Round 2

On Sun, Jan 22, 2017 at 4:01 AM, Cory Benfield wrote: > >> On 20 Jan 2017, at 23:00, Nathaniel Smith wrote: >> >> - given that for next protocol negotiation we have to accept arbitrary >> bytestrings and the primary value of the NextProtocol class is to >> protect against typos, I wonder if it wo

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 22 Jan 2017, at 18:11, Ethan Furman wrote: > > As long as SChannel does not allow / ignores restrictions can we not issue > a warning (probably with the logging module) saying such? That’s a matter for the concrete implementation. If the Python standard library grows an SChannel implement

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 22 Jan 2017, at 18:55, Wes Turner wrote: > > So then there are two ways to preserve the centralized configuration (with a > configuration object): > > 1. extra_config, a TLSConfiguration parameter pointing to e.g. a (mutable) > List or an OrderedDict of additional parameters > 2. create

Re: [Security-sig] Unified TLS API for Python: Round 2

On Sunday, January 22, 2017, Cory Benfield wrote: > > On 22 Jan 2017, at 17:01, Wes Turner > wrote: > > - OpenSSL 1.1.0 supports DANE > - GnuTLS supports DANE > - AFAIU, neither SChannel nor Secure Transport yet support DANE > > So, in order to support e.g. DANE, where would the additional > bac

Re: [Security-sig] Unified TLS API for Python: Round 2

On 01/22/2017 04:18 AM, Cory Benfield wrote: On 21 Jan 2017, at 13:07, Nick Coghlan wrote: Proposed Interface ^^ The proposed interface for the new module is influenced by the combined set of limitations of the above implementations. Specifically, as every implementation *exce

Re: [Security-sig] Unified TLS API for Python: Round 2

On 2017-01-22 18:01, Wes Turner wrote: > > > On Sunday, January 22, 2017, Cory Benfield > wrote: > > >> On 22 Jan 2017, at 16:23, Wes Turner > > wrote: >> >> Looking at the GnuTLS manual [1], I see a number of potential >> additional configuration para

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 22 Jan 2017, at 17:01, Wes Turner wrote: > > - OpenSSL 1.1.0 supports DANE > - GnuTLS supports DANE > - AFAIU, neither SChannel nor Secure Transport yet support DANE > > So, in order to support e.g. DANE, where would the additional > backend-specific configuration occur? This would be u

Re: [Security-sig] Unified TLS API for Python: Round 2

On Sunday, January 22, 2017, Cory Benfield wrote: > > On 22 Jan 2017, at 16:23, Wes Turner > wrote: > > Looking at the GnuTLS manual [1], I see a number of potential additional > configuration parameters: > > - session resumption (bool, expiration time) > - Trust on first use (SSH-like) > - DANE

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 22 Jan 2017, at 16:23, Wes Turner wrote: > > Looking at the GnuTLS manual [1], I see a number of potential additional > configuration parameters: > > - session resumption (bool, expiration time) > - Trust on first use (SSH-like) > - DANE [2] Remember that the goal of this API is not to s

Re: [Security-sig] Unified TLS API for Python: Round 2

On Sunday, January 22, 2017, Cory Benfield wrote: > > > On 21 Jan 2017, at 13:07, Nick Coghlan > wrote: > > > > > > I agree with Wes that the backwards compatibility guarantees around > > adding new configuration fields should be clarified. > > > > I think it will suffice to say that "new fields

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 21 Jan 2017, at 13:07, Nick Coghlan wrote: > > > I agree with Wes that the backwards compatibility guarantees around > adding new configuration fields should be clarified. > > I think it will suffice to say that "new fields are only appended, > existing fields are never removed, renamed,

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 20 Jan 2017, at 23:00, Nathaniel Smith wrote: > > - given that for next protocol negotiation we have to accept arbitrary > bytestrings and the primary value of the NextProtocol class is to > protect against typos, I wonder if it would simplify things slightly > to make the attributes of thi

Re: [Security-sig] Unified TLS API for Python: Round 2

On 20 January 2017 at 04:29, Cory Benfield wrote: > Please let me know what you think. > > The version of the draft PEP, from commit ce74bc60, is reproduced below. Thanks Cory, this is looking really good. I don't have anything to add on the security design front, but do have a few comments/quest

Re: [Security-sig] Unified TLS API for Python: Round 2

[resending from a real computer since the security-sig auto(?)-moderator didn't like me top-posting from my phone :-)] On Thu, Jan 19, 2017 at 9:29 AM, Cory Benfield wrote: > All, > > Thanks for your feedback on the draft PEP I proposed last week! There was a > lot of really enthusiastic and val

Re: [Security-sig] Unified TLS API for Python: Round 2

Got it. Thanks again! On Friday, January 20, 2017, Cory Benfield wrote: > > On 20 Jan 2017, at 16:30, Wes Turner > wrote: > > I think there's somewhat high likelihood that additional parameters will > be relevant to TLS Configuration in the future. > > > I think that we can upgrade “somewhat hi

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 20 Jan 2017, at 16:30, Wes Turner wrote: > > I think there's somewhat high likelihood that additional parameters will be > relevant to TLS Configuration in the future. I think that we can upgrade “somewhat high likelihood” to “mathematical certainty”. This again fits with my overall posi

Re: [Security-sig] Unified TLS API for Python: Round 2

On Friday, January 20, 2017, Cory Benfield wrote: > > On 20 Jan 2017, at 04:38, Wes Turner > wrote: > > Thanks! TLSConfiguration looks much easier to review; and should make > other implementations easier. > > I read a great (illustrated) intro to TLS1.3 the other day: > > https://temen.io/resou

Re: [Security-sig] Unified TLS API for Python: Round 2

> On 20 Jan 2017, at 04:38, Wes Turner wrote: > > Thanks! TLSConfiguration looks much easier to review; and should make other > implementations easier. > > I read a great (illustrated) intro to TLS1.3 the other day: > > https://temen.io/resources/tls-gets-an-upgrade:-welcome-1.3/ >

Re: [Security-sig] Unified TLS API for Python: Round 2

On Thursday, January 19, 2017, Cory Benfield wrote: > > Configuration > ~ > > The ``TLSConfiguration`` concrete class defines an object that can hold and > manage TLS configuration. The goals of this class are as follows: > > 1. To provide a method of specifying TLS configuration that

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

On 2017-01-13 17:37, Cory Benfield wrote: > >> On 13 Jan 2017, at 16:35, Christian Heimes wrote: >> >> How would this work for OpenSSL? In OpenSSL the SNI callback replaces >> the SSL_CTX of a SSL socket pointer with another SSL_CTX. The new >> SSL_CTX takes care of cipher negotiation, certs and

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

> On 13 Jan 2017, at 16:35, Christian Heimes wrote: > > How would this work for OpenSSL? In OpenSSL the SNI callback replaces > the SSL_CTX of a SSL socket pointer with another SSL_CTX. The new > SSL_CTX takes care of cipher negotiation, certs and other handshake > details. The SSL_CTX should be

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

On 14 January 2017 at 02:20, Christian Heimes wrote: > There aren't many settings that are truly implementation independent. > Even ciphers depend on the implementation and version of the TLS > provider. Some implementations do support more or less ciphers. Some > allow ordering or black listing o

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

On 2017-01-13 16:58, Cory Benfield wrote: > >> On 13 Jan 2017, at 15:45, Nick Coghlan wrote: >> >> So the essential stack would look like: >> >> TLSConfig[uration?]: implementation independent, settings only >> TLSClientContext: ABC to combine settings with a specific TLS implementation >> TLS

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

On 2017-01-13 16:45, Nick Coghlan wrote: > On 13 January 2017 at 23:56, Cory Benfield wrote: >> While we’re here, I should point out that this does not replace the abstract >> contexts entirely, because we still need the wrap_* methods. These would now >> just be fed a Configuration object (I’m mo

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

On 14 January 2017 at 01:58, Cory Benfield wrote: > >> On 13 Jan 2017, at 15:45, Nick Coghlan wrote: >> >> So the essential stack would look like: >> >> TLSConfig[uration?]: implementation independent, settings only >> TLSClientContext: ABC to combine settings with a specific TLS implementation

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

> On 13 Jan 2017, at 15:45, Nick Coghlan wrote: > > So the essential stack would look like: > > TLSConfig[uration?]: implementation independent, settings only > TLSClientContext: ABC to combine settings with a specific TLS implementation > TLSServerContext: ABC to combine settings with a spe

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

On 13 January 2017 at 23:56, Cory Benfield wrote: > While we’re here, I should point out that this does not replace the abstract > contexts entirely, because we still need the wrap_* methods. These would now > just be fed a Configuration object (I’m more comfortable with the name > Configuration t

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

> On 13 Jan 2017, at 13:09, Nathaniel Smith wrote: > > I guess another possible point in the design space would be to split the > difference: instead of an abstract context class or a dict, define a concrete > context class that acts as a simple transparent container for these settings, > eff

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

On Jan 13, 2017 3:17 AM, "Nick Coghlan" wrote: On 13 January 2017 at 19:33, Nathaniel Smith wrote: > On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield wrote: > I get what you're saying about a typed API -- basically in the current > setup, the way _BaseContext is written as a bunch of Python metho

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

On 2017-01-13 12:02, Nick Coghlan wrote: > On 13 January 2017 at 18:27, Cory Benfield wrote: >> >>> On 13 Jan 2017, at 08:04, Nick Coghlan wrote: >>> >>> I'd still be inclined to keep that concern separate from those of the >>> core TLS context (which is about applying a given security context to

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

On 13 January 2017 at 19:33, Nathaniel Smith wrote: > On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield wrote: > I get what you're saying about a typed API -- basically in the current > setup, the way _BaseContext is written as a bunch of Python methods > means that the interpreter will automaticall

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

On 13 January 2017 at 18:27, Cory Benfield wrote: > >> On 13 Jan 2017, at 08:04, Nick Coghlan wrote: >> >> I'd still be inclined to keep that concern separate from those of the >> core TLS context (which is about applying a given security context to >> sockets and buffers) though, and instead hav

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

On Fri, Jan 13, 2017 at 1:09 AM, Cory Benfield wrote: > > On 13 Jan 2017, at 09:07, Nathaniel Smith wrote: > > I was imagining something along the lines of > > ClientContext({...}).wrap_socket(...) > > where ClientContext.__init__ would do the validation. Or there are > various other ways to slot

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

On Fri, Jan 13, 2017 at 12:55 AM, Cory Benfield wrote: > >> On 13 Jan 2017, at 08:48, Nathaniel Smith wrote: >> >> The potentially-useful idea I took from this subthread was: right now >> we have an interface with a bunch of getter/setter methods. Would it >> make sense to *replace* that with som

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

> On 13 Jan 2017, at 09:07, Nathaniel Smith wrote: > > I was imagining something along the lines of > > ClientContext({...}).wrap_socket(...) > > where ClientContext.__init__ would do the validation. Or there are > various other ways to slot the pieces together, but in general > validation doe

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

> On 13 Jan 2017, at 08:48, Nathaniel Smith wrote: > > The potentially-useful idea I took from this subthread was: right now > we have an interface with a bunch of getter/setter methods. Would it > make sense to *replace* that with something more declarative, like a > single method that takes co

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

On Fri, Jan 13, 2017 at 12:27 AM, Cory Benfield wrote: > >> On 13 Jan 2017, at 08:04, Nick Coghlan wrote: >> >> I'd still be inclined to keep that concern separate from those of the >> core TLS context (which is about applying a given security context to >> sockets and buffers) though, and instea

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

> On 13 Jan 2017, at 08:04, Nick Coghlan wrote: > > I'd still be inclined to keep that concern separate from those of the > core TLS context (which is about applying a given security context to > sockets and buffers) though, and instead have the specific concept of > a TLSPolicy that can be used

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

On 13 January 2017 at 16:32, Wes Turner wrote: > Another reason I believe there should be a configuration object with a > .validate() method for centralized SSL configuration: > > - Having one .validate() method (with as many necessary subvalidators) > provides a hook for security-conscious organi

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

On Fri, Jan 13, 2017 at 12:09 AM, Nick Coghlan wrote: > On 13 January 2017 at 07:05, Wes Turner wrote: > > +1 for start simple and iterate; > > but expecting a config object is not easy to add later. > > Yes, it is - all that is necessary is to add a "make_ssl_context" > helper function that tra

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

On 13 January 2017 at 07:05, Wes Turner wrote: > +1 for start simple and iterate; > but expecting a config object is not easy to add later. Yes, it is - all that is necessary is to add a "make_ssl_context" helper function that translates from the declarative configuration format (however defined)

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

gt; Reply: Donald Stufft > Date: January 12, 2017 at 13:46:26 > To: Cory Benfield > Cc: security-sig@python.org , Christian > Heimes > Subject: Re: [Security-sig] Unified TLS API for Python > > > > > > On Jan 12, 2017, at 2:39 PM, Cory Benfield wrote: > > >

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

-Original Message- From: Donald Stufft Reply: Donald Stufft Date: January 12, 2017 at 13:46:26 To: Cory Benfield Cc: security-sig@python.org , Christian Heimes Subject:  Re: [Security-sig] Unified TLS API for Python > > > On Jan 12, 2017, at 2:39 PM, Cory Benfield wrote: &g

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

On Thursday, January 12, 2017, Christian Heimes wrote: > On 2017-01-12 18:07, Wes Turner wrote: > > > > > > On Thursday, January 12, 2017, Cory Benfield > > > wrote: > > > > > >> On 11 Jan 2017, at 21:44, Wes Turner > >> ');>> > wrote: > >> > >> This may

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

> On Jan 12, 2017, at 2:39 PM, Cory Benfield wrote: > > I'm not even sure about the specific API we're using for SNI: I might just > want to restrict it to emitting new certificates. I am pro restricting the API, can always relax restrictions later. — Donald Stufft ___

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

I agree with Christian and Donald (unsurprisingly). The key thing to note is that we can extend this API as time goes on and we get a better understanding of what's happening. And any application that is doing hot TLS config changes is likely not going to be agnostic to the concrete TLS impleme

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

> On Jan 12, 2017, at 2:13 PM, Christian Heimes wrote: > > Let's keep it simple. We can always define an enhanced superset of the > TLS ABC later. But we cannot remove features or change API in an > incompatible way later. I think the server side stuff makes sense, it’ll be important for proje

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

On 2017-01-12 18:16, Wes Turner wrote: > - Do these need a __cmp__()? > - Are there concrete-implementation-specific const constants for each > library? Why would you need to compare these? The TLS API will merely provide generic constants. Every implementation of the unified TLS API needs to map

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

On 2017-01-12 18:07, Wes Turner wrote: > > > On Thursday, January 12, 2017, Cory Benfield > wrote: > > >> On 11 Jan 2017, at 21:44, Wes Turner > > wrote: >> >> This may be a bit of a different use case (and possibly worth >> having in the first version

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

On Thursday, January 12, 2017, Cory Benfield wrote: > > On 11 Jan 2017, at 21:44, Wes Turner > wrote: > > This may be a bit of a different use case (and possibly worth having in > the first version of a new tls module): > > "Hitless TLS Certificate Rotation in Go" > https://diogomonica.com/2017/

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

On Thursday, January 12, 2017, Christian Heimes wrote: > On 2017-01-12 15:09, Nick Coghlan wrote: > > On 12 January 2017 at 22:44, Cory Benfield > wrote: > >> We can do that. > >> > >> I should note that MINIMUM_SUPPORTED and MAXIMUM_SUPPORTED are not > intended > >> to be equal to SSLv2 and TLS

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

On 2017-01-12 15:09, Nick Coghlan wrote: > On 12 January 2017 at 22:44, Cory Benfield wrote: >> We can do that. >> >> I should note that MINIMUM_SUPPORTED and MAXIMUM_SUPPORTED are not intended >> to be equal to SSLv2 and TLSv1_3, or indeed to any other value in this enum. >> They are future-proof

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

On 12 January 2017 at 22:44, Cory Benfield wrote: > We can do that. > > I should note that MINIMUM_SUPPORTED and MAXIMUM_SUPPORTED are not intended > to be equal to SSLv2 and TLSv1_3, or indeed to any other value in this enum. > They are future-proofing tools that allow users to say “I want TLSv1

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

> On 12 Jan 2017, at 12:37, Nick Coghlan wrote: > > For "Enums" where I genuinely don't care about the values, I'll > typically set them to the string that matches the attribute name: > > ``` > class TLSVersion(Enum): >SSLv2 = "SSLv2" >MINIMUM_SUPPORTED = SSLv2 >SSLv3 =

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

On 12 January 2017 at 18:49, Cory Benfield wrote: > >> On 12 Jan 2017, at 05:36, Wes Turner wrote: >> >> So, with >> >> ``` >> class TLSVersion(Enum): >> MINIMUM_SUPPORTED >> SSLv2 >> SSLv3 >> TLSv1 >> TLSv1_1 >> TLSv1_2 >> TLSv1_3 >>

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

> On 12 Jan 2017, at 10:14, Christian Heimes wrote: > > On 2017-01-12 09:45, Cory Benfield wrote: >> >>> On 11 Jan 2017, at 21:23, Christian Heimes 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 t

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

On 2017-01-12 09:45, Cory Benfield wrote: > >> On 11 Jan 2017, at 21:23, Christian Heimes 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

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

> On 12 Jan 2017, at 05:36, Wes Turner wrote: > > So, with > > ``` > class TLSVersion(Enum): > MINIMUM_SUPPORTED > SSLv2 > SSLv3 > TLSv1 > TLSv1_1 > TLSv1_2 > TLSv1_3 > MAXIMUM_SUPPORTED > ``` > > What are the (signed?) integer va

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

> On 11 Jan 2017, at 21:44, Wes Turner wrote: > > This may be a bit of a different use case (and possibly worth having in the > first version of a new tls module): > > "Hitless TLS Certificate Rotation in Go" > https://diogomonica.com/2017/01/11/hitless-tls-certificate-rotation-in-go/ >

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

> On 11 Jan 2017, at 21:23, Christian Heimes 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 STA

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

On Wednesday, January 11, 2017, Christian Heimes wrote: On 2017-01-11 20:01, Cory Benfield wrote: > > > The ``Context`` abstract base class defines an object that allows > configuration > > of TLS. It can be thought of as a factory for ``TLSWrappedSocket`` and > > ``TLSWrappedBuffer`` objects. >

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

On 2017-01-11 21:20, Cory Benfield wrote: > >> On 11 Jan 2017, at 19:49, Christian Heimes wrote: >> >> AFAIK PyOpenSSL doesn't support this mode. How do we deal with >> unconnected sockets, UDP/DTLS and other transports? Are sockets limited >> to AF_INET / AF_INET6 and SOCK_STREAM? > > To begin

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

On 2017-01-11 21:16, Cory Benfield wrote: > >> On 11 Jan 2017, at 19:36, Christian Heimes > > wrote: >> >> Since this function is only required for TLS servers and TLS client cert >> authentication, I'd rather mark this function provisional or not define >> it in the f

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

> On 11 Jan 2017, at 19:49, Christian Heimes wrote: > > AFAIK PyOpenSSL doesn't support this mode. How do we deal with > unconnected sockets, UDP/DTLS and other transports? Are sockets limited > to AF_INET / AF_INET6 and SOCK_STREAM? To begin with, I think we need to restrict ourselves to SOCK_

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

> On 11 Jan 2017, at 19:36, Christian Heimes wrote: > > Since this function is only required for TLS servers and TLS client cert > authentication, I'd rather mark this function provisional or not define > it in the first version. Is that the best option? Will there be any TLS implementation tha

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

On 2017-01-11 20:01, Cory Benfield wrote: > Socket > ~~ > > The socket-wrapper ABC will be defined by the ``TLSWrappedSocket`` ABC, which > has the following definition:: > > class TLSWrappedSocket(metaclass=ABCMeta): > # The various socket methods all must be implemented. Their

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

On 2017-01-11 20:01, Cory Benfield wrote: > The ``Context`` abstract base class defines an object that allows > configuration > of TLS. It can be thought of as a factory for ``TLSWrappedSocket`` and > ``TLSWrappedBuffer`` objects. > > The ``Context`` abstract base class has the following class d