[Ndn-interest] Ndn clock synchronization requirements

[David R. Oran]

On 14 Jun 2019, at 6:22, Viktor S. Wold Eide via Ndn-interest wrote:

> On Thu, Jun 13, 2019 at 7:58 PM Mosko, Marc <mmosko at parc.com>
> <mmosko at parc.com> wrote:
>>
>> SignatureTime and SignatureSeqNum are both in the current NDN spec.  
>> SignatureTime has been around since the beginning.  I am not sure 
>> when SignatureSeqNum was introduced.  SignatureTime may be used both 
>> in signed Data and signed Interest.
>>
>> The SignedInterest spec 
>> (http://named-data.net/doc/NDN-packet-spec/current/signed-interest.html) 
>> has an explicit dependency on CurrentTime() being loosely synced (a 
>> 60 second grace period) to determine if the first interest with a key 
>> is valid, then it slides forward from that time if SignatureTime is 
>> used.
>>
>> One could use a SignatureNone (and remember a nonce history) or 
>> SignatureSeqNum instead.
>>
>> I agree with your premise that one should be explicit about time 
>> dependency -- which components have it and why and how can one use a 
>> alternatives if desired.
>
> OK, thanks.
>
> I see that SignatureTime may be present or not, and that there are
> other alternatives such as SignatureNonce/SignatureSeqNum.
>
> The question then becomes - is SignatureTime used in any way in any of
> the core protocols / software?
>
> If any core protocol / software relies on SignatureTime, then clock
> synchronization becomes a hard requirement.
>
It’s a bit weaker than that, since those functions/applications that 
don’t depend on accurate time will still work ok.

> It that is not the case, then nothing in the core protocols / software
> should fail if clocks are not synchronized, not from SignatureTime at
> least.
>
> I understand that it might not be such a clean cut, but I would 
> appreciate
> if someone could share their insight in this respect.
>
Yes, it’s not a clean cut, in two ways:
(1) there are (at least) two regimes: things that only depend on clocks 
not being insane (i.e. having large error or big jumps into the past or 
the future) and those where skew or drift on application timescales 
matter. Some applications (like professional video) have pretty tight 
drift and skew requirements on their synchronization. Most signature 
schemes are pretty loose where the bound can be hours or more - adequate 
to support reasonably robust key rollover and certificate revocation.
(2) In order to have a complete system without external dependencies, it 
does seem important to be able to obtain time good enough for for your 
target application using NDN protocols. So as we pointed out earlier, 
you have to design an NDN time protocol that has no clock dependencies, 
and once you have that, you can then leverage it to tell whether your 
time is only sane, or good enough to depend on for application 
semantics.


> Best regards
> Viktor S. Wold Eide.
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

DaveO