On Sunday, January 22, 2017, Cory Benfield <c...@lukasa.co.uk> wrote:
> > On 22 Jan 2017, at 16:23, Wes Turner <wes.tur...@gmail.com > <javascript:_e(%7B%7D,'cvml','wes.tur...@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 >
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
