Re: [Standards] XEP-0178 1.1rc3
On 4/20/11 9:00 AM, Peter Saint-Andre wrote: > On 4/20/11 7:42 AM, Philipp Hancke wrote: > 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. :) >>> >>> Please see the latest version, reflecting what I think is the consensus >>> from list discussions: >>> >>> http://xmpp.org/extensions/tmp/xep-0178-1.1.html >>> >>> http://xmpp.org/extensions/diff/api/xep/0178/diff/1.0/vs/1.1rc4 >> >> Not related to the diff, but I just spotted this: >> S2S step 9: no match -> close => MAY close or may allow dialback? > > Ah yes, TLS+Dialback? ;-) > > Changed in my working copy to: > > If no match is found, Server2 MAY either close Server1's TCP connection > or continue with a Server Dialback [8] negotiation. > >> S2S step 10: I think MUST NOT is too strong. After all, XMPP is deployed >> using the EXTERNAL mechanism (see the xmppwg charter :-), so >> we can not change the rules that way. >> MAY include (for interop reasons) with a note that a future version may >> remove this (actually I think that EXTERNAL will be deprecated in favor >> of d-w-d before that happens)? That way we have a clear migration path. > > OK. > > Changed in my working copy to: > > For server-to-server authentication, the element MAY include an > authorization identity, however a future version of this specification > might disallow use of the authorization identity in server-to-server > authentication (in the following example, Server1 includes an empty > response of "=" as shown in RFC 6120). > >> Note #7 is obsolete, that spec is 0238 - which is deprecated so it does >> not make sense to add a reference. > > True. And the dialback flows will be in d-w-d anyway, I'd think. Removed. BTW, I checked over 1.1rc5 and found a few typos and infelicities, so I've checked 1.1rc6 into git: http://xmpp.org/extensions/diff/api/xep/0178/diff/1.1rc5/vs/1.1rc6 Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0220 (Server Dialback)
Version 0.9 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: To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Originating Server to Receiving Server. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0220/diff/0.8/vs/0.9 URL: http://xmpp.org/extensions/xep-0220.html
Re: [Standards] serious bugs in XEP-0220 (Server Dialback)
On 4/22/11 12:27 PM, Peter Saint-Andre wrote: > On 4/22/11 7:27 AM, Philipp Hancke wrote: >> I think the bug is less serious than you think ... >> >>> There are two basic problems: >>> >>> 1. In all of the examples of XEP-0220, the dialback key should be the >>> same key -- but the key varies across examples. >> >> The XEP shows _two_ dialback sessions on two TCP connections. >> If you re-read it with that POV things should make more sense. > > Now, why did we do that?!? ;-) > > Currently the text (not the examples) says that the spec presents a > single dialback negotiation, organized as follows: > > §2.1.1 = Originating Server Generates Outbound Request for Authorization > by Receiving Server > > §2.1.2 = Receiving Server Generates Outbound Request for Verification of > Originating Server by Authoritative Server > > §2.2.1 = Receiving Server Handles Inbound Authorization Request from > Originating Server (this is the flip side of 2.1.1) > > §2.2.2 = Authoritative Server Handles Inbound Verification Request from > Receiving Server (this is the flip side of 2.1.2) > > I think we wrote it this way so that a developer could read §2.1 while > writing the code that generates outbound dialback elements (whether > acting as an Originating Server or a Receiving Server) and then read > §2.2 while writing the code that handles inbound dialback elements > (whether acting as a Receiving Server or an Authoritative Server). > > I don't know how helpful that really is in practice when developers sit > down to write their dialback code, but that's what we say we're doing. > However, the fact that the examples aren't aligned with what we say > we're doing doesn't help matters. > > So we need to either (1) change the examples to match what we say we're > doing, or (2) change the text to match what the examples show. I lean > strongly toward (1). I've made these changes and will publish version 0.9 soon. Naturally, further review would be appreciated. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
