Subject: [Ntp] WG: Re: Antw: Re: Antw: Re: Antw: Re: WG Call for Adoption: draft-stenn-ntp-extension-fields

From: [email-masked]
Date: Mon, 30 Jul 2018 13:30:44 +0200

The spec hard-codes the length of the secrets (down to the global server 
seed) underlying those MACs to 32 bits.
If a gazillion bit long MAC is based on a 32 bit secret, then I still only 
need to test 2^32 values - which by modern standards is a piece of cake.

Von:    "Harlan Stenn" <[email-masked]>
An:     "Ulrich Windl" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Datum:  30.07.2018 12:39
Betreff:        Re: [Ntp] Antw: Re: Antw: Re: Antw: Re: WG Call for 
Adoption: draft-stenn-ntp-extension-fields
Gesendet von:   "ntp" <[email-masked]>

On 7/30/2018 3:30 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[email-masked]> schrieb am 30.07.2018 um 12:05 in 
Nachricht
> <[email-masked]>:
> 
> [...]
>> Are you seriously trying to tell me that writing the spec first, then
>> implementing it, will generally produce a *better* result than 10 years
>> of actual engineering work that gets turned in to a specification?
> 
> Well, just look at the "key renewal" of autokey: Actually only the 
certificate is renewed, not the key. I'd call that a major design flaw.

I'll see if I can get Dave to reply to this.  I never paid that much
attention to it.

> The the key size: There were/are no provisions for using a longer key or 
different algorithms, so we need a new NTP protocol version to get that.

For the MAC?

You are completely wrong.  We've already supported 16, 20, and 24 octet
MAC lengths.  We've never changed the NTP protocol version for this. We
could allow for even larger MAC sizes now, with no problems.  We have
also long supported a number of different algorithms.

Even today, everybody is saying that 160 bits for a hash is still
sufficient. But if somebody *wanted* to send more, they certainly could.

But perhaps I am misunderstanding you.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 04:39:11 -0700

Yes, I'm not talking about autokey.

And the entire point of the EF type (2 for Autokey version 2) was that
we had room to grow this.  The original  spec reserved values  3-7 for
future versions of Autokey, expecting that non-Autokey EFs would start
with 8, and build to 255.

When it became clear that there was no interest in Autokey V3, there was
no need to continue to reserve EF types 3-7 for future versions of Autokey.

But we certainly *could* have created an Autokey V3, using EF #3, using
the subcodes and the flag bits (just like the extended information,
I-DO, and probably some other proposals do), and in that we could have
trivially increased the size of that cookie from 32-bits.  I wouldn't
call that field a "MAC".

H