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

[Harlan Stenn <[e-mail]>]

I'll provide a more detailed response to your previous email about this
as soon as I can.  It might be later tonight.

On 12/9/18 3:43 AM, [e-mail] wrote:
> Fair enough, I guess.
> 
> However, please don't use "Harlan hasn't gotten his way on issue X" and "issue X 
> has never even been adressed" interchangably.

I think that's an inappropriate and offensive thing to say, and I
challenge you to either clearly support it or retract it.

> Otherwise, anyone trying to follow the WGLC discussion who isn't aware of the 
> history might be confused.
Perhaps it would be at least inadequate for people to follow the WGLC
discussion and *not* consider the history.

If you are saying that the WGLC discussion should be a complete
discussion of the issues, I would object to that.  That's an incredible
amount of work for each person involved to do, and I really have better
uses for my time and attention than to rehash things that you, for
example, have already said you will "dismiss".

> Also, please clarify what the mentioned "proposed solution" by Dave is referring to.
> Merely claiming that there is some holy grail document that people are just 
> ignoring for no good reason does not further constructive discussion.

Please search the email history.  I'm pretty sure there are at least
one, and possibly two documents from Dave in there, and there are
certainly other related discussions.

H
--
> 
> Best regards,
> Kristof
> 
> 
> -----"ntp" <[e-mail] <mailto:[e-mail]>> schrieb: -----
> An: [e-mail] <mailto:[e-mail]>
> Von: "Harlan Stenn"
> Gesendet von: "ntp"
> Datum: 09.12.2018 06:48
> Kopie: [e-mail] <mailto:[e-mail]>
> Betreff: Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-using-nts-for-ntp
> 
> Hence my objections remain.
> 
> H
> 
> On 12/8/2018 12:39 PM, [e-mail] <mailto:[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.
>  >
>  > 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.
>  >
>  > - 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.
>  >
>  > - 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.
>  >
>  > - 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).
>  >
>  > - 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.
>  >
>  > - 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?
>  >
>  > Is there anything else (preferably actionable suggestions) you still feel has
>  > not been adressed?
>  >
>  >
>  > Best regards,
>  > Kristof
>  >
>  >
>  > -----"ntp" <[e-mail] <mailto:[e-mail]> 
> <mailto:[e-mail]>> schrieb: -----
>  > An: [e-mail] <mailto:[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]> 
> <mailto:[e-mail]>>
>  > http://networktimefoundation.org - be a member!
>  >
>  > _______________________________________________
>  > ntp mailing list
>  > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>  > https://www.ietf.org/mailman/listinfo/ntp
>  >
> 
> -- 
> 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!