Re: Support tls-exporter as channel binding for TLSv1.3

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support tls-exporter as channel binding for TLSv1.3
Date: 2022-10-14 02:00:10
Message-ID: Y0jCqr1chYoGhM40@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 13, 2022 at 10:30:37AM -0700, Jacob Champion wrote:
> Is the intent to backport tls-exporter client support? Or is the
> compatibility break otherwise acceptable?

Well, I'd rather say yes thanks to the complexity avoided in the
backend as that's the most sensible piece security-wise, even if we
always require a certificate to exist in PG. A server attempting to
trick a client in downgrading would still be a problem :/

tls-exporter would be a new feature, so backporting is out of the
picture.

> It seemed like there was also some general interest in proxy TLS
> termination (see also the PROXY effort, though it has stalled a bit).
> For that, I would think tls-server-end-point is an important feature.

Oh, okay. That's an argument in favor of not doing that, then.
Perhaps we'd better revisit the introduction of tls-exporter once we
know more about all that, and it looks like we would need a way to be
able to negotiate which channel binding to use (I recall that the
surrounding RFCs allowed some extra negotiation, vaguely, but my
impression may be wrong).
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-10-14 02:14:55 Re: Use LIMIT instead of Unique for DISTINCT when all distinct pathkeys are redundant
Previous Message David Rowley 2022-10-14 01:39:23 Re: Incorrect comment regarding command completion tags