Re: Handling better supported channel binding types for SSL implementations

On Mon, Jan 22, 2018 at 04:52:11PM +0100, Daniel Gustafsson wrote:
> Not really, but IIUC a bug in this code could lead to channel binding
> not being used for a connection even if the user wanted it (and may
> miss that ixt didn’t happen due to not looking at logs etc)?

Possible, if an implementation decides to send a NIL list as return
result of this API when it should not.

> Considering the limited set of values (currently) it should be quite
> simple to check for offending entries, if there is indeed a risk of
> “silently” not using channel binding.

I think I understand the point you are coming at, but a problem is that
the channel binding type the client wants to use is known by the server
in SCRAM authentication only after reading the client-first message,
which happens of course after the client decided to choose if channel
binding is used or not. Now the server needs to emit first a list of
supported SASL mechanisms which are consistent with what the SSL
implementation can do when the mechanism is negotiated. Another, third
approach that I can think of is to have this additional API in betls
emit a list of mechanisms, but I am not sure that this is worth the
complication as at the end what you want to know is if at least one
channel binding type is supported or not.

We could as well live with the existing set of betls APIs, just that the
implementation of secure transport for MacOS will need a hack in auth.c
to stop the -PLUS mechanisms to be sent. Putting this load into each
be-secure-*.c file is cleaner in my opinion.
--
Michael