Subject: [dtn-interest] FW: Another question: DTN security discussion summary (01/2005)
From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Date: Fri, 28 Jan 2005 14:04:53 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Subject: Re: Another question: DTN security discussion summary (01/2005)
From: "Stephen Farrell" <[email-masked]>
To: "Susan F. Symington" <[email-masked]>
Date: Tue, 25 Jan 2005 06:20:17 -0500

Hi Susan,

1. There's no need to have contiguous data, all practical
hash algorithms have to have a stateful start/continue/end
mode of operation so you can run the hash over data that's
bigger than your buffers. I would however agree that hashing
over a contiguous block of PDU makes it easier to explain,
which is IMO a very useful security benefit, and is perhaps
more extensible since you start by saying that everything
from here to there is hashed, which allows you to add in
a new field in the middle later on without changing code.
Only other issue would be the tiny performance improvement
of just making one call vs. 3 (start/cont/end) where the
to-be-hashed data is small enough to fit into a single
buffer. I wouldn't get excited either way, so long as
its crystal clear exactly which bits are input to the
hash.

2. Bits are generally better as I said, and 16 bits is
plenty for any field I'd expect. So, if you're saving
bytes you're comparing a 2 byte field represnting a bit
length, vs. a one byte field representing an octet
length. Using the SDNV style approach, you actually
only get 7 bits in that octet, so once you're regularly
processing >1024 bit signatures, you've lost that
saving. I'd never expect a MAC to be that long and
only RSA keys really produce such long signatures and
 >1024 bit sigs will be common in future. (Note though
that other signature algorithms like ECDSA produce
shorter sigs.) Basically, YMMV.

So, if you really want to use byte lengths, then you
can do so, by simply mandating that only cryptosystems
and keys which can fit values unambiguously into byte
boundaries are to be used. Which is fine in practice,
but not quite ideal in general.

Cheers,
Stephen.

PS: Just out of curiosity, who's "us"?

Susan F. Symington wrote:
> Stephen,
> 
> Thanks for the positive feedback.  You make some good suggestions and I
> appreciate receiving them.
> 
> I am wondering if you can help us with two additional item that have been
> raised in response to the recent write-up that I sent out. 
> 
> 1. In that write-up, you might remember that one of the proposed solutions
> that was presented was to pre-pend the BAH header to the bundle to
> facilitate having the information over which the BAH hash would be
> calclulated be contiguous, rather than have to perform a "scatter/gather"
> operation to calculate the hash (with the added complication that some of
> the headers/fields are variable-length).
> 
> This proposal to pre-pend the hash has been met with by some skepticism.
Not
> everyone is convinced that there is any need or even advantage to having
the
> information over which the hash is to be calculated be contiguous. We are
> wondering if you might perhaps have some useful experience that would give
> us some insight into whether or not we are making a valid assumption when
we
> say that it is desirable to have the information be contiguous. 
> 
> As far as you know, do any hash algorithms require contiguous blocks of
data
> for their computation? If not, do you know if computation is significantly
> facilitated if the information over which the hash is computed are
> contiguous?
> 
> 2. The proposal that the length fields for the BAH authentication
> information and the PSH security information (both of which hold either
> digital signatures or message authentication codes) be used to signify the
> bit-length, rather than the byte-length of these values has also been met
> with skepticism. Folks are interested in saving the space that would be
> required to provide bit-lengths if it would be possible to instead always
> provide byte-lengths and have the receiving node infer how many 0-bits
have
> been inserted on the left, if possible. Given that the communicating
parties
> will know a) the hash algorithm used, b) the encryption algorithm used to
> generate either the digital signature or the message authentication code,
> and c) and the key used with the encryption algorithm, is there any way
that
> the receiving party can use this information to determine the bit-length
of
> the authentication information?  
> 
> Thinking of it in terms of an example: when the receiving DTN node
receives
> a bundle with a BAH, it computes its own hash on the received bundle.
> Clearly it knows the length of this hash because it computes it. 
> 
> Next, the receiving node must decrypt the received authentication
> information. It has the encryption algorithm and the key to perform this
> decryption, and it knows what the length of the result should be (i.e. the
> length of the hash it computed above). Suppose that the length of the
> authentication information is always provided in terms of bytes and, if
the
> length of the actual information is not a multiple of 8, 0-bits are put in
> the left to pad out the leftmost byte of this informatmion. This means
that
> the receiving node knows the bit-length of the authentication information
to
> within 8 bits. Is this enough information to enable the receiving node to
> always be able to determine the bit-length of the authentication
> information? 
> 
> The feedback that I have heard so far is that since we expect most
> authentication information to be a multiple of 8, it would be nice if we
> could just use byte values in the length field. For the rare cases in
which
> the lengths that are not a multiple of 8, we should infer the actual bit
> length from the information the receiving node already has. Is this even
> feasible?
> 
> We would appreciate hearing any insights or useful experience thath you
may
> have with these issues.
> 
> Thanks.
> 
> -susan
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, January 24, 2005 12:13 PM
> To: Susan F. Symington
> Cc: [email-masked]
> Subject: Re: [dtn-interest] DTN security discussion summary (01/2005)
> 
> 
> Hi Susan,
> 
> That all looks like it'll be a really good improvement
> to the security parts of the next version of the spec.
> 
> If the new src. routing field is accepted, then there's
> maybe a need for a bit of security considerations text
> since it allows for the potential creation of a simple
> looping DoS, e.g. (src="foo,bar,foo") or similar. Note
> that this could be much harder to spot if some agents
> have aliases as in (src="foo,bar,alias-foo")]. While
> the forwarding count field allows detection of this,
> some security cons. text is still probably worthwhile.
> You'd also want to ensure that no negative forwarding
> count can be encoded, though I guess that's for free
> with what I'd expect your likely encoding would be. Not
> sure if that's worth a mention in the sec. cons section
> or not.
> 
> Likewise, the src. field could be used to mount a DDoS
> if loads of bundles have src addresses for the same
> victim waypoint, so guidance to implementers on that
> front might be useful. I guess the guidance is to watch
> out for unexpected peaks of traffic or something? In
> LTP, we've defined a cookie mechansism which could, at
> least in some scenarios, be turned on in such cases,
> though I think that that's probably not much good for
> bundles.
> 
> Also, (forgetting security for a bit), I'm wondering
> how the waypoint model works for regions that have
> more than one "exit"/gateway agent? If what I require
> is that the budle be reassembled at *some* region-exit,
> (but I don't care, or perhaps, know, which) can I
> specify that? Or maybe you discounted that scenario?
> If not, simply including the region without the
> admin part, might be a useful waypoint option to
> represent this case.
> 
> Lastly, there's probably a lot of literature and some
> experience with other source routing schemes (e.g. DSR),
> that might usefully be checked over - I personally am
> not familiar enough with that stuff to say if there's
> existing experience relevant to bundling. One thing I
> have heard though is that DSR was found not to scale
> for bigger MANETs since it involved making the headers
> too big. I realise that the waypoint model is probably
> better than specifying a route, but header inflation
> would still be a worry I guess if there are cases with
> links that have quite small MTU.
> 
> Cheers,
> Stephen.
> 
> 
> Susan F. Symington wrote:
> 
> 
>>All,
>> 
>>A few of us got together last week to talk about DTN security. Attached 
>>is a summary of that discussion.
>> 
>>-Susan Symington
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
>