On Fri, Aug 16, 2019 at 02:11:57PM -0400, Jonathan S. Katz wrote: > To be pedantic, +1 on the channel_binding param.
Seems like we are moving in this direction then. I don't object to the introduction of this parameter. We would likely want to do something for downgrade attacks in other cases where channel binding is not used, still there is verify-ca/full even in this case which offer similar protections for MITM and eavesdropping. > I would ask if scram-sha-256-plus makes the list if we have the > channel_binding param? No in my opinion. > If channel_binding = require, it would essentially ignore any non-plus > options in password_protocol and require scram-sha-256-plus. In a future > scram-sha-512 world, then having scram-sha-256-plus or > scram-sha-512-plus options in "password_protocol" then could be > necessary based on what the user would prefer or require in their > application. Not including scram-sha-512-plus or scram-sha-256-plus in the comma-separated list would be a problem for users willing to give for example scram-sha-256,scram-sha-512-plus as an authorized list of protocols but I don't think that it makes much sense as they basically require an SSL connection for tls-server-end-point per the second element. -- Michael
signature.asc
Description: PGP signature
