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

[[e-mail]]

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.

Otherwise, anyone trying to follow the WGLC discussion who isn't aware of the history might be confused.

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.

Best regards,

Kristof 

-----"ntp" <[e-mail]> schrieb: -----

An: [e-mail]
Von: "Harlan Stenn"
Gesendet von: "ntp"
Datum: 09.12.2018 06:48
Kopie: [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] 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]>> 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" rel="nofollow">http://networktimefoundation.org - be a member!
>
> _______________________________________________
> ntp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp
>

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

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp