Matthew Wild wrote: > On Wed, Oct 22, 2008 at 9:51 PM, XMPP Extensions Editor <[email protected]> > wrote: >> This message constitutes notice of a Last Call for comments on XEP-0205 >> (Best Practices to Discourage Denial of Service Attacks). >> >> Abstract: This document recommends a number of practices that can help >> discourage denial of service attacks on XMPP-based networks. >> >> URL: http://www.xmpp.org/extensions/xep-0205.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 [email protected] 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? >> > > Is not: > > 4.3 Unauthenticated Connections > > In accordance with RFC 3920, a server MUST NOT process XML stanzas > from clients that have not provided appropriate authentication > credentials, and MUST NOT process XML stanzas from peer servers whose > identity it has not either authenticated via SASL (see RFC 4422 [9]) > or verified via server dialback. > > misleading? I mean, you need to process incoming stanzas in order to > authenticate, etc. I know this is obvious, but perhaps the text should > mention presence/iq/message explicitly instead. > > ...or maybe I'm just being fussy :)
TLS and SASL negotiation elements are not stanzas as defined in RFC 3920 and rfc3920bis. But we can mention presence/message/iq if that helps make things clearer. > I also agree with Pedro that type='modify' seems wrong in example 1. > The RFC states modify means "retry after changing the data sent ". > Changing the data sent will not fix this error. However I do not think > it should be 'cancel' either (RFC: "do not retry (the error cannot be > remedied)") - rather I think it should be 'wait' (one of the other > resources may log out, for example). That's nothing you can count on -- the other resource might be logged in for 3 years with long-lived TCP connections. So I think "cancel" is more helpful here. > Also note that RFC3920bis specifies a completely different error in this case: > http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#bind-servergen-error-resourceconstraint Corrected. Peter
