Hi, I didn't want to suggest specific wording, but the more I think about it, the more I am against of any RFC style wording in the Security Considerations section of 0440. If it's part of the protocol described in 0440 and RFC style wording makes sense, it should be outside the Security Considerations (it maybe repeated there for emphasis). If it's not part of the protocol of 0440, then it shouldn't be using RFC style wording in first place. Many Security Considerations (especially those related to the security of channel binding types) apply no matter if 0440 is implemented, so why would be put anything normative about their security in 0440? The whole "Which channel-binding types should be supported?" IMO belongs somewhere else, not in 0440. Security Considerations can provide some guidance here (and also some rationale as to why it might be reasonable to implement tls-server-end-point even if tls-exporter is more secure), but those shouldn't be normative in any capacity. Marvin On Wed, 2024-05-08 at 16:42 +0200, Florian Schmaus wrote:
On 08/05/2024 12.41, Marvin W wrote:> To address your concerns I'd suggest the following changes to 0440:
- Reduce tls-server-end-point to SHOULD for servers and MAY for clients, specifically mention that this is only for better compatibility.
I'd like to note that we previously explicitly decided[1] that requiring a common channel-binding type would increase security. And that type had to be tls-server-end-point, as it is generally available. That is why the XEP currently says that servers MUST support tls-server-end- point.
- Add tls-exporter as a SHOULD for servers and clients, specifically mentioning it's what should be used if technically possible - Add that clients SHOULD pin channel binding methods (in a way that allows upgrades to tls-exporter but not downgrades from it) OR use other reasonable methods to prevent downgrades, e.g. by using 0474.
Those two points are valid, the XEP already tries to encourage usage of tls-exporter (although the wording could be improved) and suggests pinning to improve security.
However, using RFC keywords in such cases was sometimes met with little approval in the past. That is the main reason why the XEP does avoid it at the moment.
If it is consensus that using RFC keywords here provides a significant advantage, then it can be changed.
That said, I am a little bit unhappy with "SHOULD pin channel binding methods or use other reasonable methods". Personally, I would avoid the combination of a SHOULD/MUST with some rather imprecise requirements ("other reasonable methods").
- Flow
1: See Russlan's standards@ mail from 2020-07-01