On Fri, Apr 7, 2017 at 9:59 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 04/07/2017 10:38 AM, Magnus Hagander wrote: > >> So here's a wild idea. What if we just call it "sha256"? Does the user >> actually care about it being scram, or is scram just an implementation >> detail for them? That way when the next one shows up, it'll be sha512 or >> whatever. It happens to use scram under the hood, but does the user have >> to >> or does the user want to care about that? >> >> (One could argue the same way that the user shouldn't have to or want to >> care about the hashing algorithm -- but if that's the case then we should >> only have one entry, it would be "scram", and the system would decide from >> there. And I think this discussion already indicates we don't think this >> is >> enough) >> > > I think the "SCRAM" part is more important than "SHA-256", so -1 on that. > If that is the important part, then I agree :) I am not entirely sure that the scram part *is* more important though. I think most users will be a lot more comfortable with "sha256" than "scram" though. But I guess that says using scram-sha-256 is the correct way. > The main against using just "scram" is that it's misleading, because we > implement SCRAM-SHA-256, rather than SCRAM-SHA-1, which was the first SCRAM > mechanism, commonly called just SCRAM. As long as that's the only SCRAM > variant we have, that's not too bad, but it becomes more confusing if we > ever implement SCRAM-SHA-512 or SCRAM-something-else in the future. That's > the point Noah made, and it's a fair point, but the question is whether we > consider that to be more important than having a short name for what we > have now. Yeah, I agree we should be prepared for the future. And having "scram" and "scram-sha-512" would definitely fall under confusing. The channel binding aspect is actually more important to think about right >> now, as that we will hopefully implement in the next release or two. >> >> In [1], Michael wrote: >> >> There is also the channel binding to think about... So we could have a >>> list of keywords perhaps associated with SASL? Imagine for example: >>> sasl $algo,$channel_binding >>> Giving potentially: >>> sasl scram_sha256 >>> sasl scram_sha256,channel >>> sasl scram_sha512 >>> sasl scram_sha512,channel >>> In the case of the patch of this thread just the first entry would >>> make sense, once channel binding support is added a second >>> keyword/option could be added. And there are of course other methods >>> that could replace SCRAM.. >>> >> >> It should also be possible to somehow specify "use channel binding, if the >> client supports it". >> > > Is that really a type of authentication? We already hvae the idea of > authentication method options, used for most other things except md5 which > doesn't have any. So it could be "sha256 channelbind=on", "sha256 > channelbind=off" or "sha256 channelbind=negotiate" or something like that? > > Technically, the channel-binding variant is a separate SASL mechanism, i.e. it has a separate name, SCRAM-SHA-256-PLUS. I'm not sure if > users/admins think of it that way. I bet they don't. I don't think "sasl" is interesting to a user, it's the actual mechanisms >> (e.g "scram-sha256") that matter. So I'd suggest that we allow a list of >> algorithms in the method field. If we go with the longer "scram-sha-256" >> name, it would look like this: >> >> # TYPE DATABASE USER ADDRESS METHOD >> host all all example.com scram-sha-256-plus, >> scram-sha-256 >> >> The problem again is that those names are quite long. Is that OK? >> > > Not sure if it would be doable in the code, but we could also have: > host all all example.com scram method=sha256plus,sha256 > > or something like that. Which would fit within the current syntax of the > file. But I think it might not be enough, because then you couldn't have > two entries with different scram methods for the same combination of the > other fields -- the hba *matching* doesn't look at the options fields. > > You can't have two entries with the same type+database+user+address combination, period. (Or if you do, the second one is ignored.) That's exactly my point. //Magnus
