On 31/05/17 03:39, Michael Paquier wrote:
> On Tue, May 30, 2017 at 5:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> That sounds like undue optimism to me. Unless somebody's tested that
>> Michael's proposed implementation, which uses undocumented OpenSSL
>> APIs, actually interoperates properly with a SCRAM + channel binding
>> implementation based on some other underlying SSL implementation, we
>> can't really know that it's going to work. It's not like we're
>> calling SSL_do_the_right_thing_for_channel_binding_thing_per_rfc5929().
>> We're calling SSL_do_something_undocumented() and hoping that
>> something_undocumented ==
>> the_right_thing_for_channel_binding_thing_per_rfc5929. Could be true,
>> but without actual interoperability testing it sounds pretty
>> speculative to me.
> Hm? Python is using that stuff for a certain amount of years now, for
> the same goal of providing channel binding for SSL authentication. You
> can look at this thread:
> https://bugs.python.org/issue12551
> So qualifying that as a speculative method sounds a quite hard word to me.
Actually this Python patch seems to ultimately rely on the same
OpenSSL functions as your implementation.
I don't have anything against implementing tls-unique, specially as
per the RFC it is mandatory (if channel binding support is provided).
However, given the use of undocumented API, given that at least the Java
driver would have a very difficult time implementing it (basically
replacing Java's standard SSL stack with a completely external one,
BouncyCastle, which adds load, size and complexity), I would rather
focus the efforts on tls-server-end-point which only needs to access the
certificate data, something that most APIs/frameworks/languages seem to
cover much more naturally than tls-unique.
Both are equally safe and effective and so having support for both
seems sensible to me.
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data