Security Layer Byte Precision?

Question

In the XMPP RFC, there are two MUST directives stating that the XML used for STARTTLS and SASL must not include any whitespace, for the sake of something that the spec states as "security layer byte precision". What is that?

---

Relevant extacts from RFC:

...

During STARTTLS negotiation, the entities MUST NOT send any whitespace as separators between XML elements (i.e., from the last character of the first-level element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace as sent by the initiating entity, until the last character of the first-level element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace as sent by the receiving entity). This prohibition helps to ensure proper security layer byte precision.

... During SASL negotiation, the entities MUST NOT send any whitespace as separators between XML elements (i.e., from the last character of the first-level element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the initiating entity, until the last character of the first-level element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the receiving entity). This prohibition helps to ensure proper security layer byte precision.

Answer 1

This directive is to ensure proper handling of byte streams. Imagine if a client sends a newline after XML fragments, it might send a response like this:

<response ... /> [LF]

The server will parse the XML incrementally up to the final '>', at which point it will send a <success/> element back to the client. Now the client will send a new stream start i.e. <stream:stream ... > using the security layer. This should cause the security layer to break on the server side, since it will expect the extra LF character to be part of the security layer when it is not.

You may say that the server should simply clear its receive buffer before issuing a <success/> packet, but this not the proper way to treat a bytestream. After all, the underlying subsystem might have delayed the delivery of that LF character, and the server might receive it after sending the <success/> packet.

The solution, of course, is for the client to NOT send such extra data. You can read more about this specific discussion here on the mailing list.