Re: Negotiating the SCRAM channel binding type

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Negotiating the SCRAM channel binding type
Дата
Msg-id 6f77cade-9a7f-7ea6-3e74-84edac30d0a8@iki.fi
обсуждение исходный текст
Ответ на Re: Negotiating the SCRAM channel binding type  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Negotiating the SCRAM channel binding type
Список pgsql-hackers
On 12/07/18 12:06, Michael Paquier wrote:
> On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
>> It seems that all implementations can support tls-server-end-point, after
>> all, so I'm not too worried about this anymore. The spec says that it's the
>> default, but I don't actually see any advantage to using it over
>> tls-server-end-point. I think the main reason for tls-unique to exist is
>> that it doesn't require the server to have a TLS certificate, but PostgreSQL
>> requires that anyway.
> 
> Er.  My memories about the spec are a bit different: tls-unique must be
> implemented and is the default.
> 
> [ ... digging ... ]
> 
> Here you go:
> https://tools.ietf.org/html/rfc5802#section-6.1

Meh. We're not going implement tls-unique, anyway, in some of the 
upcoming non-OpenSSL TLS implementations that don't support it.

Hmm. That is actually in a section called "Default Channel Binding". And 
the first paragraph says "A default channel binding type agreement 
process for all SASL application protocols that do not provide their own 
channel binding type agreement is provided as follows". Given that, it's 
not entirely clear to me if the requirement to support tls-unique is for 
all implementations of SCRAM, or only those applications that don't 
provide their own channel binding type agreement.

- Heikki


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: no partition pruning when partitioning using array type
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: buildfarm vs code