Subject: [dtn-interest] On dependence of security on synchronized clocks

From: <[email-masked]>
Date: Mon, 18 Aug 2014 12:49:15 +0000

(well, this list seems dead.)

http://engineering.bergcloud.com/2014/08/problem-with-ntp/

has a nice practical example of how security starts to break without synchronised clocks.

Insist on the need for security, and you will insist on the need for synchronised clocks. Which is, I think, where DTN came in.

(The problem's a litte contrived, in that you should be getting time from someone you trust - private tunnel - or someone your ISP views as authoritative, which is its timeserver. Timeserving across the internet is often messier than the hierarchy one might expect. But still, nice example.)

Lloyd Wood
http://sat-net.com/L.Wood/dtn

---

From: Sebastian Schildt <[email-masked]>
Date: Mon, 18 Aug 2014 15:13:50 +0200

Hi Lloyd,

> has a nice practical example of how security starts to break without synchronised clocks.
It has a passing mention that SSL relies on synchronized clock

> 
> Insist on the need for security, and you will insist on the need for synchronised clocks. 
I think that is a highly debatable statement. (Well, actually stated this generally,  I think it is not true). I do acknowledge that time is an important topic, and that no notion of time, or not fully synchronized clocks, does not make the job of designing suitable security concepts easier...

But obviously agreeing on the notion, concept and usage of time (keeping security in mind) would be an important working point for a WG (also the RG in case the WG thingy is not going forward...). Then build suitable security concepts on top.

 However, in my opinion the current best practice, with absolute time and optionally age blocks is just fine. I would not want to remove "time" from the protocol at all, because often it is feasible and helpful. In the same vain I would not like to rely only on an age block concept.  It would not be a problem not to demand (synchronized) clocks for a DTN, but also specify "If you want to use this and this security concept, you need synchronized clocks".

The question is, whether the protocol should say something about time synchronization between nodes or not (we could just declare this an user's problem). While I would not say it is already a "spec-worthy" solution, IBR-DTN has a simple "just-works" time sync approach builtin: When enabled, and I meet a node with a higher clock rating, I take his clock. This is general enough as  not to be tied to special assumptions, and can be fine-tuned on an application basis with regard to the actual clock ranges and degradation values.

Sebastian

P.S.: Hope the list feels less dead now :)