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

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 9 Aug 2017 04:41:25 +0000

Folks,

This begins a three week working group last call (WGLC) for "Network Time Security for the Network Time Protocol”.

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

Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG. 

Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to [email-masked]. ]

Regards,
Karen and Dieter

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 29 Aug 2017 02:25:02 +0000

Folks,

The working group last call for this document has been out for almost three weeks now. Please respond immediately with technical comments and an indication of whether or not you approve the advancement of this document. 

Regards,
Karen

> On Aug 9, 2017, at 12:41 AM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 31 Aug 2017 05:40:01 +0000

Hi, after going through this draft, I am not sure whether ietf-ntp-data-minimization-00 should be listed in the Normative Reference, or not at all.
Usually, an unpublished normative reference will dramatically slow the process of turning a draft into a RFC (they need to be published as a cluster at the same time).
It seems also ietf-ntp-data-minimization solves the problem of unlinkability, not necessarily a part of NTS, but a complement (just as the relationship of Section 9 "Security Considerations" and Section 10 "Privacy Considerations" ). 

Minor editorial comments:
1. IETF requirement languages can be used in Section 4 more frequently.
2. "both parties should attempt to initiate a DTLS session with their peer" can be rephrased into "each party SHOULD attempt to initiate a DTLS session with its peer" in Page 7.
3. " an Warning record " to "a Warning record" in Section 5.1.4.

Kind regards,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Karen O'Donoghue
Sent: Wednesday, August 09, 2017 12:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] WGLC for draft-ietf-ntp-using-nts-for-ntp

Folks,

Regards,
Karen and Dieter
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 11:14:27 +0200

On Wed, Aug 09, 2017 at 04:41:25AM +0000, Karen O'Donoghue wrote:
> Please review and provide comments to the mailing list by no later than 31 August 2017.

I don't support advancing the document as it currently stands (commit
5835e58 in the github repo).

As I said before [1], the main issue for me is the use of DTLS transport
in the symmetric mode. It's an easy solution how to get around some
issues, but it demotes the mode to a second-class status. I think all
timing messages in NTP should use the same transport. i.e. standard
NTP format with optional extension fields on UDP port 123.

The draft is still not clear on how should two active peers match
their DTLS connections. I think it would need to specify the port of
the DTLS client or exchange some additional information in DTLS or NTP
that would identify the peer.

My recommendation is to remove the specification of NTS in the symmetric
mode from the document, at least for now. I believe the NTS-KE used in
the client/server mode can be adopted for the symmetric mode, possibly
with some small extensions, but it will take time. I think most of us
here will agree it shouldn't delay the adoption of NTS in the
client/server mode.

[1] https://www.ietf.org/mail-archive/web/ntp/current/msg02048.html

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:34:02 -0400

Replies inline, paragraphs reordered.

> NTP format with optional extension fields on UDP port 123.

I strongly disagree with you that this is giving "second-class
status". I don't view NTS-KE as the Right Thing and DTLS encapsulation
as a kludge; if anything, it's the other way around. The DTLS record
layer is simple, correct, and performant. It's what I'd want to use
for everything if it weren't for the pesky state-management issue.

Lots of people on this list seem to have the intuition that sending
time packets over DTLS can never be as accurate as sending them over
the NTP port with an authenticator attached. But as I showed in my
analysis the other day, that just ain't so.

> here will agree it shouldn't delay the adoption of NTS in the

If specification for symmetric mode were removed, how would section 4
read? Do you want to get rid of DTLS encapsulation altogether?
Restrict what traffic can be sent over it? Can you send a PR with what
you have in mind? (Won't promise to merge it, but I'll review it)

> that would identify the peer.

In my composing this reply you've convinced me on the "not clear"
part; I'd better add something about this in the security
considerations or everybody is going to screw it up. With plain
unauthenticated NTP, we rely on IP and port to identify peers. But IP
addresses aren't cryptographic identities; that's why DTLS needs
certificates. To do symmetric mode safely, you need a mutually
authenticated handshake (i.e., both sides present certificates). The
identity in that certificate is the additional information you're
looking for.

Chairs, I'm temporarily changing my *own* vote on advancement to "no"
until I've expanded on this. It goes back to "yes" with my next git
push :-).

---

From: Daniel Franke <[email-masked]>
Date: Thu, 31 Aug 2017 08:45:29 -0400

On 8/31/17, Jiangyuanlong <[email-masked]> wrote:
> Hi, after going through this draft, I am not sure whether
> ietf-ntp-data-minimization-00 should be listed in the Normative Reference,
> or not at all.

I was *just* about to bring this up myself. I think it's properly an
informative reference.

Sharon, Aanchal, CCing the two of you because I recall you had a
different opinion last year in Boston and thought it should stay a
normative reference (but I'm not sure I understood you correctly
then). Note that this is a completely separate issue from whether data
minimization should be published as Standards Track vs. Informational.
It can stay a Standards Track document and still be cited from NTS for
Informative purposes.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 31 Aug 2017 16:02:58 +0200

> analysis the other day, that just ain't so.

The problem is not with transmission. The problem as I see it is with
transport and reception. Encryption prevents modifications of the
packet in the network, which will be needed for delay corrections.
A different port number will not work with existing QoS in
switches/routers and hardware timestamping in NICs. I'm sure in some
cases reconfiguration to handle both ports will be possible, but there
is HW where the port number is hardcoded in the firmware or silicon.
If there is a rarely used port for timing messages, will everyone
support it? I doubt that. The symmetric mode will not get all benefits
of NTP support.

If DTLS records were exchanged in NTP packets in extension fields, as
was originally considered by the design group, this wouldn't be a
problem.

> you have in mind? (Won't promise to merge it, but I'll review it)

I'm not sure. I think the whole section could be limited to the
control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be
allowed, but not recommended. In the broadcast mode I think it doesn't
make much sense anyway.

> The

Ok, thanks.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 31 Aug 2017 22:36:34 +0200

Miroslav, please see my comment below

-----"ntp" <[email-masked]> wrote: -----

>To: Daniel Franke <[email-masked]>
>From: Miroslav Lichvar 
>Sent by: "ntp" 
>Date: 08/31/2017 16:03
>Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
><[email-masked]>, Karen O'Donoghue <[email-masked]>
>Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
>

During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach.

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 31 Aug 2017 15:18:37 -0700

Yo Daniel!

On Thu, 31 Aug 2017 08:34:02 -0400

> analysis the other day, that just ain't so.

Analysis is great, but I'd like to see running code.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 1 Sep 2017 00:19:37 +0000

Daniel, that also works. BTW, you need not give the exact version of the WG draft, but tag it as "in progress".

Cheers,
Yuanlong

> From: Daniel Franke [mailto:[email-masked]]
> Sent: Thursday, August 31, 2017 8:45 PM
> To: Jiangyuanlong
> Cc: Karen O'Donoghue; [email-masked]; [email-masked]; Sharon Goldberg;
> Aanchal Malhotra
> > ietf-ntp-data-minimization-00 should be listed in the Normative
> > Reference, or not at all.
> 
> I was *just* about to bring this up myself. I think it's properly an informative
> reference.
> 
> Sharon, Aanchal, CCing the two of you because I recall you had a different
> opinion last year in Boston and thought it should stay a normative reference
> (but I'm not sure I understood you correctly then). Note that this is a
> completely separate issue from whether data minimization should be
> published as Standards Track vs. Informational.