Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 06, 2018 at 01:16:11PM -0700, Steven Fackler wrote:

Thanks for the pointers, Steven. You should avoid top-posting on this
list, this is not the style used on the Postgres lists.

> TLS 1.3, (which is currently in a draft state, but is theoretically being
> finalized soon) does not support the TLS channel binding algorithms [1].
> From talking with one of the people working on the TLS 1.3 standard,
> tls-unique is seen as particularly problematic. There's some discussion on
> the IETF mailing lists from a couple of years ago [2].

Well, it seems that we are going this API to decide if an SSL
implementation supports channel binding or not then:
https://www.postgresql.org/message-id/20180122072936.GB1772%40paquier.xyz
And for TLS 1.3 it would need to use SSL_get_version() or such with the
connection context.

> Ignoring that line of the draft, the current tls-unique implementation in
> Postgres is currently incorrect for TLS 1.3 handshakes anyway since the
> server sends the first Finished message rather than the client [3].

Does this mean that tls-server-end-point goes into unsupported mode?
The emails you mention (thanks!), talk about only tls-unique while the
RFCs mention all channel binding types.

> This is also the case for TLS 1.2 handshakes with session resumption [4].

Please let me think about this one, I am not completely sure yet what
that would mean for libpq and the backend code.
--
Michael