Subject: [Ntp] NTS/Updated Autokey

From: Harlan Stenn <[email-masked]>
Date: Sun, 20 Aug 2017 19:41:06 -0700

Dave has been working on an evaluation of the NTS proposal.

We've been discussing this document in our internal NTS implementation
meetings, and Dieter asked me to send this to the WG mailing list.

Dave updated the document after my last go-round, so I just took his new
version and integrated his changes with the ones we made.

I'll be working on my WGLC comments separately.
-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: [email-masked]
Date: Mon, 21 Aug 2017 09:27:28 +0200

To clarify: I asked Dave to discuss his questions regarding the NTS draft 
(https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt) in the 
NTP mailing list. I didn't asked to submit a further proposal.

Dieter

> Von: Harlan Stenn <[email-masked]>
> An: [email-masked]
> Datum: 21.08.2017 04:41
> Betreff: [Ntp] NTS/Updated Autokey
> Gesendet von: "ntp" <[email-masked]>
> 
> [Anhang "Autokey-20170815.txt" gelöscht von Dieter Sibold/PTB] 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: [email-masked]
Date: Mon, 21 Aug 2017 09:27:28 +0200

Dieter

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 21 Aug 2017 09:45:02 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 21.08.2017 um 04:41 in Nachricht
> version and integrated his changes with the ones we made.

Hi,

some random comments:

"Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction IMHO: If one bit changes, the function octet cannot be the same.

I think the "minimum packet headway" is a new phrase. Why not using "minimum poll delay" (or interval) instead?

"An NTP secure network consists of an acyclic, undirected graph organized as a tree with nodes descending from the root node." Is there really one root? What about multiple stratum-1 servers being configured? Maybe clarify this.

"Each step involves a sign exchange, (...)" I would name it "signature exchange" for consistency.

"In particular, the packet header and extension field lengths, if present." This is an incomplete sentence; is "are verified" missing at the end?

"The format scan results in a pointer just before the message authentication code (MAC)." Isn't this an unnecessary implementation detail (to describe the semantics)? Maybe describe what the layer is expected to do in better words.

"However, i,t is vital (...)" Simple typo ("it is vital")...

"If a shared hash key is not available, such as during the agreement process itself, the existence of an implicit hash key zero is assumed. The value of hash key zero could be a random number known only to verified and trusted hosts in the NTP network. Hash key zero could be any mutually agreed upon symmetric key.  The design intent is to verify this number as well as detect errors, rather than protect against middleman attack. By protocol rule, if a message request uses hash key zero, the message response also uses hash key zero." Isn't that a change to the current implementation where no key or key ID zero means "no MAC"?

"The OpenSSL library includes just about every hash algorithm likely to be imagined. While historically ambiguous, the International Trade in Arms Regulations (ITAR) prohibits export of the OpenSSL library, so only the MD5 hash algorithm is included in the reference distribution. Alternatively, the OpenSSL library can be imported from foreign or domestic sources, although generated binaries may not be exported from the US.." Isn't there an exception for open source products?

"(...)and the modifier octet used as the key number." Shouldn't "as the key number" be "is the key number"?

Note on "The comparison of these two timestamps is called the loopback test. The transmit timestamp functions as a nonce to verify that the response corresponds to the original request.": In the current implementation this test fails if one client is configured multiple times, it seems.

I'm unhappy with the phrase "sign exchange" (as said earlier): Either "signature exchange" or "sign(ature) request" would better. Maybe it's a CSR (Certificate Signing Request)...

"In the following, the host certificate belongs to the host containing the public/private keys, while a server certificate belongs to each association separately." Does this say that each host has a public/private key pair in addition to is self-signed certificate, while there is only a certificate for each association? If so I find the latter statement more clear.

"In the authentication phase, Alice sends her signature of the shared hash key to Bob. Bob verifies the signature, then sends his signature of the shared hash key to Alice. Alice verifies his signature." I'm not a crypto expert, but isn't the hash key also encrypted (in addition to being signed) for the other party?

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 21 Aug 2017 09:45:02 +0200

Hi,

some random comments:

Regards,
Ulrich

---

From: [email-masked]
Date: Mon, 21 Aug 2017 10:38:59 +0200

I also would like to emphasize that it needs to be clearer whether (and, 
if yes, how) Dave's document is supposed to relate to the NTS draft and 
its current WGLC procedure.

Kristof

Von:    [email-masked]
An:     Harlan Stenn <[email-masked]>
Kopie:  [email-masked]
Datum:  21.08.2017 09:27
Betreff:        [Ntp] Antwort:  NTS/Updated Autokey
Gesendet von:   "ntp" <[email-masked]>

Dieter

> https://www.ietf.org/mailman/listinfo/ntp[Anhang "smime.p7s" gelöscht 
von Kristof Teichel/PTB] _______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: [email-masked]
Date: Mon, 21 Aug 2017 10:38:59 +0200

Kristof

Dieter

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 01:44:34 -0700

Dave cannot easily participate on the mailing list discussions.

You can discuss this with him on the call if you like.

Either way, he raises a number of points in his document that he feels
must be addressed in any proposal that would intend to replace the
existing Autokey proposal.

H

On 8/21/2017 1:38 AM, [email-masked] wrote:
> ------------------------------------------------------------------------
> 
> 
> 
> (_https://www.ietf.org/id/draft-ietf-ntp-using-nts-for-ntp-09.txt_) in
> the NTP mailing list. I didn't asked to submit a further proposal.
> 
> Dieter
> 
> 
> 
> 
>> _http://nwtime.org_ <http://nwtime.org/>- be a Member!
>> _https://www.ietf.org/mailman/listinfo/ntp__[Anhang "smime.p7s"
> gelöscht von Kristof Teichel/PTB]
> ________________________________________________
> ntp mailing list
> [email-masked]

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 01:44:34 -0700

H

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 02:06:37 -0700

> "Ordinarily, the function octet for both the request and response messages is the same; a bit is allocated in the function octet to serve as a response indicator." This is kind of a contradiction I…

Really?  That's how autokey did it, and the I-DO proposal does this as
well.  NTS would also use this.

> I think the "minimum packet headway" is a new phrase. Why not using "minimum poll delay" (or interval) instead?

I'll ask Dave about this.

> "An NTP secure network consists of an acyclic, undirected graph organized as a tree with nodes descending from the root node." Is there really one root? What about multiple stratum-1 servers being…

There is one root.  If you are using multiple stratum 1 servers, you're
still using at most 1 of them as a system peer.

> "Each step involves a sign exchange, (...)" I would name it "signature exchange" for consistency.

I'll tell Dave you agree with me :)

> "In particular, the packet header and extension field lengths, if present." This is an incomplete sentence; is "are verified" missing at the end?

I think so.

> "The format scan results in a pointer just before the message authentication code (MAC)." Isn't this an unnecessary implementation detail (to describe the semantics)? Maybe describe what the layer…

It's likely also specific to the Legacy MAC.  I'll ask.

> "If a shared hash key is not available, such as during the agreement process itself, the existence of an implicit hash key zero is assumed. The value of hash key zero could be a random number known…

I don't think so.  It's descriptive, and need not imply a literal key#0.
 It *could* be used, as a crypto-NAK is keyID 0 *and* a zero length
field.  The point is that each side must agree on the key being used to
validate the initial exchange.  There's room for discussion here.

> "The OpenSSL library includes just about every hash algorithm likely to be imagined. While historically ambiguous, the International Trade in Arms Regulations (ITAR) prohibits export of the OpenSSL…

Maybe.  But Dave is not a lawyer, and when Autokey was first deployed
and when OpenSSL was first used for symmetric key stuff, we could not
export that code from the US.  Things may have changed since then.

> "(...)and the modifier octet used as the key number." Shouldn't "as the key number" be "is the key number"?

I'll look or ask Dave, after I wake up.

> Note on "The comparison of these two timestamps is called the loopback test. The transmit timestamp functions as a nonce to verify that the response corresponds to the original request.": In the cu…

I'll check.

> "In the authentication phase, Alice sends her signature of the shared hash key to Bob. Bob verifies the signature, then sends his signature of the shared hash key to Alice. Alice verifies his signa…

I'll ask Dave.

Thanks!

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 02:06:37 -0700

I think so.

I'll check.

I'll ask Dave.

Thanks!

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Aug 2017 12:53:57 +0000

It is unfortunate that Dave cannot easily participate in the mailing list discussion, since we all know that is where the IETF does its work.

I gave a quick read to his document.  First, it seems to be a mix of questions/comments and an alternate proposal.  Please ask him to separate those into two messages.  If you are acting as his interlocutor, please post the questions part directly, not as an attachment.  Second, DH is way too expensive, ECDH probably using X25519, is the only mechanism to use.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Aug 2017 12:53:57 +0000

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 21 Aug 2017 15:21:26 +0200

>>> "Salz, Rich" <[email-masked]> schrieb am 21.08.2017 um 14:53 in Nachricht
<[email-masked]>:
> It is unfortunate that Dave cannot easily participate in the mailing list 
> discussion, since we all know that is where the IETF does its work.
> 
> I gave a quick read to his document.  First, it seems to be a mix of 
> questions/comments and an alternate proposal.  Please ask him to separate 
> those into two messages.  If you are acting as his interlocutor, please post 
> the questions part directly, not as an attachment.  Second, DH is way too 
> expensive, ECDH probably using X25519, is the only mechanism to use.

Hi!

When discussing "way too expensive", can we talk in cycles of a modern CPU, comapring the state now and the proposed changes. I'm aware that desktop CPU's may be very high end, while some embedded CPU's have weaker CPUs.

(Did I mention our old serial console server (fan-less 400MHz ARM CPU, I think) that needs several seconds to establish an SSH login?) ;-)

2017-08-21 15:17:09	Connecting to 192.x.x.40 port 22
2017-08-21 15:17:09	We claim version: SSH-2.0-PuTTY_Release_0.69
2017-08-21 15:17:10	Server version: SSH-2.0-OpenSSH_4.4
2017-08-21 15:17:10	We believe remote version has SSH-2 channel request bug
2017-08-21 15:17:10	Using SSH protocol version 2
2017-08-21 15:17:10	Doing Diffie-Hellman group exchange
2017-08-21 15:17:10	Doing Diffie-Hellman key exchange with hash SHA-256
2017-08-21 15:17:26	Server also has ssh-dss host key, but we don't know it
2017-08-21 15:17:26	Host key fingerprint is:
2017-08-21 15:17:26	ssh-rsa 1024 32:24:1f:3f:d1:29:15:e7:51:6b:cd:5a:b8:df:40:ce
2017-08-21 15:17:26	Initialised AES-256 SDCTR client->server encryption
2017-08-21 15:17:26	Initialised HMAC-SHA1 client->server MAC algorithm
2017-08-21 15:17:26	Initialised AES-256 SDCTR server->client encryption
2017-08-21 15:17:26	Initialised HMAC-SHA1 server->client MAC algorithm

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 21 Aug 2017 15:21:26 +0200

Hi!

Regards,
Ulrich

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Aug 2017 13:36:48 +0000

➢ When discussing "way too expensive", can we talk in cycles of a modern CPU, comapring the state now and the proposed changes. I'm aware that desktop CPU's may be very high end, while some embedded CPU's have weaker CPUs.
    
Sorry.  Start here: https://cr.yp.to/ecdh/curve25519-20060209.pdf

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Aug 2017 13:36:48 +0000

---

From: Brian Utterback <[email-masked]>
Date: Mon, 21 Aug 2017 11:18:32 -0400

On 8/21/2017 5:06 AM, Harlan Stenn wrote:
>>>>> Harlan Stenn<[email-masked]>  schrieb am 21.08.2017 um 04:41 in Nachricht
I don't think Ulrich is saying it is bad or good, he is saying that this 
sentence is ambiguous. I noticed this as well.

It could be "Ordinarily the function octet for both the request and 
response messages is the same, but in this protocol a bit is allocated 
in the function octet to serve as a response indicator, making them 
response and request function octet different."

or it could be the self inconsistent sentence "This protocol uses the 
same function octet for response and requests, with a bit allocated in 
the function octet to serve as a response indicator."

The problem is that logic would suggest the first, but the sentence 
structure suggests the second.

-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principal Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems Server & Cloud Engineering
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually show their own agendas.
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment

---

From: Brian Utterback <[email-masked]>
Date: Mon, 21 Aug 2017 11:18:32 -0400

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 17:14:02 -0700

On 8/21/2017 5:53 AM, Salz, Rich wrote:
> It is unfortunate that Dave cannot easily participate in the mailing
> list discussion, since we all know that is where the IETF does its
> work.

Yes.

It's unfortunate that Dave is effectively blind.

It's unfortunate that accessibility tools aren't up for the job of
handling intricate and meticulous work like this.

He can be on calls.

> those into two messages. If you are acting as his interlocutor, please
> post the questions part directly, not as an attachment. Second, DH is
> way too expensive, ECDH probably using X25519, is the only mechanism to use.

Sorry, he can't easily do that, and I have way too many other things
biting at my heels to do it.

Dave says using ECDH is fine - he disagrees that DH is way too expensive.

In his document, see the Symmetric mode discussion in section 8, which
talks about all of this in more detail.
-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 17:14:02 -0700

Yes.

He can be on calls.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Aug 2017 02:34:38 +0000

➢ It's unfortunate that Dave is effectively blind.
➢     It's unfortunate that accessibility tools aren't up for the job of
➢ handling intricate and meticulous work like this.
    
I am sorry to hear that.

➢     Sorry, he can't easily [split the document], and I have way too many other things
➢     biting at my heels to do it.
    
Perhaps someone else will be able to do so.  An intermix of questions and alternative proposal – is it intended to become a new draft? – will make it hard to address any questions and concerns he might have.

➢     Dave says using ECDH is fine - he disagrees that DH is way too expensive.
   
With all due respect, he is wrong.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Aug 2017 02:34:38 +0000

I am sorry to hear that.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 22 Aug 2017 05:32:59 +0200

Short comment in support:

> With all due respect, he is wrong.

+1.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 22 Aug 2017 05:32:59 +0200

+1.

Aaron

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 21:16:04 -0700

>> With all due respect, he is wrong.

No worries.

Dave already said that ECDH is fine, and his express intent is to
implement a station-to-station protocol.  The choice of *which* DH
scheme is used isn't really the point.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 21 Aug 2017 21:16:04 -0700

No worries.

---

From: [email-masked]
Date: Tue, 22 Aug 2017 09:56:31 +0200

I agree with Rich. It would be very helpful if especially concerns 
regarding the NTS draft are posted separately.
Dieter

"ntp" <[email-masked]> schrieb am 21.08.2017 14:53:57:

> Von: "Salz, Rich" <[email-masked]>
> An: Harlan Stenn <[email-masked]>, "[email-masked]" <[email-masked]>
> Datum: 21.08.2017 14:54
> Betreff: Re: [Ntp] NTS/Updated Autokey
> list discussion, since we all know that is where the IETF does its work.
> 
> questions/comments and an alternate proposal.  Please ask him to 
> separate those into two messages.  If you are acting as his 
> interlocutor, please post the questions part directly, not as an 
> attachment.  Second, DH is way too expensive, ECDH probably using 
> X25519, is the only mechanism to use.
> 
> 
>

---

From: [email-masked]
Date: Tue, 22 Aug 2017 09:56:31 +0200