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
signature.asc
Description: PGP signature
