Subject: [BEEPwg] Cipher block boundaries and the TCP mapping

From: james woodyatt <[email-masked]>
Date: Thu, 5 Aug 2004 22:29:43 -0700

everyone—

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?  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?

-- 
j h woodyatt <[email-masked]>

_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg

---

From: Darren New <[email-masked]>
Date: Fri, 06 Aug 2004 08:29:23 -0700

james woodyatt wrote:
> 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.

 >  If you wanted to do that,

That would be a request for the other side to ensure that frames match 
cypher blocks? 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.

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

-- 
   Darren New / San Diego, CA, USA (PST)
   "You may mail in the form, and wait 4 to 6 weeks, or call us and
    get your answer right over the phone... after being on hold for
    4 to 6 weeks."
_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg

---

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2004 10:35:16 -0700

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?
>
> 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.

> 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.

― ∴

---

From: Greg Hudson <[email-masked]>
Date: Sat, 07 Aug 2004 00:38:32 -0400

> begin (or end) on a cipher block boundary?

Why do you want this?  Don't TLS and SASL mechanisms have their own
padding facilities for encoding short blocks of data?

---

From: james woodyatt <[email-masked]>
Date: Fri, 6 Aug 2004 21:58:55 -0700

On 06 Aug 2004, at 21:38, Greg Hudson wrote:
>> not

Ack.  My mistake.  I just found the section of RFC 2222 that deals with 
this.  I swear it wasn't there the last time I looked.  I am such a 
moron.  Sorry.

― ∴