Subject: [Ntp] Fwd: WGLC: draft-ietf-ntp-using-nts-for-ntp

From: Karen O'Donoghue <[email-masked]>
Date: Mon, 3 Dec 2018 16:23:59 +0000

Folks,

We’ve extended this WGLC to this Friday, 7 December 2018. We’d still love some broader security review if possible. Note this protocol uses TLS so folks might to ensure we haven’t caused any problems there.

Karen

Begin forwarded message:

From: Karen O'Donoghue <[email-masked]<mailto:[email-masked]>>
Subject: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp
Date: November 6, 2018 at 3:46:12 PM EST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Folks,

This message initiates a three plus week working group last call for:

Network Time Security for the Network Time Protocol
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed.

Please send all comments in by COB on Friday 30 November. We realize this is a bit longer than normal but we are coming out of an IETF week and heading into the Thanksgiving holiday in the US.

Thanks!
Karen and Dieter
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Martin Langer <[email-masked]>
Date: Tue, 04 Dec 2018 10:52:39 +0100

Hello together,

the current NTS draft is fine for me and I have just a few comments.

page 7:

"Implementations MUST NOT negotiate TLS versions earlier than 1.2,
SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY
refuse to negotiate any TLS version which has been superseded by a
later supported version."

-> I guess the minimum TLS version MUST be 1.3. The effort for 
developers should be very small.
In OpenSSL, I only need one extra line of code to force TLS1.3 and 
disable TLS1.2. Many implementations
support the final TLS1.3 (RFC) or the latest TLS draft (see: 
https://github.com/tlswg/tls13-spec/wiki/Implementations).
The remaining platforms will probably follow soon. Therefore, I see no 
further need to support older TLS versions
than 1.3.

page 8:

"The semantics of record types 0-6 are specified in this memo."
-> must be '0-7'

page 15:

"Nonce length: Two octets in network byte order, ..."
-> must be 'Nonce Length:'

page 16:

"Additional Padding: Clients which use a nonce length shorter than
the maximum allowed by the negotiated AEAD algorithm may be
required to include additional zero-padding. The necessary length
of this field is specified below."

-> This confused me the first time. I thought it was a mistake and meant 
'minimum'.
'maximum' is right, but should we leave this information here?

Alternative form:
"Additional Padding: The nonce length used by the client maybe required
to include additional zero-padding depending on the negotiated AEAD
algorithm."

page 17:

"The purpose of the Additional Padding field is to ensure that servers
can always choose a nonce whose length is adequate to ensure its
uniqueness, even if the client chooses a shorter one, and still
ensure that the overall length of the server’s response packet. does
not exceed the length of the request."

-> in the penultimate line is a dot

page 19:

-> The timelines are different in length. (the client line need one more 
'-')

page 27:

"The Network Time Security Warning Codes Registry SHALL initally be
empty except for the reserved range, i.e.:"

-> typo: 'initially'

best regards,
Martin

-- 
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel. : +49 5331 939 43370
Web  : https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 6 Dec 2018 00:51:22 -0800

Folks,

Dave is currently unable to respond to any of these:

- UDel recently converted to using gmail for incoming email, and
  that has 'broken' incoming email for Dave.

- Dave recently converted his desktop machine from Windows 7
  to Windows 10, and all of his accessibility tools broke in
  the process.  He can't have the computer "read" to him, and
  he can't dictate either.

So he can't review the current documents, and he can't reply to them.

His previous comments on any of these drafts remain unchanged, as best
as he and I can tell.

H

On 11/30/18 12:37 PM, Karen O'Donoghue wrote:
> Folks,
> 
> After receiving a few requests, I am going to extend this WGLC for one week. Please submit comments by COB on Friday 7 December. Even if you don’t have any comments, please indicate to the mailing list that you have read the draft and you believe it is ready for submission to the IESG. This is critical to helping the chairs determine working group consensus on this document. 
> 
> Regards,
> Karen
> 
>> On Nov 6, 2018, at 3:46 PM, Karen O'Donoghue <[email-masked]> wrote:
>>
>> Folks,
>>

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 6 Dec 2018 13:16:56 +0100

> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

I support advancing this document. It's well written and it secures
the most important mode of NTP - client-server.

>From an implementor's point of view, I'd prefer if TLS 1.3 was
required, but I don't know much about TLS or crypto in general.

I still think it would be good to specify the maximum length of the
cookie. This would simplify the client implementation. From a previous
discussion, it looks like 256 octets should be enough.

In 5.2 there is "Possibly, some additional extension fields which are
neither encrypted nor authenticated.  These are discarded by the
receiver." I'd suggest to change the last sentence to "These are
normally discarded by the receiver". This is explained later in the
document for both client and server sides.

In 5.6 there are two instances "zero-padded to a word (four octets)
boundary" and two instances of "bytes". The size of a word and byte is
specific to the architecture, so just use "to a four-octet boundary"
and "octets".

In 5.7 there are typos in "but MUST be encrypted from sent from
server to client." and "comply with RFC 5095, Section 7.4".

In 5.7 there is "In that case, it MUST be able to detect and stop
looping between the NTS-KE and NTP servers.". This could be explained
in a more detail. The detection here means that the client should
check if there were no good NTP packets received between NTS-KE
exchanges?

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 6 Dec 2018 15:03:17 +0100

Hey all,

Overall, I want to affirm that I am not currently aware of any 
dealbreakers in the issues brought up - I have my opinions, but I don't 
consider any of the currently running discussions to represent hills that 
I would die on.
As far as I am concerned, I would bow to consensus on any issue I'm (that 
I'm aware of - this is kind of a caveat, wasn't there talk about an issue 
tracker for this WGLC?).

I would only like to reiterate my general notion that at this point, 
changes (as in real semantic ones that alter the meaning of what is 
written) in the draft seem to be inherently more expensive than sticking 
with the status quo, and that I would prefer to only have any more of them 
if absolutely necessary.

Best regards,
Kristof

"ntp" <[email-masked]> schrieb am 03.12.2018 17:23:59:

> Von: "Karen O'Donoghue" <[email-masked]>
> An: "[email-masked]" <[email-masked]>
> Kopie: "[email-masked]" <[email-masked]>
> Datum: 03.12.2018 17:24
> Betreff: [Ntp] Fwd:  WGLC: draft-ietf-ntp-using-nts-for-ntp
> Gesendet von: "ntp" <[email-masked]>
> 
> Folks, 
> 
> We?ve extended this WGLC to this Friday, 7 December 2018. We?d still
> love some broader security review if possible. Note this protocol 
> uses TLS so folks might to ensure we haven?t caused any problems there. 
> 
> Karen
> 
> Begin forwarded message:
> 
> From: Karen O'Donoghue <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> 
> Folks,
> 
> Please review the referenced document and send any comments to the 
> mailing list including your assessment of whether this document is 
> mature enough to proceed to the IESG. Please note that these 
> messages of support for progression to the mailing list will be used
> to determine WG consensus to proceed. 
> 
> Please send all comments in by COB on Friday 30 November. We realize
> this is a bit longer than normal but we are coming out of an IETF 
> week and heading into the Thanksgiving holiday in the US. 
> 
> Thanks!
> Karen and Dieter

---

From: Denis Reilly <[email-masked]>
Date: Thu, 6 Dec 2018 16:13:01 +0000

Hello!

I have read the latest NTS for NTP draft and believe it is ready for submission to the IESG. I have no comments.

--
Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837

-----Original Message-----
From: ntp <[email-masked]> On Behalf Of Karen O'Donoghue
Sent: Friday, November 30, 2018 3:37 PM
To: [email-masked]
Subject: Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp

Folks,

Regards,
Karen

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp
ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 6 Dec 2018 21:40:25 +0100

Following discussion on the list and in a conference call with Me,
Daniel, Dieter, Karen, and Ragnar, I've created a pull request in the
Github repo with some suggested changes. Each link points to the change
on Github.

As I've stated before, I support the draft in its current state. These
suggestions represent minor fixes and improvements.

Kind regards,
Marcus

* Added a missing XML section close tag that prevented xml2rfc from
parsing the file.
https://github.com/dfoxfranke/nts/pull/15/commits/077f0da64a1356d7d62e406dbfa699b3cabaadac

* Relaxed the requirement that the client associates with a NTP server
at the same address as the NTS-KE server from SHALL to SHOULD.
https://github.com/dfoxfranke/nts/pull/15/commits/a7c4f563ab121b45e778975f3869ebf13e6c871d

* Improved the language on cookie reuse. This is Ragnar's suggested
text, with improvements suggested by Dieter.
https://github.com/dfoxfranke/nts/pull/15/commits/60d34d92c026369b551d93abb465e4cfdbeff567

* Added section to Security Considerations section on NTS stripping.
https://github.com/dfoxfranke/nts/pull/15/commits/2b436df8c666ee5e87cc46d9a2531134c99f2dc7

* Emphasize that clients shouldn't reperform NTS-KE handshake just
because the the server's certificate expires.
https://github.com/dfoxfranke/nts/pull/15/commits/15ed0dc29549df362961c7f1a1556b1d4dfe64a3

* Added note on importance of forward secrecy.
https://github.com/dfoxfranke/nts/pull/15/commits/6309580e5d35e2295e3623d23937a4e125e775e5

* Fixed typos discovered by Martin Langer.
https://github.com/dfoxfranke/nts/pull/15/commits/83ddc061c014a9aaac934e05f501e41ebe0c2f50

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 7 Dec 2018 14:05:23 -0800

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.

---

From: [email-masked]
Date: Sat, 8 Dec 2018 21:39:02 +0100

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" <[email-masked]> schrieb: -----

An: [email-masked]
Von: "Harlan Stenn"
Gesendet von: "ntp"
Datum: 07.12.2018 23:05
Betreff: Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 8 Dec 2018 21:48:05 -0800

Hence my objections remain.

H

On 12/8/2018 12:39 PM, [email-masked] wrote:
> The summary of my response is: yes, we have seen most or all of the here-cited 
> concerns of yours before, and dismissed them.
> - 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?
> 
> -----"ntp" <[email-masked] <mailto:[email-masked]>> schrieb: -----
> An: [email-masked] <mailto:[email-masked]>
> Von: "Harlan Stenn"
> Gesendet von: "ntp"
> Datum: 07.12.2018 23:05
> Harlan Stenn <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Sun, 9 Dec 2018 12:43:34 +0100

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

An: [email-masked]
Von: "Harlan Stenn"
Gesendet von: "ntp"
Datum: 09.12.2018 06:48
Kopie: [email-masked]
Betreff: Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-using-nts-for-ntp

H

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 9 Dec 2018 18:30:39 +0000

I agree with Kristof's summary (and views) and believe that Harlan is in the rough for consensus.

I would like to know if anyone in the WG agrees with the list of issues that Harlan has raised.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 10 Dec 2018 01:22:33 -0800

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, [email-masked] 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.

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

> 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
--
> An: [email-masked] <mailto:[email-masked]>
> Von: "Harlan Stenn"
> Gesendet von: "ntp"
> Datum: 09.12.2018 06:48
> Kopie: [email-masked] <mailto:[email-masked]>
> On 12/8/2018 12:39 PM, [email-masked] <mailto:[email-masked]> wrote:
>  > -----"ntp" <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>> schrieb: -----
>  > An: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>  > Von: "Harlan Stenn"
>  > Gesendet von: "ntp"
>  > Datum: 07.12.2018 23:05
>  > Harlan Stenn <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>>
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 10 Dec 2018 12:32:46 +0100

"Harlan Stenn" <[email-masked]> schrieb am 10.12.2018 10:22:33:

> Von: "Harlan Stenn" <[email-masked]>
> Datum: 10.12.2018 10:22
> Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: WGLC: draft-ietf-ntp-
> using-nts-for-ntp
> 

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.
> > Merely claiming that there is some holy grail document that peopleare 
just 
> 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.
 
> > On 12/8/2018 12:39 PM, [email-masked] <
mailto:[email-masked]
> > wrote:
> >  > I'm on my browser mail client and sadly can't respond in-line 
> without making a
> >  > mess of the formatting.
> >  >
> >  > 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:
> >  >
> >  > Is there anything else (preferably actionable suggestions) you 
> still feel has
> >  > not been adressed?
> >  >
> >  >
> >  > Best regards,
> >  > Kristof
> >  >
> >  >

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 10 Dec 2018 03:37:36 -0800

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

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

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

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

> one, bit for that one I would still need to be convinced there is an issue in 

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?

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

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

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 10 Dec 2018 03:38:49 -0800

Argumentum ad populum.

H

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Dec 2018 12:53:51 +0000

Not at all.

You have raised some issues.

I would like to know if anyone else agrees that these are things to address.

On 12/10/18, 6:38 AM, "Harlan Stenn" <[email-masked]> wrote:

    Argumentum ad populum.
    
    H

---

From: [email-masked]
Date: Mon, 10 Dec 2018 14:19:52 +0100

I would like to re-post parts of an old e-mail of mine from August of this 
year regarding Dave's "DTLS Lite for NTP" document (as posted by Harlan, 
on August 2nd), as I'm unsure whether my text ever made it to the list 
(posted it from my private account, can't see it on my work accounts) and 
it is kind of essential to at least my own dismissal of that document as 
an all-in-one solution, and of potential points that could be taken from 
it and applied to the NTS spec:

My main problem with the presented document remains the same from previous 
versions of it:
I find it hard to see what the reader is supposed to take away from it, or 
what kind of document it should be seen as. 

Scanning some of the parts where it does go into more detail, I have also 
found a few items that I think show major issues, at least one for each of 
the modes:

- Symmetric Mode: there seems to be no initial validation of which public 
key belongs to whom (such as externally validates certificates could 
provide). 
In this case, all the procedure does (at best) is to ensure that whoever 
I'm talking to initially is also the same entity I'm talking to later, 
which still allows anyone to pose as any entity initially. 
I find it doubtful whether this represents any improvement over just using 
the symmetric key security approach for this mode.

- Client/Server Mode: "The cookie is the hash of the client IP addresses 
concatenated with a server secret key using the selected hash algorithm". 
This is straight out of the Autokey playbook. It was clearly identified in 
2012 in S. Roettger's analysis of Autokey as one of the major issues and a 
complete showstopper regarding security.

- Broadcast Mode: Seems to use asymmetric signatures in a straightforward 
design. 
But we ruled this out years ago because we found it unclear that every 
device that potentially was going to be a broadcast server (or arguably 
even a broadcast client) was going to be able to do this without 
significant detriment to timestamp accuracy. 

Best regards,
Kristof

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 10 Dec 2018 23:08:58 +0100

Hi Marcus,
here are my comments for pull request #15

077f0da6
The current documents translates correctly without any errors. 
Therefore, I would imply that the additional section closing tag is one 
too much.

---------------------
a7c4f563
I don't get why you want to relax this requirement. Please explain.

---------------------
60d34d92
This is ok with me.

---------------------
2b436df8
I agree in principal. I suggest following changes

### original
         <t>
           Implementers must be aware of the possibility of "NTS 
stripping"
           attacks, where an attacker tricks clients into reverting to 
plain
           NTP. Naive client implementations might, for example, revert
           automatically if the NTS-KE handshake fails. A 
man-in-the-middle
           attacker can easily cause this to happen. Even clients that 
already
           hold valid cookies can be vulnerable, since an attacker can 
force a
           client to reperform the NTS-KE handshake by sending faked NTP 
mode 4
           replies with the NTS NAK kiss code. Forcing a client to 
reperform the
           NTS-KE handshake can also be the first step in more advanced 
attacks.
         </t>

### new
         <t>
           Implementers must be aware of the possibility of "NTS 
stripping"
           attacks, where an attacker tricks clients into reverting to 
plain
           NTP. Naive client implementations might, for example, revert
           automatically to plain NTP if the NTS-KE handshake fails. A 
man-in-the-middle
           attacker can easily cause this to happen. Even clients that 
already
           hold valid cookies can be vulnerable, since an attacker can 
force a
           client to repeat the NTS-KE handshake by sending faked NTP 
mode 4
           replies with the NTS NAK kiss code. Forcing a client to 
repeat the
           NTS-KE handshake can also be the first step in more advanced 
attacks.
         </t>

---------------------
15ed0dc2
ok

---------------------
6309580e
ok

---------------------
83ddc061
ok

Dieter Sibold
[email-masked]

On 6 Dec 2018, at 21:40, Marcus Dansarie wrote:

>> mature enough to proceed to the IESG. Please note that these messages 
>> of support for progression to the mailing list will be used to 
>> determine WG consensus to proceed.
>>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Dec 2018 08:30:06 -0500

Hi Harlan,

> possibly assign 6 random EFs for this use case.

Actually, it is up to IANA on which values they assign. That is their job.

I have been through a myriad of scenarios where WGs squatted on
IANA-assigned codepoints without communicating their requests to IANA.
This led to situations where IANA assigned those codepoints for other
uses/WGs before the squatters submitted their document for publication.

The proper way to manage those types of assignments is to ask IANA for
an early assignment for a document. To my knowledge no one has made that
request.

Any reference to an EF type in a draft should be as TBD.

Regards,
Brian (a recovering AD)

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 11 Dec 2018 13:36:49 +0000

> On Dec 11, 2018, at 8:30 AM, Brian Haberman <[email-masked]> wrote:
> 
> Hi Harlan,
> 

Actually Brian, we did make a request during the development of the first version of NTS. That request was withdrawn when the first version blew up in the WGLC process. We are now on the third major revision of this specification. Once it clears the WGLC process, I’ll submit another early assignment request. 

The real problem here is Harlan wants to have a structure for the code points that has not gotten WG consensus. This structure comes from the extension field draft he has been working on that has not gotten wg consensus for adoption. 

Karen

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 11 Dec 2018 17:18:54 +0100

Thank you! My replies follow inline.

Kind regards,
Marcus

> Therefore, I would imply that the additional section closing tag is one

This appears to have been due to an error on my end. My apologies.

There may be some (weird) cases where a user wishes to manually instruct
their NTP client to use the received cookies with a different NTP
server. I also believe SHALL should be reserved for cases where
non-compliance could cause security issues or cause the protocol to
break. This is not an important issue for me, however, and I'll be
perfectly happy even if this isn't included.

>           Implementers must be aware of the possibility of "NTS stripping"
>           attacks, where an attacker tricks clients into reverting to plain
>           automatically if the NTS-KE handshake fails. A man-in-the-middle
>           Implementers must be aware of the possibility of "NTS stripping"
>           attacks, where an attacker tricks clients into reverting to plain
>           client to repeat the NTS-KE handshake by sending faked NTP mode 4
>           replies with the NTS NAK kiss code. Forcing a client to repeat
> the

Ok.

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 11 Dec 2018 19:34:41 +0100

Hi Marcus,
thanks for your reply. See comments below.
- Dieter

Dieter Sibold
[email-masked]

> perfectly happy even if this isn't included.

Ok, understand. I have no strong opinion on this matter. Perhaps there 
are other comments?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Dec 2018 18:38:17 +0000

> perfectly happy even if this isn't included.

SHALL isn't just for security issues, it's for "what is required for interop."

Leaving the SHALL NOT share cookies is the right thing to do, and a client if it wants to share cookies with another server and it knows that it is okay, is free to do so.

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 11 Dec 2018 19:40:18 +0100

Hi Martin,
thanks for your comments. See replies inline.

Dieter Sibold
[email-masked]

> further need to support older TLS versions
As authors we had a discussion on this matter. And we decided that the 
language as it is provide the most flexibility for implementors. It 
allows to provide TLS 1.2 and 1.3 but it does not mandate to provide 1.2 
or 1.3. It only mandates that at least one of these version has to be 
provided.

> -> This confused me the first time. I thought it was a mistake and 
> meant 'minimum'.
> -> The timelines are different in length. (the client line need one 
> more '-')
>
>
>
> page 27:
>
> Web  : 
> https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer
>

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 11 Dec 2018 20:13:16 +0100

Hi Rich,
I’m not sure if I got your right. Are you arguing to leave the SHALL 
as it is?
- Dieter

Dieter Sibold
[email-masked]

On 11 Dec 2018, at 19:38, Salz, Rich wrote:

> Leaving the SHALL NOT share cookies is the right thing to do, and a 
> client if it wants to share cookies with another server and it knows 
> that it is okay, is free to do so.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Dec 2018 19:16:19 +0000

Yes, leave the SHALL.  IF a client goes outside the "boundary" because it knows it is safe to do so, that is okay.

On 12/11/18, 2:13 PM, "Dieter Sibold" <[email-masked]> wrote:

    Hi Rich,

    Dieter Sibold
    [email-masked]

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 11 Dec 2018 20:17:31 +0100

thanks for clarification.

Dieter Sibold
[email-masked]

On 11 Dec 2018, at 20:16, Salz, Rich wrote:

> Yes, leave the SHALL.  IF a client goes outside the "boundary" because 
> it knows it is safe to do so, that is okay.
>
>     >     > There may be some (weird) cases where a user wishes to 
> manually
>     >     > instruct
>     >     > their NTP client to use the received cookies with a 
> different
>     > NTP
>     >     > non-compliance could cause security issues or cause the 
> protocol
>     > to
>     >     > break. This is not an important issue for me, however, and 
> I'll
>     > be
>     > SHALL isn't just for security issues, it's for "what is required 
> for
>     > interop."
>     >

---

From: Martin Langer <[email-masked]>
Date: Wed, 12 Dec 2018 08:38:04 +0100

Hello Dieter,

thanks for your reply. You are right. I already talked to Kristof about 
the TLS1.2 / 1.3
question and I agree to provide both versions.

best regards,
Martin

Am 11.12.2018 um 19:40 schrieb Dieter Sibold:
>> The remaining platforms will probably follow soon. Therefore, I see 
>> no further need to support older TLS versions
>> than 1.3.
>>
> allows to provide TLS 1.2 and 1.3 but it does not mandate to provide 
> 1.2 or 1.3. It only mandates that at least one of these version has to 
> be provided.
>
>
>>
>>
>> page 8:
>>

---

From: "Dieter Sibold" <[email-masked]>
Date: Sat, 15 Dec 2018 18:32:29 +0100

Dear Miroslav,
sorry for the late reply. See my comments inline.

Dieter Sibold
[email-masked]

> required, but I don't know much about TLS or crypto in general.

Martin also expressed preferences of TLS 1.3. See my reply to his email.

> discussion, it looks like 256 octets should be enough.

The cookie contained in the Cookie EF is implementation specific.
Therefore in my opinion the size should not be specified, although
it might simplify implementation.

> document for both client and server sides.

I see. I would like to phrase it „In general, these are discarded by
the receiver.“ in order to emphasize the normal behavior.

> specific to the architecture, so just use "to a four-octet boundary"

Thanks. I replaced the bytes by octets.
> server to client." and "comply with RFC 5095, Section 7.4".

Thanks.

---

From: Ragnar Sundblad <[email-masked]>
Date: Sun, 16 Dec 2018 13:44:49 +0100

Hi Miroslav,

> On 6 Dec 2018, at 13:16, Miroslav Lichvar <[email-masked]> wrote:
> 

Very good catch, thanks!

The main issue is to not overload the KE server, and that should apply
wether or not one or a few NTP transactions actually has worked or not.

The problem also may be a temporary error in the server end, so the client
actually should retry every now and then.

I believe we should replace the current:
"In that case, it MUST be able to detect and stop looping between the
NTS-KE and NTP servers.”
with something like:
“In that case, the client MUST be able to prevent fast looping between
the NTS-KE and NTP servers by rate limiting the retries using e.g.
exponentially increasing retry intervals.”

Maybe we should also add something about a recommended lower and upper
limits on the retry interval, like 30 seconds to 6 hours or so.
Or maybe we shouldn’t.

I’d be happy to share your thoughts on this!

Best regards,

/ragge