Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-using-nts-for-ntp

[Harlan Stenn <[e-mail]>]

On 12/8/18 12:39 PM, [e-mail] wrote:
> I'm on my browser mail client and sadly can't respond in-line without making a 
> mess of the formatting.
> 
> The summary of my response is: yes, we have seen most or all of the here-cited 
> concerns of yours before, and dismissed them.
> Sorry if that was not always communicated clearly enough - although I have a 
> feeling that in most cases, it was.

They were not clearly dismissed "for cause".

If you simply disagree with them, that's not "for cause".

> 
> In any case, let me give short-ish versions of replies regarding the mentioned 
> points:
> 
> - The "earmarked" EF type thing: to me it looks like you're basically trying to 
> have NTS make people adhere to an NTF-internal numeration system (the only place 
> I know of where it is "standardized" is the Autokey RFC?). That, I oppose.

To say this is an NTF-internal numeration system is wrong and
inappropriate.  It would not even be correct to say it adheres to an NTP
Project internal numeration system.  I say this for the following reasons:

- EFs were invented to deal with Autokey.  The first code for this dates
back to June of 2000.  RFC5906 was not passed for *10 more years* - June
of 2010.  NTF did not even exist until June of 2011.

- The general format and structure of EFs should have, in hindsight,
been specified in 5905, not 5906.  This also set the stage for the
difficulties that led to RFC7822, and the subsequent problems because of
the content of RFC7822.  We are still trying to see these problems
fixed, and that's what draft-stenn-ntp-extension-fields, first published
in November of 2016, is all about.  Note again that the co-author of
that proposal is Dave Mills.  I say this as a reference to the
extraordinary amount of history, knowledge, and experience Dave has with
NTP, the protocol, the code, and the Standards process.

Like it or not, the usual order of events is "make sure the code works
and is fully tested and follows the desired engineering principles, then
write the standard, then review the code and the standard to find and
fix any discrepancies."  That's why it took 10 years to come up with
5905 and 5906.  Note that a driving force behind 7822 was 7821, which
became the *second* EF type defined, after 15 years of there being only
one EF type.  If you *don't* like the way the standard has been
developed, I ask you to evaluate the costs and benefits of the way we've
been doing it, and then the costs and benefits of switching to anything
else.  Couple this with the amount of time it takes to get even the
simplest of proposals thru this working group.  Are you seriously
suggesting that we spend 2-3+ years in the simple case (5.5 years' so
far on NTS) to create the standard before we implement it in the hope
that it works?  I know my answer to that.

- I spent a long time trying to convey to Karen and Dieter the reasons
why we CANNOT simply let IANA randomly (or even sequentially) assign EF
types when an EF proposal is advanced.  The NTP Project believes it is
critical and essential that changes to the standards be known to work,
be as well-tested and robust as possible, that whenever possible avoid
incompatibilities.  If there are implementations out there that use one
EF value and this value changes as a result of this WG not recommending
an EF type to IANA, we are creating both damage and extra work.  Do you
disagree?

You say that the EF enumeration is standardized in the Autokey RFC and
you oppose it.  If I understand you correctly I appreciate your honesty.
 By that logic, people can ignore whatever they want with any part of a
standard and do what they want if they oppose the standard, right?

So can you cite technical support and benefit to using, for example, EFs
10, 11, 12, and 13 for the 4 NTF messsages, as opposed to using the EF
type we (Karen, Dieter, and the NTP Project) agreed on, 4, with subcodes
0x0104, 0x0204, 0x0304, and 0x0404?  How do you justify using 4 separate
EF codes instead of 1?  Please note that as written, we have NO IDEA
what numbers IANA might assign for the NTS EFs.

> - Being "monolithic": this seems like a mere impression that you have that is 
> also mostly false (e.g. a client could choose to send no cookie placeholders and 
> ignore all fresh cookies - though I do not advertise this idea). I can only 
> guess what you would like us to do about your concern, and the things I am 
> guessing (such as dividing AEAD and fresh cookies off into some kind of optional 
> sub-mode), I definitely oppose.

You have missed the point.

The cookies are part of the NTS proposal.  They could be separate.

The AEAD stuff is part of the NTS proposal.  It could be separate.

*This* is what I mean by monolithic.

> - TCP matters: are you seriously suggesting for NTS to rest until a number of 
> other drafts potentially reach RFC status? If not, what exactly are you 
> suggesting? If so, I oppose.

I am saying I objected to reserving a new TCP port for NTS, a long time ago.

If "you" wanted to avoid any delay around this, any of the following
could have been done:

- "you" could have designed this better before submitting it.

- "you" could have designed this better or sought collaboration to fix
it once it was first brought up.

- "you" could have offered/offer to collaborate on the proposals I
submitted to fix this.  But if that was something you were really
interested in, I would suspect this case might be covered by the
previous two options.

> - The "one cookie/placeholder per field" issue: could someone who has 
> implemented this please elaborate on the typical size of a cookie? In any case, 
> a placeholder must by design be as large, so I'm not convinced there is any 
> issue here. In either case, I don't see an actionable suggestion (I can guess at 
> one, bit for that one I would still need to be convinced there is an issue in 
> the first place).

I'm a little stunned that as an author of this proposal you do not know
how long cookies will be.  I am more than a little stunned that none of
the other authors have spoken up about this.

If this information is not known, this tells me the proposal has not
been adequately engineered and should not be advanced until such time as
we know how it will behave.

The issue isn't "people don't have to use cookies".  The issue is "what
happens if people use cookies", and how many cookies will they use, and
what is the expected padding overhead that will be used to satisfy 7822?

> - The "all modes or bust" issue: I remember giving you a lengthy response to 
> this previously. Please stop insisting this concern has never been adressed. 
> Also, what is you actionable suggestion? Put everything on hold, until solutions 
> have been found that everyone including you can agree on, for modes that are 
> used significantly less than the one adressed? If so, I oppose.

You have said you disagree with it, but you have neither addressed the
concern nor proposed a solution.  Simply saying "it's too hard" doesn't
cut it.

On the one hand, with the described NTS architecture it is clearly hard
to solve this problem.  Evidence of this can be found by the fact that
attempted support for symmetric mode has been removed, and while we all
agree that supporting this for 1-way broadcast is not practical, Dave's
proposal clearly supports symmetric mode and may well support m*cast modes.

On the other hand, we hear from a lot of people that they want the
codebase to be as small as possible.  Implementing client/server NTS and
then adding in completely separate code paths to deal with symmetric
mode and m*cast will bloat the code.

> - The "Dave has a viable alternative" claim: what is the proposed "solution" of 
> which you speak? I remember a document skeleton which barely had more than 
> headlines for its sections, and I remember a lengthy document that switched 
> between a vague critique of mixed NTS versions and a proposal for what a 
> proposal might look like (where some of the few concrete suggestions would be 
> attackable with methods straight out of Roettger's 2012 critique of Autokey)... 
> if you mean either of those then please stop bringing them up as though there 
> was a serious discussion to be had at this point. If you mean something else, 
> please refer us to it so that a real discussion is possible. And again, what 
> would even be your actionable suggestion to us, the editors of the NTS document?

For the answer to this, I'd recommend you re-read Dave's proposals
again, and engage with him on it.

What I can tell you is that the proposal we've been working on boils
down to:

- Use a TCP connection to perform key exchange, algorithm agreement, etc.

- Come up with an independent cookie scheme.  It could be the current
model, over UDP or TCP (which would seem to avoid the need for AEAD), or
it could use other models.  Either way, as an INDEPENDENT scheme, it
would be easy to create additional schemes, as opposed to trying to do
this via the monolithic NTS model.

- Come up with an independent AEAD scheme, assuming it's useful.  Is
there a known use-case for AEAD beyond the cookie exchange?

Once we have keying information, we can trivially use the existing MAC
and the proposed MAC-EF mechanisms for security.  I will again point out
that doing this INSTANTLY gives us support for client/server and
symmetric modes, and may well handle m*cast (I haven't looked).

And the other point is that Dave is currently unable to comment on these
issues, but we all have a pretty good idea of what he thinks.  I have
every reason to believe he is still opposed to the adoption of the NTS
document as written.

> Is there anything else (preferably actionable suggestions) you still feel has 
> not been adressed?

Not sure, and doing that full analysis would require an immediate and
massive amount of my time and attention.  Frankly, since you have
repeatedly dismissed all my previous attempts to communicate these
points to you, I'm having trouble seeing why this instance would be any
different.

I don't mean the following to be unkind:  There are really only 2
experienced implementors here - the NTP Project, and Miroslav.  Miroslav
ignored EFs for a very long time because the only implementation out
there that provided them was the Reference Implementation.  While he has
his experience with the NTP codebase, that may not translate well into
implementation with chronyd.  If one is being honest, NTPsec doesn't
count as it stopped being a reference implementation because even though
it's a fork from the NTP Project, when it threw out everything except
the core stuff it ceased to be a reference implementation.  The other
issue is there doesn't seem to be anybody actively (or even inactively)
coding on that project who has more than a couple of years' experience
with the codebase.  I'll stop now.

This WG is, of course, free to make whatever decisions it wants.

I submit the underlying issues here are:

- disagreement - objectively technical issues
- disagreement - subjectively technical issues
- disagreement - one person's signal is another person's noise

which then boils down to collaboration issues.

I'll say it again: I am happy and eager to work with people of good
character who are competent and collaborative.

My underlying point is that we owe each other as well as the larger
community we serve an excellent specification and implementation.  This
draft is not, IMO, an excellent specification.

H
--
> Best regards,
> Kristof
> 
> 
> -----"ntp" <[e-mail] <mailto:[e-mail]>> schrieb: -----
> An: [e-mail] <mailto:[e-mail]>
> Von: "Harlan Stenn"
> Gesendet von: "ntp"
> Datum: 07.12.2018 23:05
> Betreff: Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp
> 
> I am strongly supportive of the goal of providing a replacement for
> Autokey, as soon as possible.
> 
> As written, I am opposed to the adoption of this proposal, as the
> detailed objections and concerns I have repeatedly raised have still not
> been addressed.
> 
> Off the top of my head, here is a (partial?) summary of my objections:
> 
> - we have long earmarked EF type 4 for NTS, and this is still not in the
> document as a recommendation for IANA.  In particular, if the proposal
> advances as written we would want to see:
> 
> |   0x0104   | * NTS Unique Identifier Request              |
> |   0x8104   | * NTS Unique Identifier Response             |
> |   0x0204   | * NTS Cookie                                 |
> |   0x0304   | * NTS Cookie Placeholder                     |
> |   0x0404   | * NTS AEEF Request                           |
> |   0x8404   | * NTS AEEF Response                          |
> 
> (or similar).  There is no good reason to leave it up to IANA to
> possibly assign 6 random EFs for this use case.
> draft-stenn-ntp-extension-fields (for which I will be trying to post an
> update soon) clearly and simply describes this.
> 
> - The proposal is too monolithic, and we would all be better served with
> a proposal that separates the cookie mechanism and encrypted transfers
> into separately-usable mechanisms.  There may be other similar cases as
> well, but my brain is too fuzzy right now to think more about this.
> 
> - It creates a separate TCP service/port specifically for NTS key
> exchange.  This is wasteful in general, and would be better served by
> folks collaborating on:
> 
>   draft-stenn-ntp-tcp-services
>   draft-stenn-ntp-tcp-services-keyexchange
> 
> - The proposal uses multiple Cookie and Cookie Placeholder messages (as
> I recall - see my other message about the cold I'm still recovering
> from) instead of having a single Cookie and Cookie Placeholder message
> that supports multiple entries.  This would not be an issue if 7822 did
> not specify a 28-octet minimum final EF size, or if
> draft-stenn-ntp-extension-fields was implemented (or being considered,
> even).
> 
> - It only supports client/server mode, and it does so in a way for which
> adding support for symmetric and [mb]*cast modes had been demonstrated
> to be problematic.  We need an encompassing solution, and this isn't it.
> 
> It would not surprise me at all to discover issues I have forgotten to
> list above that are in my previous messages on this topic.
> 
> I'm sorry I haven't had the resources to once again re-study and re-list
> my objections to this proposal.
> 
> Dave Mills has posted several papers about the above problems including
> a proposed solution, but for whatever reasons, for years we have
> continued to pursue this increasingly limited solution instead of
> working towards a better/more functional solution.
> 
> As I said in an earlier message, Dave is currently unable to receive or
> send email messages, so he apparenetly can't participate in this WGLC.
> 
> -- 
> Harlan Stenn <[e-mail] <mailto:[e-mail]>>
> http://networktimefoundation.org - be a member!
> 
> _______________________________________________
> ntp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ntp
> 

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