Re: [Ntp] Comments on Roughtime

Hi Hal,

replies in-line.

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________

"ntp" <ntp-bounces@ietf.org> schrieb am 14.08.2022 06:33:00:

> Von: "Hal Murray" <halmurray@sonic.net>
> An: ntp@ietf.org
> Kopie: "Hal Murray" <halmurray@sonic.net>
> Datum: 14.08.2022 06:33
> Betreff: [Ntp] Comments on Roughtime
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> 
> 
> Section 5.1.1 int32
>   You are using signed-magnitude when int32 is widely used to mean 2s 
> complement.
>   It doesn't even say "sign-magnitude until the second sentence.  I 
suggest 
> switching to 2s complement.  If you don't want to change the bits onthe 
wire, 
> split it into a flag and an uint31.
> 
> Sections 5.1.1, 5.1.2, 5.1.3: int32, uint32, uint64
>   All are "least significant byte first".  That's little endian.  The 
IETF is 
> traditionally big endian.  I don't know if you can get that past the 
> appropriate reviewers.  If you can, it needs some SHOUTING TEXT 
> warning of the 
> non-standard usage.
> 
> 
> Section 6.2.5 SREP
> 
>   Servers MUST ensure that the true time is within (MIDP-RADI, 
MIDP+RADI) at
>   the time they transmit the response message.
> 
> This gets into an interesting can of worms.  What does MUST mean in this 

> context?  I picture clock errors as having long tails.  How many 9s to 
you 
> want?  What's the right way to think about this?
> 
> Section 6.2.5, last sentence
>   ... server does not hold any updated leap second information.
>   Why the updated?  I think it makes sense if you remove it.
> 
> Section 12 Security Considerations, second paragraph.
>   Maintaining a list of trusted servers and adjudicating violations of
>   the rules by servers is not discussed in this document and is
>   essential for security. Roughtime clients MUST regularly update
>   their view of which servers are trustworthy in order to benefit from
>   the detection of misbehavior.
> 
> That conflicts with solving my 10 year problem.
> (My 10 year problem is a spare that sits on the shelf for 10 years. 
> That box won't have a RTC so it won't know the time when first 
> plugged in.  Traditional certificates will have expired...)

I find it obvious (and maybe we should have a document stating this, as it 
still seems to be a point of contention) that nothing (!)will truly solve 
your 10-year problem.

You can take stuff very far I guess with human intervention on each device 
(i.e. manually setting its clock to roughly the right time), but really 
that effectively only means "unless a bad actor human can get physical 
access and the right access codes".

And with network protocol means alone, you can certainly improve chances 
that the individual device will happen to get it right, but if you assume 
a total lack of knowledge of current time in at least one direction (i.e. 
a device might have "hardcoded" some date that is 100% already past, but 
you can't possibly do that for a date that is 100% not past) and you also 
assume bad actors really trying to get the best of that device... then the 
device is simply out of luck.

> There are 2 types of misbehavior: bugs and evil.
> 
> I didn't find any discussion of how many servers to use.  With 3 
> servers, 2 can outvote 1 bad guy. ...  I think the same logic 
> applies to NTP servers and Roughtime servers.  Chronos may get 
> tangled up here. 

Yup, AFAWK anything will ultimately adhere to byzantine fault logic: you 
need 3n actors overall to even enable (!) countering n bad actors.

> Maybe we should start another thread.  Part of the
> discussion would be how old is your list of trusted servers.
> 
> I didn't look at any of the Merkle text.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp