[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 [64.233.184.238]) 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 10.54.72.4 with SMTP id u4mr3569308wra; Mon, 17 Apr 2006 13:51:37 -0700 (PDT)
Received: by 10.54.69.15 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 payload) 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. Thanks, Mooi Choo
- Re: [dtn-security] comments on security draft 01 Stephen Farrell
- [dtn-security] comments on security draft 01 Mooi Choo Chuah