On 8/13/19 6:25 PM, Jeff Davis wrote:
> On Tue, 2019-08-13 at 16:51 -0400, Jonathan S. Katz wrote:
>> Alternatively, we could combine 2 & 3, e.g.:
>>
>> channel_binding = {disable|prefer|require}
>>
>> # comma-separated list of protocols that are ok to the user, remove
>> # ones you don't want. empty means all is ok
>> password_protocol = "plaintext,md5,scram-sha-256,scram-sha-256-
>> plus"
>
> I still feel like lists are over-specifying things. Let me step back
> and offer an MVP of a single new parameter:
>
> channel_binding={prefer|require}
>
> And has a lot of benefits:
> * solves the immediate need to make channel binding useful, which
> is a really nice feature
> * compatible with most of the other proposals we're considering, so
> we can always extend it when we have a better understanding and
> consensus
> * clear purpose for the user
> * doesn't introduce new concepts that might be confusing to the
> user, like SASL or the use of "-plus" to mean "with channel binding"
> * guides users toward the good practice of using SSL and SCRAM
> * simple to implement
+1; I agree with your overall argument. The only thing I debate is if we
want to have an explicit "disable" option. Looking at the negotiation
standard[1] specified for channel binding with SCRAM, I don't think we
need an explicit disable option. I can't think of any good use cases for
"disable" off the top of my head either. The only thing is it would be
consistent with some of our other parameters in terms of having an
explicit "opt-out."
Jonathan
[1] https://tools.ietf.org/html/rfc5802#section-6