Subject: [xmpp] 11.3. Well-Formedness (MUST close the stream is too strict)

From: Curtis King <[email-masked]>
Date: Wed, 8 Sep 2010 10:40:29 -0700

11.3.  Well-Formedness

   There are two varieties of well-formedness:

   o  "XML-well-formedness" in accordance with the definition of "well-
      formed" from Section 2.1 of [XML].
   o  "Namespace-well-formedness" in accordance with the definition of
      "namespace-well-formed" from Section 7 of [XML-NAMES].

   The following rules apply.

   An XMPP entity MUST NOT generate data that is not XML-well-formed.
   An XMPP entity MUST NOT accept data that is not XML-well-formed;
   instead it MUST return an <xml-not-well-formed/> stream error and
   close the stream over which the data was received.

   An XMPP entity MUST NOT generate data that is not namespace-well-
   formed.  An XMPP server MUST NOT route or deliver data that is not
   namespace-well-formed, and MUST return a stanza error of <not-
   acceptable/> or a stream error of <xml-not-well-formed/> in response
   to the receipt of such data.

      Interoperability Note: Because these restrictions were
      underspecified in [RFC3920], it is possible that implementations
      based on that specification will send data that does not comply
      with these restrictions.

The only problem I have with this section is "MUST return an <xml-not-well-formed/> stream error and close the stream over which the data was received." is too strict. 

If servers must handle xml being not well formed without closing the connection why can't a client? It turns out to-be an easy DOS attack if a server isn't 100% compliant. I know it's bug if the server is routing bad XML, but let's face the fact all implementations have bugs. If a client can handle some bad XML it should and not be mandated to close the connection.

cheers,

ck

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 12:01:15 -0600

On 9/8/10 11:40 AM, Curtis King wrote:
> formed" from Section 2.1 of [XML]. o  "Namespace-well-formedness" in
> accordance with the definition of "namespace-well-formed" from
> Section 7 of [XML-NAMES].
> 
> An XMPP entity MUST NOT generate data that is not XML-well-formed. An
> XMPP entity MUST NOT accept data that is not XML-well-formed; instead
> it MUST return an <xml-not-well-formed/> stream error and close the
> stream over which the data was received.
> 
> Interoperability Note: Because these restrictions were underspecified
> in [RFC3920], it is possible that implementations based on that
> specification will send data that does not comply with these
> restrictions.
> 
> 
> The only problem I have with this section is "MUST return an
> <xml-not-well-formed/> stream error and close the stream over which
> the data was received." is too strict.
> 
> If servers must handle xml being not well formed without closing the
> connection why can't a client? It turns out to-be an easy DOS attack
> if a server isn't 100% compliant. I know it's bug if the server is
> routing bad XML, but let's face the fact all implementations have
> bugs. If a client can handle some bad XML it should and not be
> mandated to close the connection.

The reason servers are called out in the quoted text is that they act as
gatekeepers to the network. If a client doesn't close the stream upon
receiving such data, there is no broader harm.

Furthermore, why do you think that servers must handle non-well-formed
data without closing the stream? A server is given a choice of returning
a stanza error or a stream error, but the text does not say that a
server MUST handle non-well-formed data without closing the stream.

Do you have specific text change to propose? As document editor I'm not
sure what to change based on your comments.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Curtis King <[email-masked]>
Date: Wed, 8 Sep 2010 11:15:04 -0700

> receiving such data, there is no broader harm.

Accept to the person using the client :-)

> data without closing the stream?

Must was the wrong wording on my part. Servers have option as you point out and I would like the client to have the same option.

> A server is given a choice of returning

I would like the client to have the same option as the server, "MUST return a stanza error of <not-acceptable/> or a stream error of <xml-not-well-formed/> in response to the receipt of such data."

It would be nice to add in the interoperability note, "a xmpp entiity should handle not well formed with a stanza error when possible"

ck

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 12:35:45 -0600

On 9/8/10 12:15 PM, Curtis King wrote:
>>> o  "XML-well-formedness" in accordance with the definition of
>>> "well- formed" from Section 2.1 of [XML]. o
>>> "Namespace-well-formedness" in accordance with the definition of
>>> An XMPP entity MUST NOT generate data that is not
>>> XML-well-formed. An XMPP entity MUST NOT accept data that is not
>>> XML-well-formed; instead it MUST return an <xml-not-well-formed/>
>>> stream error and close the stream over which the data was
>>> received.
>>> 
>>>  formed.  An XMPP server MUST NOT route or deliver data that is
>>> not namespace-well-formed, and MUST return a stanza error of
>>> <not- acceptable/> or a stream error of <xml-not-well-formed/> in
>>> response to the receipt of such data.
>>> 
>>> <xml-not-well-formed/> stream error and close the stream over
>>> which the data was received." is too strict.
>>> 
>>> If servers must handle xml being not well formed without closing
>>> the connection why can't a client? It turns out to-be an easy DOS
>>> attack if a server isn't 100% compliant. I know it's bug if the
>>> server is routing bad XML, but let's face the fact all
>>> implementations have bugs. If a client can handle some bad XML it
>>> should and not be mandated to close the connection.
>> 
>> The reason servers are called out in the quoted text is that they
>> act as gatekeepers to the network. If a client doesn't close the
>> stream upon receiving such data, there is no broader harm.
> 
>> Furthermore, why do you think that servers must handle
>> non-well-formed data without closing the stream?
> 
> Must was the wrong wording on my part. Servers have option as you
> point out and I would like the client to have the same option.
> 
>> A server is given a choice of returning a stanza error or a stream
>> error, but the text does not say that a server MUST handle
>> non-well-formed data without closing the stream.
>> 
>> Do you have specific text change to propose? As document editor I'm
>> not sure what to change based on your comments.
> 
> I would like the client to have the same option as the server, "MUST
> return a stanza error of <not-acceptable/> or a stream error of
> <xml-not-well-formed/> in response to the receipt of such data."

Aha, I see.

> It would be nice to add in the interoperability note, "a xmpp entiity
> should handle not well formed with a stanza error when possible"

How is the following text?

   An XMPP entity MUST NOT generate data that is not namespace-well-
   formed.  An XMPP entity MUST NOT accept data that is not namespace-
   well-formed (in particular, an XMPP server MUST NOT route or deliver
   data that is not namespace-well-formed); instead it MUST return
   either a stanza error of <not-acceptable/> or a stream error of <xml-
   not-well-formed/> (where it is preferable to return a stream error
   because accepting such data can open an entity to certain denial of
   service attacks).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Curtis King <[email-masked]>
Date: Wed, 8 Sep 2010 11:39:09 -0700

>   because accepting such data can open an entity to certain denial of

Works for me.

Thanks!

ck

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 12:55:50 -0600

>>   because accepting such data can open an entity to certain denial of

Super. I'm going to submit version -14 of 3920bis now so that our
esteemed chairs can request an IETF Last Call. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/