[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

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

[Standards] Re: LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

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

[Standards] Re: Feedback requested: SVCB for XMPP

Hi Dave! I've only briefly reviewed this so far, so please forgive if I've missed things, but I have some early comments: Major blocker I'm not sure can be addressed: 1. This essentially re-introduces the major security flaw that was addressed in XEP-0156 by removing the TXT record, just

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

Hi Dave! On 12/27/23 04:12, Dave Cridland wrote: I dislike this XEP intensely. But... I think it's probably the most pragmatic solution that fits the existing standards space. Honestly... Nice summary of my opinion too. :) We need things, sadly we don't live in an ideal world, and this

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

Hi Fannys! On 12/16/23 04:06, Fannys wrote: As I said in the @xsf room the problem with this XEP is that the author is convinced that this is the one answer to everything and assumes a *lot* of stuff to get there. And besides the title obviously that is obvious in a few other places. To try

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

Apologies for the delay on this, but I finally have an update: On 12/15/23 23:00, Travis Burtrum wrote: Lastly I was asked to contact to XEP-0156 authors to see how they'd feel about this updating '156 instead of being it's own XEP I emailed stpeter directly and he responded promptly, thanks

[Standards] Re: XEP-0440 and tls-server-end-point

On 1/11/24 10:37, Dave Cridland wrote: On Thu, 11 Jan 2024 at 12:39, Holger Weiß > wrote: * Simon Josefsson mailto:si...@josefsson.org>> [2024-01-11 13:10]: >I believe tls-server-end-point is generally best left unimplemented to >guide

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

Hi all, Quick summary of this ProtoXEP: It's intended to be the single new de-facto way all servers and clients look up connection info to connect to servers. It was clear from the feedback that this ProtoXEP needed an extensive rationale section explaining why other alternatives aren't

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

Jun 6, 2023 4:31:54 PM Dave Cridland : > > On Thu, 4 May 2023 at 15:06, wrote: >> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been >> released. > > This is weirdly horrible. Me too, but it's not council's job to police the protocol, what gets widely used is decided by running

Re: [Standards] Channel binding and token authentication

Sep 26, 2022 7:42:48 AM Kevin Smith : > -- Original Message -- > From: "Matthew Wild" > To: "XMPP Standards" > Sent: 26/09/2022 18:24:37 > Subject: [Standards] Channel binding and token authentication > >> Does anyone have objections to proceeding with the definition of one >> or more

Re: [Standards] Proposed XMPP Extension: Events

I don't think we should be accepting XEPs without "Security Considerations" being filled in. Any chance that could be done before voting starts? Sep 23, 2022 5:52:36 AM Jonas Schäfer (XSF Editor) : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Events >

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

this issue. I would go even farther and note that DNS TXT records were never a great idea for this functionality (they're actively discouraged in the DNS community for application-level uses like this). On 2/9/22 4:29 PM, Travis Burtrum wrote: Hi all, The long story short (is outside

Re: [Standards] Danish chains too short

On 2/12/22 08:02, Dave Cridland wrote: On Thu, 10 Feb 2022 at 04:46, Travis Burtrum We should instead specify in a best practice document for DANE+XMPP that only DANE-EE(3) should be supported/used. Because? Because as you've pointed out DANE-TA(2) has numerous downsides

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

PR implementing my proposal https://github.com/xsf/xeps/pull/1158 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] Danish chains too short

On 1/30/22 11:38, Dave Cridland wrote: But the default choice to maximize interop should be to include the trust anchor. 1) Do people agree? No. Because... 2) If so, where on earth should we specify this? (A Best Practice doc on PKIX/DANE?) We should instead specify in a best practice

Re: [Standards] XEP-0156 _xmppconnect is vulnerable to MITM

Issues I know about right now: https://github.com/processone/docs.ejabberd.im/issues/113 https://github.com/JustOxlamon/TwoRatChat/issues/2 https://github.com/poVoq/converse_wp/issues/2 https://github.com/BombusMod/BombusMod/issues/130

[Standards] XEP-0156 _xmppconnect is vulnerable to MITM

Hi all, The long story short (is outside of DNSSEC) it's impossible to use _xmppconnect TXT records to securely connect to BOSH or WebSockets. Every client I've been able to find that supported this is vulnerable to trivial MITM (Man-In-The-Middle) via DNS spoofing.  If you have a client

[Standards] Proposed XEP-0060 Changes

Hi all, A change to XEP-0060 has been proposed: https://github.com/xsf/xeps/pull/1126/files 2 out of 3 parts are editorial in nature, the one part that is a potential concern takes the current sentence: > After receiving the configuration form, the owner SHOULD submit a completed

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

On 2/11/20 11:29 AM, Jonas Schäfer (XSF Editor) wrote: > 1. What software has XEP-0368 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final.

Re: [Standards] Council Minutes 2019-07-10

On 7/19/19 7:52 AM, Florian Schmaus wrote: > On 19.07.19 07:36, Travis Burtrum wrote: >>> If the initiating party cannot connect via either SRV record, it >> SHOULD perform A/ fallback to port(s) of it's choice (perhaps 443, >> 5223, etc) because, in the absence of DN

Re: [Standards] Council Minutes 2019-07-10

Hi all, On 7/17/19 9:57 AM, Tedd Sterr wrote: > *3b) PR #796 - XEP-0368: clarify what happens when a `.` target is > published* - https://github.com/xsf/xeps/pull/796 > Jonas: +1 > Link: +1 (definitely!) > Georg: +1 (this is just a clarification of RFC 2782) > Dave: [pending] > Kev: [pending]

Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?

On June 30, 2019 12:32:07 PM EDT, Ralph Meijer wrote: >Do you know which server implementations currently support both TLS and >non-TLS (with STARTLS) on the same port? If you put sslh in front of them, all servers do. Try burtrum.org:443 for instance.

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

On 3/13/19 12:55 PM, Ralph Meijer wrote: On 13/03/2019 15.09, Travis Burtrum wrote: On 3/13/19 3:40 AM, Philipp Hörist wrote: Whats the use case for this XEP? Until now i only needed DNS querys to connect to the XMPP Server, i see this XEP is not helping with that as it already needs

Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

On 3/12/19 4:08 PM, Jonas Schäfer (XSF Editor) wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: DNS Queries over XMPP (DoX) Thanks Jonas! If anyone wants to poke at a JID running this feel free to send queries to d...@moparisthebest.com/listener which is

Re: [Standards] XMPP Council Agenda 2018-05-16

Hi all, On 05/15/2018 11:17 AM, Dave Cridland wrote: > 3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX) FYI I have updated this here to address some early feedback: https://github.com/xsf/xeps/pull/633 https://burtrum.org/hacx/ Thanks, Travis

Re: [Standards] Council Agenda 2018-05-09

Hello, On 05/09/2018 06:58 AM, Dave Cridland wrote: > 3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX) > > Title: XMPP Connections across HTTPS (HACX) > Abstract: > This specification defines a procedure to look up various connection > methods for an XMPP server over HTTPS, with a

Re: [Standards] Proposed XMPP Extension: XMPP Connections across HTTPS (HACX)

On 05/03/2018 11:06 AM, Sam Whited wrote: > On Thu, May 3, 2018, at 07:26, Jonas Wielicki wrote: >> URL: https://xmpp.org/extensions/inbox/hacx.html > > This appears to have significant overlap with the HTTP mechanism from > XEP-0156: Discovering Alternative XMPP Connection Methods, but I don't

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

Hi Jonas, On 04/30/2018 07:20 AM, Jonas Wielicki wrote: > What do you think about the independent extension to the text I proposed in > https://github.com/xsf/xeps/pull/625 ? These two requirements: - Services SHOULD allow operators to delete all files of a specific user. - Services

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

On 04/27/2018 02:39 AM, Jonas Wielicki wrote: > On Freitag, 27. April 2018 04:59:25 CEST Travis Burtrum wrote: >> Many implementations don't even track who uploaded what, isn't that >> better? No records, no problems? > > No. It’s not about the association, it’s

Re: [Standards] XEP-0363 (HTTP Upload): Privacy Considerations & Deletion

On 04/26/2018 10:35 AM, Jonas Wielicki wrote: > As it turns out, several implementations are making it not trivial for > operators to be GDPR compliant. One of the things definitely necessary (as > far > as our understanding goes) is that users must be able to have their data > deleted in a

Re: [Standards] Proper SRV Record Fallback

Hi Jonas, Thanks for resurrecting the thread. And nice work with aioxmpp! On 03/19/2018 03:24 PM, Jonas Wielicki wrote: > - authentication failures are treated as fatal and abort everything > immediately. You mean username/password errors? Not TLS certificate authentication errors, just to

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

At which point it's no longer P2P and you might as well use https, which also works with multiple clients unlike P2P/turn. On February 24, 2018 12:07:51 PM EST, Evgeny Khramtsov <xramt...@gmail.com> wrote: >Sat, 24 Feb 2018 11:24:39 -0500 >Travis Burtrum <tra...@bur

Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234

Unfortunately you also can't reasonably expect P2P to work today in most cases because everyone is behind a NAT including most mobile phone networks. So https is still your best bet, and since most servers support http upload it's already done for you. On February 24, 2018 3:12:30 AM EST,

Re: [Standards] Proper SRV Record Fallback

Hello, My replies in-line as well. On 01/10/2018 03:20 AM, Jonas Wielicki wrote: > Hi Travis, > > Notes inline. > > On Montag, 8. Januar 2018 23:19:36 CET Travis Burtrum wrote: >> First, what do docs say: >> >> RFC-6120[2] Section-3.2.1 #7 says: >>> 7.

Re: [Standards] Proper SRV Record Fallback

On 01/10/2018 07:59 AM, Holger Weiß wrote: > * Travis Burtrum <tra...@burtrum.org> [2018-01-09 21:28]: >> Is there any reason why any client would rather fail and show a 'cannot >> connect' to a user rather than actually allowing them to connect? > > The standar

Re: [Standards] Proper SRV Record Fallback

On 01/10/2018 01:34 AM, Evgeny Khramtsov wrote: > Rephrasing, the question about what to consider a success connection. > We have several phases of stream negotiation (not to mention mam or > roster queries). Ah right. Well I think maybe the username+password step might be a good cut-off for

Re: [Standards] Proper SRV Record Fallback

On January 10, 2018 12:55:06 AM EST, Evgeny Khramtsov <xramt...@gmail.com> wrote: >Tue, 9 Jan 2018 21:28:55 -0500 >Travis Burtrum <tra...@burtrum.org> wrote: > >> Is there any reason why any client would rather fail and show a >> 'cannot connect' to a user r

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 03:58 PM, Marcel Waldvogel wrote: > Is there a mechanism a client can determine whether ALPN is needed for a > particular SRV entry? (Besides guessing based on the port number) No. In fact it wouldn't even fit on a SRV record level. For instance I have 1 SRV record pointing to

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 05:55 AM, Florian Schmaus wrote: > On 09.01.2018 05:19, Travis Burtrum wrote: >> It is also clear I didn't think about this too hard when writing >> XEP-0368, because I clearly (to me) assume SRV fallback will happen if a >> complete XMPP connection is not succ

Re: [Standards] Proper SRV Record Fallback

On 01/09/2018 05:03 AM, Dave Cridland wrote: > On 9 January 2018 at 04:19, Travis Burtrum <tra...@burtrum.org> wrote: >> In my opinion, at least all of cannot-connect-to-port, non-XML, >> not-proper-stream and invalid TLS cert should trigger a fallback to the >> next

[Standards] Proper SRV Record Fallback

Hi all, I have not been able to find proper SRV record fallback behavior documented, and could not come to a clear consensus in the XSF MUC earlier, so I thought I'd bring the discussion on-list. (and hopefully document it in implementation notes of XEP-0368[1]) The main question is when you

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

On 09/22/2017 08:39 AM, Dave Cridland wrote: > a) I query whether ALPN needs to be SHOULD rather than MAY, > particularly for S2S cases. That very well could be. I'll give you the background, and the exact wording can be discussed. ALPN is only required for easy multiplexing multiple services

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

On 09/19/2017 12:04 PM, Jonas Wielicki wrote: > Dear list, > > With my XEP Editor hat on, we’d like to issue a Call for Experience for > XEP-0368. This is the step taken before proposing advancement of a XEP to > Final status to Council. > > > During the Call for Experience, please answer the

Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks

On 03/30/2017 08:47 AM, Andreas Straub wrote: > GCM also isn't > quite as easily available on some platforms as we'd like, whereas CBC > and HMAC are pretty much ubiquitous. The HTTP/2 spec mandates support of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [1] and I'd guess HTTP/2 is already supported

Re: [Standards] Deprecating Privacy Lists (again)

Hi all, On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote: > List allows you creating overriding allow entry which will unblock > single person while keeping the group blocked (order matters). So does keeping the UI option to block a whole group, and then just using the blocking command to

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 02/15/2017 05:54 AM, Kim Alvefur wrote: > As for security, I'm concerned that the added complexity of mixing > STARTTLS and Direct TLS will lead to security problems. Doing it one way > or the other has, as have been noted before, mostly equivalent security > properties, but doing both seems to

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 02/15/2017 02:48 AM, Ruslan N. Marchenko wrote: > Ideally I'd like loadbalancer to offload both tls and stream > negotiation, to filter out stream-flood (similar to syn-flood) - eg. > pass/relay connection to the pool only once initial handshake is > complete (stream/to + tls/SAN). That allows

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 02/14/2017 02:00 PM, Ruslan N. Marchenko wrote: > It has nothing to do with port reuse, rather service binding. When I'm > thinking how many ports I need to open on firewall to allow simple mail > exchange - it just makes me feel sad an sorry for all the people who > developed those standards.

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 02/13/2017 04:43 PM, Ruslan N. Marchenko wrote: > Yes, and that's what written as XEP's use-case - how to abuse corporate > firewall by masking im/p2p software to legitimate business traffic (https). > This is not fair, and if I were CSO who found out such "use-case" in the > network I'd just

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 02/13/2017 02:26 PM, Ruslan N. Marchenko wrote: > So security here will be just in the sense "all or nothing" - > either you pass through (non-paranoid) or not (paranoid). That's not true though, there are firewalls in practice today that only allow HTTP on port 80, and only TLS on port 443,

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

Boy am I glad you missed the last call deadline by a day so I don't have to address your concerns. :) On 02/12/2017 11:03 AM, Sam Whited wrote: > A minor nitpick: The requirements section isn't really requirements, > it's the actual main content of the spec. Someone mentioned that before but

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 01/30/2017 12:43 AM, Daurnimator wrote: >> 5. Is the specification accurate and clearly written? > > No. > > The stuff in 'requirements' are not requirements but implementation > instructions > >> When ALPN is used protocol MUST be 'xmpp-client' where 'xmpps-client' is the >> SRV

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

On 01/28/2017 01:21 PM, Evgeny Khramtsov wrote: > I think the sentence: > >> ALPN (RFC 7301) requires registration of the new Protocol IDs, >> 'xmpp-client' and 'xmpp-server', specified in this document > > is incorrect, because 'xmpp-client' and 'xmpp-server' are not Protocol > IDs, but

Re: [Standards] Advance XEP-0368 to Proposed

On 01/24/2017 10:20 AM, Sam Whited wrote: > I agree with Zash, they're equivalant; 6120 says > that even if STARTTLS isn't advertised you should attempt it, and this > is the same thing. Falling back to plain is a bad idea, but it's a > matter of client policy. I still disagree, I know in the

Re: [Standards] Advance XEP-0368 to Proposed

On 01/24/2017 08:08 AM, Kim Alvefur wrote: > On Thu, Jan 19, 2017 at 03:19:12PM -0500, Travis Burtrum wrote: >> I am proposing advancing XEP-0368 from Experimental to Proposed, and the >> XSF MUC said to do this by sending an email to the standards list. >> >> https://x

Re: [Standards] Advance XEP-0368 to Proposed

Hello, Thanks for the comments, I'll address these in-line: On 01/19/2017 05:11 PM, Dave Cridland wrote: > 1) SNI really needs to be a MUST rather than a SHOULD. It's the moral > equivalent to having a "to" in the stream open for the pre-TLS > STARTTLS case, which is also mandated as of RFC

[Standards] Advance XEP-0368 to Proposed

Hi all, I am proposing advancing XEP-0368 from Experimental to Proposed, and the XSF MUC said to do this by sending an email to the standards list. https://xmpp.org/extensions/xep-0368.html It's been a bit over a year, no one has suggested any changes to me. There is at least one client

Re: [Standards] JingleFT XEP encryption conflicts

On 01/03/2017 06:19 PM, Lance Stout wrote: > E2E security in Jingle can be negotiated in three different places: > > 1) As part of the application > 2) As part of the transport > 3) As an additional layer between the transport and the application So #3 has no currently defined XEPs or RFCs?

[Standards] JingleFT XEP encryption conflicts

Hello all, I noticed https://xmpp.org/extensions/xep-0234.html#security says: In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For example, end-to-end encryption can be negotiated over either SOCKS5 Bytestreams or

Re: [Standards] Images in chat

Hello Peter, Just pointing out that Conversations does encrypt the file before uploading it to the HTTP server in a way that matches the encryption being used in the current chat. This keeps the trust in the HTTP server the exact same as the trust in the XMPP server. For example in a XEP-0027

Re: [Standards] Markdown in XMPP IM

On 01/06/2016 08:00 AM, Peter Waher wrote: > Sending markdown encoded as markdown has several benefits. But also many downsides, there is not really such a thing as a markdown standard. There are different 'flavors', such as github-flavored-markdown, and then there are just major/minor

Re: [Standards] Markdown in XMPP IM

On 01/06/2016 12:53 PM, Ashley Ward wrote: > text/x-markdown Except markdown means nothing, there is no standard, and no common implementation. I love markdown, but just because your markdown converts with your tool to a format you want, doesn't mean anyone else can get that same output with any

Re: [Standards] Markdown in XMPP IM

On 01/05/2016 10:49 AM, Peter Waher wrote: > But instead of sending markdown as simple text in a normal > message, I would like to mark it as such and provide an unformatted text > version (with any markdown formats removed) as well, much like how > HTML-IM works. Isn't the point of markdown that

Re: [Standards] NEW: XEP-0368 (SRV records for XMPP over TLS)

On 12/15/2015 03:58 PM, XMPP Extensions Editor wrote: > URL: http://xmpp.org/extensions/xep-0368.html I made the requested updates, sending the JID domain-part as the SNI name, and changing the SRV names to _xmpps-*._tcp from _xmpp-*._tls. I also elaborated a bit more on the security/privacy

Re: [Standards] Proposed XMPP Extension: SRV records for XMPP over TLS

On 12/09/2015 05:58 AM, Dave Cridland wrote: > - The SRV label form probably ought to follow the precedent set by RFC > 6186, even though I think that's uglier. I am fine with changing the SRV format from the current _xmpp-client._tls/_xmpp-server._tls to _xmpps-client._tcp/_xmpps-server._tcp

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2015 06:20 PM, Tomasz Sterna wrote: > Dnia 2015-11-09, pon o godzinie 17:33 -0500, Travis Burtrum pisze: >> That seems like a ridiculous question to me. If not, why even bother >> with STARTTLS/TLS in the first place? It

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/09/2015 02:46 PM, Tomasz Sterna wrote: > Isn't smart proxy like sslh[1] better suited for the use case? > > > [1] http://www.rutschle.net/tech/sslh.shtml Which use case? I actually do use sslh on my port 443, because I wrote a patch to let

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/09/2015 05:22 PM, Tomasz Sterna wrote: > Dnia 2015-11-09, pon o godzinie 15:29 -0500, Travis Burtrum pisze: >> accepting raw xmpp along with https on 443 is not a good option >> because it's obviously xmpp and can be tr

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/06/2015 08:24 AM, Kim Alvefur wrote: > On 2015-11-06 11:28, Georg Lukas wrote: >> * Travis Burtrum <tra...@burtrum.org> [2015-11-05 20:56]: >>> That was a deliberate decision on my part, and does not affect >

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/06/2015 05:28 AM, Georg Lukas wrote: > So lets assume I want to connect as ge...@example.com and the SRV > record is > > _xmpp-client._tls.example.com. IN SRV 5 1 443 xmpp.example.com. > > My client then makes a TCP connection to

[Standards] ProtoXEP: SRV records for XMPP over TLS

This proposal defines a procedure to look up _tls SRV records in addition to _tcp and mix weights/priorities. Rendered version can be found at https://burtrum.org/xeps/tls-srv.html This discussion was already started on a github pull request here: https://github.com/xsf/xeps/pull/116 but was

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

Hello Peter, On 11/05/2015 01:27 PM, Peter Saint-Andre wrote: > I haven't yet had time to look at your proposal in detail. However, > there is no _tls Protocol name in RFC 2782 or RFC 6335. It seems strange > for us to be the only ones using that non-standard value. At least Microsoft Lync and

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Georg, On 11/05/2015 02:21 PM, Georg Lukas wrote: > 6. Client or server SHOULD set SNI TLS extension to the host in the > SRV record. > > Is that a deliberate decision or just inappropriate wording? That was a deliberate decision on my

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

On 11/05/2015 03:02 PM, Philipp Hancke wrote: > turns out I was wrong about Lync which uses >_sipfederationtls._tcp > to achieve this. It looks like lync uses both _sip._tls and _sipfederationtls._tcp: https://technet.microsoft.com/en-us/library/gg412787%28v=ocs.15%29.aspx On 11/05/2015

Re: [Standards] ProtoXEP: SRV records for XMPP over TLS

Hello Dave, On 11/05/2015 04:09 PM, Dave Cridland wrote: > 2) I'm a little concerned that this may be somewhat out of scope for the > XSF; in particular, it might be better discussed within the IETF and > reformulated as an Internet Draft (and ultimately an RFC). I can tell > you how to go about