8 May
2024
8 May
'24
9:16 a.m.
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