> On 23 Jan 2018, at 03:24, Michael Paquier <michael.paqu...@gmail.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
