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

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

Harlan,

my original point was just this:
Please do not hold the idea of how great Autokey would be if only it was 
not broken as an alternative to an actual fleshed-out proposal.
Anything that works and is *actually secure* on its design level would be 
a good replacement for Autokey - by merit of the fact that Autokey is 
absolutely not.

The alternative to having one secured mode with good client-number scaling 
via NTS is *not* having three secured modes via Autokey.
It is having zero secured modes via Autokey (or, alternatively, having 
security with horrible client-number scaling via the symmetric key 
scheme).

Kristof

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

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:
> 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 
Kristo
> 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]>
> 
> 
> 
> 
> 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.
>>
>> 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).
> 
> 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.
> 
>> 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
> 
> 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.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Jul 2018 13:58:53 +0200

Skickat från min iPhone

> 30 juli 2018 kl. 13:32 skrev [email-masked]:
> 
> Harlan, 
> 
> Please do not hold the idea of how great Autokey would be if only it was not broken as an alternative to an actual fleshed-out proposal. 
> Anything that works and is *actually secure* on its design level would be a good replacement for Autokey - by merit of the fact that Autokey is absolutely not. 
> 
> The alternative to having one secured mode with good client-number scaling via NTS is *not* having three secured modes via Autokey. 
> It is having zero secured modes via Autokey (or, alternatively, having security with horrible client-number scaling via the symmetric key scheme). 
> 
> 

This is the ”running code” part of the famous IETF tagline. NTS has multiple groups willing to adopt and implement.

It seems clear that although NTS ”only” solves the client-server usecase, this constitutes the major usecase.

It also seems clear that the chairs original question has been answered.

> Betreff:        Re: [Ntp] WG: NTS-related digression (WAS: Re: WG Call for Adoption: draft-stenn-ntp-extension-fields) 
> > 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 Kristo
> > - For broadcast (this isn't in Stephen's analysis), the spec has to assume 
> > 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) 
> >> that scales well with the number of clients per server - the exact thing
> > NTS would properly be Autokey V3, if that what anybody wanted to call it.
> >