Subject: [Ntp] NTS Hackathon minutes

From: Daniel Franke <[email-masked]>
Date: Sat, 17 Mar 2018 09:38:57 -0400

We're not yet half way through day 1 of the NTS hackathon but we've
already collected some excellent data. We spent the morning getting my
janky, never-even-run-before-this-morning Python client to
interoperate with Martin's server implementation. Here's what we've
learned.

Modulo trivial bugs in my code which were obvious and just took a few
minutes to fix, our NTS-KE implementations interoperated on the first
try. Apparently all of sections 4 and 5.1 are clear. Martin noticed
that my client's NTS-KE requests were four octets shorter than his
client's requests. That's because his client supports all three
AES-SIV key lengths (256/384/512) while mine only supports 256 bits.
This is permitted by the spec and algorithm negotiation worked as
intended.

Martin mentioned that he was logging warnings about unexpected
behavior with respect to closing the connection after the NTS-KE
handshake. We haven't gotten to the bottom of this yet or determined
which implementation is at fault but I'm confident it's a
library-usage issue and not anything that the spec needs to clarify.
>From the perspective of my client, the handshake was successful.

Moving along to NTS extension fields, our respective RFC7822
implementations also interoperated on the first try.

>From there, though, we started running into issues.

I was at first having trouble getting Martin's server to respond to
me. It turned out that this was because he was expiring cookies very
quickly, rotating master keys every 600 seconds and allowing the past
three keys. In this situation the spec requires that the server send
an NTS NAK rather than just dropping the packet on the floor. Martin
was already aware of this and just has not yet implemented NTS NAK
support.

Even with NTS NAKs, though, 600 seconds is much too fast for
production use. I'm going to add some discussion about this to section
7. Since clients typically stabilize to a polling interval of 1024
seconds, and keep an inventory of eight cookies, the server's key
rotation interval needs to be a minimum of 8192 seconds and should
probably be considerably longer. Also, I'm going to add a
recommendation that clients work through their cookies in FIFO order.
LIFO clients will tend to let all but one cookie sit around and
expire, resulting in the need to re-handshake the moment there's a
dropped packet.

The next issue we discovered was the most acute: Martin misunderstood
the requirement that cookies sent from server to client be encrypted
within the Authenticator and Encrypted Extensions EF, and was instead
sending them authenticated but unencrypted; he thought the fact that
they're already encrypted to the server's master key per section 7 was
sufficient to satisfy the requirement for encryption. Martin is
currently revising his implementation, and I'm figuring out how to
make the spec clearer on this point.

I think we'll have achieved full interop by the end of the day. From
there I could try hacking together a server implementation and testing
it against Martin's client, or we could just declare victory and the
rest of you can go tour London tomorrow while I finish the server on
my own time. Up to the rest of you.

---

From: Daniel Franke <[email-masked]>
Date: Sat, 17 Mar 2018 12:12:37 -0400

After Martin's fix for cookie encryption we appear to have achieved
interop. I'm now going to hack this client code into a little less of
a shambles and then get started on a server. Having this ready for
tomorrow is probably ambitious but I'll aim for before the end of the
summit.

---

From: [email-masked]
Date: Sat, 17 Mar 2018 18:35:34 +0100

Congratulations. 

do you think it make sense to be at the beginning of tomorrow's hackathon 
and then decide depending on the state of your implementation how to 
proceed?

Dieter

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Zeitverteilung mittels IP
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: [email-masked]

Von:    "Daniel Franke" <[email-masked]>
An:     [email-masked]
Datum:  17.03.2018 17:12
Betreff:        Re: [Ntp] NTS Hackathon minutes
Gesendet von:   "ntp" <[email-masked]>

> my own time. Up to the rest of you.

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Daniel Franke <[email-masked]>
Date: Sat, 17 Mar 2018 13:46:51 -0400

No, don't bother. I'm probably going to spend the next several hours
just wrestling with FFI stuff.

On Sat, Mar 17, 2018 at 1:35 PM,  <[email-masked]> wrote:
> ________________________________
>
>
>

---

From: Martin Langer <[email-masked]>
Date: Sat, 17 Mar 2018 18:43:27 +0000

hey Daniel,

I find out why the server got an error message at the end of the NTS KE.
Well, the server sends a 'close notify' after the transmission of the
application data (NTS records). In this way the server close immediate the
TLS connection. After receiving the messages your TLS client sends a 'close
notify' too. The server does not expect this message anymore and generate
the error message. Maybe we should define if the client send this message.
I think this is optional and the server can ignore this message.

This mail contains 2 files with TLS connections. One file shows the NTS KE
with my implementation and the second one is your implementation against
mine. You can open these files with wireshark.

Martin

---

From: Daniel Franke <[email-masked]>
Date: Sat, 17 Mar 2018 16:08:52 -0400

Thanks. I had just assumed this worked like TCP where each side sends
its own FIN. I'll dig in and figure out the Right Thing.

On Sat, Mar 17, 2018 at 2:43 PM, Martin Langer
<[email-masked]> wrote:
> the error message. Maybe we should define if the client send this message. I
> think this is optional and the server can ignore this message.
>

---

From: Daniel Franke <[email-masked]>
Date: Sat, 17 Mar 2018 16:24:03 -0400

Ah, so I actually assumed correctly. However, the SSL_shutdown() call
underlying the close notify alert has complicated semantics (see the
whole NOTES section of the manpage) and we're probably both misusing
it. I peeked at your code and looks like you're got ASIO as an
abstraction layer in front of this, and quite possibly a buggy
abstraction layer.

---

From: Martin Langer <[email-masked]>
Date: Sat, 17 Mar 2018 21:10:44 +0000 (GMT)

yes indeed,

Boost.ASIO needs a small workaround for this. Maye I find a better way.

Martin

---

From: Martin Langer <[email-masked]>
Date: Sun, 18 Mar 2018 10:44:14 +0000 (GMT)

Hi Daniel,

I updated my public NTS server for our tests and you can use nts1-e.ostfalia.de (141.41.241.68) for this purpose. You also can read the logs from the NTS server (http://nts1-e.ostfalia.de/homePi/SERVER/Logs/). Please let me know if you want to test the other direction.

Martin