[dtn-security] comments on security draft 01

"Mooi Choo Chuah" <mcchuah@gmail.com> Mon, 17 April 2006 20:51 UTC

Received: from wproxy.gmail.com (wproxy.gmail.com []) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id k3HKpbg25212 for <dtn-security@mailman.dtnrg.org>; Mon, 17 Apr 2006 13:51:38 -0700
Received: by wproxy.gmail.com with SMTP id 50so629086wri for <dtn-security@mailman.dtnrg.org>; Mon, 17 Apr 2006 13:51:37 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=kPjAUwNDj301zB+gkVBBprUNitUFPF92X5KyH9PsOIJXXYSDbxUWkdr+GtNDiQ0LpkT+8r+n9sk8CIztLvk/OpObBmB9koUCMbCfFwdWik1pyUwej/u14WuFOXznJQfv64N1L6t+3ztVpXsNyjxFLCHzzm4E9aiL+hf/8Ul19P8=
Received: by with SMTP id u4mr3569308wra; Mon, 17 Apr 2006 13:51:37 -0700 (PDT)
Received: by with HTTP; Mon, 17 Apr 2006 13:51:37 -0700 (PDT)
Message-ID: <380141b20604171351p786e210w90b8402d7180c1ba@mail.gmail.com>
Date: Mon, 17 Apr 2006 13:51:37 -0700
From: "Mooi Choo Chuah" <mcchuah@gmail.com>
To: dtn-security@mailman.dtnrg.org
In-Reply-To: <380141b20604110519x28490227oba8cc8299453ff06@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_12909_13143867.1145307097155"
References: <380141b20604110519x28490227oba8cc8299453ff06@mail.gmail.com>
Subject: [dtn-security] comments on security draft 01
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

Dear all,
Susan encouraged me to send these comments to all so that others can respond
too. I already got some answers from her.

Mooi Choo

 Hi Susan,
here are the comments/questions Walter and I have on your security draft 01.

1. pg 5, 3rd line BN4 not BPA4.

2, pg 7: header processing flags - I think a clear definition (even if this
is not finalized) of the different flags will be helpful to the readers.

3. pg 9: an example of when the two instances: an "up front" BAH instance
containing ciphersuite and another that contains security result will be
used will be helpful.
The correlator field is not well explained. Again, an example will help.

4. pg 12: The sentence "Subsequent CH security results will contain headers
encrypted using the BEK if non-payload headers are to be encrypted" needs to
be expanded with an example.
Can we include an ASCII version of the slide that we have exchanged in the
document? I think it will help to clarify this. We can put this in the
Appendix. It will help the readers understand certain sentences.

5.  pg 13: The sentence "This would result in uses of PSH which presumably
all protect the payload, and which cannot in general protect one another" is
confusing. An example explaining this will be helpful.
6. pg 22 - explain more about mulitple security results embedded in the

Also, explain more about what you meant by "the bundle MUST be fragmented
immediately after the last security result value in the partial payload that
is received".

Say I have an original bundle that has CH and PSH invoked. The encrypted
payload is 1000 bytes but I only manage to transmit 230 bytes out (the 1st
fragment has the CH and PSH as drawn in the slide we exchanged). Then, what
do I do with the 2nd fragment that I sent out? Do I include just the BAH (if
it is invoked) and the remaining 770 bytes of encrypted payload?

also, although it may be obvious, I think it will help if we say we treat
custody transfer ack the same as regular bundle - meaning if security
feature is invoked, it will apply to custody transfer too.

Mooi Choo