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

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 1 Sep 2017 09:57:57 +0200

On Thu, Aug 31, 2017 at 10:36:34PM +0200, [email-masked] wrote:
> 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.

If DTLS over NTP was just postponed, why specify now a different
transport for this rarely used mode? Is anyone actually interested in
implementing the symmetric mode over DTLS as it is proposed? If I
understand it correctly, there is no plan to support it in any of the
(few) existing open source implementations. Isn't there a rule about
not specifying things for which there is no demand?

Maybe I'm completely wrong, but to me it feels like there is a
pressure for NTS to cover as many modes of NTP as quickly as possible.
If we support two different transports, with every new change in NTP
we will have to ask if and how it works in each of them.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Fri, 1 Sep 2017 11:03:12 +0200

For the given application (comparison of performance of two different 
techniques), I fail to see how that is supposed to work.
Should running code be created for BOTH transport mechanisms (DTLS 
encapsulation and regular NTP packet with authenticator token) before a 
decision is made?
I believe that is taking the "running code" maxim too far.

Von:    "Gary E. Miller" <[email-masked]>
An: 
Kopie:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Datum:  01.09.2017 00:18
Betreff:        Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
Gesendet von:   "ntp" <[email-masked]>

Yo Daniel!

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

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

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
[Anhang "attpwg8d.dat" gelöscht von Kristof Teichel/PTB] 
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:29:06 -0400

I am strongly in favor of moving this draft toward standardization.
This is tremendous work that will eliminate entire classes of attacks
against protocols that depend on synchronized time.

A few comments:

(1) I couldn't figure out if it is possible for the client to request
multiple cookies with time synchronization requests. If it isn't, it
seems like it should be to avoid the inevitable re-establishment of
keys if the client's cookie pool permanently drops by one every time a
packet is lost. Being able to request more than one cookie will enable
the client to maintain the recommended pool of 8.

(2) In section 5, the description of the record type field seems
wrong. It says q( A 15-bit integer in network byte order (from
most-to-least significant, its bits are record bits 7-1 and then
15-8). ). This seems to imply that (for example) the value 16385 would
be encoded as 000000100000001 when read from left-to-right in the
given diagram, when I believe it should be encoded as 100000000000001.
I would just lose everything between the parentheses: it seems
sufficient to say that record type is a 15-bit unsigned integer in
NBO.

(3) Section 5.2 states that key material "SHALL" be extracted
according to RFC 5705. What is the plan if some TLS 1.3-specific
mechanism deprecates 5705?

Kyle

On Wed, Aug 9, 2017 at 12:41 AM, Karen O'Donoghue <[email-masked]> wrote:
> 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: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 10:32:36 -0400

> be encoded as 000000100000001 when read from left-to-right in the

Er, I mean 000000110000000. Either way, still seems wrong.

Kyle

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 11:25:51 -0400

> the client to maintain the recommended pool of 8.

That's exactly what the NTS Cookie Placeholder extension is for.

          The client MAY include one or more NTS Cookie Placeholder
          extension field, which MUST be authenticated and MAY be
          encrypted. The number of NTS Cookie Placeholder extension
          fields that the client includes SHOULD be such that if the
          client includes N placeholders and the server sends back N+1
          cookies, the number of unused cookies stored by the client
          will come to eight. When both the client and server adhere
          to all cookie-management guidance provided in this memo, the
          number of placeholder extension fields will equal the number
          of dropped packets since the last successful volley.

> sufficient to say that record type is a 15-bit unsigned integer in

Already fixed in git.

> mechanism deprecates 5705?

Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for
HKDF but keep the interface exactly the same. The intent, which seems
clear at least to me, is that anything which currently uses RFC 5705
will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions.
Once TLS 1.3 is finalized, we can publish an update to clarify this if
it isn't clear enough already.

If even the *interface* changed then we'd have to do an update for
sure, but I think the odds of that approach nil.

---

From: "Gary E. Miller" <[email-masked]>
Date: Fri, 1 Sep 2017 10:16:27 -0700

Yo [email-masked]!

On Fri, 1 Sep 2017 11:03:12 +0200
[email-masked] wrote:

> encapsulation and regular NTP packet with authenticator token) before
> a decision is made?

I'm more worried that it even works, not how well it works.  I just
want to see "good enough".

RGDS
GARY

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

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 13:31:14 -0400

> it isn't clear enough already.

I think it's worth clarifying this because you don't want one
implementation using 5705 and another using HKDF and agreeing on
different keys. For some use cases it doesn't matter (server deriving
keys that only it knows), but in cases of shared keys we would have a
problem.

Kyle

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:01:12 -0400

> keys that only it knows), but in cases of shared keys we would have a

Got any idea for how to phrase this without creating a normative
reference that blocks us on TLS 1.3 publication?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Sep 2017 19:03:41 +0000

Just say something like
	Implementations MUST use HKDF
I know the temptation is to want to give a rationale but you needn’t put that in the text.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 1 Sep 2017 15:14:46 -0400

> reference that blocks us on TLS 1.3 publication?

So actually, I just took another close look at 5705 and at the history
of the TLS RFCs, and I think the Right Thing is already unambiguous.
RFC 5705 says to apply "TLS Pseudorandom Function in use for the
session". The TLS PRF has already changed incompatibly in past TLS
versions. In TLS 1.2, it's part of the ciphersuite's specification. In
1.1 and prior, it was fixed, and based on an XOR of MD5 and SHA1. So
any correct RFC 5705 implementation is already taking protocol version
into account and choosing what function to apply accordingly.

---

From: Kyle Rose <[email-masked]>
Date: Fri, 1 Sep 2017 15:24:51 -0400

On Sep 1, 2017 3:14 PM, "Daniel Franke" <[email-masked]> wrote:

Ok, I'm satisfied. I just checked the relevant text in the TLS 1.3 draft,
and it looks like it would be unambiguous here:

q( [RFC5705] defines keying material exporters for TLS in terms of the TLS
pseudorandom function (PRF). This document replaces the PRF with HKDF, thus
requiring a new construction. The exporter interface remains the same. )

Kyle