Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/21/13 1:21 PM, Philipp Hancke wrote: > Am 21.08.2013 21:07, schrieb Peter Saint-Andre: [...] This = mid-session stream feature negotiation? >>> >>> Yes. Basically I would expect all stream feature negotiation >>> to happen immediately in response to . Not >>> after doing something else (like dialback). >> >> Well, we can't negotiate everything at once. :-) So you might >> negotiate Feature1 and then Feature2. > > Right, but are there cases where you feature1 doesn't require a > stream restart? If there are such cases, shouldn't you negotiate > them in a single step? Practically, I don't think it matters. We > would have run into that problem otherwise. Let's just fix 0170. I don't think we've ever clearly thought about that kind of scenario. >> And dialback is weird because it predates the whole stream >> features framework. > > yes. Unfortunately, I didn't manage to kill it last year :-/ Hey, it's useful. If we didn't re-use dialback for signaling, we'd need to invent something very much like it... >>> I do not think that the receiving server would enforce such a >>> rule however. And we have just removed two features that would >>> have required a stream restart, which is certainly a bad idea >>> mid-session, so no objection from me. >> >> I definitely agree about mid-session feature negotiation and >> stream restarts. > > Great. > >>> [...] > http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart > > >> > doesn't return from DONE Erratum reports are always welcome. ;-) >>> >>> No, I think that the flowchart makes sense. We might want to >>> keep this discussion in mind for 6120bis though. >> >> Agreed! Not that I'm looking forward to that work (although I >> think the eventual diff will be relatively small -- certainly a >> lot smaller than the changes between 3920 and 6120). > > can we make it a STD then? It's a pity xmpp isn't considered under > the 2-step process. Unfortunately, that depends on the address / internationalization stuff. Thus (in part) the push to finish 6122bis and PRECIS. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFRd0AAoJEOoGpJErxa2pXJAP/Ru4PD3SM08uqWHkFP+bqy02 sFewZyP18nAEfEj+5iR00ruyB3cYqk7YYSVi79tcUMhBGZZfTWwSUhU9OxT2qCff OMA6eaAtS/BoekVX5WOHdlRjJ4z/qtJi+ucun3oO99fazfFU5PPldaXxMEDEtlki 4JeQjJDmbtx+7SvKFRiU4gtnwJl1DrdPI+vPsP/evDB1PddK37q+bN/vD/vF9WKb 1i6IhZMEHq5OprBzmCpBuQcPxBVW/COUMkWKGAnKkgoZMN2tfmegIA+9ilPHXVsM 2eQWps4WN4+oet5xMLgluPr/YncNtU6YKSnc+KLX+b8/Pq4OLlCG2SAMsCDhLsTB xFeJp7HZ6fshVKKBcne36yolcdbsdbmMMmHvefK/yxdmsOmWAYclOtU8YHpdDbnU Qy04qBaVjIM52VtX3bTNOzGtZhJ5yy19G0EdoLMvu8UD0Q3l4il6M7ovc/uobmYm tq40cNPU24TrofNf49a0u9vHAOxiokF/7o2tkMQkAE/+niWuBLqr6T4Zdjz1ELdr d17q5UI4rQLvYNoAEWsA8LsCrrsp774Lym5BUhdNLDcG5IWvvnNOKEgiV5HHH3Lu b+r/DUjrzMH2V/JdSiXXKg1GbE3sp5dKxbSV4AimaTSbvRSjUpRNPYDWUaTX4cWg WBSZuaEc1ZoWS6CnYsMm =fKnE -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/16/13 2:16 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0220 (Server Dialback).
Off-list, Philipp Hancke and I have had a few co-author discussions
about a few sections of this spec. Since we don't want to make changes
in private, here's a summary of what we've discussed.
1. 2.1.1 Initiating Server Generates Outbound Request for
Authorization by Receiving Server
OLD
Naturally, the Initiating Server can also enable or negotiate other
stream features at this point, such as Stream Compression [9] and Stream
Management [10].
NEW
Naturally, the Initiating Server can also enable or negotiate other
stream features at this point.
Rationale: as discussed on the list, the recommended order of stream
feature negotiation is really a matter for XEP-0170 (which needs to be
updated).
2. Section 2.2.1 Receiving Server Handles Inbound Authorization
Request from Initiating Server
OLD
This key MUST be verified before the Initiating Server is authorized
to send stanzas from the Sender Domain ("capulet.lit") to the Target
Domain ("montague.lit"). Note that the verification process might fail
prematurely, for example, if the Receiving Server's policy states that
connections from the Initiating Server or the Sender Domain are not
allowed.
NEW
Before the Receiving Server allows the Initiating Server to send
stanzas from the Sender Domain (here "capulet.example") to the Target
Domain (here "montague.example"), it MUST verify the identity of the
Initiating Server. Depending on how the server dialback protocol is
used, this can be done by verifying the dialback key or by using some
out-of-band method as in the POSH [11] prooftype for DNA [12]. Note
that the verification process might fail prematurely, for example, if
the Receiving Server's policy states that connections from the
Initiating Server or the Sender Domain are not allowed.
Rationale: because we're talking about re-using the dialback protocol
(but not necessarily dialback keys) for domain name assertions in
general (see draft-ietf-xmpp-dna), we can't say you must check the
dialback key since verification can be based on, say, POSH.
3. 2.2.1 Receiving Server Handles Inbound Authorization Request from
Initiating Server
OLD
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
Initiating Server for the verified domain pair.
In addition, the Receiving Server SHALL notify the Initiating Server
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"
(or "error", as shown above).
NEW
After the validity of the key has been established (for example, by
the Authoritative Server), the Receiving Server can safely accept
stanzas from the Initiating Server for the verified domain pair.
In addition, the Receiving Server SHALL notify the Initiating Server
of the result and thus signal its willingness to accept stanzas from
the Initiating Server for the verified domain pair. 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" (or "error", as shown above).
Rationale: it's not correct to say that the Receiving Server "MUST"
accept stanzas.
4. Section 2.6 Multiplexing
OLD
A single XML stream between Initiating Server and Receiving Server can
be used to multiplex stanzas for more than one domain pair. We call this
usage "multiplexing" (historically it has also been known as
"piggybacking"). One common motivation for multiplexing is virtual
hosting, under which many domains are hosted on the same server. Another
common motivation for such reuse is the existence of additional services
associated with the Sender Domain but hosted at "subdomains" thereof.
For example, both the "montague.lit" and the "capulet.lit" XMPP servers
might host Multi-User Chat [16] services at "chat.montague.lit" and
"rooms.capulet.lit" respectively. Without multiplexing, many
server-to-server connections would be necessary to exchange stanzas
between those domains. With more domains, the number of connections
might exceed the maximum number of connections allowed from a single IP
address as explained in Best Practices to Discourage Denial of Service
Attacks [17]. Multiplexing reduces the number of connections to two.
Note: Because dialback operates on domain pairs, a total of eight
dialback negotiations is necessary for a bidirectional exchange of
stanzas between two sending domains and two target domains.
NEW
A single XML stream between Init
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Am 21.08.2013 21:07, schrieb Peter Saint-Andre: [...] This = mid-session stream feature negotiation? Yes. Basically I would expect all stream feature negotiation to happen immediately in response to . Not after doing something else (like dialback). Well, we can't negotiate everything at once. :-) So you might negotiate Feature1 and then Feature2. Right, but are there cases where you feature1 doesn't require a stream restart? If there are such cases, shouldn't you negotiate them in a single step? Practically, I don't think it matters. We would have run into that problem otherwise. Let's just fix 0170. And dialback is weird because it predates the whole stream features framework. yes. Unfortunately, I didn't manage to kill it last year :-/ I do not think that the receiving server would enforce such a rule however. And we have just removed two features that would have required a stream restart, which is certainly a bad idea mid-session, so no objection from me. I definitely agree about mid-session feature negotiation and stream restarts. Great. [...] http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart doesn't return from DONE Erratum reports are always welcome. ;-) No, I think that the flowchart makes sense. We might want to keep this discussion in mind for 6120bis though. Agreed! Not that I'm looking forward to that work (although I think the eventual diff will be relatively small -- certainly a lot smaller than the changes between 3920 and 6120). can we make it a STD then? It's a pity xmpp isn't considered under the 2-step process.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/21/13 12:06 PM, Philipp Hancke wrote: > Am 21.08.2013 19:51, schrieb Peter Saint-Andre: >> On 8/21/13 11:47 AM, Philipp Hancke wrote: >>> Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...] > Digging out my print copy i found some notes regarding > stream compression and session managment in 2.1.1 (after > example 3). Really old thread alert. :-) >>> >>> Old enough that my print copy which I recently dug out is >>> starting to fall apart :-) [...] I propose that we make the following change to XEP-0220 in Section 2.1.1: OLD Naturally, the Initiating Server can also enable or negotiate other stream features at this point, such as Stream Compression [9] and Stream Management [10]. NEW Naturally, the Initiating Server can also enable or negotiate other stream features at this point. >>> >>> I'd actually expect stream features to be negotiated before any >>> real stanzas flow, not mid-session and such text might allow >>> this. >> >> This = mid-session stream feature negotiation? > > Yes. Basically I would expect all stream feature negotiation to > happen immediately in response to . Not after > doing something else (like dialback). Well, we can't negotiate everything at once. :-) So you might negotiate Feature1 and then Feature2. And dialback is weird because it predates the whole stream features framework. > I do not think that the receiving server would enforce such a rule > however. And we have just removed two features that would have > required a stream restart, which is certainly a bad idea > mid-session, so no objection from me. I definitely agree about mid-session feature negotiation and stream restarts. > [...] >>> http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart >>> >>> doesn't return from DONE >> >> Erratum reports are always welcome. ;-) > > No, I think that the flowchart makes sense. We might want to keep > this discussion in mind for 6120bis though. Agreed! Not that I'm looking forward to that work (although I think the eventual diff will be relatively small -- certainly a lot smaller than the changes between 3920 and 6120). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFRAMAAoJEOoGpJErxa2prEIP/iggyCRYvAp6Vv5sypHfvI2w gMCzl6SIxulwesNwdp/6/dT2Y3aJ8JRrNX2AuH7LbDt9Zh+HUbKhyPlnRdAdkf6R b8eN+fnLg9j9GCIHNPJ+7Ty2lpVbzBBaoI09YQ8dl+mli+2LZz+h9Q3XBgOIqkBR dDNhRcnEGi1v1n09PGmab7xoFImbwlg2+AIXW58k0diOPkotwCmfIgbIlXy834pc wwRX4hMCgFaDDB5nCktlXF77Yd6UL1RCZTqacHmw97OQQu34Kn7Eo62MxuuucGTB KVFckTMrWidx1J6XsDjwVlF1z8xX2noIaey+0tWkGSlrXXP1jqhlkuEV4Xt7/40u EP86qjZMqKL3cU/nXpWMSHaXSnpYBWnyyTcrLTmsDzU9WFiTu2JVdo0UOLWzDjBu 7wGjUDMDydnmBTbwpAucyHD8MtOujBFoVLwmDQwatXxolGLzaea+walV5OWX4udm LJb2d+ggShcMrUN1a878ePBNj1gV2aQ4BJmS+Ov4aRsbA0iRSltR/FLFJqZqgetj 1/hjh0PhsbxQcE0qA47Exdrh7cucZDYLEyi4jJJOBxtxapBRljhrhzWLjAWUDSrq EI16BdzPdsfmohA443RfB3+NQ1PELnQCsreWnzbFICRqVRyHM+V/lOQFRcrKvkuL /3bTaC6lPiKX6RIrdHhg =RIAI -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Am 21.08.2013 19:51, schrieb Peter Saint-Andre: On 8/21/13 11:47 AM, Philipp Hancke wrote: Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...] Digging out my print copy i found some notes regarding stream compression and session managment in 2.1.1 (after example 3). Really old thread alert. :-) Old enough that my print copy which I recently dug out is starting to fall apart :-) [...] I propose that we make the following change to XEP-0220 in Section 2.1.1: OLD Naturally, the Initiating Server can also enable or negotiate other stream features at this point, such as Stream Compression [9] and Stream Management [10]. NEW Naturally, the Initiating Server can also enable or negotiate other stream features at this point. I'd actually expect stream features to be negotiated before any real stanzas flow, not mid-session and such text might allow this. This = mid-session stream feature negotiation? Yes. Basically I would expect all stream feature negotiation to happen immediately in response to . Not after doing something else (like dialback). I do not think that the receiving server would enforce such a rule however. And we have just removed two features that would have required a stream restart, which is certainly a bad idea mid-session, so no objection from me. [...] http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart doesn't return from DONE Erratum reports are always welcome. ;-) No, I think that the flowchart makes sense. We might want to keep this discussion in mind for 6120bis though.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On 8/21/13 11:47 AM, Philipp Hancke wrote: > Am 21.08.2013 18:01, schrieb Peter Saint-Andre: > [...] >>> Digging out my print copy i found some notes regarding stream >>> compression and session managment in 2.1.1 (after example 3). >> >> Really old thread alert. :-) > > Old enough that my print copy which I recently dug out is starting to > fall apart :-) > [...] >> I propose that we make the following change to XEP-0220 in Section 2.1.1: >> >> OLD >> Naturally, the Initiating Server can also enable or negotiate other >> stream features at this point, such as Stream Compression [9] and Stream >> Management [10]. >> >> NEW >> Naturally, the Initiating Server can also enable or negotiate other >> stream features at this point. > > I'd actually expect stream features to be negotiated before any real > stanzas flow, not mid-session and such text might allow this. This = mid-session stream feature negotiation? XEP-0220 is not the governing spec for when stream feature is allowed. Removing that last clause was intended only to reduce the possibility of confusion. > http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart > doesn't return from DONE Erratum reports are always welcome. ;-) >> And then start an effort to review and revise XEP-0170. > > +1 > >> The second-listed post was about XEP-0198 and dialback. Here again the >> issue is the order of operations, governed by XEP-0170. So my conclusion >> is the same: let's fix XEP-0170. > > +2 > Great. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Am 21.08.2013 18:01, schrieb Peter Saint-Andre: [...] Digging out my print copy i found some notes regarding stream compression and session managment in 2.1.1 (after example 3). Really old thread alert. :-) Old enough that my print copy which I recently dug out is starting to fall apart :-) [...] I propose that we make the following change to XEP-0220 in Section 2.1.1: OLD Naturally, the Initiating Server can also enable or negotiate other stream features at this point, such as Stream Compression [9] and Stream Management [10]. NEW Naturally, the Initiating Server can also enable or negotiate other stream features at this point. I'd actually expect stream features to be negotiated before any real stanzas flow, not mid-session and such text might allow this. http://xmpp.org/rfcs/rfc6120.html#streams-negotiation-flowchart doesn't return from DONE And then start an effort to review and revise XEP-0170. +1 The second-listed post was about XEP-0198 and dialback. Here again the issue is the order of operations, governed by XEP-0170. So my conclusion is the same: let's fix XEP-0170. +2
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Old thread alert. On 4/29/13 12:40 AM, Philipp Hancke wrote: > On Tue, 16 Apr 2013, XMPP Extensions Editor wrote: >> This message constitutes notice of a Last Call for comments on >> XEP-0220 (Server Dialback). >> >> 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 initiating server, it >> does not process traffic over the connection until it has verified the >> initiating server's key with an authoritative server for the domain >> asserted by the initiating server. Additionally, the protocol is used >> to negotitate whether the receiving server is accepting stanzas for >> the target domain. Although Server Dialback does not provide strong >> authentication and it is subject to DNS poisoning attacks, it has >> effectively prevented address spoofing on the XMPP network since its >> development in the year 2000. >> >> URL: http://xmpp.org/extensions/xep-0220.html >> >> This Last Call begins today and shall end at the close of business on >> 2013-05-10. >> >> Please consider the following questions during this Last Call and send >> your feedback to the standards@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! > > Digging out my print copy i found some notes regarding stream > compression and session managment in 2.1.1 (after example 3). Really old thread alert. :-) > Have we resolved > http://mail.jabber.org/pipermail/standards/2012-May/025999.html > and > http://mail.jabber.org/pipermail/standards/2012-May/025998.html > ? I don't think we have. The first-listed post was about compression after dialback. In that message you wrote: The reason why stream compression is after some kind of authentication is probably to have an asserted idenity of the peer and avoid offering it to parties whose trust level is not high enough (aka: you trust those parties never to send zlib bombs). That's an accurate description of the concern we had with offering compression before authentication. However, you make a good point about the need for stream restarts after dialback under the order of operations mandated in XEP-0170. It seems that we had not thought that through in detail with regard to dialback. The points you raise seem compelling. This seems to require a change to XEP-0170 -- and as you said that "might be necessary for things like 0198 and 0288 anyway". I propose that we make the following change to XEP-0220 in Section 2.1.1: OLD Naturally, the Initiating Server can also enable or negotiate other stream features at this point, such as Stream Compression [9] and Stream Management [10]. NEW Naturally, the Initiating Server can also enable or negotiate other stream features at this point. And then start an effort to review and revise XEP-0170. The second-listed post was about XEP-0198 and dialback. Here again the issue is the order of operations, governed by XEP-0170. So my conclusion is the same: let's fix XEP-0170. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On 16 April 2013 21:16, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0220 > (Server Dialback). > > 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 initiating server, it does not process traffic over the > connection until it has verified the initiating server's key with an > authoritative server for the domain asserted by the initiating server. > Additionally, the protocol is used to negotitate whether the receiving server > is accepting stanzas for the target domain. Although Server Dialback does not > provide strong authentication and it is subject to DNS poisoning attacks, it > has effectively prevented address spoofing on the XMPP network since its > development in the year 2000. > > URL: http://xmpp.org/extensions/xep-0220.html > > This Last Call begins today and shall end at the close of business on > 2013-05-10. > > Please consider the following questions during this Last Call and send your > feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? Definitely needed. > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes, it does. > 3. Do you plan to implement this specification in your code? If not, why not? We have, except for the newer "errors" portion of the protocol and "multiplexing sender domains". Support for errors is planned. > 4. Do you have any security concerns related to this specification? Nothing not already documented. > 5. Is the specification accurate and clearly written? The nature of the protocol is confusing, and it isn't helped by carrying legacy baggage and not fitting very nicely into the rest of XMPP. Nevertheless, I think the specification does a decent job at trying to present everything logically, and I didn't have that much trouble implementing it. Editorially there seem to be some issues with internal references. For example links and text about section 2.4, which is about advertising support and not errors in particular. Overall I think this is a good useful document of a protocol that isn't going away any time soon. Someone asked only yesterday if Prosody could be configured to do TLS authentication *and* dialback (i.e. requiring both to pass). Regards, Matthew
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On Tue, 16 Apr 2013, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0220 (Server Dialback). 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 initiating server, it does not process traffic over the connection until it has verified the initiating server's key with an authoritative server for the domain asserted by the initiating server. Additionally, the protocol is used to negotitate whether the receiving server is accepting stanzas for the target domain. Although Server Dialback does not provide strong authentication and it is subject to DNS poisoning attacks, it has effectively prevented address spoofing on the XMPP network since its development in the year 2000. URL: http://xmpp.org/extensions/xep-0220.html This Last Call begins today and shall end at the close of business on 2013-05-10. Please consider the following questions during this Last Call and send your feedback to the standards@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! Digging out my print copy i found some notes regarding stream compression and session managment in 2.1.1 (after example 3). Have we resolved http://mail.jabber.org/pipermail/standards/2012-May/025999.html and http://mail.jabber.org/pipermail/standards/2012-May/025998.html ?
[Standards] LAST CALL: XEP-0220 (Server Dialback)
This message constitutes notice of a Last Call for comments on XEP-0220 (Server Dialback). 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 initiating server, it does not process traffic over the connection until it has verified the initiating server's key with an authoritative server for the domain asserted by the initiating server. Additionally, the protocol is used to negotitate whether the receiving server is accepting stanzas for the target domain. Although Server Dialback does not provide strong authentication and it is subject to DNS poisoning attacks, it has effectively prevented address spoofing on the XMPP network since its development in the year 2000. URL: http://xmpp.org/extensions/xep-0220.html This Last Call begins today and shall end at the close of business on 2013-05-10. Please consider the following questions during this Last Call and send your feedback to the standards@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!
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] 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] 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] LAST CALL: XEP-0220 (Server Dialback)
Old thread alert! On 11/19/10 7:20 AM, Philipp Hancke wrote: > David Richards wrote: >> I would like to see the advertisement section (2.3) revised to be more >> prescriptive about how to use the two forms. It seems to me that an XMPP >> 1.0 stream should only advertise with the old dialback namespace >> method on >> the initial stream element of the negotiation in case it's a 0.9 >> implementation. When opening a stream to a peer server, you don't know if the peer is XMPP-compliant (1.0) or pre-XMPP (0.9), so how can you know whether to include the dialback namespace or not? >> If the response is a 0.9 stream then keep going in that >> mode. If the response is a 1.0 stream, it should not include the old >> namespace I don't see any harm in including the dialback namespace, so SHOULD NOT might be too strong. >> and then must include a dialback feature. Not including the >> feature seems wrong - 0220 only says it is preferred, not required. I'd be fine with that. >> 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. The problem is that no one behaves this way now, so in all likelihood dialback negotiation would break if your server is strict about this behavior, resulting in a lack of interoperability. > This _might_ break things with good old jabberd1. At least not including > the dialback namespace in the stream header on a 1.0 stream failed back > in... 2006. Perhaps we can do some testing? I'm sure there are still jabberd 1.4 servers and other "0.9" implementations on the network. I don't see a good reason to break backward-compatiblity if we don't have to. >> Also, why the recommendation to have dialback required and SASL >> optional if >> both are advertised? I'm not sure it matters, just curious about the >> rationale. Seems like the server would mark as required the one that it >> prefers since it doesn't make sense to do both - sort of a makeshift >> priority indicator. > > I think we can just remove the and , since that > is no longer defined in 3920bis :-) Correct. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
David Richards wrote: I would like to see the advertisement section (2.3) revised to be more prescriptive about how to use the two forms. It seems to me that an XMPP 1.0 stream should only advertise with the old dialback namespace method on the initial stream element of the negotiation in case it's a 0.9 implementation. If the response is a 0.9 stream then keep going in that mode. If the response is a 1.0 stream, it should not include the old namespace and then must include a dialback feature. Not including the feature seems wrong - 0220 only says it is preferred, not required. 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. This _might_ break things with good old jabberd1. At least not including the dialback namespace in the stream header on a 1.0 stream failed back in... 2006. Also, why the recommendation to have dialback required and SASL optional if both are advertised? I'm not sure it matters, just curious about the rationale. Seems like the server would mark as required the one that it prefers since it doesn't make sense to do both - sort of a makeshift priority indicator. I think we can just remove the and , since that is no longer defined in 3920bis :-) Thanks for the feedback! philipp
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
OK, so it does matter whether SASL or dialback is marked required since there is no stream restart on dialback - correct? Which of course bega that question as well. -Original Message- From: David Richards [mailto:dricha...@coversant.com] Sent: Friday, October 22, 2010 10:40 AM To: 'XMPP Standards' Subject: RE: [Standards] LAST CALL: XEP-0220 (Server Dialback) I would like to see the advertisement section (2.3) revised to be more prescriptive about how to use the two forms. It seems to me that an XMPP 1.0 stream should only advertise with the old dialback namespace method on the initial stream element of the negotiation in case it's a 0.9 implementation. If the response is a 0.9 stream then keep going in that mode. If the response is a 1.0 stream, it should not include the old namespace and then must include a dialback feature. Not including the feature seems wrong - 0220 only says it is preferred, not required. 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. Also, why the recommendation to have dialback required and SASL optional if both are advertised? I'm not sure it matters, just curious about the rationale. Seems like the server would mark as required the one that it prefers since it doesn't make sense to do both - sort of a makeshift priority indicator. Dave Richards
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
I would like to see the advertisement section (2.3) revised to be more prescriptive about how to use the two forms. It seems to me that an XMPP 1.0 stream should only advertise with the old dialback namespace method on the initial stream element of the negotiation in case it's a 0.9 implementation. If the response is a 0.9 stream then keep going in that mode. If the response is a 1.0 stream, it should not include the old namespace and then must include a dialback feature. Not including the feature seems wrong - 0220 only says it is preferred, not required. 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. Also, why the recommendation to have dialback required and SASL optional if both are advertised? I'm not sure it matters, just curious about the rationale. Seems like the server would mark as required the one that it prefers since it doesn't make sense to do both - sort of a makeshift priority indicator. Dave Richards
[Standards] LAST CALL: XEP-0220 (Server Dialback)
This message constitutes notice of a Last Call for comments on XEP-0220 (Server Dialback). 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. URL: http://www.xmpp.org/extensions/xep-0220.html This Last Call begins today and shall end at the close of business on 2010-11-12. Please consider the following questions during this Last Call and send your feedback to the standards@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!
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On Nov 17, 2008, at 3:24 AM, Philipp Hancke wrote: I have not seen any strictly separated inbound and outbound boxes for quite some time. Even gmail does not use this feature (they connect from 209.85.163.125, aka xmpp-server4.l.google.com (which is contained in the set of names returned when looking up _xmpp-server._tcp.gmail.com). There is another reason why dialback is better than a simple dns lookup. It protects against evil shell users on the originating server that are able to open connections using its address. Since there exists a good reason that we agree on, we don't have to agree on the first one. :)
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Joe Hildebrand schrieb: On Nov 13, 2008, at 4:27 AM, Philipp Hancke wrote: If you want to remove dialback, maybe we should check if it can be replaced by a dns lookup. Historically I that dialback is a result of jabberd not binding to the proper ip address: http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html There's a deployment reason for dialback. If you want your inbound and outbound connections on separate boxes, it's handy to not just rely on the IP address of the outbound server matching the one returned from DNS. I have not seen any strictly separated inbound and outbound boxes for quite some time. Even gmail does not use this feature (they connect from 209.85.163.125, aka xmpp-server4.l.google.com (which is contained in the set of names returned when looking up _xmpp-server._tcp.gmail.com). There is another reason why dialback is better than a simple dns lookup. It protects against evil shell users on the originating server that are able to open connections using its address.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Peter Saint-Andre wrote: This Last Call has ended. I received some feedback off-list, which I will consolidate and post to the list next week. Not neccessary. I finally had the time to fully read this version :-( 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes. 2. Does the specification solve the problem stated in the introduction and requirements? Probably. However, it should explain, why dialback is preferable over a simple DNS lookup. I can think of at least two reasons. 3. Do you plan to implement this specification in your code? No. My current implementation has worked well enough for five years. 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? No. See below for details. I have read various versions of this. RFC 3920, 3920bis, all versions of 220. The description has changed quite a lot in each version... Details: (The XMPP Standards Foundation (XSF) [4] has worked to make certificates easier to obtain by running the XMPP Intermediate Certification Authority [5].) This 'advertisement' is completly misplaced. Anyone reading this spec wants to find out about dialback, not about the ICA. because the certificate presented by the peer service during TLS negotiation is self-signed and local service policies stipulate that it is preferable to weakly identify the peer service via Server Dialback rather than depend on the self-signed certificate for identity verification. I think I criticized this sentence multiple times now, with no effect. Now I would like an explanation: what service policy _uses_ self- signed certificates for identity verification? Section 2 is very boring. I read RFC 3920, I know how to resolve addresses, how to open a connection etc. Why is this repeated? Most error cases described herein belong to 3920bis. there is no IP address associated with this domain since it is merely asserted by the Originating Server There is an ip address associated with this connection. Usually it is the 192.0.2.23, but for sake of the argument it is better to use a different address. The Receiving Server SHOULD include the dialback feature I still do not see a reason for this. If the sending side is not using sasl, it will assume that is has to authenticate - using dialback. If SASL is used, dialback is unnecessary, at least according to the XEP. 2.2.1: I agree with what Matthias said in <[EMAIL PROTECTED]> . Jer came up with a smart method to check the dialback keys, but it is not the only way of doing it. Example 17+18: can not happen unless you piggyback. Otherwise, that error would have occured earlier (example 11). 2.5.2: what happens to the connection between receiving and authoritative server? As said before, this may be closed by the receiving server, however this is left unspecified here. The authoritative server MUST NOT close this connection. 2.5.3.1 The Receiving Server then SHOULD also terminate the XML stream and the underlying TCP connection between the Receiving Server and the Authoritative Server. MAY also terminate. Closing this connection makes no sense usually. 3. Support for piggybacking is OPTIONAL. This is consensus? I certainly disagree, even though I used to highly dislike piggybacking. The passive part of piggybacking is not difficult to implement. db:result type='error' Not necessary if the spec demands support for (passive) piggybacking. The specification fails to describe 2-connection dialback and 3-connection dialback. The former is reusing the R2A connection as the new O2R, the latter opens a TCP connection just for the verification of the dialback key. Usually, this will also use SSL for that, which then results in even more roundtrips and perceived latency.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On Nov 13, 2008, at 4:27 AM, Philipp Hancke wrote: If you want to remove dialback, maybe we should check if it can be replaced by a dns lookup. Historically I that dialback is a result of jabberd not binding to the proper ip address: http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html There's a deployment reason for dialback. If you want your inbound and outbound connections on separate boxes, it's handy to not just rely on the IP address of the outbound server matching the one returned from DNS.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Dave Cridland wrote: Well, going forward, I'm hoping we'll remove the need for dialback at all. I'd like to hope it remains purely as a stub protocol for connection reuse, and that db:verify simply disappears in a puff of certificate equality checking. (Which it could do, I think). Get a large list of servers and check how often this would work in practice. I wonder if the old ratio of 1/10 from 2007 is still valid. If you want to remove dialback, maybe we should check if it can be replaced by a dns lookup. Historically I that dialback is a result of jabberd not binding to the proper ip address: http://mail.jabber.org/pipermail/xmppwg/2002-October/000155.html Two questions: 1) Do any server implementations actually do piggybacking anymore? I have a recent log of gmail.com piggybacking googlemail.com. Philipp
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On Nov 12, 2008, at 2:12 PM, Dave Cridland wrote: Thanks, this is really useful. On Wed Nov 12 11:56:57 2008, Pedro Melo wrote: 3. Section 3, Reuse of Connections (piggybacking) 1. Cosmetic: maybe we should start using the term multiplexing; I think changing it now would be more confusing than not changing it. Ok, it was mere cosmetic issue. 2. The second paragraph limits the piggyback connections to sub- domains of the initial negotiated domain. I don't see any security reason for this. You can allow any domain to be multiplexed on an already existing connection, provided that the dialback verification process is successful. This would allow services with large number of domains to reuse S2S connections much easily. Interesting - I don't read that as limiting reuse to that case, I read it as saying that's merely a typical reason. Indeed, Google used to do this kind of piggybacking, and as I recall, it couldn't cope with piggybacking being refused. ok, I read it as a limitation. I'll re-read. 3. Support for multiplex connections Going forward, it would be cleaner if the Recv Server announces support for multiplexed connections in the initial stream features. Something like: R2O: This clearly announces support for the feature and would precent try- and-miss attempts on future servers. Well, going forward, I'm hoping we'll remove the need for dialback at all. I'd like to hope it remains purely as a stub protocol for connection reuse, and that db:verify simply disappears in a puff of certificate equality checking. (Which it could do, I think). Two questions: 1) Do any server implementations actually do piggybacking anymore? 2) Do any server implementations reject piggybacking attempts, as per Example 45? Going forward, if we get servers hosting thousands of domains, multiplex/piggyback is a must have feature, IMHO. I think the number of S2S would soon get out of hand if you don't use multiplex. But actually this is another topic, so I'll refrain from talking about it in this thread :) Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
On Fri, Nov 7, 2008 at 11:47 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > This Last Call has ended. I received some feedback off-list, which I > will consolidate and post to the list next week. > I recently finished implementing dialback. The XEP seems ok, minus the points that Pedro highlighted (I missed many of those myself). There is also a use of remote-server-timeout in the notes under examples 12 & 18. I have not added support for piggybacking. I don't know what other servers support and actively use it, so I don't yet know what happens when another server attempts it. I'm afraid I have not even begun to test my implementation for compliance, it just "works" at the moment, hence I haven't really studied the error cases yet. Matthew.
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Thanks, this is really useful. On Wed Nov 12 11:56:57 2008, Pedro Melo wrote: 3. Section 3, Reuse of Connections (piggybacking) 1. Cosmetic: maybe we should start using the term multiplexing; I think changing it now would be more confusing than not changing it. 2. The second paragraph limits the piggyback connections to sub- domains of the initial negotiated domain. I don't see any security reason for this. You can allow any domain to be multiplexed on an already existing connection, provided that the dialback verification process is successful. This would allow services with large number of domains to reuse S2S connections much easily. Interesting - I don't read that as limiting reuse to that case, I read it as saying that's merely a typical reason. Indeed, Google used to do this kind of piggybacking, and as I recall, it couldn't cope with piggybacking being refused. 3. Support for multiplex connections Going forward, it would be cleaner if the Recv Server announces support for multiplexed connections in the initial stream features. Something like: R2O: This clearly announces support for the feature and would precent try- and-miss attempts on future servers. Well, going forward, I'm hoping we'll remove the need for dialback at all. I'd like to hope it remains purely as a stub protocol for connection reuse, and that db:verify simply disappears in a puff of certificate equality checking. (Which it could do, I think). Two questions: 1) Do any server implementations actually do piggybacking anymore? 2) Do any server implementations reject piggybacking attempts, as per Example 45? Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
Hi, I found the following items that need correction: 1. Section 2, Protocol: in the first bullet set, the fourth bullet is wrong, it should be "The Stream ID of the stream from the Receiving Server to the Originating Server is ..." - the servers are reversed; 2. Section 2.3.4.2: there is an empty Note Well block in the fourth paragraph. 3. Example 31, 35 and 41: the error should be failed>, as the text before the example states. The following items are questions I have about the spec: 1. Section 2.4.2.2: Error cases for Authoritative Server Processes Verification Request Two error cases are shown, but I think a third is also required: the value of the 'from' address provided by the Receiving Server is not authorized to connect to you. If some miss-configured outgoing S2S service at Originating Server initiates a connection to a domain that he was not allowed to, then the Authorization Server has this opportunity to prevent the connection from completing. 2. Section 2.6.2.1, Invalid connection from Auth Server to Recv Server The spec notes that the Recv Server MUST close the connection to the Auth Server if it receives a of type='invalid'. If the verification is being performed in a piggyback connection (as permitted in Section 1.5, last note), this is not very helpful because it could close an already active and useful connection. I would suggest that a doesn't alter the connection at al. This way the Recv Server can reuse that connection for other purposes, including other verifications. Also notice that the behavior (whether to close or not the connection after receiving the ) is left unspecified in the following Section 2.6.2.2, Valid Connection. A small note common to both 2.6.2.1 and 2.6.2.2 staging that the connection between Recv and Authz can be left open for reuse probably clarifies the whole issue. 3. Section 3, Reuse of Connections (piggybacking) 1. Cosmetic: maybe we should start using the term multiplexing; 2. The second paragraph limits the piggyback connections to sub- domains of the initial negotiated domain. I don't see any security reason for this. You can allow any domain to be multiplexed on an already existing connection, provided that the dialback verification process is successful. This would allow services with large number of domains to reuse S2S connections much easily. 3. Support for multiplex connections Going forward, it would be cleaner if the Recv Server announces support for multiplexed connections in the initial stream features. Something like: R2O: This clearly announces support for the feature and would precent try- and-miss attempts on future servers. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] LAST CALL: XEP-0220 (Server Dialback)
This Last Call has ended. I received some feedback off-list, which I will consolidate and post to the list next week. XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on > XEP-0220 (Server Dialback). > > 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 receives a server-to-server connection request from an > originating server, it does not accept the request 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. > > URL: http://www.xmpp.org/extensions/xep-0220.html > > This Last Call begins today and shall end at the close of business on > 2008-11-07. > > Please consider the following questions during this Last Call and > send your feedback to the standards@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] LAST CALL: XEP-0220 (Server Dialback)
This message constitutes notice of a Last Call for comments on XEP-0220 (Server Dialback). 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 receives a server-to-server connection request from an originating server, it does not accept the request 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. URL: http://www.xmpp.org/extensions/xep-0220.html This Last Call begins today and shall end at the close of business on 2008-11-07. Please consider the following questions during this Last Call and send your feedback to the standards@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!
