XEP-0440: Rework Security Considerations and related sections by tmolitor-stud-tu · Pull Request #1477 · xsf/xeps

tmolitor-stud-tu · 2025-10-24T23:58:10Z

This is my proposed PR resulting from the discussions at standards@.

@Flowdalic feel free to call me out on anything you don't like and I'll be happy to change it :)

tmolitor-stud-tu · 2025-10-26T05:04:24Z

I've cleaned it up a bit and removed unnecessary SCRAM references. The new rendered version:
xep-0440.html

xep-0440.xml

tmolitor-stud-tu · 2025-10-28T10:31:45Z

@Flowdalic Daniel commented, that "(or just randomly pick a channel-binding and hope for the best)" sounds weirdly untechnical, so I force pushed a small change here.

Flowdalic

LGTM. But please use "SASL mechanisms with channel-binding support" instead of "*-PLUS".

I would have also welcomed not mixing trivial fixes within the same commit as the big rewording change. And some rationale for the rewording in the commit message.

Besides that, please feel free to add yourself as author of the document, if you want to.

Flowdalic · 2025-10-30T19:46:14Z

xep-0440.xml

+      Clients SHOULD implement tls-server-end-point and use it if no other
+      (stronger) channel-binding method is supported by both sides.</li>
+    <li>If the client doesn't support channel-binding, it MUST send "n" in the GSS-header (see &rfc5802;).</li>
+    <li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor


This implies that only SASL mechanisms ending with -PLUS support channel-binding. This may be true now, but may not hold in the future.

Suggested change

<li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor

<li>If the client supports channel-binding, but the server announced no SASL mechanisms supporting channel binding nor

Flowdalic · 2025-10-30T19:46:47Z

xep-0440.xml

+    <li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor
+      channel-binding types (via this specification), it MUST send "y" in accordance to &rfc5802;.</li>
+    <li>If the client is using SASL2 (&xep0388;) to authenticate and received announcements
+      for '*-PLUS' from the server, but no channel-binding types, it MUST abort the authentication


Flowdalic · 2025-10-30T19:47:26Z

xep-0440.xml

+      This condition is undefined with SASL1 (&rfc6120;), but the client MAY also abort authentication
+      in this case (or just randomly pick a channel-binding and hope for the best).</li>
+    <li>If the client is using SASL2 to authenticate and it receives channel-binding announcements,
+      from the server, but no '*-PLUS' methods are announced, it MUST abort authentication


Flowdalic · 2025-10-30T19:47:38Z

xep-0440.xml

+      from the server, but no '*-PLUS' methods are announced, it MUST abort authentication
+      (this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li>
+    <li>If the client is using either SASL1 or SASL2 to authenticate and receives announcements for
+      '*-PLUS' methods and channel-binding types, but none of these announced channel-binding types are


Flowdalic · 2025-10-30T19:49:51Z

xep-0440.xml

+      in this case (or just randomly pick a channel-binding and hope for the best).</li>
+    <li>If the client is using SASL2 to authenticate and it receives channel-binding announcements,
+      from the server, but no '*-PLUS' methods are announced, it MUST abort authentication
+      (this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li>


Suggested change

(this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li>

(this is an implementation error or ongoing MITM attack where SASL mechanisms are stripped). It SHOULD do the same when using SASL1.</li>

xep-0440.xml

tmolitor-stud-tu · 2025-10-30T21:30:23Z

Good point regarding the -PLUS stuff!
Regarding the trivial fixes: I can split them into a separate commit, if you want met too. That's an easy fix :)

Neustradamus · 2025-10-30T23:01:15Z

@tmolitor-stud-tu: Thanks for your work on the XEP-0440.

But why have you removed the RFC 5056 part?

https://github.com/xsf/xeps/pull/1477/files#diff-9e528c5b13aaaa709aef326965980b51c7171818b6e2c9263ccef01e1f3af7beL3

The "RFC 5056: On the Use of Channel Bindings to Secure Channel" is not obsolete:

https://datatracker.ietf.org/doc/html/rfc5056

cc: @nicowilliams (Nicolas Williams, author of RFC 5056, RFC 5801, RFC 5802, RFC 5929 and a lot others).

Neustradamus · 2025-10-30T23:15:06Z

Linked to:

XEP-0474: Introduce business rules detailing client behavior #1481

tmolitor-stud-tu · 2025-10-30T23:19:40Z

@Neustradamus Please don't spam and try to understand the file format before posting!

Neustradamus · 2025-10-30T23:30:33Z

To add clearer guidance on what to do as a client developer, this update adds a new Business Rules section referencing to the new XEP-0440 Business Rules.

As author, I obviously approve this, but it should only be merged after merging the XEP-0440 changes.

tmolitor-stud-tu · 2025-10-31T17:45:43Z

Ah, upon revisiting the -PLUS stuff, I'm not sure anymore, if using "SASL mechanisms supporting channel-bindin" instead of *-PLIUS is a good fit, since the y and n things are only defined in the SCRAM RFC and other SASL methods might have some other mechanism to signal these conditions. Tying it to SCRAM makes sense imho, to not confuse implementors into trying to send y in places were it doesn't belong (some future PAKE mechanism for example) and instead of doing the right things.

We could add some pointer that the y and n are SCRAM specific into the paragraph above the list of rules, though. That paragraph already tries to make clear, that this is for SCRAM, but maybe we could make that even stronger/clearer.

tmolitor-stud-tu · 2025-10-31T17:57:35Z

Okay, I removed the *-PLUS reference, and additionally amended the rules introduction paragraph regarding other SASL mechanisms supporting channel-binding.
I'll force push that to make that change available in github, but will do another force-push factoring out the trivial changes into their own commit shortly. :)

tmolitor-stud-tu · 2025-10-31T18:34:20Z

Okay, I've split also the commit now :)

Flowdalic

LGTM, only one minor rewording left.

xep-0440.xml

This update addresses a possible MITM attack vector by making the tls-server-end-point channel-binding mandatory to implement. This significantly raises the bar for such MITM attackers. The new Business Rules section explains the details how to remedy the attack vector, while the Security Considerations section gives a detailed explanation for these rules.

This also adds a new SASL2 example alongside the SASL1 one.

tmolitor-stud-tu · 2025-11-03T09:11:57Z

This should be ready to be merged now :)

(Not sure why the workflow didn't run properly.)

tmolitor-stud-tu force-pushed the 0440-update-01 branch 3 times, most recently from 9d94061 to cbd560d Compare October 26, 2025 05:02

tmolitor-stud-tu marked this pull request as draft October 26, 2025 05:05

tmolitor-stud-tu marked this pull request as ready for review October 26, 2025 05:05

Flowdalic reviewed Oct 26, 2025

View reviewed changes

xep-0440.xml Outdated Show resolved Hide resolved

tmolitor-stud-tu force-pushed the 0440-update-01 branch 2 times, most recently from 14fc837 to dd52abe Compare October 28, 2025 10:31

Flowdalic suggested changes Oct 30, 2025

View reviewed changes

Neustradamus mentioned this pull request Oct 30, 2025

XEP-0474: Introduce business rules detailing client behavior #1481

Merged

tmolitor-stud-tu force-pushed the 0440-update-01 branch 2 times, most recently from 535706e to 32d34d6 Compare October 31, 2025 18:33

Flowdalic suggested changes Nov 3, 2025

View reviewed changes

xep-0440.xml Outdated Show resolved Hide resolved

xep-0440.xml Outdated Show resolved Hide resolved

tmolitor-stud-tu added 2 commits November 3, 2025 10:08

XEP-0440: Some minor editorial changes

89909e2

This also adds a new SASL2 example alongside the SASL1 one.

tmolitor-stud-tu force-pushed the 0440-update-01 branch from 794f933 to 89909e2 Compare November 3, 2025 09:08

Flowdalic approved these changes Nov 3, 2025

View reviewed changes

iNPUTmice merged commit ea27112 into xsf:master Nov 3, 2025
1 check failed

	<li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor
	<li>If the client supports channel-binding, but the server announced no SASL mechanisms supporting channel binding nor

	(this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li>
	(this is an implementation error or ongoing MITM attack where SASL mechanisms are stripped). It SHOULD do the same when using SASL1.</li>

Conversation

tmolitor-stud-tu commented Oct 24, 2025

Uh oh!

tmolitor-stud-tu commented Oct 26, 2025

Uh oh!

Uh oh!

tmolitor-stud-tu commented Oct 28, 2025

Uh oh!

Flowdalic left a comment

Choose a reason for hiding this comment

Uh oh!

Flowdalic Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

Flowdalic Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

Flowdalic Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

Flowdalic Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

Flowdalic Oct 30, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tmolitor-stud-tu commented Oct 30, 2025

Uh oh!

Neustradamus commented Oct 30, 2025

Uh oh!

Neustradamus commented Oct 30, 2025

Uh oh!

tmolitor-stud-tu commented Oct 30, 2025

Uh oh!

Neustradamus commented Oct 30, 2025

Uh oh!

tmolitor-stud-tu commented Oct 31, 2025

Uh oh!

tmolitor-stud-tu commented Oct 31, 2025

Uh oh!

tmolitor-stud-tu commented Oct 31, 2025

Uh oh!

Flowdalic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tmolitor-stud-tu commented Nov 3, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants