Subject: Re: [Ntp] WG: NTS-related digression (WAS: Re: WG Call for Adoption: draft-stenn-ntp-extension-fields)

From: [email-masked]
Date: Wed, 1 Aug 2018 11:38:58 +0200

Oh my, it seems I really needed a crash course in early history of crypto 
security (and on even the first details of actually applying Moore's law). 

I never even questioned that 32 bits must have been acceptable at some 
point during Autokey's design. Thanks, Daniel.

Anyway, this just emphasizes my original issue, which is that I dislike 
the implications of using "is a valid replacement for Autokey" as a 
serious criterion, specifically related to the modes of operation covered.
Autokey is negligible as something to measure up against (unless you 
measure against what promises instead of what it delivers).

Von:    "Daniel Franke" <[email-masked]>
An:     [email-masked]
Kopie:  [email-masked], "Harlan Stenn" <[email-masked]>
Datum:  30.07.2018 19:27
Betreff:        Re: [Ntp] WG: NTS-related digression (WAS: Re: WG Call for 
Adoption: draft-stenn-ntp-extension-fields)
Gesendet von:   "ntp" <[email-masked]>

On Mon, Jul 30, 2018, 06:32 <[email-masked]> wrote:
Apart from the point it makes about insufficient bit lengths, I don't 
think any of the detected weaknesses have much to do with Moore's law (and 
believe me, if we could have just updated Autokey with an erratum to the 
effect of "larger bit lengths" and achieved a secure spec that way, we 
would have gladly done so years ago). 

Neither can the use of a 32-bit key be excused be "Moore's law caught up". 
DES was designed in 1975 with a 56 bit key, and this was widely understood 
to be too short by at least the mid 90s. At no date since the dawn of 
computers has 32 bits ever been a remotely reasonable choice.
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 2 Aug 2018 00:04:40 -0700

Brian,

On 7/30/18 4:56 AM, Brian Haberman wrote:
> Harlan,
> 
> On 7/30/18 6:44 AM, Harlan Stenn wrote:
>> Kristof,
>>
>> You may raise some good points here.
>>
>> But given we know we are planning to deprecate Autokey, I can't really
>> see the point in continuing this discussion.
>>
>> There are a lot of other crypto algorithms and protocols that are now
>> obsoleted.
>>
>> What possible good can come from continuing this thread?
>>
>> We know we need something better than RFC-5906.
> 
> Agreed.
> 
>>
>> NTS was supposed to be that.
>>
>> NTS is now nowhere near a solution for anything other than client/server
>> mode.  It's partially-cooked chicken.
> 
> I have no involvement in the development of NTS, but I find this
> statement a bit misleading. If you were to provide ratios for each of
> the NTP modes of operation, wouldn't client/server be well above 80%?
> And wouldn't that mode be the one that would benefit the most from
> enhanced security?
Have you thought about "later", when we do have something that supports
client/server, symmetric modes, manycast, multicast, and control modes,
and we also still have NTS to carry along?

Misleading?

I have no idea what the percentages are.  I submit the percentages don't
really matter.  I do know that symmetric mode is used inside an
enterprise more than it is over the internet.  Multicast and manycast
are also used more in an enterprise than over the internet.

Is the partially-cooked chicken metaphor more clear now?

NTS was originally designed to be as close to a full replacement for
Autokey as possible.  We're now seeing that 1-way broadcast is
apparently an intractable problem, but that's mitigated because IPv6
doesn't do that type of broadcast.  I'll add that for the reference
implementation, in an enterprise setting one can watch for spoofed
source addresses, and one can also use the 4th argument of the ntp.keys
file to limit what IPs are allowed to be time servers.  So in the
primary (only?) situation where broadcast time might be useful, it
remains a reasonable alternative choice if one does a decent job at the
risk/rewards analysis.

The current NTS draft originally attempted to support symmetric mode.
But that proved to be so difficult and cumbersome that attempted support
for this mode was dropped.  It is therefore ... doubtful that some
future mechanism that is consistent with the design of NTS will be found
that will support symmetric mode, or multicast/manycast.

The current NTS spec has plenty of warts and other things I think are
either wrong or kludgey.  But I'm not going to restate my mention of
these now.

Given that there are people who really want a security model for NTP
that is beyond private keys, and given the fact that NTS cannot find a
way to support more than client/server after years of effort, it seems
almost certain that an elegant and efficient way to support "more than
client/server" will not be forthcoming.

Therefore, a solution that supports "more than client/server" that
involves NTS will likely need to carry along the NTS baggage, for years.

Our SNT proposal (which to-date has a staggeringly lame write-up)
addresses these issues, and we'll be publishing this spec as soon as we
can.  We certainly hope to have both a proper proposal and a
demonstrable implementation by the interim meeting in October.

To be clear, NTF is also continuing to work on its implementation of NTS
as well.

I'm also about to post the latest from Dave Mills and I, which builds on
his previous postings.  This is also mentioned in the email I just sent
to the list on Dave's behalf.

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 2 Aug 2018 10:09:49 +0200

> and we also still have NTS to carry along?

Is this solution described in an I-D or is it purely aspirational?

I freely admit failure in relating this to any form of poultry,
cooked or otherwize.

	Cheers Leif