Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019, at 20:33, Kim Alvefur wrote: > You can detect it, it's advertised in DNS. The point of this is a fallback in case it's not advertised in DNS. > Since a common use case of Direct TLS is to put it on port 443, why > don't you also probe that port? That might be a good idea too. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Voting Summary 2019-06-30
2019-06-12 (expired 2019-06-26) VETOED (-1:0:+4) Last Call: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) - https://xmpp.org/extensions/xep-0300.html Dave: +1 Georg: -1 (pretty sure +1, but would like a quick glance to confirm) Jonas: +1 Kev: +1 (may as well) Link: +1 (with a few small nits) 2019-06-19 (expiring 2019-07-03) Last Call: XEP-0300 (Use of Cryptographic Hash Functions in XMPP) - https://xmpp.org/extensions/xep-0300.html Dave: +1 Georg: +1 (maybe Table 1 belongs in some kind of registry, but as long as we have a way forward when this is Final and somebody invents a new hash function) Jonas: +1 Kev: [pending] Link: +1 PR #793 - XEP-0166: Relax transport element requirement - https://github.com/xsf/xeps/pull/793 Dave: -1 (pending review) Georg: -1 (needs significant discussion and review by implementors using Jingle) Jonas: [on-list] Kev: [pending] Link: [on-list] 2019-06-26 (expiring 2019-07-10) Proposed XMPP Extension: Stanza Content Encryption - https://xmpp.org/extensions/inbox/xep-sce.html Dave: +1 Georg: +1 Jonas: +1 Kev: [on-list] Link: [on-list] Last Call: XEP-0353 (Jingle Message Initiation) - https://xmpp.org/extensions/xep-0353.html Dave: +1 Georg: +1 Jonas: +1 Kev: [pending] Link: +1 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019 at 06:23:36PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote: > > Please don't. While detecting use of TLS or plain is fairly simple it > > is more complicated to handle both on the same port. I don't know any > > socket handling framework that makes this easy. Usually the TLS > > library takes over the socket and if you inspected the first bytes > > then it fails. > > You don't have to support them both on the same port necessarily, but > since I can't detect if you support it or not I don't have many options > other than to just try it. You can detect it, it's advertised in DNS. Since a common use case of Direct TLS is to put it on port 443, why don't you also probe that port? -- Zash signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Leading and trailing spaces in resourceparts
Hi, Thanks, next time i will read also the errata :) Regards Philipp Am So., 30. Juni 2019 um 21:44 Uhr schrieb Sam Whited : > On Sun, Jun 30, 2019, at 19:12, Philipp Hörist wrote: > > I tried to test against the examples in > > https://tools.ietf.org/html/rfc7622#section-3.5 > > and found that my tests fail for the example > > The document goes on mentioning the JID beeing illegal because leading > > spaces are illegal. > > This is a verified problem, see errata 4560: > > https://www.rfc-editor.org/errata/eid4560 > > —Sam > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Leading and trailing spaces in resourceparts
On Sun, Jun 30, 2019, at 19:12, Philipp Hörist wrote: > I tried to test against the examples in > https://tools.ietf.org/html/rfc7622#section-3.5 > and found that my tests fail for the example > The document goes on mentioning the JID beeing illegal because leading > spaces are illegal. This is a verified problem, see errata 4560: https://www.rfc-editor.org/errata/eid4560 —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Leading and trailing spaces in resourceparts
Hi, I tried to test against the examples in https://tools.ietf.org/html/rfc7622#section-3.5 and found that my tests fail for the example The document goes on mentioning the JID beeing illegal because leading spaces are illegal. My question is rather simple, where is this rule documented? rfc7622 mandates to apply the PRECIS-OpaqueString profile to resources, which does not enforce a mapping for spaces to none at start and end. There is a PRECIS-Nickname profile which does, but its not mentioned in the document. regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019, at 18:15, Kim Alvefur wrote: > Please don't. While detecting use of TLS or plain is fairly simple it > is more complicated to handle both on the same port. I don't know any > socket handling framework that makes this easy. Usually the TLS > library takes over the socket and if you inspected the first bytes > then it fails. You don't have to support them both on the same port necessarily, but since I can't detect if you support it or not I don't have many options other than to just try it. > Trying direct TLS on a starttls port will usually result in garbage > being fed to the XML parser, which leads to very loud error messages, > possibly even including thing garbage. That seems like a terrible (and possibly dangerous) thing for a framework to do. If this is true I'd argue that your XML parser or server is broken. —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean?in?_xmpps-client/server records?
On Sun, Jun 30, 2019 at 04:55:47PM +, Sam Whited wrote: > On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote: > > Do you know which server implementations currently support both TLS > > and non-TLS (with STARTLS) on the same port? > > I'm sure if any of them do, but the fallback would still be useful in > case the service is only configured to support direct TLS on the > regular port. Please don't. While detecting use of TLS or plain is fairly simple it is more complicated to handle both on the same port. I don't know any socket handling framework that makes this easy. Usually the TLS library takes over the socket and if you inspected the first bytes then it fails. Trying direct TLS on a starttls port will usually result in garbage being fed to the XML parser, which leads to very loud error messages, possibly even including thing garbage. I's annoying enough when some clients do this, don't legitimize it. -- Regards, Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 16:32, Ralph Meijer wrote: > Do you know which server implementations currently support both TLS > and non-TLS (with STARTLS) on the same port? I'm sure if any of them do, but the fallback would still be useful in case the service is only configured to support direct TLS on the regular port. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 5:20:09 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: >> Hmm. On which port? I want to point out explicitly that although 5223 >> has been used a bunch since before the IETF standardization, IANA has >> assigned it to some HP management service. Hence my other proposal, >> which is still currently unregistered. > >5222, assuming a client connection, probably. If we ever got a port >registered for xmpps-client, I'd probably switch it to that. Although >right now it seems fine to do both on 5222. Do you know which server implementations currently support both TLS and non-TLS (with STARTLS) on the same port? -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 15:16, Ralph Meijer wrote: > Hmm. On which port? I want to point out explicitly that although 5223 > has been used a bunch since before the IETF standardization, IANA has > assigned it to some HP management service. Hence my other proposal, > which is still currently unregistered. 5222, assuming a client connection, probably. If we ever got a port registered for xmpps-client, I'd probably switch it to that. Although right now it seems fine to do both on 5222. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 5:07:08 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote: >> Just to be clear, in the same way as for xmpp-client, as per RFC >2782? > >I think so; I meant by fetching the A/ record of the domain part of >the JID, and then attempting to perform direct TLS if a connection is >established. Then again, if an attacker can poison my DNS to send me a >"." SRV record, they can probably mess with the A/ records too so I >suppose it doesn't matter all that much. > >Either way, if a connection is made at some point I'll probably try >direct TLS whether it was advertised or not. Hmm. On which port? I want to point out explicitly that although 5223 has been used a bunch since before the IETF standardization, IANA has assigned it to some HP management service. Hence my other proposal, which is still currently unregistered. -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 14:58, Ralph Meijer wrote: > Just to be clear, in the same way as for xmpp-client, as per RFC 2782? I think so; I meant by fetching the A/ record of the domain part of the JID, and then attempting to perform direct TLS if a connection is established. Then again, if an attacker can poison my DNS to send me a "." SRV record, they can probably mess with the A/ records too so I suppose it doesn't matter all that much. Either way, if a connection is made at some point I'll probably try direct TLS whether it was advertised or not. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 4:45:40 PM GMT+02:00, Sam Whited wrote: >On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote: >> 1) It's not A/ fallback "as per RFC 6120", because we're talking >>about a Direct TLS fallback. It should be per section... erm... >> 2) This document doesn't mention a A/ fallback at all, and >perhaps >>that's right - do we ever want one with '368? >> > Please comment on-list. > >I've been meaning to change my library to do its fallback a little >differently, including trying direct TLS fallback A/ fallback. DNS >often doesn't use any sort of security measures, so to prevent DNS >based >downgrade attacks it seems best to me to always try direct TLS on the >A/ record, just as we always try StartTLS even if it's not >advertised. Just to be clear, in the same way as for xmpp-client, as per RFC 2782? -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, Jun 30, 2019, at 09:54, Dave Cridland wrote: > 1) It's not A/ fallback "as per RFC 6120", because we're talking >about a Direct TLS fallback. It should be per section... erm... > 2) This document doesn't mention a A/ fallback at all, and perhaps >that's right - do we ever want one with '368? > > Please comment on-list. I've been meaning to change my library to do its fallback a little differently, including trying direct TLS fallback A/ fallback. DNS often doesn't use any sort of security measures, so to prevent DNS based downgrade attacks it seems best to me to always try direct TLS on the A/ record, just as we always try StartTLS even if it's not advertised. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On June 30, 2019 11:53:39 AM GMT+02:00, Dave Cridland wrote: > [..] >OK, two comments, which are essentially both my fault: > >1) It's not A/ fallback "as per RFC 6120", because we're talking >about >a Direct TLS fallback. It should be per section... erm... >2) This document doesn't mention a A/ fallback at all, and perhaps >that's right - do we ever want one with '368? I think we should have a fallback, though. RFC 2782, in the section about "Usage rules", clearly specifies the resolution procedure, which includes a fallback using A/ records. E.g. in Twisted, SRV resolution is protocol agnostic, and behalves as in the RFC. Also, and more importantly, I think it is good for consistency. I believe this also means that when we register the service name with IANA, we have to provide a port number. I suggest 5857, and leave the "why this one?" as an exercise to the reader. -- Cheers, ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Sun, 30 Jun 2019 at 09:40, Jonas Schäfer wrote:
> On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> > On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> > >
> > > jo...@wielicki.name> wrote:
> > > >Hi list,
> > > >
> > > >It is not clear to me how to interpret, in a library connecting to an
> > > >XMPP
> > > >service, a single SRV record for _xmpps-{client,server} which has `.`
> > > >as the
> > > >target.
> > > >
> > > >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> > > >`.`
> > > >indicates that the domain does not host an XMPP service at all, so
> > > >attempting
> > > >to form a connection should stop right there (most notably, no
> fallback
> > > >to
> > > >domainpart A/ lookup).
> > > >
> > > >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> > > >do not
> > > >speak direct TLS, but try _xmpp-client records"? Or should it
> indicate,
> > > >right
> > > >away, that there is no XMPP service on the domain?
> > >
> > > According to RFC 2782 it means the service xmpps-client is not
> available
> > > at this domain. So I think the answer should be the former. If there
> is a
> > > similar record for xmpp-client, though, you can't connect the regular
> way
> > > either. Maybe there's still another binding (BOSH, WebSocket) that
> could
> > > succeed, but
> > > defining all possible permutations is a bit much.
> >
> > I think:
> >
> > 1) A client ought to, if possible, send the two DNS queries in parallel.
> > 2) If this isn't the case, there's no "right" order.
> > 3) Therefore it'd be possible to obtain some records from _xmpp-client,
> but
> > afterward get a '.' from _xmpps-client.
> > 4) Therefore the only sensible interpretation is that it says direct TLS
> > (xmpps-client) is not supported, and says nothing about the traditional
> > method (xmpp-client).
> >
> > > >Whatever the consensus is, this should be written down in the XEP I
> > > >think.
> > >
> > > Agreed.
> >
> > I'm always for documenting things.
> >
> > May as well note here that the '.' target explicitly prevents use of the
> > fallback A/ resolution.
>
> Thanks for your feedback folks.
>
> Here’s a proposal: https://github.com/xsf/xeps/pull/796
>
>
OK, two comments, which are essentially both my fault:
1) It's not A/ fallback "as per RFC 6120", because we're talking about
a Direct TLS fallback. It should be per section... erm...
2) This document doesn't mention a A/ fallback at all, and perhaps
that's right - do we ever want one with '368?
> Please comment on-list.
>
> kind regards,
> Jonas___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0368: What does a . for a target mean in _xmpps-client/server records?
On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> On Sat, 29 Jun 2019 at 16:56, Ralph Meijer wrote:
> > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> >
> > jo...@wielicki.name> wrote:
> > >Hi list,
> > >
> > >It is not clear to me how to interpret, in a library connecting to an
> > >XMPP
> > >service, a single SRV record for _xmpps-{client,server} which has `.`
> > >as the
> > >target.
> > >
> > >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> > >`.`
> > >indicates that the domain does not host an XMPP service at all, so
> > >attempting
> > >to form a connection should stop right there (most notably, no fallback
> > >to
> > >domainpart A/ lookup).
> > >
> > >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> > >do not
> > >speak direct TLS, but try _xmpp-client records"? Or should it indicate,
> > >right
> > >away, that there is no XMPP service on the domain?
> >
> > According to RFC 2782 it means the service xmpps-client is not available
> > at this domain. So I think the answer should be the former. If there is a
> > similar record for xmpp-client, though, you can't connect the regular way
> > either. Maybe there's still another binding (BOSH, WebSocket) that could
> > succeed, but
> > defining all possible permutations is a bit much.
>
> I think:
>
> 1) A client ought to, if possible, send the two DNS queries in parallel.
> 2) If this isn't the case, there's no "right" order.
> 3) Therefore it'd be possible to obtain some records from _xmpp-client, but
> afterward get a '.' from _xmpps-client.
> 4) Therefore the only sensible interpretation is that it says direct TLS
> (xmpps-client) is not supported, and says nothing about the traditional
> method (xmpp-client).
>
> > >Whatever the consensus is, this should be written down in the XEP I
> > >think.
> >
> > Agreed.
>
> I'm always for documenting things.
>
> May as well note here that the '.' target explicitly prevents use of the
> fallback A/ resolution.
Thanks for your feedback folks.
Here’s a proposal: https://github.com/xsf/xeps/pull/796
Please comment on-list.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
