I want to bump this email from an earlier LC of 0440
On Wed, May 8, 2024 at 5:16 PM Marvin W <xmpp@larma.de> wrote:
> 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. ^
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 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@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org