TLS cipher restrictions should be relaxed for the authorise endpoint

[Joseph Heenan]

OpenBanking have decided to allow more ciphers on the authorise endpoints for user-agent interoperability reasons:

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/47546479/Known+Specification+Issues

We should probably make some allowance for this in the FAPI spec - I'm not sure what we should actually recommend though; perhaps just say it may be weaker and use there own judgement to follow BCP195?

[Nat Sakimura]

So what was added?

[Tom Jones]

I disagree. Over time we know that stronger encryption becomes a requirement and that many organizations differ updating. Not good to encourage bad behaviors.

[Joseph Heenan]

The current OB resolution is "Clarification to reflect that the ASPSP's are free to support a more expansive list of TLS Ciphers on the Authorization Server Endpoint than is explicitly supported by the FAPI Read Write Security Profile section 8.6 "

@tomcjones I'm not sure I follow what are you suggesting.

The point here is that banks believe that FAPI compliant services have poor user agent interoperability so are deploying non-compliant services.

If we believe user agent interoperability is poor, I believe we should update FAPI to improve user agent interoperability.

[Tom Jones]

I think you miss my point. It does not seem to be a good idea for implementers to have freedom to pick whichever crypto algorithm they like. It always ends badly.

[Joseph Heenan]

@tomcjones Ah, got it.

What's unclear is what we should actually say. Do you have any suggestions?

[Tom Jones]

you could answer Nat's questions - what do you want to add. Taking away all restrictions seems like the wrong approach.

[Joseph Heenan]

I did answer Nat's question about what OpenBanking added - the exact text they added is "ASPSP's are free to support a more expansive list of TLS Ciphers on the Authorization Server Endpoint than is explicitly supported by the FAPI Read Write Security Profile section 8.6 " There is no further guidance in the OpenBanking spec.

Sadly I'm not a user agent interoperability expert so I don't have any good insight.

The options we currently have on the table are:

A) Keep as is; seems bad for interoperability and/or compliance with the spec

B) Leave it up to the AS implementor as OpenBanking are doing currently

C) State in FAPI part 2 that, for the authorization_endpoint only, more ciphers may be permitted and BCP195 should be followed

D) Find someone who is an expert in this area to give us a better proposal

E) Follow a third party document, eg. https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations

Of these "D" seems best if we can, failing that the best option currently on the table is "C" in my opinion.

[Tom Jones]

C should work fine, why don't you recommend that. I would add that BCP's are subject to revision from time to time and the implementer should be careful to use the latest version at https://tools.ietf.org/html/bcp195 btw, i used to manage ssl on windows dev team

[Joseph Heenan]

Thanks Tom.

I've had a go at creating wording for that and created a merge request here:

https://bitbucket.org/openid/fapi/pull-requests/43/allow-more-ciphers-between-authorisation/diff

[Tom Jones]

I have no objection to the statement as written. Does anyone think there might be a better place in the document that applies more broadly?

[Nat Sakimura]

Allow more ciphers between authorisation server & user's browser

Fixes #129

→ <<cset 4024ba7d0ca4>>