Re: [dtn-security] Detail of PSB change...

"Peter Lovell" <> Fri, 23 February 2007 15:32 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id l1NFWFY12628 for <>; Fri, 23 Feb 2007 07:32:16 -0800
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id l1NFW6hA006532; Fri, 23 Feb 2007 09:32:06 -0600
Received: from ( []) by (8.12.11/8.13.1) with ESMTP id l1NFVviS007951; Fri, 23 Feb 2007 09:32:06 -0600
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 10:31:56 -0500
From: "Peter Lovell" <>
To: "Stephen Farrell" <>
Cc: <>, "Peter Lovell" <>
Subject: Re: [dtn-security] Detail of PSB change...
Date: Fri, 23 Feb 2007 10:31:54 -0500
Message-Id: <>
In-Reply-To: <>
References: <>
X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) <>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2007 15:31:57.0043 (UTC) FILETIME=[C0BC6430:01C7575F]
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

>In a mail to dtn-interest I said:
> > PS: I'm not saying the current BSP spec has got this correct, it
> > probably needs fixing in a few ways. But I do think we can do that
> > in the BSP spec and not re-open the BP spec. E.g. perhaps we need
> > to add a optional "signature number" to the current PSB ciphersuite,
> > with the meaning that this is the n-th signature added or something.
>I just had a maybe-better/maybe-worse idea:
>We could add a "signature layer" value s.t. signatures with layer
>N cover all PSBs with layer < N. I think that's cute and maybe
>useful, but we'll have to think through the semantics.

Hi Stephen,

my thinking had been in that general direction. I hadn't included it in
my message as I wanted that to be mainly a description of the problem,
and not so much a speculation on possible solutions.

Rather than a "signature layer", I might call it a "layer identifier"
and apply it to all security blocks. For concreteness, let's think of it
as a one-byte field, although there is a scenario where we might need it
larger. [note 1]

Layers would be conceptually wrapped around the payload block. If you
add a new layer, its number is one greater than the largest number you
have already. You add the block (conceptually) at the front, just after
the primary. [note 2]

You can only remove or modify the outermost layer (can be recursive, though). 

The downside is that the numbers are only on security blocks, so we can
only deal with them, plus primary and payload itself, of course. We must
ignore all other extension blocks [note 3]. This is the current
situation with BSP but we had been hoping to extend coverage to metadata
- I'm not sure if we can do that now.


Note 1: we might need this in the case of adding blocks to fragment-
bundles, so we can differentiate between them when it comes time to
reassemble the bundle

Note 2: If you use a correlated block you add that at the back as the
last block. If you have several correlated blocks, they must all
conceptually follow the payload. This is a change for Confidentiality
suite #3, by the way, but workable. We can order the multiple correlated
blocks using the scheme we discussed a couple of days ago.

Note 3: for payload security and confidentiality ciphersuites. We can
solve the problem for bundle authentication ciphersuites, so all blocks
can be included in that digest process.