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

From: [email-masked]
Date: Mon, 30 Jul 2018 11:12:58 +0200

I don't necessarily think this discussion will actually lead anywhere, but 
this comment should really not stand undisputed.

Yes, NTS is very much in at least one way the replacement for Autokey. 
It was explicitly started as "Autokey 2.0", and its main goal has remained 
to this day to provide a way to secure NTP packets in a way that scales 
well with the number of clients per server - the exact thing that Autokey 
set out to do (but failed).

Regarding feature-completeness: the way I see it, a specification that 
successfuly attempts to secure one use case is still objectively a good 
replacement for a specification that attempts to secure several and fails 
at each.

Regards,
Kristof

Von:    "Harlan Stenn" <[email-masked]>
An:     [email-masked]
Datum:  28.07.2018 04:55
Betreff:        Re: [Ntp] WG Call for Adoption: 
draft-stenn-ntp-extension-fields
Gesendet von:   "ntp" <[email-masked]>

A functional replacement for RFC5806 (Autokey V2) is very important.

NTS is in no way that replacement.

H

On 7/27/2018 5:32 AM, Brian Haberman wrote:
> 
> 
> On 7/26/18 8:23 PM, Harlan Stenn wrote:
>>
>>
>> On 7/26/2018 6:46 AM, Brian Haberman wrote:
>>> I'll keep this short and sweet... I agree with Daniel's assessment 
that
>>> we would be creating a mess within the protocol by adopting this 
document.
>>
>> I'm genuinely curious.  In what way do you think the proposal "would be
>> creating a mess within the protocol"?
> 
> This WG is effectively making it impossible for anyone (an implementer,
> an operator, or a user) to understand what is/isn't a part of NTPv4.
> 
>>
>>> Let's get NTS out the door and then we can worry about designing 
NTPv5,
>>> if there is interest.
>>
>> Let's keep NTS separate from this.
> 
> I made my comment as way to express a priority. I see it as far more
> important to publish NTS than anything else being discussed on the list.
> 
> Regards,
> Brian
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.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 02:19:44 -0700

On 7/30/2018 2:12 AM, [email-masked] wrote:
> I don't necessarily think this discussion will actually lead anywhere,
> but this comment should really not stand undisputed.
> 
> It was explicitly started as "Autokey 2.0", and its main goal has
> remained to this day to provide a way to secure NTP packets in a way
> that scales well with the number of clients per server - the exact thing
> that Autokey set out to do (but failed).

We're going to have to be careful here.  RFC-5906 was Autokey V2.

NTS would properly be Autokey V3, if that what anybody wanted to call it.

And Autokey did exactly what it was designed to do.

Moore's law caught up with it.

And we found different use-cases that would be greatly helped with
improvements.

But Autokey did not fail to do what it set out to do.

> replacement for a specification that attempts to secure several and
> fails at each.
> 
> 
> Regards,
> Kristof

OK, and I could put a nice piece of chicken in front of you, where the
skin is very crispy and well-seasoned, and the outer edges are cooked.

But if you bit in to it and the inside was raw, you would be talking
about the raw "insides", not how well the skin or outside was cooked.

Assuming, of course, that you like to each chicken.

---

From: [email-masked]
Date: Mon, 30 Jul 2018 12:31:02 +0200

All discussion about poultry aside...
"Autokey did not fail what it set out ot do" is another of those things 
that I think simply shouldn't stand undisputed.
How closely have you read Stephen Röttger's Autokey analysis? (Am I just 
unaware of a serious rebuttal of it?)

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). 
In particular:

- Autokey security for both client/server and peer mode can be broken by 
anyone capable of IP spoofing (he can just go "I am the client, please 
tell me my permanent secret key again?").
- Four of the five identity schemes for those two modes can also be 
directly broken by a Man-in-the-Middle attacker. For one of them, all it 
takes is almost literally writing "Dude, trust me" into the right 
extension field. The one that's left doesn't let the server operate 
statelessly (so no improvement over symmetric key scheme).
- For broadcast (this isn't in Stephen's analysis), the spec has to assume 
an attacker cannot prevent a packet from being delivered and cannot even 
delay it - the document itself states that if this assumption is removed, 
security is lost.

Since the Autokey spec tells us exactly what it sets out to do (Section 3) 
and one of the points is to "be resistant to cryptographic attacks, 
specifically those identified [...] above" and one of "those" is a 
Man-in-the-Middle attack: yes, it is safe to say that even at the time 
(that is, even if one assumes 32 bits to be a sufficient length for a 
crypto key or hash) it missed its most significant and overarching goal.

Best regards.
Kristof

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

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 03:44:33 -0700

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.

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.

Of all of the discussions we've had around NTS and friends over the
years, how much of it has been actually useful towards producing a
proper replacement for Autokey?  How much time has that taken?

H

On 7/30/2018 3:31 AM, [email-masked] wrote:
> believe me, if we could have just updated Autokey with an erratum to the Kristo

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Jul 2018 07:56:33 -0400

Harlan,

> We know we need something better than RFC-5906.

Agreed.

> 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?

Regards,
Brian

---

From: Daniel Franke <[email-masked]>
Date: Mon, 30 Jul 2018 13:25:57 -0400

> 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.