20 Oct
2025
20 Oct
'25
10:46 a.m.
On Sat, 18 Oct 2025 at 17:32, Daniel Gultsch <daniel(a)gultsch.de> wrote:
I want to bump this email from an earlier LC of 0440
On Wed, May 8, 2024 at 5:16 PM Marvin W <xmpp(a)larma.de> wrote:
FWIW, I've argued for decades that MTI levels and protocols ought not to be
combined in a single specification.
But anyway.
Yes, the MTI advice in this document is indeed a bit weird.
tls-server-endpoint is MUST, but with little background information, but it
then goes on to say that tls-exporter is preferable.
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.
Yes. Basically this. ^
I did a little bit of digging and it seems that the making endpoint a
MUST got introduced by Thilo presumably because iOS doesn’t do unique.
However that was 5 years ago and while that is still true we live in a
TLS 1.3 world now and export seems to be fairly widely supported.
Again I’m not saying that the XEP should explicitly recommend against
endpoint but also not require it (neither as MUST nor as SHOULD (it
was should prior to Thilo‘s change))
Stock Java still doesn't support tls-exporter. You can use Bouncy Castle,
though (and even unto FIPS), and get access - if local policy allows, which
it might not. Otherwise you're stuck with tls-server-endpoint - which is
still better than nothing of course.
The web browser doesn't support anything useful at all, you're entirely out
for channel binding - and therefore may wish to support "non channel
binding" versions.
Any server operating behind a load balancer that terminates TLS cannot do
anything but tls-server-endpoint, of course.
At minimum, I think a document, somewhere, should provide advice on what
security stuff to implement and why in 2025, and include the MTIs for such
things, and be kept current. That could I suppose be the compliance docs,
though those have typically concentrated on features rather than security
MTIs.
At the moment that seems to be this document for channel bindings, which is
not ideal, I agree.
(If nobody else fancies writing a separate document, I'd be up for making a
start on one?)
So yeah, basically what Marvin said 1.5 years ago.
cheers
Daniel
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org