Re: [Standards] XEP-0220: handling of invalid dialback key
On 4/14/11 10:12 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: > [...] >>> I do not see any conflicts. As noted on the XMPPWG list, DNA actually >>> requires support for dialback errors, but otherwise I do not see why it >>> would not work as described. >> >> So, in DNA, if a DNSSEC-based verification doesn't work out, the >> Authoritative Server returns an error, not "invalid"? > > The Authoritative Server (in the dialback sense) is not involved - there > is no dial-back. > > [...] > > If it never uses dial-back, why should the receiving server send > 'invalid' instead of 'error'? Could you clarify that scenario? >>> >>> The receiving server will only "forward" invalid, never generate it >>> itself. >> >> Hmm, yes. > > I just noticed that the current DNA draft does not use 'invalid' in this > way: >> If there are no DNSSEC records or the >> signature is not valid, then the server rejects the request to send >> stanzas from that domain. [...] >> R: > > I think using a dialback error (possibly ) is more > appropriate in that situation. Right, thus my confusion. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0220: handling of invalid dialback key
Peter Saint-Andre wrote: [...] I do not see any conflicts. As noted on the XMPPWG list, DNA actually requires support for dialback errors, but otherwise I do not see why it would not work as described. So, in DNA, if a DNSSEC-based verification doesn't work out, the Authoritative Server returns an error, not "invalid"? The Authoritative Server (in the dialback sense) is not involved - there is no dial-back. [...] If it never uses dial-back, why should the receiving server send 'invalid' instead of 'error'? Could you clarify that scenario? The receiving server will only "forward" invalid, never generate it itself. Hmm, yes. I just noticed that the current DNA draft does not use 'invalid' in this way: > If there are no DNSSEC records or the > signature is not valid, then the server rejects the request to send > stanzas from that domain. [...] > R: I think using a dialback error (possibly ) is more appropriate in that situation.
Re: [Standards] XEP-0220: handling of invalid dialback key
On 4/14/11 3:27 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: >> On 4/14/11 2:47 PM, Philipp Hancke wrote: >>> Peter Saint-Andre wrote: > Actually, I mostly disagree with the "removed requirement for the > Receiving Server to close the stream if the dialback key is invalid" > stuff. From the security POV, why should the receiving server not > terminate the stream? Because, from the performance point of view, it doesn't want to discard the 10,000 valid domains it already supports on that stream. That's a >>> >>> The average stream has probably one domain pair. Do you want me to make >>> a simple extrapolation of the power law to demonstrate that most domains >>> will not even have 500 domain pairs? >> >> Sure they won't. But the few services that do virtual hosting will do it >> on a massive scale. > > You did not get the joke :-) > > Karma might be a reason why you actually do not want to multiplex on > such a scale. > huge cost to impose on the server just because the 10,001st domain has a DNSSEC problem. For traditional dialback the force-close requirement is fine. For dialback as used for domain name assertions with DNSSEC it seems too strong to me. >>> >>> If DNSSEC is used, when does the receiving server ask the authoritative >>> server to verify a dialback key? >> >> http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 >> >> I grant that I need to think about that spec further, but I don't want >> to make DNA impossible because of a requirement in XEP-0220 that applies >> to the one-to-one federation model but not the virtual hosting >> federation model. > > I do not see any conflicts. As noted on the XMPPWG list, DNA actually > requires support for dialback errors, but otherwise I do not see why it > would not work as described. So, in DNA, if a DNSSEC-based verification doesn't work out, the Authoritative Server returns an error, not "invalid"? > However, I think that DNA needs a "big picture" merge with 220 > (multiplexing), 288 (bidi) and the d-w-d spec that dwd promised to write > some time ago. I completely agree with that. In fact that might be an argument for moving XEP-0220 and XEP-0288 to the XMPP WG. I'd like to get XEP-0220 to Draft before we do that. Alternatively we could Retract it and submit it as an Internet-Draft, since it basically updates RFC 3920 anyway. I plan to ask the XMPP Council about this at its meeting next week. >>> If it never uses dial-back, why should the receiving server send >>> 'invalid' instead of 'error'? >> >> Could you clarify that scenario? > > The receiving server will only "forward" invalid, never generate it itself. Hmm, yes. >>> And you might still generate valid dialback keys for >>> dialback-with-dnssec to avoid that problem. >> >> Possibly. >> >> Anyway, here is revised text: >> >> If the value of the 'type' attribute is "invalid", then the Originating >> Server's identity (as valid for the Sender Domain) could not be verified >> by the Receiving Server. In this case, the Receiving Server MUST NOT >> process any queued stanzas from the Originating Server but instead MUST >> return any queued stanzas with an stanza error. > > No. The originating server MUST NOT send any stanzas before it receives > a valid dialback result, so there are no stanzas to process and no > stanzas to be bounced. That is the whole point of all this dialback > stuff, that you negotiate the domain pair before sending any stanzas to > avoid bouncing stanzas. > >> In addition, it is strongly RECOMMENDED for the Receiving Server to >> close the underlying stream (the only reason the Receiving Server might >> not close the underlying stream is if the stream is already being used >> for other domain pairs that have already been validated). > > -1. But that is mostly because I think that 'invalid' is currently only > used in cases where it is justified to close the stream. You're right about the queueing -- I misunderstood the spec so I've clarified that queueing refers to outbound stanzas. I'm still not convinced about forcing the receiving server to close the stream categorically, but I'll think about it further... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 3:30 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: > [...] >> I *think* that this discussion thread leads to the following text in >> Section 3, but please double-check it. >> >> ### >> >> [...] >> >> 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For >> server-to-server authentication the element MUST NOT include an >> authorization identity (thus Server1 includes an empty response of "=" >> as shown in RFC 6120). >> >> > mechanism='EXTERNAL'>= >> >> Interoperability Note: Previous versions of this specification relied on >> the authorization identity being present on the receiving server. Even >> though this is no longer required, the connecting server should include >> it for backward compability. > > MUST NOT include but should include for backward compability? > Include it always and blame it on me (even though I don't have the old > logs from 2006). > > I am not sure if backward compability really matters, the last time I > checked I offered EXTERNAL to three servers... jabber.org, > dave.cridland.net and some host running prosody. Right. Let's get some feedback Dave Cridland and Matthew Wild, at the least. I'm not sure that we have any implementations with which to be backward compatible. :) >> 11. Server2 determines if hostname is valid. >> >> a. If the 'from' attribute of stream header sent by Server1 can be >> matched against one of the identifiers provided in the certificate >> following the matching rules from RFC 6125, Server2 returns success. >> >> >> >>Implementation Note: If Server2 needs to assign an authorization >> identity during SASL negotiation, it SHOULD use the value of the 'from' >> attribute of the stream header sent by Server1. > > +1 Thanks for the review. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
Peter Saint-Andre wrote: [...] I *think* that this discussion thread leads to the following text in Section 3, but please double-check it. ### [...] 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication the element MUST NOT include an authorization identity (thus Server1 includes an empty response of "=" as shown in RFC 6120). = Interoperability Note: Previous versions of this specification relied on the authorization identity being present on the receiving server. Even though this is no longer required, the connecting server should include it for backward compability. MUST NOT include but should include for backward compability? Include it always and blame it on me (even though I don't have the old logs from 2006). I am not sure if backward compability really matters, the last time I checked I offered EXTERNAL to three servers... jabber.org, dave.cridland.net and some host running prosody. 11. Server2 determines if hostname is valid. a. If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success. Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1. +1
Re: [Standards] XEP-0220: handling of invalid dialback key
Peter Saint-Andre wrote: On 4/14/11 2:47 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: Actually, I mostly disagree with the "removed requirement for the Receiving Server to close the stream if the dialback key is invalid" stuff. From the security POV, why should the receiving server not terminate the stream? Because, from the performance point of view, it doesn't want to discard the 10,000 valid domains it already supports on that stream. That's a The average stream has probably one domain pair. Do you want me to make a simple extrapolation of the power law to demonstrate that most domains will not even have 500 domain pairs? Sure they won't. But the few services that do virtual hosting will do it on a massive scale. You did not get the joke :-) Karma might be a reason why you actually do not want to multiplex on such a scale. huge cost to impose on the server just because the 10,001st domain has a DNSSEC problem. For traditional dialback the force-close requirement is fine. For dialback as used for domain name assertions with DNSSEC it seems too strong to me. If DNSSEC is used, when does the receiving server ask the authoritative server to verify a dialback key? http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 I grant that I need to think about that spec further, but I don't want to make DNA impossible because of a requirement in XEP-0220 that applies to the one-to-one federation model but not the virtual hosting federation model. I do not see any conflicts. As noted on the XMPPWG list, DNA actually requires support for dialback errors, but otherwise I do not see why it would not work as described. However, I think that DNA needs a "big picture" merge with 220 (multiplexing), 288 (bidi) and the d-w-d spec that dwd promised to write some time ago. If it never uses dial-back, why should the receiving server send 'invalid' instead of 'error'? Could you clarify that scenario? The receiving server will only "forward" invalid, never generate it itself. And you might still generate valid dialback keys for dialback-with-dnssec to avoid that problem. Possibly. Anyway, here is revised text: If the value of the 'type' attribute is "invalid", then the Originating Server's identity (as valid for the Sender Domain) could not be verified by the Receiving Server. In this case, the Receiving Server MUST NOT process any queued stanzas from the Originating Server but instead MUST return any queued stanzas with an stanza error. No. The originating server MUST NOT send any stanzas before it receives a valid dialback result, so there are no stanzas to process and no stanzas to be bounced. That is the whole point of all this dialback stuff, that you negotiate the domain pair before sending any stanzas to avoid bouncing stanzas. In addition, it is strongly RECOMMENDED for the Receiving Server to close the underlying stream (the only reason the Receiving Server might not close the underlying stream is if the stream is already being used for other domain pairs that have already been validated). -1. But that is mostly because I think that 'invalid' is currently only used in cases where it is justified to close the stream.
Re: [Standards] XEP-0198: errors in stanza counting?
On 4/14/11 2:36 PM, Yann Leboulanger wrote: > Hi, Hi Yann! > I just re-read XEP-0198 (Stream management), and I'm not sure about the > way stanza are counted. In example 17, shouldn't client answer with h=1? > It already received his roster, so h should be 1. That sure seems to be wrong in the example, because at that point the client has received one stanza. This implies that in Example 19 it should be h='2', not h='1'. > And in example 21, after 5 messages server should reply with h=5 (not 4) > as it received 5 messages. (And h=10 after 10 messages, not 9) Correct. > Did I misunderstood something? The only thing I don't understand is how we got the examples wrong in the last revision of the spec. :( Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0220: handling of invalid dialback key
On 4/14/11 2:47 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: >>> Actually, I mostly disagree with the "removed requirement for the >>> Receiving Server to close the stream if the dialback key is invalid" >>> stuff. From the security POV, why should the receiving server not >>> terminate the stream? >> >> Because, from the performance point of view, it doesn't want to discard >> the 10,000 valid domains it already supports on that stream. That's a > > The average stream has probably one domain pair. Do you want me to make > a simple extrapolation of the power law to demonstrate that most domains > will not even have 500 domain pairs? Sure they won't. But the few services that do virtual hosting will do it on a massive scale. >> huge cost to impose on the server just because the 10,001st domain has a >> DNSSEC problem. For traditional dialback the force-close requirement is >> fine. For dialback as used for domain name assertions with DNSSEC it >> seems too strong to me. > > If DNSSEC is used, when does the receiving server ask the authoritative > server to verify a dialback key? http://tools.ietf.org/html/draft-ietf-xmpp-dna-01 I grant that I need to think about that spec further, but I don't want to make DNA impossible because of a requirement in XEP-0220 that applies to the one-to-one federation model but not the virtual hosting federation model. > If it never uses dial-back, why should the receiving server send > 'invalid' instead of 'error'? Could you clarify that scenario? > And you might still generate valid dialback keys for > dialback-with-dnssec to avoid that problem. Possibly. Anyway, here is revised text: If the value of the 'type' attribute is "invalid", then the Originating Server's identity (as valid for the Sender Domain) could not be verified by the Receiving Server. In this case, the Receiving Server MUST NOT process any queued stanzas from the Originating Server but instead MUST return any queued stanzas with an stanza error. In addition, it is strongly RECOMMENDED for the Receiving Server to close the underlying stream (the only reason the Receiving Server might not close the underlying stream is if the stream is already being used for other domain pairs that have already been validated). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 2:22 PM, Philipp Hancke wrote: > Peter Saint-Andre wrote: never necessary to include the authzid? I suppose the latter approach is simpler... >>> >>> Sure. But that was changed in version 0.0.3 and I don't think we can >>> "fix" that now nor is there a compelling reason. >> >> No, there is no compelling need -- such flexibility might be desirable >> someday, but we don't design for someday. > > We can still be liberal in what we accept and deal with empty > authorization ids today. > >>> I have no objections to adding a fallback to the stream's in s2s step 11 >>> if the authorization id is empty. IIRC some servers already do that. >> >> What is the nature of the fallback? > > I think it gets obvious if you add a 'from' after "stream's" :-/ > The stream's 'from' attribute is used instead of the (empty) > authorization id. Dave? I *think* that this discussion thread leads to the following text in Section 3, but please double-check it. ### [...] 10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication the element MUST NOT include an authorization identity (thus Server1 includes an empty response of "=" as shown in RFC 6120). = Interoperability Note: Previous versions of this specification relied on the authorization identity being present on the receiving server. Even though this is no longer required, the connecting server should include it for backward compability. 11. Server2 determines if hostname is valid. a. If the 'from' attribute of stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from RFC 6125, Server2 returns success. Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1. [...] ### smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0220: handling of invalid dialback key
Peter Saint-Andre wrote: Actually, I mostly disagree with the "removed requirement for the Receiving Server to close the stream if the dialback key is invalid" stuff. From the security POV, why should the receiving server not terminate the stream? Because, from the performance point of view, it doesn't want to discard the 10,000 valid domains it already supports on that stream. That's a The average stream has probably one domain pair. Do you want me to make a simple extrapolation of the power law to demonstrate that most domains will not even have 500 domain pairs? huge cost to impose on the server just because the 10,001st domain has a DNSSEC problem. For traditional dialback the force-close requirement is fine. For dialback as used for domain name assertions with DNSSEC it seems too strong to me. If DNSSEC is used, when does the receiving server ask the authoritative server to verify a dialback key? If it never uses dial-back, why should the receiving server send 'invalid' instead of 'error'? And you might still generate valid dialback keys for dialback-with-dnssec to avoid that problem.
[Standards] XEP-0198: errors in stanza counting?
Hi, I just re-read XEP-0198 (Stream management), and I'm not sure about the way stanza are counted. In example 17, shouldn't client answer with h=1? It already received his roster, so h should be 1. And in example 21, after 5 messages server should reply with h=5 (not 4) as it received 5 messages. (And h=10 after 10 messages, not 9) Did I misunderstood something? -- Yann
Re: [Standards] XEP-0220: handling of invalid dialback key
On 4/14/11 2:22 PM, Philipp Hancke wrote: > Actually, I mostly disagree with the "removed requirement for the > Receiving Server to close the stream if the dialback key is invalid" > stuff. From the security POV, why should the receiving server not > terminate the stream? Because, from the performance point of view, it doesn't want to discard the 10,000 valid domains it already supports on that stream. That's a huge cost to impose on the server just because the 10,001st domain has a DNSSEC problem. For traditional dialback the force-close requirement is fine. For dialback as used for domain name assertions with DNSSEC it seems too strong to me. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0220: handling of invalid dialback key
Peter Saint-Andre wrote: [...] Here is why I think that's schizophrenic. The receiving server is required to accept and process stanzas for already verified domain pairs. I think we disagree about the usage of 'invalid'. However, if verification of a new domain pair fails, then the receiving server is required to treat all previous verifications as now invalid (despite the fact that they were valid before). That seems wrong The result is invalid because the authoritative server explicitly told the receiving server that the originating server is not authorized. That is quite different from cases where verification fails because - for example - the receiving server can not contact the authoritative server. This is to be handled by type='error'. to me, and potentially very problematic given that we plan to use dialback for domain name assertions [2] in the XMPP WG. In particular, domain name assertions might lead to re-use of a given stream for a very large number of domain pairs (say, 10,000), and forcing the receiving server to close that stream because domain pair #10,001 is invalid seems like a pretty serious operational burden. IMHO it would be best to leave Don't attempt to send keys for domains that you don't own. Even better: do certificate-based d-w-d or the dnssec d-w-d and avoid the dial-back thing. that decision up to local service policy and not mandate it in the spec. Therefore in version 0.6 of XEP-0220 I changed the last paragraph cited above to: slightly reformatted... If the value of the 'type' attribute is "invalid", this means that the Originating Server's identity (as valid for the Sender Domain) could not be verified by the Receiving Server. correct. Queued stanzas MUST be returned to the respective senders with an stanza error This happens on the originating server. and the underlying stream MAY be closed unless it is being used by other domain pairs. as does this. > Note that the Receiving Server might choose to terminate the TCP connection. I'd be fine with changing "MAY" to "SHOULD" here, but I think "MUST" is too strong. You are trying to specify the behaviour of the _originating_ server? MAY is fine with me, since the next thing the originating server receives is usually a , hence it does not make much difference. Actually, I mostly disagree with the "removed requirement for the Receiving Server to close the stream if the dialback key is invalid" stuff. From the security POV, why should the receiving server not terminate the stream?
Re: [Standards] XEP-0178 1.1rc3
Peter Saint-Andre wrote: never necessary to include the authzid? I suppose the latter approach is simpler... Sure. But that was changed in version 0.0.3 and I don't think we can "fix" that now nor is there a compelling reason. No, there is no compelling need -- such flexibility might be desirable someday, but we don't design for someday. We can still be liberal in what we accept and deal with empty authorization ids today. I have no objections to adding a fallback to the stream's in s2s step 11 if the authorization id is empty. IIRC some servers already do that. What is the nature of the fallback? I think it gets obvious if you add a 'from' after "stream's" :-/ The stream's 'from' attribute is used instead of the (empty) authorization id. Dave?
Re: [Standards] XEP-0178 1.1rc3
On 4/14/11 6:11 AM, Philipp Hancke wrote: > Peter Saint-Andre wrote: >>> s2s step 10 includes the authorization identity, whereas section 9.2.2. >>> in the RFC includes an empty response. >>> Unless we consider that a bug in the RFC we need some kind of handling >>> for using the stream's from attribute in step 11 when the response is >>> empty. >> >> I think it depends. >> >> As in XEP-0220, if the sending domain is authorizing as (e.g.) a >> subdomain such as chat.sender.tld then wouldn't the originating server >> specify that as an authorization identity? Or do we assume that the > > Multiple authentications? > >> 'from' will always match the authorization identity, in which case it's > > That assumption is already there, because the receiving server offers > EXTERNAL only if the 'from' is contained in the certificate. You're right. >> never necessary to include the authzid? I suppose the latter approach is >> simpler... > > Sure. But that was changed in version 0.0.3 and I don't think we can > "fix" that now nor is there a compelling reason. No, there is no compelling need -- such flexibility might be desirable someday, but we don't design for someday. > I have no objections to adding a fallback to the stream's in s2s step 11 > if the authorization id is empty. IIRC some servers already do that. What is the nature of the fallback? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Multiple location sources in XEP-0080
On 4/14/11 2:18 AM, Dave Cridland wrote: > I'm not just replying to this to out-delay Peter. I'd honestly not > noticed this one... > > On Fri Apr 9 03:02:11 2010, Ilya Braude wrote: >> >> gps >> Geode >> 45.44 >> 12.33 >> > > Should these be freeform text, or registered tokens? > > The patch you attached somewhat suggests these are freeform text fields, > but ones that have a specific meaning, which I don't think is a great > combination. > > I think this is reasonable fare for a registry, though. Yes, it makes sense to have a registry, at least for source (I don't think we need a registry for provider). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] XEP-0220: handling of invalid dialback key
Version 0.5 of XEP-0220 (server dialback) was, I think, a bit
schizophrenic about handling of incoming connections. [1] It said this
in Section 2.2.1:
###
This subsection describes the interaction between the Originating Server
and the Receiving Server, from the perspective of the Receiving Server
This key MUST be verified before the Sender Domain ('sender.tld') is
authorized to send stanzas
Note: the Receiving Server MUST continue to accept and process stanzas
for already verified domain pairs, and MUST continue to process both
and elements.
After the validity of the key has been established (for example, by the
Authoritative Server), the domain pair is to be considered as verified
and the Receiving Server MUST accept stanzas from the Originating Server.
In addition, the Originating Server is notified of the result. This is
done by creating a element which MUST possess a 'from'
attribute whose value is the Target Domain, MUST possess a 'to'
attribute whose value is the Sender Domain, and MUST possess a 'type'
attribute whose value is either "valid" or "invalid"
If the type is 'invalid', the Originating Server is attempting to spoof
the Sender Domain. The Receiving Server MUST terminate the XML stream
and the underlying TCP connection and SHOULD log the attempt.
###
Here is why I think that's schizophrenic. The receiving server is
required to accept and process stanzas for already verified domain
pairs. However, if verification of a new domain pair fails, then the
receiving server is required to treat all previous verifications as now
invalid (despite the fact that they were valid before). That seems wrong
to me, and potentially very problematic given that we plan to use
dialback for domain name assertions [2] in the XMPP WG. In particular,
domain name assertions might lead to re-use of a given stream for a very
large number of domain pairs (say, 10,000), and forcing the receiving
server to close that stream because domain pair #10,001 is invalid seems
like a pretty serious operational burden. IMHO it would be best to leave
that decision up to local service policy and not mandate it in the spec.
Therefore in version 0.6 of XEP-0220 I changed the last paragraph cited
above to:
If the value of the 'type' attribute is "invalid", this means that
the Originating Server's identity (as valid for the Sender Domain)
could not be verified by the Receiving Server. Queued stanzas MUST
be returned to the respective senders with an
stanza error and the underlying stream MAY
be closed unless it is being used by other domain pairs. Note that
the Receiving Server might choose to terminate the TCP connection.
I'd be fine with changing "MAY" to "SHOULD" here, but I think "MUST" is
too strong.
Feedback is welcome.
Peter
[1] http://xmpp.org/extensions/attic/xep-0220-0.5.html
[2] http://tools.ietf.org/html/draft-ietf-xmpp-dna-01
smime.p7s
Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0220 (Server Dialback)
Version 0.7 of XEP-0220 (Server Dialback) has been released. Abstract: This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an originating server, it does not process traffic over the connection until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000. Changelog: Removed stream feature for advertising mere protocol support, using it only for advertising support for enhanced error handling. (ph/psa) Diff: http://xmpp.org/extensions/diff/api/xep/0220/diff/0.6/vs/0.7 URL: http://xmpp.org/extensions/xep-0220.html
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On 4/14/11 7:41 AM, Peter Saint-Andre wrote: > On 4/14/11 5:45 AM, Philipp Hancke wrote: >> Peter Saint-Andre wrote: > Preferably, the receiving server would not include the old namespace > at all > on the stream in response to a 1.0 stream. It just confuses matters. > And > on stream restarts, the old ns should not be used at all by either > side. >>> >>> Ah, I see what you mean -- if you *know* that the other side knows about >>> XMPP 1.0 then use the stream feature exclusively. >> >> which is a problem because the dialback stream feature is an >> afterthought and not "xmpp 1.0". > > Stream features are 1.0, but the dialback stream feature is not. > >> I would propose to get rid of the first bullet (and associated text) in >> section 2.3. This "new" method of signalling support for dialback does >> not offer any advantages. >> That way, the stream feature is only used to signal support for dialback >> error handling. > > I think that would be OK. I'm going to push out a revised XEP shortly to fix this matter. After that I hope we can finally publish this as a Draft spec. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] updated Sensors proposal
On 4/14/11 2:15 AM, Charles Spirakis wrote: > As Peter mentioned, we are very interested in seeing if people think > SOX can meet their sensing and control needs and if not, what aspect > of the proposal could be modified to meet those needs. Thanks for the explanation. I have pinged some folks I know working with XMPP in the smart grid space but I don't think they've reviewed the spec yet. I'll ping them again now that the new version is out. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On 4/14/11 5:45 AM, Philipp Hancke wrote: > Peter Saint-Andre wrote: Preferably, the receiving server would not include the old namespace at all on the stream in response to a 1.0 stream. It just confuses matters. And on stream restarts, the old ns should not be used at all by either side. >> >> Ah, I see what you mean -- if you *know* that the other side knows about >> XMPP 1.0 then use the stream feature exclusively. > > which is a problem because the dialback stream feature is an > afterthought and not "xmpp 1.0". Stream features are 1.0, but the dialback stream feature is not. > I would propose to get rid of the first bullet (and associated text) in > section 2.3. This "new" method of signalling support for dialback does > not offer any advantages. > That way, the stream feature is only used to signal support for dialback > error handling. I think that would be OK. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0178 1.1rc3
Peter Saint-Andre wrote: s2s step 10 includes the authorization identity, whereas section 9.2.2. in the RFC includes an empty response. Unless we consider that a bug in the RFC we need some kind of handling for using the stream's from attribute in step 11 when the response is empty. I think it depends. As in XEP-0220, if the sending domain is authorizing as (e.g.) a subdomain such as chat.sender.tld then wouldn't the originating server specify that as an authorization identity? Or do we assume that the Multiple authentications? 'from' will always match the authorization identity, in which case it's That assumption is already there, because the receiving server offers EXTERNAL only if the 'from' is contained in the certificate. never necessary to include the authzid? I suppose the latter approach is simpler... Sure. But that was changed in version 0.0.3 and I don't think we can "fix" that now nor is there a compelling reason. I have no objections to adding a fallback to the stream's in s2s step 11 if the authorization id is empty. IIRC some servers already do that. philipp
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Peter Saint-Andre wrote: Preferably, the receiving server would not include the old namespace at all on the stream in response to a 1.0 stream. It just confuses matters. And on stream restarts, the old ns should not be used at all by either side. Ah, I see what you mean -- if you *know* that the other side knows about XMPP 1.0 then use the stream feature exclusively. which is a problem because the dialback stream feature is an afterthought and not "xmpp 1.0". I would propose to get rid of the first bullet (and associated text) in section 2.3. This "new" method of signalling support for dialback does not offer any advantages. That way, the stream feature is only used to signal support for dialback error handling.
Re: [Standards] Multiple location sources in XEP-0080
I'm not just replying to this to out-delay Peter. I'd honestly not noticed this one... On Fri Apr 9 03:02:11 2010, Ilya Braude wrote: gps Geode 45.44 12.33 Should these be freeform text, or registered tokens? The patch you attached somewhat suggests these are freeform text fields, but ones that have a specific meaning, which I don't think is a great combination. I think this is reasonable fare for a registry, though. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] updated Sensors proposal
All -- For those on the mailing list who may not be familiar with the Sensor-Over-XMPP (aka SOX) proposal, SOX is a payload specification that allows sensors and actuators (data producers) to provide information to agents (data consumers) via XMPP's publish-subscribe extension (XEP-0060). The SOX effort has been going on at CMU for over 3 years (Sensor Andrew - http://www.ices.cmu.edu/censcir/sensor-andrew/) and is currently used to monitor buildings on the CMU campus. SOX works with any XMPP server that implements XEP-0060 and the authors currently have sensors and actuators connected via SOX on unmodified ejabberd and openfire XMPP servers. Open source SOX libraries have been written in both C and Java. Sensors and actuators come in a variety of shapes, sizes and protocols and the SOX proposal attempts to demonstrate its flexibility by including several use cases and examples. For those who prefer shorter documents, feel free to skip over section 5. As Peter mentioned, we are very interested in seeing if people think SOX can meet their sensing and control needs and if not, what aspect of the proposal could be modified to meet those needs. -- charles
