On 14 January 2017 at 01:58, Cory Benfield <c...@lukasa.co.uk> wrote:
>> On 13 Jan 2017, at 15:45, Nick Coghlan <ncogh...@gmail.com> 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 specific TLS implementation
>>  TLSSocket: ABC to combine a context with a network socket
>>  TLSBuffer: ABC to combine a context with a pair of data buffers
>> And then TLSPolicy would be a potential future implementation
>> independent addition that could be used to constrain acceptable TLS
>> configurations.
> If we were going this way, I’d want to add one extra caveat: I think I’d want 
> the Contexts to become immutable.
> The logic for the SNI callback would then become: you are called with the 
> Context that created the socket/buffer, and you return a Configuration object 
> that contains any changes you want to make, and the Context applies them if 
> it can (or errors out if it cannot). A new Context is created. This relegates 
> Context to the role of “socket/buffer factory”. The advantage of this is that 
> we have vastly reduced the moving parts: a Context can ensure that, once 
> initiated, the Policy that belongs to it will not change under its feet. It 
> also allows the Context to refuse to change settings that a given concrete 
> implementation cannot change in the SNI callback.

Having immutable-by-default config with explicitly managed state
changes in particular well-defined scenarios sounds like a big win to

> This would almost certainly make Context implementation easier, as there is 
> no longer a requirement to monitor your configuration and support 
> live-updates.

It also drastically reduces the test matrix required, as eliminating
any potential dependence on the order in which settings are applied,
means you only need to test interesting *combinations* of settings,
and not different configuration *sequences*.


Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
Security-SIG mailing list

Reply via email to