6 May
2024
6 May
'24
11:21 a.m.
This message constitutes notice of a Last Call for comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2024-05-20.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
7 May
7 May
12:43 a.m.
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes, it allows to negotiate the used
channel-binding rather than just guessing
what type the server might support.
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes
3. Do you plan to implement this specification in your
code? If not,
why not?
Already implemented for > 1 year now
4. Do you have any security concerns related to this
specification?
No
5. Is the specification accurate and clearly written?
Yes
-tmolitor
7:34 p.m.
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 the problem stated in
the introduction
and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with the
MITM themselves.
3. Do you plan to implement this specification in your
code? If not,
why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes.
This specification? No.
4. Do you have any security concerns related to this
specification?
So many.
1. it gives a MUST for servers and SHOULD for clients to implement
tls-server-end-point which is weak and likely shouldn't be implemented
at all. Note TLS-intercepting-proxies can implement the strong
tls-exporter just fine by simply passing the keying material to the
backend server. See
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA…
for more discussion.
2. tls-unique is broken by https://www.mitls.org/pages/attacks/3SHAKE
and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your
client-side TLS library and config meets a ton of ifs. It has to
implement the extended master secret extension *and* the server has to
negotiate this. (remember, the server here is the potential attacker, so
it would just... not).
So to securely implement tls-unique a client would need to *require*
negotiation of the extended master secret extension for TLS 1.2
connections and fail to connect otherwise. How many clients do this?
How many clients have any idea whether their TLS lib supports or
enforces this? How many TLS libs even let you check this?
We must assume tls-unique is not to be trusted.
3. That leaves tls-exporter as the only secure channel binding method.
One method doesn't need negotiation. A wise person recently said
"parameterize of security protocols and algorithms are generally a bad
idea as it adds complexity which reduces security."
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4…
This spec in particular says to nicely ask the attacker if they support
it before doing it... and the attacker will just say no. The XEP
handwaves this security destroying attack as a "well clients could pin
channel bindings" not even a MAY, SHOULD, or MUST. Do any
implementations today do this? If not it is just feel good security
theater that gives absolutely no security against a MITM.
5. Is the specification accurate and clearly written?
See #4
In summary, a XEP to negotiate channel binding with the attacker isn't
helpful.
The only security we can get from channel binding is by *requiring*
clients to do only tls-exporter with only TLS 1.3 or QUIC. If this fails
the client MUST pop up a warning similar to "this is an untrusted
certificate, deny/allow".
If we want a XEP that suggests the above it should be clear in the
security considerations what it prevents and what it doesn't, and how it
compares to other things like public key pinning (DANE or '487), likely
suggesting to do both. Roughly both public key pinning and requiring
tls-exporter channel binding both protect against a jabber.ru style MITM
where the MITM gets their own new certificate, but does not read the
disk of the server they are attacking. Neither public key pinning *nor*
channel binding protect against a MITM where the attacker can read the
disk of the XMPP server and take the public key (and/or cert) and
password hashes to use for SCRAM authentication itself.
Thanks,
Travis
8 May
8 May
1:34 a.m.
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 application.
Our attack on the tls-unique channel binding affects application-level protocols that
rely on this channel binding to prevent credential forwarding attacks. In general, all
uses of tls-unique are suspect, but the following are known to be specifically affected:
* SCRAM is used in SASL and GSSAPI and relies on tls-unique for channel binding. SCRAM is
the default authentication protocol for XMPP.
4:41 a.m.
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 would also be able to
manipulate the host-meta file and thereby pin to a new public key that
they control. In this context it's worth noting that SCRAM channel
binding (even if broken) is never worse than key pinning over HTTPS, as
HTTPS doesn't provide similar security. The only thing that '487 could
do is to delay the start of the attack by up to '487's TTL.
Similar reasoning can be applied to DANE, although it's less obvious
that the jabber.ru attacker would be able to manipulate the DNS.
However given that the jabber.ru attacker seemingly was able to
manipulate the network of two different hosting companies, it's
reasonable to assume they'd be able to manipulate a domain registrar
and/or hosted DNS service as needed.
SLOTH severely weakens the security of tls-unique SCRAM, however due to
it still requiring up to 2^48 HMAC computations, a practical attack is
very unlikely and requires much larger resources than used in the
jabber.ru attack (remember the 2^48 HMACs must be calculated within a
minute or so as the connection would timeout if not).
I'd therefore conclude that a widespread deployment of 0440 and 0474
would likely have prevented the jabber.ru attack even if tls-exporter
was not provided.
<hr>
Most notable though, regarding your feedback, it makes it sound as if
0440 was unfixable, however I think your feedback could be well
incorporated into 0440 to resolve your valid concerns.
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.
- 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.
Beside that, I think your understanding of the wording "gaps in the
XMPP protocol" is (intentionally) wrong: Without 0440 there is no way
to discover which channel binding types can be used, with 0440 there is
one. The question thus is if the lack of discoverability is a "gap" in
the protocol and I think it clearly is, with your answer you claim it's
not, that is, you claim there is no need for discoverability of channel
binding capability.
All the problems that you describe are not related to the protocol, but
to the protocols that can be announced with it and the advice from the
XEP's Security Considerations.
Most notably, the protocol does not prevent clients from completely
ignoring it and always trying to use tls-exporter even if not in the
list, which would just be the status without 0440. As such 0440 is a
strict improvement over the status quo, even if not perfect.
Marvin
On Tue, 2024-05-07 at 21:34 -0400, 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 the problem
stated in the
introduction
and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with
the
MITM themselves.
3. Do you plan to implement this specification in
your code? If
not,
why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes.
This specification? No.
4. Do you have any security concerns related to
this specification?
So many.
1. it gives a MUST for servers and SHOULD for clients to implement
tls-server-end-point which is weak and likely shouldn't be
implemented
at all. Note TLS-intercepting-proxies can implement the strong
tls-exporter just fine by simply passing the keying material to the
backend server. See
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA…
for more discussion.
2. tls-unique is broken by
https://www.mitls.org/pages/attacks/3SHAKE
and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if*
your
client-side TLS library and config meets a ton of ifs. It has to
implement the extended master secret extension *and* the server has
to
negotiate this. (remember, the server here is the potential attacker,
so
it would just... not).
So to securely implement tls-unique a client would need to *require*
negotiation of the extended master secret extension for TLS 1.2
connections and fail to connect otherwise. How many clients do this?
How many clients have any idea whether their TLS lib supports or
enforces this? How many TLS libs even let you check this?
We must assume tls-unique is not to be trusted.
3. That leaves tls-exporter as the only secure channel binding
method.
One method doesn't need negotiation. A wise person recently said
"parameterize of security protocols and algorithms are generally a
bad
idea as it adds complexity which reduces security."
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4…
This spec in particular says to nicely ask the attacker if they
support
it before doing it... and the attacker will just say no. The XEP
handwaves this security destroying attack as a "well clients could
pin
channel bindings" not even a MAY, SHOULD, or MUST. Do any
implementations today do this? If not it is just feel good security
theater that gives absolutely no security against a MITM.
5. Is the specification accurate and clearly
written?
See #4
In summary, a XEP to negotiate channel binding with the attacker
isn't
helpful.
The only security we can get from channel binding is by *requiring*
clients to do only tls-exporter with only TLS 1.3 or QUIC. If this
fails
the client MUST pop up a warning similar to "this is an untrusted
certificate, deny/allow".
If we want a XEP that suggests the above it should be clear in the
security considerations what it prevents and what it doesn't, and how
it
compares to other things like public key pinning (DANE or '487),
likely
suggesting to do both. Roughly both public key pinning and requiring
tls-exporter channel binding both protect against a jabber.ru style
MITM
where the MITM gets their own new certificate, but does not read the
disk of the server they are attacking. Neither public key pinning
*nor*
channel binding protect against a MITM where the attacker can read
the
disk of the XMPP server and take the public key (and/or cert) and
password hashes to use for SCRAM authentication itself.
Thanks,
Travis
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:12 a.m.
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 messages in case client side requirements with
regards to channel binding are not met we need negotiation.
Furthermore I believe that even the weaker channel binding mechanisms
are better than not having them. It puts more hurdles into the
attackers way. Attackers aren’t always perfect. In the case of
jabber.ru it looked a lot like they were throwing vanilla proxy
software at the problem and not something specifically tailored to
break XMPP.
The other 'not really an attack' attack that even weak channel binding
can detect is when people for what ever reason install custom CA
certificates on the phone.
I agree that the current phrasing of the XEP with regards to
server-end-point is not the best.
cheers
Daniel
8:42 a.m.
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
8:56 a.m.
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:
And now I also have the link to the thread with the motivation that
there should be at least one common cb type:
https://web.archive.org/web/20221129011623/https://mail.jabber.org/pipermai…
(Thanks to travis for pointing out that the old ML archives are still
available via archive.org)
Note that a probably relevant remark from Dave is that
mandatory-to-implement does not automatically imply mandatory-to-deploy. :)
- Flow
- 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.
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 
7:42 a.m.
On Wed, 8 May 2024 at 02:35, Travis Burtrum <travis(a)burtrum.org> wrote:
Yes, but they do not, and no amount of saying that AWS could implement this
will cause them to do so.
So for practicality, the question becomes "assuming that tls-exporter is
not possible, as is the case in many current deployments, does recommending
tls-server-endpoint improve security", and I think it's fairly clear it
does.
Ideal? No. Improved? Yes. At least a bit.
Hi all,
On 5/6/24 1:21 PM, Daniel Gultsch wrote:
The particular attack is discussed (with some typos, and I think a slight
lack of clarity) in the Security Considerations, but actually it already
exists, so there is no effective change to security via the specification;
just a change to ease of use and adoption of better security.
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 the problem
stated in the introduction
and requirements?
It enables negotiating a feature meant to prevent/detect MITMs with the
MITM themselves.
3. Do you plan
to implement this specification in your code? If not,
why not?
MITM attack mitigation via public key pinning and tls-exporter? Yes.
This specification? No.
4. Do you have any security concerns related to
this specification?
So many.
1. it gives a MUST for servers and SHOULD for clients to implement
tls-server-end-point which is weak and likely shouldn't be implemented
at all. Note TLS-intercepting-proxies can implement the strong
tls-exporter just fine by simply passing the keying material to the
backend server. See
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/MBNEF3NMA…
for more discussion.
2. tls-unique is broken by
https://www.mitls.org/pages/attacks/3SHAKE
and "fixed" by https://datatracker.ietf.org/doc/html/rfc7627 *if* your
client-side TLS library and config meets a ton of ifs. It has to
implement the extended master secret extension *and* the server has to
negotiate this. (remember, the server here is the potential attacker, so
it would just... not).
So to securely implement tls-unique a client would need to *require*
negotiation of the extended master secret extension for TLS 1.2
connections and fail to connect otherwise. How many clients do this?
How many clients have any idea whether their TLS lib supports or
enforces this? How many TLS libs even let you check this?
We must assume tls-unique is not to be trusted.
This is all very good, but the specification does not mention tls-unique.
3. That leaves tls-exporter as the only secure channel
binding method.
One method doesn't need negotiation. A wise person recently said
"parameterize of security protocols and algorithms are generally a bad
idea as it adds complexity which reduces security."
https://mail.jabber.org/hyperkitty/list/standards@xmpp.org/thread/DFWL7RSQ4…
This spec in particular says to nicely ask the attacker if they support
it before doing it... and the attacker will just say no. The XEP
handwaves this security destroying attack as a "well clients could pin
channel bindings" not even a MAY, SHOULD, or MUST. Do any
implementations today do this? If not it is just feel good security
theater that gives absolutely no security against a MITM.
Your argument is that everyone should do everything. For what it's worth, I
broadly agree that this is a desirable end-goal.
However, getting There from Here is the problem this specification is
attempting to address.
The specification says - quite clearly, though I agree it could be improved
- that a client might try using tls-exporter whether it's advertised or
not. So if you want to do what you're describing, the specification doesn't
preclude that, and that's a good thing.
But for the vast majority of cases, clients might be avoiding tls-exporter
because it might give an error during authentication.
SCRAM can actually tell you that the authentication failed because the
channel-binding type is not supported - but an active attacker can spoof
that just as well as this specification, with exactly the same ease, so I
think it's important to note that the security is the same with or without
this specification - but it might help adoption.
Dave.
8:42 a.m.
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 material". You are correct that tls-server-end-point
has issues. However, using tls-exporter with TLS-intercepting proxies is
not immediately available. As you write in the linked mailing list
thread, it requires extensions to the protocol.
You write that 3SHAKE and SLOTH break tls-unique and that tls-unique
should be only used if the extended master secret extension has been
negotiated. This is also correct and the reason why most specifications
require tls-unique to be only used when the extended master secret
extension has been negotiated.
Ultimately, you should use tls-exporter with TLS 1.3 and nothing else. I
think it is fair to say that we both agree on this.
However, the idealized world often does not match the real world.
Displaying a "this is an untrusted certificate" on every connection that
does *not* use tls-exporter and TLS 1.3 is probably not sensible at the
moment. I hope that it will be in the future, though. I've been told
that around 90% of all connections to jabber.fr are already using TLS
1.3. However, the availability of APIs that allow to obtain the
tls-exporter data from your TLS implementation is probably the major
obstacle for adoption.
Therefore, if you want to provide channel binding, you have to consider
other channel-binding mechanisms. Even weaker channel binding mechanisms
than tls-exporter raise the bar for MiTM attacks.
Under this assumption, I believe the best thing we can currently provide
is xep440.
Yes, you interact with a potential MiTM when doing xep440 feature
negotiation. The only way around that would be to move the functionality
provided by xep440 down to the TLS level. Unfortunately, there is no
specification for this. And under those constraints, pinning is the only
left defensive measure. Pinning narrows the time window of a MiTM attack
significantly, reducing the number of potential victims.
Note that xep440 does not prevent clients from implementing more secure
strategies, like always attempting tls-exporter first and then pinning
tls-exporter once it is successful.
In summary, even though it is not ideal, there is value in xep440.
- Flow
7:03 a.m.
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 consider it part of the Last Call.
Dave.
On Mon, 6 May 2024 at 18:22, Daniel Gultsch <daniel(a)gultsch.de> wrote:
This message constitutes notice of a Last Call for
comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2024-05-20.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8:12 a.m.
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 about tls-end-point where we don't make it clear
that it provides vastly different security properties than unique
mechanisms like tls-unique and tls-exporter).
I also strongly agree with Dave that we should run this by KITTEN first;
asking the advice of the experts seems pertinent.
Overall I'm not against having a way to do this negotiation: if
tls-exporter starts showing signs of weaknesses it's probably good to
have a way to quickly update. But I'm somewhat against this document
making recommendations for compatibility and would prefer that to exist
elsewhere (probably somewhere we can update quicker than a standards
track XEP if future problems arise; maybe we should have a "how to use
TLS with XMPP" informational spec of our own at some point?
Finally, I'd like to see a trust-on-first-use model added to the spec.
If we're going to do this, the client may want to cache the mechanism
list on the first connection to the server and fail if that list is
downgraded in the future, or something along those lines.
TL;DR — overall I'm not against the general idea, but I don't think this
spec is ready for last call yet.
—Sam
[1]: actually, it looks like tls-exporter isn't even a SHOULD, it's a
"should". That SHOULD probably be fixed :)
On 2024-05-06 13:21, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for
comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2024-05-20.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Sam Whited
sam(a)samwhited.com
12:09 p.m.
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] https://www.rfc-editor.org/rfc/rfc7590.html
193
days inactive
195
days old
13 comments
8 participants
participants (8)
-
Daniel Gultsch -
Dave Cridland -
Florian Schmaus -
Marvin W -
Peter Saint-Andre -
Sam Whited -
Thilo Molitor -
Travis Burtrum