- 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
