[xmppwg] Security layer byte precision in xmpp-core-18

[Justin Karneges]

Hi,

Under the "security layer negotiation" entry of section 6.4:

'The security layer takes effect immediately after sending the closing ">" 
character of the <success/> element for the server, and immediately after 
receiving the closing ">" character of the <success/> element for the client 
(this element is qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 
namespace).'

I think this should instead read:

'The security layer takes effect immediately after sending the closing ">" 
character of the <success/> element for the server, and immediately after 
sending the closing ">" character of the final <response/> element for the 
client (this element is qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 
namespace).'

Otherwise it is not clear what happens to data that the client sends between 
sending of the final <response/> element and the receiving of the <success/> 
element from the server.

For instance, 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: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.  
However, there should be no problem if it does, provided that it is encoded 
by the security layer properly.  My proposed text change above covers this 
case completely, I think.

Likewise, we must fix section 5.1 for TLS:

'The receiving entity MUST consider the TLS negotiation to have begun 
immediately after sending the closing ">" of the <proceed/> element. The 
initiating entity MUST consider the TLS negotiation to have begun immediately 
after receiving the closing ">" of the <proceed/> element from the receiving 
entity.'

It should read:

'The initiating entity MUST consider any data it sends after the closing ">" 
of the <starttls/> element to be part of the TLS negotiation.  The receiving 
entity MUST consider the TLS negotiation to have begun immediately after 
sending the closing ">" of the <proceed/> element. The initiating entity MUST 
consider the TLS negotiation to have begun immediately after receiving the 
closing ">" of the <proceed/> element from the receiving entity.'

There might be additional places in the document where these things are 
mentioned, and they must be updated also.

In case it is not clear why this needs to be clarified, consider that my test 
client was sending an extra LF character after each element and this was not 
causing any problems when it clearly should have.  This could have later led 
to my client to fail when connecting to a more strict server implementation.  
This clarification ensures that other client developers don't make this 
mistake.

-Justin