[dtn-security] Re(7): [dtn-interest] block-sequencing issue

["Peter Lovell" <[e-mail]>]

On Thu, Apr 19, 2007, Symington, Susan F. <[e-mail]> wrote:

>Peter, 
>
>I have a question about the BSP that relates to the below message that
>you sent out in February.
>You argued eloquently for the requirement that the ordering of blocks
>be preserved at all nodes, and now this change has been made to the BP.
>Which this change, the ordering of the bundles can be used to indicate
>in what order they should be processed. 
>
>What I'm not clear about is where in the BSP the text actually
>specifies what order certain operations should be performed in.  For
>example, If node 1 calculates and inserts a PSB1 on the bundle and then
>the next node, node 2, calculates and inserts a PSB2 on the bundle
>(including the BSP1 that was inserted by node 1) then some later node
>that wants to verify the security result of BSP 1 needs to know to
>exclude BSP2 and a node that wants to verify the security result of
>BSP2 needs to know to include BSP1. From your email, it seems that the
>relative order of BSP1 and BSP2 in the bundle is what indicates which
>signature covers which. My concern is that (unless I am missing it),
>the specification isn't very clear on how the relative ordering of two
>blocks determines how the security result of one does (or doesn't)
>include the other block.
>
>The only text in the spec that I could find that seems to address this
>issue is in 3.2.2, where it says, 
>    " - the ciphersuite will likely specify that the "current" security
>      block security result field not be considered part of the
>      canonical form.  This differs from the case in strict
>      canonicalisation since we might use the mutable canonicalisation
>      algorithm to handle sequential signatures, where later signatures
>      should cover earlier ones."
>
>Am I missing some text somewhere?
>
>Don't we need to add text to the PSB-RSA-SHA256 section, for example,
>that says something like:
>
>"If a PSB with this ciphersuite is being inserted into a bundle then:
> - it must be added after all other PSBs (if any) that are in the
>bundle,
> - its canonical form must include all PSBs that precede the PSB in
>question and must exclude the security result field of the PSB in
>question. 
>
>When verifying the security result in a PSB that uses this ciphersuite,
>all PSBs that precede the PSB in question must be included as part of
>the canonical form, all PSBs that follow the PSB in question must be
>excluded, and all fields of the PSB in question except for the security
>result field must be included?"
>
>(I'm assuming that this is how your implementation works.) 
>
>-susan


Hi Susan,

You are correct - there is additional language needed in BSP to discuss
the sequencing, as Keith's email had also suggested.

The block sequence is critical for things such as PS digests, as I
mentioned and as is now described in the spec. A second reason for
maintaining order is to determine the process sequence, which was
mentioned only lightly during the discussion.

Although we need language to define the processing order, that has been
hard to pin down. I've been trying to leave it open and use the BSP code
development as a guide to what we need to codify. 

There are some general principles I've been using ...

1. some actions don't need sequence at all, and can be done any time

2. some actions don't cause a change but must happen at a specific point
in the sequence, digest creation is a typical example

3. some actions change data and must happen at a specific point,
encryption being an example of this

4. the "layering" outward from the payload block is an indicator of the
processing sequence


There are some actions which don't have a marker in the sequence, with
fragmentation being the most obvious. Although there may be ways to
determine in some cases just when a bundle was fragmented, I'm not sure
if we can generally do it. For example, can we always tell whether
fragmentation was before encryption, or after it? We certainly can
sometimes tell, but I'm not certain about "always". 

I'm thinking about establishing a new extension block type to track
modifications, for those situations where there isn't a block already.
Although it would be a "block", core code would understand it. I'm
thinking of having it as a block mainly so the sequence/layering is
quite clear. It would then be easy to determine, for example, that a
bundle was fragmented, then encrypted, and fragmented again -- no
uncertainty at all.

This might also be a good alternative for bundle-in-bundle
encapsulation. The payload would then not be an administrative record,
with all the side effects you described in your recent email. Instead,
we'd have an extension block processor which deals with BiB, just as a
confidentiality ciphersuite does encryption. One advantage of this
approach is that the block can have the "relicate in every fragment"
flag set, so all fragments carry the BiB labeling (having the admin-
record information at the front of the payload means that it it's only
in the zero-offset fragment).

Regards.....Peter