[Ntp] Re: Grease in Roughtime

[[e-mail]]

Hey Marcus,

sorry, I just don't see how it works.
I see the stated purpose: forcing client implementations to actually 
verify signatures rather than cheaping out and skipping that operation.
I also see the stated measure: instructing server implementations to 
occasionally give bad time with faulty signatures.
But I cannot see how the latter achieves the former.

(As a side note, the stated purpose already seems weird to me: why would 
clients deliberately cheap out and forgo a major benefit of the whole 
protocol? And why would anyone else want or need to enforce that they 
don't? It literally only hurts the client itself)

>From where I'm standing, the client implementations are still 100% free to 
cheap out. 
Sure, they will have false time if they do, but... they won't necessarily 
even know that, and thus not have any reason to change anything.
If it is meant as a deterrent (and TBH I think anything that I won't even 
notice if it happens is a terrible deterrent) - wouldn't the possibility 
of there being an attacker already achieve that, too?

It seems like we're instructing implementations to randomly behave badly 
for no (to me) tangible benefit.
Would appreciate any help in understanding this.


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.:        [phone]
E-Mail:   [e-mail]
__________________________________________



Von:    "Marcus Dansarie" <[e-mail]>
An:     [e-mail]
Kopie:  "[e-mail]" <[e-mail]>
Datum:  24.09.2024 17:41
Betreff:        Re: [Ntp] Re: Grease in Roughtime



Hi Kristof,

the point of greasing the signatures by providing bad time and bad 
signatures is to force implementations to check signatures, thereby 
preventing lazy implementations. Greasing signatures in this way has 
been in the text since Aanchal's first draft in 2019. The latest change 
just makes the purpose explicit.

Kind regards,
Marcus


On 2024-09-24 09:46, kristof.teichel=[e-mail] wrote:
> Hi Marcus,
> 
> thanks for doing my pull request and integrating my changes. I should 
> have done it earlier, but didn't.
> 
> About the GREASE section... can you explain the thinking behind randomly 

> sending faulty packets?
> a)     How would anyone (other than the client itself) even know whether 

> or not the client reacted correctly (discarding a packet with 
> inconsistent data or an invalid signature)?
>      I don't think I see who would even evaluate this as a test, much 
> less how this could "ensure that clients validate signatures".
>      What am I missing here?
> b)    Wouldn't it make more sense to send packets with a valid timestamp 

> but invalid signature - so that in the case of misbehaviour (accepting 
> the time in spite of incorrect signature), nothing terrible would 
happen?
> 
> 
> 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.:    [phone]
> E-Mail: [e-mail]
> __________________________________________
> 
> 
> 
> Von: "Marcus Dansarie" <[e-mail]>
> An: [e-mail]
> Datum: 23.09.2024 22:49
> Betreff: [Ntp] Re: Grease in Roughtime
> ------------------------------------------------------------------------
> 
> 
> 
> Thanks for the comments!
> 
> I just made a pull request on Github
> (https://github.com/ietf-wg-ntp/draft-roughtime/pull/4 <https:// 
> github.com/ietf-wg-ntp/draft-roughtime/pull/4>) that should
> clarify how grease is used in Roughtime. It also addresses most of
> Martin and Kristof's comments.
> 
> On 2024-09-17 13:52, David Venhoek wrote:
>> First of all, regarding the ver tag, there is no requirement for
>> servers to ignore unknown versions in that tag. this means that
>> technically it is valid behavior right now for a server receiving
>> unknown versions to reject that packet, even if there is version
>> overlap. This seems highly undesirable
> 
> I don't think I fully understand the problem you are describing here
> however. Could you give an example?
> 
> Kind regards,
> Marcus
> 
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
> 
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]