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

[Wes Turner]

On Sunday, January 22, 2017, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> On 22 Jan 2017, at 16:23, Wes Turner <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> 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 support every configuration
> option supported by 1 or more concrete implementations. The goal of this
> API is to support the common superset of the most-used APIs as needed for
> TLS. TOFU at the TLS level is not in that scope. DANE is not widely
> supported.
>

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


>
> So the only question there is session resumption, which I think may well
> be in-scope, but probably doesn’t need to go in the API in v1.
>
> ... IDK about *args (and integer namedtuple field indexing). I also (these
> days) tend to disagree with items-accessible-as-attributes dicts because
> dashes and consistency of API.
>
>
> Can you elaborate on this? I feel like I’m missing some context.
>

A frozen ordered dict would be preferable because:

- Inevitable eventuality of new/additional config parameters
- Consistency and readability of API access with [], .__getitem__(), .get()
- https://www.python.org/dev/peps/pep-0416/#rejection-notice ...
- https://docs.python.org/3.5/library/types.html#types.MappingProxyType

NamedTuple is preferable because:

- Immutability
- Speed
- RAM


>
> GCD, LCD.
>
> 3. ciphers__.get(SCHANNEL) OR ciphers
>
>
> Can you elaborate on this too?
>

If defined, backed specific configuration settings could take precedence
over platform-neutral defaults.


>
> Are these exceptions redundant? Could they derive from the new TLSError as
> well as the existing comparable exception?
>
>
> 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 module” because Python isn’t linked against OpenSSL
> seems like a pretty silly problem.
>

Good call.


>
> Cory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/security-sig/attachments/20170122/190c7761/attachment.html>