[BEEPwg] Cipher block boundaries and the TCP mapping

james woodyatt jhw at wetware.com
Fri Aug 6 11:35:16 PDT 2004


On 06 Aug 2004, at 08:29, Darren New wrote:
> james woodyatt wrote:
>> Is it my imagination, or does the TCP mapping for the BEEP protocol 
>> not specify any way for frames to be spaced properly so that they 
>> always begin (or end) on a cipher block boundary?
>
> Is there a need for this to be part of the protocol? There wouldn't 
> seem to be. Part of an API, perhaps, but not part of a protocol, I 
> would think.

I think it specifically needs to be a part of the protocol.  While some 
applications will use content types that can be padded at the tail of 
the entity body before the END\r\n trailer comes, others might not.  
There are also frames that have no payload to pad, e.g. the SEQ frame.

To get the spacing feature I want, I would allow zero or more null 
octets between the end of one BEEP frame and the start of the next BEEP 
frame, limited to no more than the current cipher block size of the 
SASL security layer or the TLS encryption cipher.

>> If you wanted to do that, would declaring it as a "feature" in the 
>> greeting be the right choice?  What would a specification of this 
>> extension look like?
>
> That would be a request for the other side to ensure that frames match 
> cypher blocks?

It could also be regarded as an advertisement to the other side that it 
is permitted to insert padding between frames.

> It would seem to make more sense to make that an option of the TLS or 
> SASL profiles, than as an option of the entire session.

Yeah, but there isn't a way to set an "option" in those profiles.

> Consider, what would be the meaning of this feature if TLS was never 
> invoked? What would be the meaning if TLS was already invoked?

The cipher block size for a session with no TLS and no SASL security 
layer tuning is exactly one octet, and no inter-frame padding would be 
allowed.


― ∴



More information about the BEEPwg mailing list