Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxvYB-0001pN-7U for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Apr 2017 13:09:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cxvYA-0002QB-O7 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Apr 2017 13:09:38 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cxvY9-0002Pu-LB for pgsql-hackers@postgresql.org; Tue, 11 Apr 2017 13:09:37 +0000 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cxvY5-0002QV-3K for pgsql-hackers@postgresql.org; Tue, 11 Apr 2017 13:09:35 +0000 Received: by mail-wm0-x22d.google.com with SMTP id w64so63268039wma.0 for ; Tue, 11 Apr 2017 06:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8kdata-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=adA6cjF0z4OfaQYlCXLpmCAnUXt1dfHVB8eUURqqvvs=; b=qbLPpBCnjQ5prigMVhmw/LC5IhTDEogSMA30ihNgSydG6LIdKEN4YGTO5ftdBD0d45 o4ITjPn8pPyQ3lvZbSDAncxydo+DBPisavcIQNsHfw5XjeybD0WUV+5Xf7WG1L3bCsoA i5LcciMk6DfqLNU/KoAtzdzwyzEeA5S9TpO2aOd2/v7Ar2lWVAdZv/KQ10wWYkWOW83I uNoqP2DgsJL/ug+FkWW1uB/jRtJ4T/icyyfOWFHGO42Y8f5z7/nfC1NFqBciSlxbXeoh wrC/uJTB8Lx8t+a3ikOrg0K2x+HmHe1JQa8n9LjUnE/NRn9IfJgWMBRsFf4j9dxX99KE w4yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=adA6cjF0z4OfaQYlCXLpmCAnUXt1dfHVB8eUURqqvvs=; b=kkKtWQSGHCW0y9PvjH7tWua3Nkx3Auku5qmrff6UfjpigkLiWwC+afCw8uAwK0mMhH yoIc0MSvpGn6H0Eq+lIC07bovzs2PLXOlrvhgFb35VoPhSy6rQHE8MQUyPn7ZyQwwRhw F2AZZVnHRdQIssDvKmwQHGoJ7FoZTOXBmolFgGrFVntZvX9H+6+BezuwTeznT7Y+WaXX cxpky8X7eJeAQJFQz40N1rr4NHKpSW6GRSJcLfY7dp7vIcbGc7v2YgLBuVhjFVN5yf47 /h68yEOK9fEkhrJjBypObM/Wag5XMWxqZgSj4YpfUQtEU3mBmi8fWsWfq7B0iP8qqauM Tmew== X-Gm-Message-State: AN3rC/7MKv6S6rIpidgktp15EX0SMqLz504eSo15tC0W2RPLUhtsscAQ de32qfEvZfTltQ== X-Received: by 10.28.210.13 with SMTP id j13mr15317377wmg.94.1491916171676; Tue, 11 Apr 2017 06:09:31 -0700 (PDT) Received: from [192.168.1.130] (148.126.218.87.dynamic.jazztel.es. [87.218.126.148]) by smtp.gmail.com with ESMTPSA id h20sm2445940wmd.29.2017.04.11.06.09.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 06:09:31 -0700 (PDT) Subject: Re: Some thoughts about SCRAM implementation To: Magnus Hagander References: <729b548a-f434-f31c-15e7-59f44aaecc8d@8kdata.com> <20170410183230.oxagjpfgj6xxmcwx@alap3.anarazel.de> Cc: Andres Freund , Heikki Linnakangas , pgsql-hackers From: =?UTF-8?Q?=c3=81lvaro_Hern=c3=a1ndez_Tortosa?= Message-ID: Date: Tue, 11 Apr 2017 15:09:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DBF4B5D78F9D393CD0FA3FAD" X-Pg-Spam-Score: -1.8 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org This is a multi-part message in MIME format. --------------DBF4B5D78F9D393CD0FA3FAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/04/17 15:03, Magnus Hagander wrote: > On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa > > wrote: > > > > On 10/04/17 20:32, Andres Freund wrote: > > On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote: > > > On 10/04/17 13:02, Heikki Linnakangas wrote: > > On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote: > > - I think channel binding support should be added. > SCRAM brings security > improvements over md5 and other simpler digest > algorithms. But where it > really shines is together with channel binding. > This is the only method > to prevent MITM attacks. Implementing it should > not very difficult. > There are several possible channel binding > mechanisms, but the mandatory > and probably more typical one is 'tls-unique' > which basically means > getting the byte array from the TLSfinish() > message and comparing it > with the same data sent by the client. That's more > or less all it takes > to implement it. So I would go for it. > > We missed the boat for PostgreSQL 10. You're right > that it probably > wouldn't be difficult to implement, but until there's > a concrete patch > to discuss, that's a moot point. > > Really? That's a real shame.... I know we're very > late in the CF cycle > but, again, this would be a real shame. > > That can equally be said about about a lot of features. If we > don't > stop at some point... Also, we're not late in the CF cycle, > the CF cycle > for v10 is over. It's not like the non-existance of channel > binding > removes previously existing features, or makes SCRAM useless. > > > Greetings, > > Andres Freund > > > I know this is a lost battle. But please bear with me for a > minute. > > Let's put ourselves on the foot of potential users. Why would > anyone want to use SCRAM? What for? The hashing mechanism is > better, no question. And bring some added benefits, true. So its > "better". But the real gain comes from using channel binding, > which avoids impersonation, MITM attacks. This is the deal > breaker. SCRAM without channel binding is like Coke Zero without > caffeine and mixed with water. Don't get me wrong, the work behind > is great. > > > > I think you are seriously undervaluing the SCRAM without channel binding. I'm not. If I wouldn't appreciate its value, I wouldn't be writing a client library for the jdbc driver. > It improves a lot of things over our current md5 method beyond just > using a stronger hashing algorithm. > > Sure, channel binding is great. But that's not a dealbreaker, or even > close to it. I think otherwise. It is close to a dealbreaker. And it's so few extra code lines that it requires.... > > But just a bit more is needed to make it really a big > announcement and provide real value to (I guess, mostly but very > interesting) enterprise customers, for which MITM and > impersonating are big things. The good news is that adding channel > binding is like inverse Paretto: a 20% of extra effort (I bet > significantly less) leads to 80% improvement. > > > I would expect most enterprise customers who care about MITM > protection are already using either TLS or ipsec to cover that > already. They have benefit from the other parts of SCRAM, but they've > already solved those problems. Enterprises use checklists. And discard solutions if they don't have "checks" on all the items. One of those is, in my opinion, SCRAM with channel binding. I don't want this to happen to PG, specially when it's so easy to implement. But I will conserve my remaining courage (thanks Michael!) credits for future threads ;) I have stated my opinion clearly, I will now go back to the client library. Thanks, Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data --------------DBF4B5D78F9D393CD0FA3FAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/04/17 15:03, Magnus Hagander wrote:
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:


On 10/04/17 20:32, Andres Freund wrote:
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:

On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding. This is the only method
to prevent MITM attacks. Implementing it should not very difficult.
There are several possible channel binding mechanisms, but the mandatory
and probably more typical one is 'tls-unique' which basically means
getting the byte array from the TLSfinish() message and comparing it
with the same data sent by the client. That's more or less all it takes
to implement it. So I would go for it.
We missed the boat for PostgreSQL 10. You're right that it probably
wouldn't be difficult to implement, but until there's a concrete patch
to discuss, that's a moot point.
     Really? That's a real shame.... I know we're very late in the CF cycle
but, again, this would be a real shame.
That can equally be said about about a lot of features.  If we don't
stop at some point... Also, we're not late in the CF cycle, the CF cycle
for v10 is over.  It's not like the non-existance of channel binding
removes previously existing features, or makes SCRAM useless.


Greetings,

Andres Freund

     I know this is a lost battle. But please bear with me for a minute.

    Let's put ourselves on the foot of potential users. Why would anyone want to use SCRAM? What for? The hashing mechanism is better, no question. And bring some added benefits, true. So its "better". But the real gain comes from using channel binding, which avoids impersonation, MITM attacks. This is the deal breaker. SCRAM without channel binding is like Coke Zero without caffeine and mixed with water. Don't get me wrong, the work behind is great.


I think you are seriously undervaluing the SCRAM without channel binding.

    I'm not. If I wouldn't appreciate its value, I wouldn't be writing a client library for the jdbc driver.


It improves a lot of things over our current md5 method beyond just using a stronger hashing algorithm.

Sure, channel binding is great. But that's not a dealbreaker, or even close to it.

    I think otherwise. It is close to a dealbreaker. And it's so few extra code lines that it requires....


 
    But just a bit more is needed to make it really a big announcement and provide real value to (I guess, mostly but very interesting) enterprise customers, for which MITM and impersonating are big things. The good news is that adding channel binding is like inverse Paretto: a 20% of extra effort (I bet significantly less) leads to 80% improvement.

I would expect most enterprise customers who care about MITM protection are already using either TLS or ipsec to cover that already. They have benefit from the other parts of SCRAM, but they've already solved those problems.

    Enterprises use checklists. And discard solutions if they don't have "checks" on all the items. One of those is, in my opinion, SCRAM with channel binding. I don't want this to happen to PG, specially when it's so easy to implement.


    But I will conserve my remaining courage (thanks Michael!) credits for future threads ;) I have stated my opinion clearly, I will now go back to the client library.


    Thanks,

    Álvaro

-- 

Álvaro Hernández Tortosa


-----------
<8K>data
--------------DBF4B5D78F9D393CD0FA3FAD--