Re: Handling better supported channel binding types for SSL implementations

> On 23 Jan 2018, at 03:24, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>
> 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.

Thanks for the explanation, I agree that the proposed approach makes the most
sense.

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

I completely agree, let’s avoid such hacks.

cheers ./daniel