Subject: [Ntp] TLS for NTS for NTP

From: Hal Murray <[email-masked]>
Date: Fri, 01 Sep 2017 03:12:55 -0700

I'm trying to understand the big picture.

The typical protocol flow for client/server says the client uses TCP to do a 
TLS handshake.  (It's about 1/3 of the way down on page 5 of draft 09.)

How complicated is that?  Remember that we have to do this without knowing 
the time.

I assume most implementations will be using some TLS package.  Can somebody 
give me a quick lesson in TLS?  Is there a solid package that runs on most 
OSes?  Is the API clean?  Can it handle the time-not-known case?  What else 
should I ask? ...

That paragraph says "only one round trip".  Is that after the TLS setup, or 
can it be piggybacked on TLS so that TLS+NTS is only one round trip?

TLS needs certificates.  Do we want to piggyback on the root certificates 
distributed with most OSes, or do we want the admin setting things up to 
provide certificates for the servers they select?

How much would already having the right certificates simplify the TLS code?

Is this going to work OK on IoT devices?

How about spares that have been sitting on the shelf for a long time?

-- 
These are my opinions.  I hate spam.

---

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

> give me a quick lesson in TLS?

This is not something I can really cover in a few paragraphs, but I
recommend Ivan Ristic's book.
https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

> Is there a solid package that runs on most OSes?  Is the API clean?

Yes. OpenSSL is the most widely used, but there are several dozen alternatives.

> Can it handle the time-not-known case?

The only place that TLS needs time is when checking whether the
presented X.509 certificate is expired. See section 9.2 about that.

> can it be piggybacked on TLS so that TLS+NTS is only one round trip?

It's after TLS setup, but with TLS False Start (RFC 7918) the first
part of the NTS-KE negotiation takes place in the same round trip as
the last part of the handshake. In sum it ends up looking like this:

Client: TCP SYN
Server: TCP SYN/ACK

(No server state required so far, if the server uses SYN cookies)

Client: TCP ACK, TLS ClientHello
Server: TLS ServerHello, TLS Certificate, TLS ServerKeyExchange, TLS
ServerHelloDone

(Server state required here)

Client: TLS ClientKeyExchange, TLS ChangeCipherSpec, TLS Finished,
NTS-KE request as TLS Application Data.
Server: TLS ChangeCipherSpec, TLS Finished, NTS-KE response

(Server discards state)

> provide certificates for the servers they select?

It certainly has to be configurable. Totally up to distro maintainers
what the default configuration is.

> How much would already having the right certificates simplify the TLS code?

Irrelevant, since nobody's going to be writing their own TLS stack
just to implement NTS. But OpenSSL's chain verification code is about
3KLOC.

> How about spares that have been sitting on the shelf for a long time?

There are lots of TLS implementations targeting embedded devices a lot
smaller than the chaps they're putting in most IoT gizmos. TLS has
been around since the 90s, and even notwithstanding hardware
improvements, the algorithms we've got now are a lot cheaper than the
ones we had then.

---

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

Client: TCP SYN
Server: TCP SYN/ACK

(Server discards state)

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