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

[Harlan Stenn <[e-mail]>]

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 - 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!