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

[[e-mail]]

"Harlan Stenn" <[e-mail]> schrieb am 10.12.2018 10:22:33:

> Von: "Harlan Stenn" <[e-mail]>
> An: [e-mail]
> Kopie: [e-mail]
> Datum: 10.12.2018 10:22
> Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-
> using-nts-for-ntp
> 
> 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.

I might have presented my assessment in an unnecessarily ad hominem 
manner, for which I apologize.

However, I absolutely stand by the core of it:
The issues you claimed had "still not been adressed" had long been seen, 
actively considered and publically commented on, some of them repeatedly.
>From my point of view, that makes your claim blatantly and obviously false 
- which is important, since your opposition is argued on this basis.

I simply didn't (still don't) know how to reconcile this, other than to 
assume we mean hugely different things when we talk about 'not addressing' 
an issue.
Perhaps you can tell us what exactly you meant by 'not adressed'?

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

My issue is not that I can find no documents from Dave or related 
discussions/documents in the history, it is that that there are several 
(including different versions), none of which I think meet your 
description ("proposed solution" to the listed issues, that would enable 
"working towards a better/more functional solution" [than NTS]).

So again, please clarify unambiguously which document you mean so we can 
have (or review) a discussion on it - because this WGLC would have 
definitely represented the time and the place to do just that.
 
> 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!