On 5/8/24 8:12 AM, Sam Whited wrote:
maybe we should have a "how to use
TLS with XMPP" informational spec of our own at some point?
Thijs Alkemade and I wrote RFC 7590 [1] for that purpose, but it was
published in 2015 (via the UTA WG) and much has changed since then.
Peter
[1]
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
Sorry, maybe I wasn't explicit enough. I didn't mean to not include it,
just that it does not belong into the "Security Considerations"
section, but instead belongs into the "Occupant ID generation" section.
It's meant to be a core part of the protocol, not just something
implementers should
On 08/05/2024 16.42, 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
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
Hi Travis,
Thanks for your mail.
I am sorry that xep440 failed to communicate its goal, as it seems. I
will try to improve upon that.
You write that tls-server-end-point should not be used and that
TLS-intercepting proxies can implement tls-exporter "just fine by simply
passing the keying
I strongly disagree that this does not belong in the security
considerations. "anonymous" is not a formally provable security
property. You and I may know that that means "don't take a SHA-1 and
assume that it will be hard to guess", but as we see over and over and
over again many people won't
On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote:
> I'd like to see the security considerations expanded on this.
>
> In particular, in the business rules it mentions the fact that if
> occupant-id isn't supported it could be spoofed. This should exist in
> the security considerations.
Fair.
Indeed, sorry to be unclear, I'm suggesting that we should discuss this
in the security considerations section (probably detailing exactly what
"The occupant identifier MUST be generated such that it is anonymous"
actually means in terms of security properties). In addition, I think we
should
Also, I suspect the naive way to implement this will be to hash the bare
JID. We probably want to mention that this is a bad idea and that these
identifiers should be random (or we should explicitly define the security
properties that are required if they're derived, which probably includes
I'd like to see the security considerations expanded on this.
In particular, in the business rules it mentions the fact that if
occupant-id isn't supported it could be spoofed. This should exist in
the security considerations.
Also, I suspect the naive way to implement this will be to hash
I'm a bit torn on this one. Mostly I agree with what Travis wrote. I'm
slightly concerned that the way this spec makes recommendations (ie.
putting exporter and end-point at the same level of "SHOULD" [1]) may
lead to a false sense of security (this is already true of most
everywhere we write
On Wed, 8 May 2024 at 02:35, Travis Burtrum wrote:
> Hi all,
>
> On 5/6/24 1:21 PM, Daniel Gultsch wrote:
> > 1. Is this specification needed to fill gaps in the XMPP protocol
> > stack or to clarify an existing protocol?
>
> No. And in fact it opens gaps.
>
> > 2. Does the specification solve
Can we see if the Kitten IETF list (which tends to cover the use of TLS
channel bindings with SASL mechanisms) has any comments on this before
advancing it? I appreciate this is a departure from our process,
strictly speaking, but it feels like a bit of outreach might benefit this
and we could
Hi,
I think most of use can agree that TLS1.3 and tls-exporter is where we
want to end up at. I will likely modify the 'Require Channel Binding'
setting in Conversations to require that specific channel binding
instead of just any. However on the path toward that goal and to
provide good error
Hi Travis,
While I agree with most of your assessment in general, there is a few
things that need to be corrected:
Key pinning using '487 would not have prevented the jabber.ru attack,
as it is already known that the attacker was able to intercept and
handle http(s) requests themselves, so they
This message constitutes notice of a Last Call for comments on
XEP-0421.
Title: Anonymous unique occupant identifiers for MUCs
Abstract:
This specification defines a method that allows clients to identify a
MUC participant across reconnects and renames. It thus prevents
impersonification of
Version 1.34.6 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to
Version 2.5.0 of XEP-0030 (Service Discovery) has been released.
Abstract:
This specification defines an XMPP protocol extension for discovering
information about other XMPP entities. Two kinds of information can be
discovered: (1) the identity and capabilities of an entity, including
the
Turns out tls-unique is *additionally* broken by
https://www.mitls.org/pages/attacks/SLOTH found a few months after the release
of RFC7627 that tried to fix it:
> If your TLS application relies on the tls-unique channel binding to prevent
> credential forwarding, you need to redesign your
20 matches
Mail list logo
